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

本文来自京东商城京麦平台组开发工程师曹德然的技术分享，感谢作者。

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消息订阅等项目实现了快速接入，并提供服务； 4）在MC系统搭建的过程中，全链路消息追踪、消息统计也得到了实现（在第五节消息监控会详细讲解）。

6、推送消息组装的统一配置化

▲  新京麦消息推送系统的消息组装处理逻辑图

消息过滤、消息组装、消息存储、消息推送是京麦消息中心的四大核心。消息组装是根据不同消息的不同配置来进行的，而这些配置是在开发侧的config配置中心来配置的，因此产品或者运营想从Anycall新接入一种系统消息所做的工作量是极其大的。

基于这个原因，我们将所有的配置环节统一到了一个页面。配置信息的获取添加三层缓存（Guava Cache+redis+DB）来应对海量调用。统一配置页面的存在使得业务类系统消息的接入变的简单快捷。

另一个比较大的优化是呼起协议配置化。之前消息的呼起协议是写死在消息体里面，极其的不灵活，甚至很多系统消息无法对接呼起协议直接将链接暴露在消息体里，用户的体验是很不好的。为此，呼起协议对接统一协议管理中心（后面文章会详细介绍），所有的呼起协议会根据消息里携带的protocolID从统一协议管理中心获取。呼起协议的中心化、配置化使得消息在系统流转的过程中不再需要关注具体的呼起协议，简化了消息在系统中的处理逻辑。而且协议中心化之后，协议的内容可以直接呈现给产品和运营，整个消息呼起的过程变得更加的清晰。

7、消息推送的触达（向客户端扩散）逻辑

▲  新京麦消息推送系统的消息触达逻辑图

京麦消息触达分为在线通知和离线通知：

1）在线通知是通过服务端和客户端的TCP长连接来实现的； 2）离线通知在最开始只有IOS的apns推送，Android系统无法很好的进行离线通知的推送一直是一大痛点。

针对Android系统无法很好的进行离线通知的推送的问题（俗称Android网络、进程保活黑科技这些东西，详见：《应用保活终极总结(一)：Android6.0以下的双进程守护保活实践》、《应用保活终极总结(二)：Android6.0及以上的保活实践(进程防杀篇)》、《应用保活终极总结(三)：Android6.0及以上的保活实践(被杀复活篇)》），我们开发了Android推送的开源包，对接了华为、小米、魅族三大厂商，实现了Android离线通知的推送。

8、完整的消息推送路径监控

▲  新京麦消息推送系统的消息监控逻辑图

全链路消息追踪系统，整合从消息源到最终的消息推送，整个链路各个节点消息的流转状况，并且异步化存储。从上图可以看到系统中的处理方式是，分别订阅JMQ的同一个topic实现将消息日志分别存储在ES和HBase，存ES保证了我可以在消息管理后台对所有消息进行清晰透明化的追踪查询，存HBase是为了可以将数据长久的保存并且进一步的分析。

消息统计是依托于京东大数据平台来实现的。将HBase里的数据导入到京东数据集市，从而对消息数据进行各个维度的统计分析。

9、本文小结

京麦实时消息推送架松经过一年的成长，在稳定、监控、内容丰富程度上有了长足的发展。下一步的规划是完整的消息失败重试机制、提高消息送达率、消息推送产品化等。

京麦是一个年轻且充满活力的团队，京麦消息系统伴随着京麦的成长，不断的完善优化。

附录：更多相关技术文章

[1] 有关推送技术的文章： 《iOS的推送服务APNs详解：设计思路、技术原理及缺陷等》 《信鸽团队原创：一起走过 iOS10 上消息推送(APNS)的坑》 《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》 《扫盲贴：认识MQTT通信协议》 《一个基于MQTT通信协议的完整Android推送Demo》 《IBM技术经理访谈：MQTT协议的制定历程、发展现状等》 《求教android消息推送：GCM、XMPP、MQTT三种方案的优劣》 《移动端实时消息推送技术浅析》 《扫盲贴：浅谈iOS和Android后台实时消息推送的原理和区别》 《绝对干货：基于Netty实现海量接入的推送服务技术要点》 《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》 《为何微信、QQ这样的IM工具不使用GCM服务推送消息？》 《极光推送系统大规模高并发架构的技术实践分享》 《从HTTP到MQTT：一个基于位置服务的APP数据通信实践概述》 《魅族2500万长连接的实时消息推送架构的技术实践分享》 《专访魅族架构师：海量长连接的实时消息推送系统的心得体会》 《深入的聊聊Android消息推送这件小事》 《基于WebSocket实现Hybrid移动应用的消息推送实践(含代码示例)》 《一个基于长连接的安全可扩展的订阅/推送服务实现思路》 《实践分享：如何构建一套高可用的移动端消息推送系统？》 《Go语言构建千万级在线的高并发消息推送系统实践(来自360公司)》 《腾讯信鸽技术分享：百亿级实时消息推送的实战经验》 《百万在线的美拍直播弹幕系统的实时推送技术实践之路》 《京东京麦商家开放平台的消息推送架构演进之路》 >> 更多同类文章 …… [2] 有关IM/推送的通信格式、协议的选择： 《简述传输层协议TCP和UDP的区别》 《为什么QQ用的是UDP协议而不是TCP协议？》 《移动端即时通讯协议选择：UDP还是TCP？》 《如何选择即时通讯应用的数据传输格式》 《强列建议将Protobuf作为你的即时通讯应用数据传输格式》 《全方位评测：Protobuf性能到底有没有比JSON快5倍？》 《移动端IM开发需要面对的技术问题（含通信协议选择）》 《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》 《理论联系实际：一套典型的IM通信协议设计详解》 《58到家实时消息系统的协议设计等技术实践分享》 《详解如何在NodeJS中使用Google的Protobuf》 《技术扫盲：新一代基于UDP的低延时网络传输层协议——QUIC详解》 >> 更多同类文章 …… [3] 有关IM/推送的心跳保活处理： 《应用保活终极总结(一)：Android6.0以下的双进程守护保活实践》 《应用保活终极总结(二)：Android6.0及以上的保活实践(进程防杀篇)》 《应用保活终极总结(三)：Android6.0及以上的保活实践(被杀复活篇)》 《Android进程保活详解：一篇文章解决你的所有疑问》 《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》 《深入的聊聊Android消息推送这件小事》 《为何基于TCP协议的移动端IM仍然需要心跳保活机制？》 《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》 《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》 《移动端IM实践：实现Android版微信的智能心跳机制》 《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》 >> 更多同类文章 …… [4] 有关即时通讯架构设计： 《浅谈IM系统的架构设计》 《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》 《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》 《一套原创分布式即时通讯(IM)系统理论架构方案》 《从零到卓越：京东客服即时通讯系统的技术架构演进历程》 《蘑菇街即时通讯/IM服务器开发之架构选择》 《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》 《微信后台基于时间序的海量数据冷热分级架构设计实践》 《微信技术总监谈架构：微信之道——大道至简(演讲全文)》 《如何解读《微信技术总监谈架构：微信之道——大道至简》》 《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》 《17年的实践：腾讯海量产品的技术方法论》 《移动端IM中大规模群消息的推送如何保证效率、实时性？》 《现代IM系统中聊天消息的同步和存储方案探讨》 >> 更多同类文章 …… [5] 开源移动端即时通讯技术框架资料： 《开源移动端IM技术框架MobileIMSDK：快速入门》 《开源移动端IM技术框架MobileIMSDK：常见问题解答》 《开源移动端IM技术框架MobileIMSDK：压力测试报告》 >> 更多同类文章 …… [6] 更多即时通讯技术好文分类： http://www.52im.net/forum.php?mod=collection&op=all

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