京东京麦商家开放平台的消息推送架构演进之路

1、前言

京麦实时消息推送是京东的京麦商家开放平台的核心组成部分。从消息源到消息中心再到触达用户，以及最终根据消息协议呼起操作页面，京麦实时消息推送是一个完整且健康的生态闭环。下面我会详细的介绍下京麦实时消息推送是如何在演变中不断完善的。

京麦消息框架示意图：

我将从京麦商家开放平台的消息接入、MC系统搭建、消息配置、消息触达、消息监控五个方面来阐述和分享京麦实时消息推送架构在2017年的成长。

即时通讯技术学习交流：

- 即时通讯开发交流群：215891622[推荐]

- 移动端IM开发推荐文章：《新手入门一篇就够：从零开发移动端IM》

(本文同步发布于：http://www.52im.net/thread-1321-1-1.html)

2、京东相关技术文章

《Netty干货分享：京东京麦的生产级TCP网关技术实践总结》

《从零到卓越：京东客服即时通讯系统的技术架构演进历程》

3、本文分享者

曹德然

2016年加入京东，目前就职于京东商城京麦平台组，从事京东商家开放平台的相关开发工作；

热爱技术，熟悉各种常用开源框架，有丰富的大型分布式系统、高并发系统的开发经验；

热衷于对大数据的研究，对Hadoop、HBase以及ES有深入研究和理解。

4、消息推送的接入

原有的消息推送接入存在的弊端主要有以下两点：

1)消息接入方式多样化：

京麦消息包含业务系统类消息、服务资讯类消息以及其他各类消息类型，消息来源多种多样。当时为了快速的接入各种消息源，提供了servlet接入、client接入、JMQ接入等，接入方式多样化，加上没有完善的监控系统，这样就导致了一个很尴尬的问题，我们自己都不清楚我们的消息系统到底接入了多少种类型的消息；

2)消息处理中心与消息源强依赖：

Anycall是系统消息的主要入口，从Anycall到原消息处理后台是通过servlet调用来实现的，系统间的耦合性太强。

我们后期针对新一代消息推送做的改善如下：

1)所有的系统消息统一由Anycall进行接入，清晰化消息类型边界；

2)京麦消息的接入方式统一：所有京麦消息统一通过JMQ异步化接入，并且根据不同业务通过不同的topic进行隔离，避免数据量大的业务(比如订单消息)对其他业务的阻塞；

3)麦圈的打造、咚咚离线消息的接入等项目的完成，使得京麦消息的生态不断丰富，同时也极大的增加了用户粘性。

5、MC(京麦消息推送中心)系统的搭建

▲ 原京麦消息推送系统的接入逻辑图

如上图所示，原先京麦消息推送的主要痛点如下：

1)接入方式不统一；

2)不稳定、大促被降级；

3)消息处理逻辑复杂，接入新的消息源困难；

4)没有完善的消息追踪，消息统计。

▲  新京麦消息推送系统的接入逻辑图

基于上述原因，重新打造了一个稳定、专一的消息处理中心——MC系统(如上图所示)：

1)统一的JMQ接入，在上一部分已经介绍过了；

2)MC系统与其他系统没有耦合，不在存在由于消息量过大对京麦其他业务造成影响的问题，实现了在大促时可以提供稳定的服务；

3)MC系统使用了broker分发的模式：模块化可插拔的处理方式，使得新消息源的接入变的极其简单，大大的缩短了开发的周期。正是这种broker分发模式的存在，咚咚离线消息、ISV消息订阅等项目实现了快