前言 京麦消息是京麦商家开放平台的核心组成部分。从消息源到消息中心再到触达用户,以及最终根据消息协议呼起操作页面,京麦消息是一个完整且健康的生态闭环。下面我会详细的介绍下京麦消息是如何在演变中不断完善的。 京麦消息框架 我将从消息接入、MC系统搭建、消息配置、消息触达、消息监控五个方面来阐述京麦消息在2017年的成长。 一、消息接入 原有消息接入存在的弊端主要有以下两点: 1、消息接入方式多样化。京麦消息包含业务系统类消息、服务资讯类消息以及其他各类消息类型,消息来源多种多样。当时为了快速的接入各种消息源,提供了servlet接入、client接入、JMQ接入等,接入方式多样化,加上没有完善的监控系统,这样就导致了一个很尴尬的问题,我们自己都不清楚我们的消息系统到底接入了多少种类型的消息。 2、消息处理中心与消息源强依赖。Anycall是系统消息的主要入口,从Anycall到原消息处理后台是通过servlet调用来实现的,系统间的耦合性太强。 消息接入做的改善: 1、所有的系统消息统一由Anycall进行接入,清晰化消息类型边界。 2、京麦消息的接入方式统一。所有京麦消息统一通过JMQ异步化接入,并且根据不同业务通过不同的topic进行隔离,避免数据量大的业务(比如订单消息)对其他业务的阻塞。 3、麦圈的打造、咚咚离线消息的接入等项目的完成,使得京麦消息的生态不断丰富,同时也极大的增加了用户粘性。 二、MC(京麦消息中心)系统的搭建 原来京麦消息的主要痛点: 1、接入方式不统一。 2、不稳定、大促被降级。 3、消息处理逻辑复杂,接入新的消息源困难。 4、没有完善的消息追踪,消息统计。 基于上述原因,重新打造了一个稳定、专一的消息处理中心——MC系统。 1、统一的JMQ接入,在上一部分已经介绍过了。 2、MC系统与其他系统没有耦合,不在存在由于消息量过大对京麦其他业务造成影响的问题,实现了在大促时可以提供稳定的服务。 3、MC系统使用了broker分发的模式。模块化可插拔的处理方式,使得新消息源的接入变的极其简单,大大的缩短了开发的周期。正是这种broker分发模式的存在,咚咚离线消息、ISV消息订阅等项目实现了快速接入,并提供服务。 4、在MC系统搭建的过程中,全链路消息追踪、消息统计也得到了实现(在第五节消息监控会详细讲解)。 三、消息配置 消息过滤、消息组装、消息存储、消息推送是京麦消息中心的四大核心。消息组装是根据不同消息的不同配置来进行的,而这些配置是在开发侧的config配置中心来配置的,因此产品或者运营想从Anycall新接入一种系统消息所做的工作量是极其大的。 基于这个原因,我们将所有的配置环节统一到了一个页面。配置信息的获取添加三层缓存(Guava Cache+redis+DB)来应对海量调用。统一配置页面的存在使得业务类系统消息的接入变的简单快捷。 另一个比较大的优化是呼起协议配置化。之前消息的呼起协议是写死在消息体里面,极其的不灵活,甚至很多系统消息无法对接呼起协议直接将链接暴露在消息体里,用户的体验是很不好的。为此,呼起协议对接统一协议管理中心(后面文章会详细介绍),所有的呼起协议会根据消息里携带的protocolID从统一协议管理中心获取。呼起协议的中心化、配置化使得消息在系统流转的过程中不再需要关注具体的呼起协议,简化了消息在系统中的处理逻辑。而且协议中心化之后,协议的内容可以直接呈现给产品和运营,整个消息呼起的过程变得更加的清晰。 四、消息触达 京麦消息触达分为在线通知和离线通知。 在线通知是通过服务端和客户端的TCP长连接来实现的。 离线通知在最开始只有IOS的apns推送,Android系统无法很好的进行离线通知的推送一直是一大痛点。 在这种情况下我们开发了Android推送的开源包,对接了华为、小米、魅族三大厂商,实现了Android离线通知的推送。 五、消息监控 全链路消息追踪系统,整合从消息源到最终的消息推送,整个链路各个节点消息的流转状况,并且异步化存储。从上图可以看到系统中的处理方式是,分别订阅JMQ的同一个topic实现将消息日志分别存储在ES和HBase,存ES保证了我可以在消息管理后台对所有消息进行清晰透明化的追踪查询,存HBase是为了可以将数据长久的保存并且进一步的分析。 消息统计是依托于京东大数据平台来实现的。将HBase里的数据导入到京东数据集市,从而对消息数据进行各个维度的统计分析。 总结 京麦消息经过一年是成长,在稳定、监控、内容丰富程度上有了长足的发展。下一步的规划是完整的消息失败重试机制、提高消息送达率、消息推送产品化等。 京麦是一个年轻且充满活力的团队,京麦消息系统伴随着京麦的成长,不断的完善优化。为用户提供更优质的服务是我们永远的追求。 本文受原创保护,未经作者授权,禁止转载。 linkedkeeper.com (文/曹德然) ©著作权归作者所有 |