严选消息中心管理平台建设实践

1. 引言​​

消息中心作为电商业务场景必不可少的核心组件，自严选上线以来，就开始了建设和演进迭代之路。截止目前，消息中心已接入200+服务，1500+消息，覆盖基础技术、供应链、分销客售、主站、交易订单、数据算法等严选所有业务场景。

本文对于消息中心的技术架构演进不做详细叙述，重点介绍面向业务使用方的消息中心管理平台建设实践经验。

2. 平台建设背景​

2.1 痛点问题

通过广泛沟通收集需求，在消息中心研发运维过程中，经常会碰到如下痛点问题：

• 影响研发效率：消息中心作为异步解耦的中间节点，串联上下游服务，系统链路较长，由于缺失完整的消息链路查询功能，当业务逻辑出现问题时，无论上下游服务都需要找消息中心开发排查问题，极大影响业务侧的研发效率，同时提高了消息中心运维成本。
• 无法感知异常：消息中心异步解耦了上下游服务，导致在一些业务场景生产方无法感知消费方的处理异常，被动靠业务反馈才能发现问题。
• 运维成本高：由于生产者或者消费者监控不足，需要依赖消息中心开发通知生产方发送消息失败，或者通知消费方消费消息失败或者消息积压等，很大程度上加大了消息中心的运维成本。

2.2 价值

定位和处理上面这些问题，通常会花费较长时间，极大影响研发效率，更严重的还会影响线上业务。因此，亟需一个面向业务开发的消息中心管理平台，提高研发效能：

• 提供完整的消息链路查询能力，方便业务接入方可自助式的快速定位排查问题；
• 提供消息链路数据的准实时统计分析能力，提升系统可观测性，方便业务方配置监控报警（消息延迟、消费异常）；
• 提供消息链路数据的离线统计分析能力，方便业务使用方和消息中心自身进行风险评估，提升系统稳定性；
• 提供初步的自动化运维能力，提升应急止损处理响应效率，降低人工运维成本。

2.3 目标

面向业务使用方：为了提升各位业务开发同学对各自负责系统的消息收发治理和问题排查定位的效率，建设严选消息中心管理平台，通过整合串联不同系统间的消息链路，统一并标准化定义消息链路的关键节点，基于元数据进行统计分析从而配置报警监控，最终达到整个严选技术体系降本增效的目的。同时，通过自动化工单闭环消息发布、下线、消息订阅、取消订阅完整生命周期管理，入驻严选DevOps管理平台天枢，将消息中心融入整个DevOps研发体系。

3. 平台建设方案​

3.1 整体思路

核心思路就是通过提升消息中心的可观测性，通过消息中心管理平台给用户提供可视化配置管理能力。一个好的可观测系统，最后要做到的形态就是实现Metrics、Tracing、Logging的融合：

• Tracing：提供了一个请求从接收到处理完毕整个生命周期的跟踪路径，通常请求都是在分布式的系统中处理，所以也叫做分布式链路追踪，消息中心场景就是完整的消息链路。
• Metrics：提供量化的系统内/外部各个维度的指标，消息中心场景就是发送耗时、消费耗时、端到端的延迟、消息积压等。
• Logging：提供系统/进程最精细化的信息，消息中心场景就是消息内容、消息发送者元数据信息、消息消费者元数据信息等。这三者在可观测性上缺一不可，基于Metrics的告警发现异常，通过Tracing定位问题模块，根据模块具体的Logging定位到错误根源，最后再基于这次问题排查经验调整Metrics告警阈值，达到预警效果。

在严选消息中心场景，在尽量复用现有组件能力的原则下，获取这三者数据的具体执行路径如下：

• Tracing：复用严选分布式链路追踪系统(APM)能力，消息中心接入caesar agent，将traceId和messageId等核心数据打印到业务日志。(消息中心的流量染色，压测标识透传也基于此思路)
• Metrics：复用严选实时计算平台能力，自定义flink任务，将日志平台采集的业务日志数据进行聚合计算，将实时指标数据存入网易时序数据库(Ntsdb)。同时也可按需在严选数仓配置T+1离线任务，进行相关指标数据计算采集。
• Logging：复用​严选日志平台能力​​，打印业务日志，进行采集、存储、查询。

3.2 概念定义

3.2.1 消息链路节点定义​

消息中心以HTTP Proxy的模式对外提供服务，业务方不感知底层消息中间件，提供HTTP异步方式的发布订阅功能。由如下三部分构成了消息中心：

• 生产者代理
• 消息中间件
• 消费者代理

完整的消息链路如下图所示：

节点定义如下：

3.2.2 用户视角定义

不同的用户视角关注的消息链路是不同的，用户只需聚焦于自己的对应的消息链路即可：

• 生产者：生产者服务 -> 生产者代理 -> 消息中间件
• 消费者：消费者代理 -> 消费者服务
• 全链路：生产者服务 -> 生产者代理 -> 消息中间件 -> 消费者代理 -> 消费者服务

3.3 数据流分层架构​

3.3.1 数据源

数据源主要是基于如下三部分日志，可串联整个消息链路：

• 应用业务日志：消息中心三个集群打印messageId、traceId以及对应链路节点的关键元数据信息。
• 应用访问日志：云外(/home/logs/consul-nginx/access.log)，云内(/home/logs/yanxuan-sidecar-envoy/access.log)，可获取推送到消息订阅方的上游节点信息，若是网关节点需再结合网关日志（仅采集消息中心服务实例上的日志）。
• 网关日志：根据网关日志获取到真正接收请求方的上游节点信息。​

3.3.2 数据采集层

复用日志平台现有功能，在日志平台配置业务日志采集任务，此处不详述。

3.3.3 数据分析层

按需在数仓平台配置T+1的离线分析任务，在严选实时计算平台配置运行自定义flink任务，聚合时间窗口可根据实际情况配置，主要指标如下：

• 生产者（topic+发送方）：

• 1d/1h/5min/1min 发送量
• 1d/1h/5min/1min 发送平均耗时
• 1d/1h/5min/1min 发送慢请求率/数
• 1d/1h/5min/1min 发送失败率/数

• 消费者（topic+订阅方）：

• 1d/1h/5min/1min 消费量

• 1d/1h/5min/1min 消费平均耗时

• 1d/1h/5min/1min 消费慢请求率/数

• 1d/1h/5min/1min 消费失败率/数

• 1d/1h/5min/1min 消费平均延迟

3.3.4 数据存储层

• 日志平台ES集群：用于消息链路实时查询，日志平台提供openapi接口给消息中心管理平台进行链路查询。
• HIVE：消息中心打印的业务日志通过日志平台的日志采集传输链路会存到数仓的hive表。
• NTSDB：经过流式计算生成的指标数据会存入网易时序数据库，供消息中心管理平台进行查询生成统计图表。
• 服务端DB：消息中心管理平台一些基础信息的维护与展示，比如监控报警配置、自助运维审计日志等。​

3.3.5 数据展示层

• 消息链路查询：支持traceId和messageId两个维度的查询。
• 数据统计分析：根据统计指标展示不同维度的图表。
• 自助化运维：可从生产者和消费者两个视角进行进行消息补推，并提供审计功能：

• 生产者：指定messageId、topic的生产状态等筛选条件将消息重新写入消息中间件（即推送所有订阅方）。
• 消费者：指定messageId、topic的消费状态等筛选条件将消息重新推到指定订阅方。

• 元数据管理：主要是topic的生产订阅关系的查询功能及拓扑展示、重试策略配置、报警配置等。

4. 平台功能​

4.1 消息链路查询

​支持如下两个维度的消息链路查询：

• 消息id(messageId)搜索：对应一条完整的消息链路（消息发送方确保消息id的唯一性）。
• 分布式链路(traceId)搜索：可能对应多条消息链路（消息发送方接入APM）。

提供拓扑和日志两种视图模式，供用户进行切换展示。​

• 拓扑视图：

• 日志视图：

拓扑视图下可点击查看消息内容、消费失败原因、发送耗时、消费耗时、端到端延迟。默认展示消息的所有消费者，用户可点击筛选只展示自己感兴趣的消费者消费链路。

• 查看消息内容：

• 查看失败原因：

4.2 数据统计分析

4.2.1 业务方使用视角

可筛选查看topic 【指定时间范围内 + 指定时间间隔】的聚合指标数据，相关统计图具体如下：

• 生产消费数量统计图：排查消息消费是否存在堆积。​

• 生产消费失败统计图：排查消息生产/消费是否存在异常。​

• 生产消费平均耗时统计图：排查生产/消费的性能（【平均】是指时间窗口的聚合指标数据）。​

• 消费平均延迟统计图：排查端到端的延迟（【平均】是指时间窗口的聚合指标数据）。​

• 消息数据平均大小统计图：查看消息网络传输包大小（【平均】是指时间窗口的聚合指标数据）。​

4.2.2 系统管理员视角

系统管理员不关注具体某个topic，而是关注消息中心集群的整体运行情况，相关统计图表具体如下：

• 消费订阅系统级延迟图：通过85线、95线、99线查看消息系统整体端到端的延迟情况。​

• 消息消费延迟最大值Top排行表：用于通知消息消费者对于消息时效性的逻辑处理优化。​

• 消息消费耗时最大值Top排行表：用于通知消息消费方进行消费逻辑的性能优化。​

• 发送消费统计图：用于统计消息量较大的消息。​

4.3 元数据管理

支持从消息主题、发布方、订阅方三个维度分页查询消息元数据信息，主要包括消息主题、发布方CMDB服务编码、订阅方CMDB服务编码、订阅url等相关配置，具体如下：

可点击消息详情，查看消息元数据、消息格式、消息示例信息，具体如下：

可点击消息拓扑查看图形化的发布订阅关系，具体如下：

可查看消息失败重试策略，工单申请调整重试策略，具体如下：

可查看报警配置，消息订阅方所属服务技术负责人可调整告警配置，主要分为两种类型的告警：

• 消息失败告警：达到失败重试次数的消息认为消费失败。
• 消息延迟告警：端到端的延迟告警，对于消息时效性敏感的消息可根据实际情况调整。

报警的指标数据是通过flink实时任务聚合采集存入Ntsdb，告警通知对接严选告警平台，告警接收人员即为线上服务所对应的线上监控人员角色。

4.4 自助运维

当消息中心上下游系统出现异常时，只要确保消息已成功投递到消息中心，消息中心可提供自助补推功能，来辅助业务快速恢复。支持根据消息id或者消息状态筛选查询指定时间范围内的消息，来决定是给消息的所有订阅者推送还是给某个订阅者推送。

消息推送对操作人进行严格的数据权限隔离：

• 如果要给消息的所有订阅者推送，则必须是所属消息服务的技术负责人，需要与涉及的所有订阅方技术负责人充分沟通，再进行推送。
• 如果要给消息的某个订阅者推送，则必须是该订阅者服务的技术负责人，操作人对此次操作负责。

消息补推属于高危操作，所有操作都会进行记录进行事后审计跟踪，并可查看每条推送记录的具体详情：

4.5 工单自动化审批

通过自动化工单闭环消息发布、下线、消息订阅、取消订阅完整生命周期管理，入驻严选DevOps管理平台天枢，有机的将消息中心融入整个DevOps研发体系。

同时将消息工单作为一个变更事件，基于天枢平台自动将测试环境的工单同步到线上。同时作为需求发布上线的风险变更管控卡点项，有效规避漏申请消息发布/订阅的情况而导致的业务异常。

5. 总结与展望​

5.1 总结

消息中心管理平台自上线以来，受到了不少业务方的好评，也广泛收集建议进行了一些功能迭代优化，初步达成了预期目标：

• 业务赋能：消息中心已接入200+服务，1500+消息，覆盖基础技术、供应链、分销客售、主站、交易订单、数据算法等严选所有业务场景。
• 运维成本大幅度降低：技术咨询数量从上线前周均50+，降低到目前周均小于10次。
• 研发效率逐步提升：业务方高效便捷的自行排查问题和自助补推消息，消息工单完结率提升到超过90%。

5.2 展望

消息中心管理平台下一步的重点方向是数字化建设，借鉴当前比较流行的FinOps执行路径：成本展示 -> 成本分析 -> 成本优化：

• 展示层面：当前消息中心管理平台虽然有不少统计图表，仅仅是基于topic视角或者系统管理员的全局视角，也收到不少业务方的反馈意见，如何从业务方视角更好地将数据聚合展示推送触达用户，是接下来要考虑的问题。
• 分析层面：目前仅仅是支持消息消费失败和消息消费延迟两类告警规则，进一步的数据分析和优化建议是缺失的，这也是业界普遍公认的技术难点，需要结合实际的业务场景进行分析。
• 优化层面：目前也仅仅是线下人工通知，比如基于消费最大耗时top排行榜提醒相关业务方进行消费逻辑优化，从消费最大延迟top排行榜通知业务方消费能力不足是否需要扩容。希望达到的效果是，管理平台基于数据分析生成优化建议，自动推送送给业务方，并将业务方的反馈和执行结果跟踪到底，达到全流程的自动化闭环。

当然，作为一个消息中心管理平台，对于底层消息中间件的运维、部署、监控也是必不可少的。当前在严选的落地实践是，广泛调研并引入开源组件EFAK、rocketmq-dashboard，二次开发接入严选监控告警体系，再结合严选OF监控，低成本、高效的解决了消息中间件集群及机器维度的运维监控管理问题。至于后续是否需要将这部分功能统一集成到消息中心管理平台，需要结合实际业务诉求和成本收益再进行决策。

6. 附录

• EFAK：https://github.com/smartloli/EFAK
• rocketmq-dashboard：https://github.com/apache/rocketmq-dashboard