消息订阅系统的演变过程

1      背景介绍

为了提高用户体验、数据分析统计，数据中转，各游戏也都有自己的消息中转订阅系统，其实现方式也各有千秋；

如下例场景需求

数据统计分析侧：XX统计系统订阅XX消息，收到事件时分析情况做统计和存储

用户体验侧：营销消息模块订阅XX事件，收到事件后将营销提示语反馈给游戏系统

营销活动侧：游戏时长达到一定时间后，给玩家发XX福利。当时长符合某种阀值后，需要给玩家一个提示。

于是，消息(或者事件)的生产者需要将消息分发给需要消化消息(或者事件)的消费者；

2      什么是SubscribeSvr

SubscribeSvr(SubscribeSvr)是一个事件转发服务器，用来接收事件发布者(游戏逻辑服务器)发布的事件，然后根据配置的订阅（Subscribe）策略，分发给订阅者(逻辑服务器)。

3      SubscribeSvr工作原理

SubscribeSvr收到的消息是从上游svr转发过来的玩家事件（Event），通过EventID区分，在消息定义结构体中对应m_shBehavior字段。

SubscribeSvr收到消息之后会先根据规则配置文件的策略判断某个事件需要转发给哪些FE，而这一过程是RTISvr转发给FE对应的ProxySvr，然后ProxySvr再将消息转发给相应的FE。

4      系统架构三次变迁

4.1   初始化架构

这个架构存在一个明显的问题，就是消息的生产者（游戏服务器）和消息的消费者（个人资料服务器、游戏商城服务器）存在逻辑的依赖关系，即消费者需要什么消息，生产者也要跟随变动，从而能够提供对应的消息。

l  存在问题

Ø  产品侧：漫长的大变更与短期的小需求的冲突；

Ø  项目管理侧：重版本与轻版本的冲突、协调；

Ø  技术侧：业务模块的耦合系数太高；

Ø  资源侧：开发资源、测试资源的投入；

Ø  风险侧：重版本与轻版本在平衡过程中容易出错；

由于在以前，相关涉及到此架的业务需求并不是很多。

4.2   第一版架构

游戏的爆发式增长，对架构提出了更多挑战。这种模式下的架构已经很不符合快速迭代的需求。

于是，中转订阅服务器SubscribeSvr应潮流而生。

       通过对关键和非关键业务解耦，稳定和非稳定业务解耦，使得消息的生产模块和消息的消费模块完全独立，降低后台业务模块的的耦合性，提高各个业务模块开发的效率和稳定性。

SubscribeSvr服务器的出现从逻辑上很好的解决了上一个版本存在的诸多问题。能够很好的满足业务需求，快速迭代进行开发。

但是，随着业务发展的需要，技术的不断变化发展，

1、消息的生产者模块不局限于游戏服务器，其他的服务器也可以作为消息生产者存在（比如任务成就系统服务器需要做任务进度的反向通知）；

2、接入层服务器、中转服务器透明化、云化升级，提高负载均衡、容灾的能力。

 

4.3   现在的架构

5       SubscribeSvr相关设计

5.1   事件级别转发

在XX后台系统中，消息的全量转发由中转服务器(ProxySvr)实现；

业务订阅针对玩家事件，SubscribeSvr根据事件订阅策略进行转发；

5.2  转发策略定制

业务SVR根据需要向SubscribeSvr订阅相关的玩家事件；

l  逻辑服务器配置：

隐去

l  订阅规则配置：

隐去

5.3   消息生产者和消费者自由接入

作为消息的生产者，只需要在中转服务器配置相应的策略，向SubscribeSvr转发对应的消息即可；

作为消息的消费者，只需要在SubscribeSvr配置相应的订阅策略，从SubscribeSvr接收对应的消息即可；