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

1、前言

1.jpeg (98.46 KB, 下载次数: 1079)

下载附件  保存到相册

6 年前 上传

2、京东相关技术文章

3、本文分享者

caoderan.jpg (46.35 KB, 下载次数: 1044)

下载附件  保存到相册

6 年前 上传

• 2016年加入京东，目前就职于京东商城京麦平台组，从事京东商家开放平台的相关开发工作；
• 热爱技术，熟悉各种常用开源框架，有丰富的大型分布式系统、高并发系统的开发经验；
• 热衷于对大数据的研究，对Hadoop、HBase以及ES有深入研究和理解。
  

4、消息推送的接入

• 1）消息接入方式多样化：
  京麦消息包含业务系统类消息、服务资讯类消息以及其他各类消息类型，消息来源多种多样。当时为了快速的接入各种消息源，提供了servlet接入、client接入、JMQ接入等，接入方式多样化，加上没有完善的监控系统，这样就导致了一个很尴尬的问题，我们自己都不清楚我们的消息系统到底接入了多少种类型的消息；
• 2）消息处理中心与消息源强依赖：
  Anycall是系统消息的主要入口，从Anycall到原消息处理后台是通过servlet调用来实现的，系统间的耦合性太强。
  

• 1）所有的系统消息统一由Anycall进行接入，清晰化消息类型边界；
• 2）京麦消息的接入方式统一：所有京麦消息统一通过JMQ异步化接入，并且根据不同业务通过不同的topic进行隔离，避免数据量大的业务（比如订单消息）对其他业务的阻塞；
• 3）麦圈的打造、咚咚离线消息的接入等项目的完成，使得京麦消息的生态不断丰富，同时也极大的增加了用户粘性。
  

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

3.jpg (38.93 KB, 下载次数: 1079)

下载附件  保存到相册

6 年前 上传

• 1）接入方式不统一；
• 2）不稳定、大促被降级；
• 3）消息处理逻辑复杂，接入新的消息源困难；
• 4）没有完善的消息追踪，消息统计。
  

4.jpg (64.72 KB, 下载次数: 1083)

下载附件  保存到相册

6 年前 上传

• 1）统一的JMQ接入，在上一部分已经介绍过了；
• 2）MC系统与其他系统没有耦合，不在存在由于消息量过大对京麦其他业务造成影响的问题，实现了在大促时可以提供稳定的服务；
• 3）MC系统使用了broker分发的模式：模块化可插拔的处理方式，使得新消息源的接入变的极其简单，大大的缩短了开发的周期。正是这种broker分发模式的存在，咚咚离线消息、ISV消息订阅等项目实现了快速接入，并提供服务；
• 4）在MC系统搭建的过程中，全链路消息追踪、消息统计也得到了实现（在第五节消息监控会详细讲解）。
  

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

5.jpg (70.74 KB, 下载次数: 1040)

下载附件  保存到相册

6 年前 上传

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

6.jpg (45.87 KB, 下载次数: 1032)

下载附件  保存到相册

6 年前 上传

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

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

7.jpg (82.31 KB, 下载次数: 1060)

下载附件  保存到相册

6 年前 上传

9、本文小结

附录：更多相关技术文章