消息处理子系统是通用平台为各业务系统提供两类消息处理功能，一类是针对单个客户端的消息推送功能，另一类是针对一个群发组的消息群发功能。这两类消息处理大同小异，只是处理系统的获取的映射数据不同，单个客户端消息处理需要获取客户端路由映射数据，群发消息处理需要获取是群发ID和代理服务的映射数据。除映射数据不同外，转发处理机制一致。消息处理子系统与平台其他构件配合运行示意图如下：
消息处理子系统与平台其他构件配合运行示意图
如上图所示消息处理子系统处于消息产生服务和通用代理之间，充当一次转发处理。其实质就是根据转发类型，将数据包转发至客户端所在通用代理，或是转发至群组所在的通用代理，由代理完成数据发送的最后一棒。了解了本模块构件功能，接下来看看从运行示意图中体现的运行机制。消息处理必要有用户路由数据或群组路由数据，这两类数据是构件正常工作的必要数据，该部分数据从数据子系统中获取，并实时同步。客户端路由数据和群组路由数据是由通用代理产生并注入数据子系统。考虑到通用代理规模和收纳链接效应，采用通信子系统解决该问题。实质上消息产生服务与消息处理构件之间也是通过通信子系统完成，示意图为了更直观展示省略该部分。以下讲述设计方面问题。
1. 为什么引入消息处理
消息处理子系统在常见系统架构较为少见，本人维护过得系统也同样如此，很多人感觉这也许是个过度设计的产物，我个人认为引入该子系统后，较大提升了通用平台的综合功能，使得平台具有一定的灵活性和更大潜力。首先该子系统能进一步简化业务服务处理逻辑提升业务服务性能，业务服务无需关注客户端路由信息，省略该部分数据同步处理，也省略了消息处理逻辑，将该部分逻辑扔给消息处理子系统，业务服务能更加专注自身业务处理，在业务服务规模越大，此功效越明显。其次提升了模块构件复用性，站在通用平台角度考虑整个平台支撑能力，可以发现提供单点发送和群组发送能力是绝大多数业务系统需要具备的常用功能，因此将该功能抽象出来尽量做到业务无关形成平台级模块构件，使得多业务线能共享使用该构件，很自然提升了构件复用性，节省了开发成本，同时也提升了系统健壮性。最后该构件可能为某些业务场景缩短数据链路，将传统的多级服务层次打破，数据延迟压缩到最小，为深层次业务服务提供一条直达客户端的快捷通道。
2. 使用场景
每一个构件都有一定的使用场景，否则可能会适得其反，同样的消息处理子系统也一样有适用场景。下面根据消息处理子系统的单点和群发两类型分别讲述。
（1）一般的单点消息适用在非原路返回的情况下。如A向业务服务发送数据，服务处理完毕后利用现有链路向A返回数据，该情况下不需要单点消息处理既能很好的达到目的。所谓非原路返回情况是如A向业务服务发送数据，服务处理完毕后需要向B用户发送数据，这时候现有链路很可能无法完成该需求，为了完成目标，迫使业务服务引入用户B的路由数据才能完成，该情况下使用单点消息处理就能很好完成该目标。同时还能使得业务服务无需关注用户路有数据，判断非原路返回后，仅需向消息子系统发送返回数据包即可。举个简单例子，IM系统中，用户A向用户B发送一条消息，此时就比较适合用到单点消息处理。
（2）群发功能，适用于业务服务在处理一个数据包需要广播给多个客户端情况。这时候业务服务可以利用通用代理提供的动态创建群发组和向群发组添加、删除用户等协议灵活的组建群发组，当处理到该类数据包时，业务服务无需多次发送数据包达到群发功能，而是只需要向消息处理子系统发送一条群发数据包既能达到群发目标。
3. 工作模式
消息处理子系统有两种工作模式可选，一种是完全的群集式，处理服务自身不含有路有数据，当有消息需要进行处理时，根据关键字即时向数据子系统获取路由数据，然后进行消息处理。第二种是半集群式，既处理服务自身含有路由数据并一直保持和数据子系统进行数据同步，有消息到来可直接进行消息处理。这两种模式各有利弊，第一种完全集群式好处是处理服务无路由数据能扁平化部署，负载均衡较为简单，但弊端是路由数据临时请求，消息延迟较大。第二种由于服务自身含有最新的路由数据，所以消息延迟低，但弊端就是负载均衡不太好处理。本通用平台考虑高性能低延迟角度出发，采用包含路由数据的消息处理子系统。
4. 负载均衡处理
本通用平台采用含有路由数据的消息处理，所以需要有一定的负载均衡处理才能规避路由数据达到一定程度后，消息处理单个服务无法承载路由数据问题。需要解决该问题，有两个较好的解决方案。第一是添加消息处理子系统的代理服务，消息直接发送至代理服务，代理服务含有各个消息处理服务的负责路由信息，可以将消息发送到能进行处理的服务上。优点是该解决方案透明性好，缺点是添加中间节点，延迟增高，同时添加了代理和处理服务之间的映射数据同步。第二解决方案是，消息处理子系统内部的消息处理服务按AppID散列开，各产品线将消息发送给同AppID的消息处理服务即可。优点是根据配置解决负载均衡同时也无需同步映射数据，缺点是业务服务需要关注消息处理服务的appid细节，同时因为有了appid的隔离，整个处理服务集群被分割成更小单位，不利于整体的负载均衡和单一进程利用最大化。添加新的appid时，需要配置相应的消息处理服务。本通用平台考虑第二种解决方案既能将延迟降至最低，同时也能兼顾一定的负载均衡处理，实现简单，但是实用。
消息处理子系统工作机制较为简单，仅需要从数据子系统拿到路由数据后，就可以为业务服务提供消息处理。该模块构件存在使得通用平台功能得到很大丰富和很好扩展，将该部分公共功能提取出来提升了模块构件的复用能力。但由于该类型模块构件较为少见，而本人也能力有限，难免存在种种疏漏，各位同行如在浏览过程中发现问题，请及时通知我修正，也可以发起讨论，共同发展，共同进步。
通用服务平台之总体架构设计
