随着分布式架构转型的推进，应用从单体架构逐步转向分布式、微服务化，与此同时越来越多的系统开始了异步化改造工作，这些转变带来了大量的进程间、系统间的消息服务需求。为了解决各系统对消息服务的分散建设带来的技术栈不统一、运行风险高、资源浪费等问题，G行结合业界技术发展趋势和行内MQ产品使用情况，于2020年启动了分布式消息平台建设项目，旨在为G行业务系统提供统一、可靠的企业级消息服务能力。
经过3年的建设工作，G行分布式消息平台（简称“平台”）已经成为应用系统分布式、微服务转型的关键支撑平台。平台以PaaS化服务模式向全行提供消息服务，其业务支撑范围覆盖了内部系统、关键业务系统以及核心类系统。本文主要对G行的分布式消息平台项目建设历程、关键设计以及其在行内的应用成效进行总结梳理，并结合建设过程总结了笔者对该平台类项目的建设思考。
平台建设：从架构设计、核心能力到周边能力建设
平台架构设计
G行分布式消息平台建设以高可靠和灵活扩展为原则进行平台架构设计，以提供丰富便捷的消息服务为目标进行核心功能建设，以高效运维为目标进行周边运维能力建设。
图1 分布式消息平台基础架构
分布式消息平台整体架构包括五部分：
- 消息引擎层：平台以开源RocketMQ为基础构建底层消息服务引擎，通过跨机房的主从交叉架构和兼顾性能与可靠性的刷盘策略配置保障了底层消息集群的可靠性；
- 代理层：平台引入代理层（Proxy）实现上层应用与底层消息引擎解耦，通过代理层的无状态设计实现了平台对外服务入口的灵活扩展；
- SDK层：平台开发了统一风格的SDK实现上层应用的敏捷接入，并通过SDK端与代理层的链接管理实现了代理故障的自动转移；
- Portal层：平台设计的统一管理台，管理平面实现对消息引擎和代理集群的统一配置管理，管理台为无状态设计可根据实际需求灵活扩展；
- 注册中心：基于Consul搭建的服务注册中心，用于服务端各组件的的信息发布和SDK的接入地址。
核心功能建设
图2 分布式消息平台核心功能
分布式消息平台对标当前主流消息队列产品，结合G行应用系统的实际使用需求进行核心功能设计与开发。平台发布了Java、Python、C三种语言SDK，支持同步发送、异步发送、OneWay发送、Push消费、Pull消费、BathPush消费等常用的消息收发接口，同时与G行自研开发框架Poin深度融合，为G行的基于不同开发语言、不同开发框架的各类应用系统的接入提供了可选方案与便捷性。
在消息类型上，平台除了支持普通消息，还支持顺序消息、延迟消息、事务消息、过期消息等消息类型，满足了G行应用系统对消息队列复杂场景的使用需求；在资源管理上，平台设计了主题权限共享功能，实现了不同租户对同一主题资源的共同使用，为业务系统间的消息流转提供了便捷；在监控指标上，平台设计了死信消息计数、消息积压数量、消息积压时长等统计指标，通过提供丰富的运行统计指标实现对生产运行状态的实时监控，保障业务系统的稳定运行。
周边运维能力建设
图3 消息轨迹查询功能示例
- 消息轨迹查询：该功能支持贯穿生产者客户端-生产者代理层-消息集群-消费者代理-消费者客户端的全链路消息轨迹查询，使得业务系统能够准确定位故障原因。
- 流量摘取：平台通过对主题/订阅组的权限控制实现了故障场景下对业务流量进行拦截，避免对平台消息服务或应用系统的消费服务造成流量冲击。
- 消息回溯：平台通过对消费位点的管理，使业务系统能够根据需要回溯到特定的消费位点，以确保消费时机的准确性。
- 死信重发：平台为应用系统的死信消息提供了一键式批量重发的能力，大大简化了死信消息处理的流程，提升了处理效率。
关键设计：代理层引入与单元化部署架构
图4 代理层的引入
纵观G行分布式消息平台的建设，代理层的引入降低了上层应用和底层消息服务间的耦合度，而单元化的部署架构也实现了AZ级的流量收敛，本章节对分布式消息平台的这两项关键设计进行简单的介绍。
实现应用与消息解耦的代理层
代理层的引入主要是为了实现上层应用于底层消息引擎的解耦，从而实现底层消息服务对上层应用的透明。其中生产者代理负责将生产者客户端发送的消息转发给后端的消息集群，消费者代理则负责从消息集群拉取消息转发给消费者客户端。而随着代理层的引入，消息平台将更多扩展能力集成在代理层，使得底层消息集群更纯粹的承载消息服务、前端SDK更简单地承载消息收发服务。
代理层的引入还带来了以下优势：
- 能力扩展：代理层为平台的扩展能力建设提供了更大的空间，通过代理层实现了对SDK租户权限控制、流量控制、链接管理、负载策略自定义等原生SDK不具备的功能。
- 负载前移：将消息集群的部分功能（鉴权、流控、队列路由等）前移至代理层，降低了底层消息集群的负载，使得消息集群更纯粹的负载消息的收发和存储。
- 容量扩展：代理层的存在屏蔽了客户端与底层消息队列的直接连接，从而破除了原生消息队列对Consumer客户端数量的限制，支持更多的客户端接入。
- 多形态接入的可能：由于SDK只需要与代理层进行交互，不再需要依赖底层消息集群的服务接口，因此多语言SDK的开发只需要实现与代理层的叫交互即可。
流量收敛的单元化部署架构
随着分布式架构的转型，单元化架构成为应用系统进行架构设计的重要选择之一，为了更好的支撑应用架构部署需求，分布式消息平台支持了单元化部署架构，实现了业务消息在AZ级别的流量收敛。
图5 分布式消息平台单元化部署架构
在单元化部署架构下，应用通过网关进行流量切分后通过各自AZ内的客户端进行消息收发，分布式消息平台保障生产的消息被AZ内的客户端消费，实现业务流量的AZ级收敛，屏蔽了正常业务场景下跨AZ的消息服务调用。该架构的实现主要包含以下三个部分。
- SDK与代理层贴源：通过在SDK端携带AZ标识，客户端在本地选择代理时实现优先选择本AZ的代理节点。
- 生产者代理到RocketMQ贴源：生产者代理节点会维护所有Broker节点的配置信息和AZ信息，收到SDK请求后会解析请求中AZ标识，并在向后端RMQ转发时优先转发到具有相同AZ标识的Broker节点。
- RocketMQ到消费者代理贴源：消息平台修改了原生RocketMQ的ReblanceImpl实现类，从而使得消费者代理可以缓存AZ单元信息和Broker的AZ配置；消费者代理在创建连接消息集群的RMQConsumer实例时会在实例信息中附带AZ单元标识，实现了在队列Reblance时将AZ1的所有队列负载给带有AZ1标识的RMQConsumer实例。
应用成效：提供企业级服务能力的消息平台
图6 行内生态数据流转中心
分布式消息平台建设以来，随着消息功能的完善和周边运维能力的建设，越来越多的应用系统依赖消息平台实现异步通信需求，截至目前生产环境已接入业务系统35个，日消息量3900W。
应用成效一：行内生态数据的流转中心
为规范科技治理，G行设计了服务管理系统、架构管理系统、电子审批系统、安全溯源系统等对各领域的科技工作进行细致管理，然而在这些系统之间经常存在如人员变更、需求发布、系统架构、缺陷管理等信息的交互，在以往架构中，信息的发布方需要通过接口的方式将对应的信息发布给所有需要更新该内容的下游系统，不仅存在大量的接口对接问题，同一份信息也需要发布多次。
分布式消息平台的使用则为行内这些科技生态数据的流转提供了便利，在分布式消息平台的支持下，各业务系统仅需将信息发布到分布式消息平台，由各下游系统自行从平台订阅即可，这种消息流转方式一方面使得发布方仅需要关注信息到消息平台是否发布成功，无需关注下游系统对该信息的接收过程，另一方面各业务系统也仅需要关注与消息平台的交互接口，大幅提高了开发效率。
应用成效二：核心类应用的异步通信平台
在金融行业，核心级别应用的接入和使用是检验自研产品/平台能力的关键。G行分布式消息平台自建设以来，大部分功能点和运维能力的建设更是围绕G行新核心的建设需求展开的。目前G行分布式消息平台已在信用卡新核心投产上线，支持卡核心异步通信需求，业务类型上包括了交易流水、动账通知、数据同步等多类型业务场景。
图7 消息平台在新一代分布式核心的功能支撑
后续G行分布式消息平台将持续应用于总行新一代分布式核心系统，作为关键的异步通信平台，承担系统内交易流水、会记分录、报文异步登记等功能，以及核心系统与外围系统的动账通知等功能。
建设思考：平台自身能力建设与对外服务水平建设
G行分布式消息平台项目建设迄今为止已3年有余，笔者有幸从项目立项之初便参与到平台的设计中，并参与了平台的全过程建设，然而随着接入系统的不断增多、接入系统重要性的不断提高，笔者注意到在平台建设过程中除了自身功能性硬实力的不断增强外，平台对外服务水平这一软实力也越来越多地影响着平台的发展。
平台自身能力可靠是平台“能用”的基础保障。在项目建设之初应当对平台的建设目标有明确的定位、对平台的核心支持能力有清晰的认知，在建设的过程中要首先保障平台核心支持能力的可靠性，并依托核心能力不断进行功能扩展，核心功能的不可或缺性是任何一个企业级服务平台的建设根本。
平台周边功能丰富是平台“好用”的强大助力。对于分布式消息平台的建设，除了核心的各类型消息收发能力之外，周边能力如监控告警配置、故障排查工具、应急处置工具以及异常场景下的服务保障机制都是平台能够在各应用系统稳定运行中切实发挥作用的强大工具。
平台对外服务便捷是平台“易用”的第一印象。如果说自身能力的可靠和周边功能的丰富是平台的硬实力，那么对外服务的便捷性则是平台在推广使用过程中的软实力。在平台建设和推广使用的过程中，项目经理应当适当的把自己从平台建设本身中剥离出来，以一个产品经理的角色、站在用户的角度思考平台应当提供的附加能力。对于分布式消息平台，接入流程是否便捷、用户界面是否友好、说明文档是否完善、SDK调用是否简洁、生产配置是否灵活、版本更新是否及时等都是用户在首次接触消息平台时非常关心的问题。
