背景概述
用户成长体系通俗的来讲就是会员经验金币系统，通过量化的方式来衡量用户对平台的忠诚度、共享度等，同时提供一系列的激励机制，刺激用户留在平台上。简单来讲，成长体系的作用就是“获客”、“活客”。
对于用户来说，一个好的用户成长体系能够提升用户的主动活跃，用户也可以从体系中获得成就感、特权等利益。比如京东的京豆可以用来抵扣下次消费，QQ超级会员能让用户享受不一定的尊贵体验。
对于平台来说，通过用户成长体系可以了解用户对产品的使用情况，有助于了解用户的组成情况，可以作为后面精细化运营的基础。同时，成长体系有利于提高用户粘性和忠诚度，引导用户产出UGC内容，促成用户评论、消费、拉新等行为。
用户成长体系不论对于用户还是平台来说，都是双赢的结果。
系统设计
用户成长体系通常由经验、金币、成就三部分构成。营销中台作为成长体系的基础服务，为成长体系提供活动、权益、数据服务等基础能力的支撑。
经验体系：包含经验与等级相关的所有功能。经验管理，配置经验发放的规则，如什么事件发放多少经验；等级管理，配置等级的规则，如共有多少个等级，每个等级需要多少经验，每个等级如何展示（头像变化、皇冠）等；特权管理，配置每个特权相关的内容，以及每个特权对应的权益与用户等级，如L3用户可享受5折机票优惠等。
成就体系：主要配置成就相关的规则，如用户做什么操作可以获得什么成就。成就与经验和等级没有直接的关系。
金币体系：在系统内可以流通、兑换权益的物品，都可以纳入金币体系，如金币、钻石、积分、点券等。兑换管理，配置金币的价值，即多少金币可以兑换什么权益；金币清算与金币对账，要保证金币与权益、商品的一致性，否则可能引起权益方面的挂账；金币商城，用于金币兑换实际物品或权益。
成长体系中经验、金币、成就等的计算过程，是由其它业务系统的消息来触发的，如用户转发、评论某篇文章，收藏了某个商品，支付了某个订单等动作。成长体系收到消息后，根据规则进行计算，给用户相应的奖励。这个过程通常是以异步的方式去实现，成长体系的处理失败不应引起业务操作的失败，因此消息队列是不二的选择。对于没有企业级通用异步总线的系统，可以通过一个proxy代理模块，将联机调用转换为内部的异步调用，使计算过程与业务调用解耦（笔者所在项目没有通用的异步通讯总线，因此采用这种模式）。架构图如下所示：
User-service负责提供对客户端的查询服务，如用户已有的经验金币成就值、获取金币成就的规则等。Admin-service负责提供业务人员的管理服务，业务人员可依据运营需求及时调整金币发放等规则。Compute-service是计算引擎，也是用户成长体系的核心，它从kafka中获取用户的业务操作，计算应给用户发放的奖励。
下面主要针对Compute-service做详细的说明。
Compute-service的实现
Compute-service不仅靠kafka的消息事件来驱动，其内部也是利用spring事件驱动模型实现的。
Spring事件驱动模型
本文仅针对spring的事件驱动模型做简单的介绍，更深入的说明及用法请读者自行了解。
想要使用Spring的事件模型，需要了解以下几个类：
ApplicationEvent
事件本身，继承自Java EventObject。
ApplicationListener
监听者对象，能够选择监听不同的事件Event，并执行相应的操作。
ApplicationEventPublisher
事件的发布者，通过ApplicationEventPublisher#publishEvent的方法进行事件的广播。
具体用法如下：
定义事件类型Event
定义事件监听器
发布事件
以上3步即可完成事件驱动业务代码的编写，spring会根据发布的事件类型，找到相应的事件监听器，执行onApplicationEvent()方法。
Compute-service的内部流程图如下：
图中成就、权益相关的处理流程与经验和金币类似，不再详细画出。
从kafka中获取消息后的处理流程如下：
为防止消息重复消费，必须要保证消息处理的幂等性，即同一个消息至多消费一次。每个消息都由生产者生成一个唯一标识，消费者在消费时，将userId+唯一标识作为key存入redis，并设置过期时间为24小时（即24内没有重复消息，即可认为没有重复消息产生，过期时间可依据实际业务情况调整）。消费者接收到新的消息时，到redis里查下是否存在相应的key，若存在，即是重复消息，直接拒绝即可。
由规则选择器判定是否需要产生spring事件。规则选择器是我们定义的接口，match方法用于匹配规则，message是业务系统发来的消息内容，assemblyEvent方法用于组装event事件。如下：
具体用法举例，我们定义了日常任务，用户每天可通过阅读文章来获得经验值。这样就可以定义一个DailyTaskRuleSelector，match方法的实现为从数据库中检索，阅读文章是否在日常任务的列表中，在的话即发布一个经验事件。
发布事件的代码如下：
3. Spring事件驱动机制会自动根据事件类型，执行相应监听器的业务逻辑。
在实际业务处理过程中，经验与金币等并不是完全独立的，会有一定的相互作用。如在用户累加经验触发用户等级的提升时，通常会给用户奖励一些金币，或者发放一些权益。
这种情况下，为保证职责分离，维护代码的简洁性，不能在经验事件监听器中去做金币和权益的处理逻辑。可以有以下两种做法：
在经验的处理过程中，如果用户升级则发布一条用户升级事件，有专门的升级事件处理器去处理用户升级所带来的奖励。这种做法需要升级处理器了解金币和权益在用户升级过程中的处理细节，会破坏代码的独立性。在业务规则相对复杂的情况下，不建议使用该做法。
在经验处理器中，用户升级后，查询对应的等级有无金币奖励，若有，则发布金币事件，事件内容为用户升级，由金币处理器依据事件内容做详细的处理。权益发放也是如此。此做法会使经验处理器中包含一部分金币与权益规则判定的内容，但由于通常判定奖励规则的有无比较简单，可以放在经验处理器中；而规则的具体执行与检查逻辑相对复杂，需要相应的选择器去执行，如金币是否超上限、同一种权益是否重复发放等。笔者所在的项目就是采用该做法。
如何扩展
实际场景中，随着产品的迭代，业务规则会越来越复杂，功能也在不断的增加，对代码的可维护性和可扩展性提出了较高的要求。基于此事件驱动设计的架构，可通过增加规则选择器RuleSeletor和事件处理器EventListener，即可实现对新的业务功能的支持，原有功能及代码无需改动。
有些公司会基于成本、复用等方面的考虑，要求用户成长体系同时支持多条业务线的发展。但每条业务线上的经验、金币等规则各不相同，不能因为软件产品的复用而要求业务规则统一。
此时可通过kafka的topic区分不同的业务线，每一条业务线单独配备一套用户成长体系集群，每个集群的规则单独配置，互不影响，如下图：
总结
用户成长体系是“获客”、“活客”的重要手段，通常由经验、金币、成就三部分构成。
用户成长体系应与业务系统解耦，通过消息队列实现异步通讯，通过消息对列的发布/订阅机制和spring的事件驱动模型，实现整个系统的事件驱动设计。
系统内部各模块之间的关联，也是通过事件触发，减少模块之间的直接依赖，提高代码的简洁性。
可通过扩展系统内部spring的事件类型与处理器实现业务功能的扩展；也可通过对kafka的topic的拓展，以同时支持多个业务线的发展。
欢迎关注公众号：程序员顺仔，回复【资料】，即可获得多本架构进阶电子书籍。
