zoukankan      html  css  js  c++  java
  • 京东京麦商家开放平台的消息推送架构演进之路

    1、前言

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

    京麦消息框架示意图:

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

    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消息订阅实现了快速服务。并提供服务。

    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、本文小结

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

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

  • 相关阅读:
    day113-django-Form组件常用字段和参数
    day112-django-Form组件-ajax提交给后台的Form验证
    day110-django-中间件和(socket:wsgiref、uwsgi)
    day111-django-初识Form组件(验证登录信息)
    day109-django-多对多、session保存用户信息到数据库和从数据库获取用户信息
    day108-django-路由分发、动态路由、伪静态、根据名称反向生成url
    软件测试基础
    Python并发编程之:多进程
    进程介绍(理论部分)
    网络编程
  • 原文地址:https://www.cnblogs.com/jacksonxiao/p/8269453.html
Copyright © 2011-2022 走看看