亿级流量架构演进实战 —— 架构演进重构消息PUSH系统 05
这不是一个讲概念的专栏，而且我也不擅长讲概念，每一篇文章都是一个故事，我希望你可以通过这些故事了解我当时在实际工作中遇到问题和背后的思考，架构设计是种经验，我有幸参与到多个亿级系统的架构设计中，有所收获的同时也希望把这些收获分享与大家。
承接上篇，客户端通过调用 API 网关获取数据，但实时数据的获取，如果通过轮询网关，大量空转不仅非常的低效且浪费服务器资源。基于此，实现了一种消息推送技术，提供一个实时的、可靠的、异步的双向数据交换通道，提升 API 网关性能。
消息平台既负责消息的接入，又负责消息的推送。为了支持多数据源的高性能消息推送，消息整体架构的改造包括以下几点：
一、解耦消息接入层和消息推送层，消息接入层只负责 Request-Response 和 Notice-Repley，而消息解析、适配、推送等逻辑处理都全部由消息推送层处理，而消息接入层和消息推送层之间则有消息队列异步进行通信。
二、消息存储由原来的半推半拉改为半推半查，即消息只推送通知，所以消息实体存储在云端。采用 ElasticSearch 作为消息搜索引擎，通过 Routing 实现靠性能查询。
三、优化推送方式，将 TCP 通知由异步改同步，计算消息送到率。
如下图所示：
随着逐步对 NIO 的深入学习和对 Netty 框架的了解，采用 NIO 技术应用消息推送系统中，HTTP 长连接采用 Servlet 3 的特性，TCP 长连接采用了 Netty 4 框架，最终在2017年实现，并完全支撑业务化运行。
1。消息接入
首先，原来消息接入的痛点主要有接入方式不统一、推送不稳定、大促被降级、消息处理逻辑复杂、接入新的消息源困难、没有完善的消息追踪、消息统计等。
基于上述原因，重构优化实现了统一的消息接入；解决消息量过大对系统造成的积压问题；使用了管道分发的模式和模块化可插拔的处理方式，使消息源的接入变的极其简单，大大的缩短了开发的周期；实现全链路消息追踪和统计。
配置中心
另一个比较大的优化是呼起协议配置化，之前消息的呼起协议是写死在消息体里面，极其的不灵活，甚至很多系统消息无法对接呼起协议直接将链接暴露在消息体里，用户的体验是很不好的。为此，呼起协议对接统一协议管理中心，所有的呼起协议会根据消息里携带的 protocolID 从统一协议管理中心获取。呼起协议的中心化、配置化使得消息在系统流转的过程中不再需要关注具体的呼起协议，简化了消息在系统中的处理逻辑。而且协议中心化之后，协议的内容可以直接呈现给产品和运营，整个消息呼起的过程变得更加的清晰。
This chapter requires login to view full content. You are viewing a preview.
Login to View Full ContentCourse Curriculum
2013 京麦平台
2016 京东开放平台
2018 京东服务市场
2019 阿里云通信
2025 阿里云飞天实验室
Speaker
