作为电商业务场景必不可少的核心组成部分，新闻中心自严选上线以来就开始了建设和演进迭代。截至目前，消息中心已接入200+服务、1500+条消息，涵盖基础技术、供应链、分销、客户销售、主站、交易订单、数据算法等所有业务场景。本文不详细描述消息中心技术架构的演进过程，而是着重介绍为企业用户搭建消息中心管理平台的实践经验。1.简介作为电商业务场景必不可少的核心组件，消息中心自严选上线以来就开始了建设和演进。截至目前，消息中心已接入200+服务、1500+条消息，涵盖基础技术、供应链、分销、客户销售、主站、交易订单、数据算法等所有业务场景。本文不详细描述消息中心技术架构的演进过程，而是着重介绍为企业用户搭建消息中心管理平台的实践经验。2.平台建设背景2.1痛点通过广泛沟通收集需求，在消息中心的研发和运营过程中，经常会遇到以下痛点：影响研发效率：消息中心作为异步的中间节点解耦，串联上下游服务，系统链路长，由于缺少完整的消息链接查询功能，当业务逻辑出现问题时，上下游服务都需要找到消息中心来解决开发排查问题，极大影响业务方研发效率，提高消息中心运维成本。无法感知异常：消息中心异步解耦上下游服务，导致生产者在某些业务场景下无法感知消费者的处理异常，只能依靠业务反馈来发现问题。运维成本高：由于对生产者或消费者的监控不够，需要依赖消息中心的开发，通知生产者发送消息失败，或通知消费者消费消息失败或消息积压等，大大增加了消息中心的运维成本。2.2价值定位和处理上述问题通常耗时较长，极大地影响了研发效率，更严重的影响了线上业务。因此，迫切需要一个面向业务开发的消息中心管理平台，以提高研发效率：提供完整的消息链接查询能力，方便业务接入，以自助方式快速定位和排查问题；提供消息链路数据准实时统计分析能力，提高系统可观测性，方便业务方配置监控告警（消息延迟、异常消费）；提供消息链路数据的离线统计分析能力，方便业务用户和消息中心自行进行风险评估，提高系统稳定性；提供初步的自动化运维能力，提高紧急止损处理的响应效率，减少人工操作和处理维修费用。2.3面向业务用户：为了提高业务开发同学在各自负责系统的消息收发管理和问题排查定位中的效率，搭建严选消息中心管理平台，消息链接不同系统之间进行集成和连接，统一和规范定义消息链路的关键节??点，基于元数据进行统计分析配置告警监控，最终达到整个严选技术系统降本增效的目的。同时，通过自动化工单闭环消息发布、下线、消息订阅、取消订阅的完整生命周期管理，入驻DevOps管理平台天枢，将消息中心融入整个DevOps研发体系.3.平台建设方案3.1总体思路核心思路是通过提高消息中心的可观察性，通过消息中心管理平台为用户提供可视化的配置管理能力。一个好的可观察系统的最终形态是实现Metrics、Tracing和Logging的集成：Tracing：提供一个请求从接收到处理的整个生命周期的跟踪路径。通常，请求是在一个分布式系统中集中处理的，所以也叫分布式链路跟踪，消息中心场景就是一条完整的消息链路。Metrics：提供系统内外各个维度的量化指标。消息中心场景发送耗时、消费时间、端到端延时、消息积压等。日志记录：提供系统/进程最细化的信息。消息中心场景就是消息内容、消息发送者元数据信息、消息消费者元数据信息等，这三者在可观察性上缺一不可。基于指标警报检测异常。通过Tracing定位问题模块，根据模块具体的Logging定位错误源。最后根据该问题排查经验调整Metrics告警阈值，实现预警。影响。在严选消息中心场景下，在尽可能复用现有组件能力的原则下，获取三者数据的具体执行路径如下：Tracing：复用严选分布式链路跟踪系统（APM）进入凯撒agent，将traceId、messageId等核心数据打印到业务日志中。（消息中心的流染色和压测logo的透传也是基于这个思路）Metrics：复用实时计算平台的能力，自定义flink任务，聚合计算采集到的业务日志数据通过日志平台，存储实时指标数据进入网易时序数据库（Ntsdb）。同时，严选数据仓库也可以根据需要配置T+1离线任务，计算采集相关指标数据。日志记录：复用严选日志平台的能力，打印业务日志，收集、存储、查询。3.2概念定义3.2.1消息链接节点定义消息中心以HTTPProxy方式对外提供服务。业务端不感知底层消息中间件，提供HTTP异步发布订阅功能。消息中心由以下三部分组成：produceragent消息中间件consumeragent完整的消息链接如下图所示：节点定义如下：nodecode节点描述message_received_successproduceragentsuccessfullyreceivedmessagemessage_received_failedproduceragentreceived消息失败，通常是非法数据等异常mq_received_success消息中间件写入消息成功mq_received_failed消息中间件写入消息失败consume_failed消费代理推送消息给订阅者失败failover_retry消费代理失败重试场景从消息中间件成功拉取消息retry_failed消费代理消息失败重试场景推送消息给订阅者再次失败meet_max_retry_times消费者代理消息失败重试场景达到最大失败次数，不会转发over_duration_time消费者代理消息失败重试场景3.2.2用户视角定义不同的用户视角关注不同的消息链接，用户只需要关注自己对应的消息链接：生产者：生产者服务->生产者代理->消息中间件consumer：consumeragent->consumerservice全链路：producerservice->Produceragent->消息中间件->Consumeragent->Consumerservice3.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+sender）：1d/1h/5min/1min发送量1d/1h/5min/1min平均发送时间1d/1h/5min/1min发送慢请求率/个数1d/1h/5min/1min发送失败率/个数消费者（主题+订阅者）：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：流计算产生的指标数据将存储在网易时序数据库中，供消息中心管理平台查询和生成统计图表。ServerDB：维护和展示消息中心管理平台的一些基本信息，如监控告警配置、自助运维审计日志等。3.3.5数据展示层消息链路查询：支持traceId和messageId二维查询。数据统计分析：根据统计指标展示不同维度的图表。自助运维：可以从生产者和消费者的角度进行消息补推，提供审计功能：，推送所有订阅者）。Consumer：指定messageId、topic消费状态等过滤条件，将消息重新推送给指定的订阅者。元数据管理：主要是topic生产订阅关系的查询功能、拓扑展示、重试策略配置、告警配置等。4.平台功能4.1消息链接查询支持以下两个维度的消息链接查询：消息id（messageId）search：对应一个完整的消息链接（消息发送者保证消息id的唯一性）。分布式链接（traceId）搜索：可能对应多个消息链接（消息发送者访问APM）。提供拓扑和日志两种查看方式，供用户切换显示。拓扑视图：日志视图：在拓扑视图中，您可以点击查看消息内容、消费失败原因、发送时间、消费时间、端到端延迟。默认情况下，显示消息的所有消费者。用户可以点击过滤，只显示自己感兴趣的消费者的消费链接查看消息内容：查看失败原因：4.2数据统计分析4.2.1业务方可以过滤查看话题的聚合指标数据[指定时间范围内+指定时间间隔内]使用透视图。相关统计图表如下：生产消费统计图表：检查消息消费是否有累积。生产消费故障统计：查看消息生产/消费是否有异常。生产消费平均耗时统计：查看生产/消费的表现（【平均】是指时间窗口的聚合指标数据）。消费平均时延统计：查看端到端时延（[average]指的是时间窗口内聚合的指标数据）。消息数据平均大小统计图表：查看消息网络传输数据包大小（[平均值]指时间窗口的聚合指标数据）。4.2.2系统管理员视角系统管理员关注的不是某个具体的话题，而是关注消息中心集群的整体运行情况。相关统计图表如下：消费订阅系统级时延图：通过第85、95、99行查看消息系统在线整体端到端时延。消息消费延迟最大值排行榜：用于通知消息消费者优化消息时效性的逻辑处理。消息消费最大耗时排行榜：用于通知消息消费者优化消费逻辑的性能。发送消费统计图：用于统计消息量大的消息。4.3元数据管理支持从消息主题、发布者、订阅者三个维度逐页查询消息元数据信息，主要包括消息主题、发布者CMDB服务代码、订阅者CMDB服务代码、订阅url等相关配置，如下：可以点击消息详情查看消息元数据、消息格式、消息示例信息，如下：可以点击消息拓扑查看图形化的发布订阅关系，如下：可以查看消息失败重试策略，工单申请调整重试策略如下：可以查看告警配置，消息订阅者服务技术负责人可以调整告警配置，主要分为两种alarms：消息失败alarm：消息达到重试失败次数即视为消费失败。消息延迟告警：端到端延迟告警，对消息时效性敏感的消息可根据实际情况调整。通过flink实时任务聚合将告警的指标数据采集并存储在Ntsdb中，告警通知接入严选告警平台，告警接收者为在线服务对应的在线监控人员角色。4.4自助运维当消息中心上下游系统出现异常时，只要消息成功投递到消息中心，消息中心可以提供自助推送功能，协助处理业务快速恢复。支持根据消息id或消息状态过滤查询指定时间范围内的消息，以决定是推送给消息的所有订阅者还是推送给某个订阅者。消息推送对运营商实行严格的数据权限隔离：如果要向所有订阅者推送消息，必须是所属消息服务的技术负责人，推送前需要与所有参与订阅者的技术负责人充分沟通.如果你想推送给消息的订阅者，你必须是订阅者服务的技术负责人，运营商负责这个操作。转发消息是一项高风险操作。所有操作都会被记录下来，以便事后审计跟踪，可以查看每条推送记录的具体详情：4.5工单自动化审批通过自动工单闭环消息发布、下线、消息订阅、取消订阅完成生命周期管理，结算严选的DevOps管理平台天书，将消息中心有机的融入到整个DevOps研发体系中。同时将消息工单视为变更事件，基于天书平台自动同步测试环境工单上线。同时作为需要发布上线的风险变更管控卡点项，有效避免应用消息发布/订阅缺失导致的业务异常。5.总结与展望5.1总结消息中心管理平台自上线以来，受到了众多业务方的好评。也广泛收集建议，对功能进行了一定的迭代优化，初步实现了预期目标：业务赋能：消息中心已接入200+服务，1500+消息，覆盖基础技术、供应等所有业务场景链，分销和客户销售，主站，交易订单和数据算法。运维成本大幅降低：技术咨询量从上线前的平均每周50+，下降到目前的每周不到10。研发效率逐步提升：业务方可高效便捷地自行排查问题和推送新闻，新闻工单完成率提升至90%以上。5.2展望消息中心管理平台下一个重点方向是数字化建设，借鉴目前流行的FinOps执行路径：成本展示->成本分析->成本优化：展示层面：虽然目前消息中心管理平台有很多统计图表，仅基于话题视角或系统管理员全局视角，我们也收到了很多业务方的反馈。如何从业务方的角度更好地将数据聚合展示推向用户，是接下来要考虑的问题。分析层面：目前只支持两种告警规则：消息消费失败和消息消费延迟。缺少进一步的数据分析和优化建议。这也是业界公认的技术难点，需要结合实际业务场景进行分析。优化层面：目前只是线下手动通知，比如根据消费时间最长的排行榜提醒相关业务方优化消费逻辑，从消费延迟最大的排行榜通知业务方是否消费能力不足，有待扩大。期望的效果是管理平台根据数据分析生成优化建议，自动推送给业务端，并将业务端的反馈和执行结果跟踪到底，实现全流程的自动化闭环。当然，作为消息中心管理平台，对于底层消息中间件的运维、部署、监控也是必不可少的。严选目前的实现实践是广泛调研引入开源组件EFAK和rocketmq-dashboard，并接入严选监控告警系统进行二次开发，结合??严选OF监控，以低成本解决消息中间件集群高效和机器维度的运行、维护、监控和管理。至于未来是否将这些功能集成到消息中心管理平台中，需要根据实际业务需求和成本效益来决定。6.附录EEAK：https://github.com/smartloli/EFAKrocketmq-dashboard：https://github.com/apache/rocketmq-dashboard
