🔥 基于实时消息总线的活动系统架构设计原创

基于实时消息总线的活动系统架构设计本文分享的是网易云音乐技术团队基于实时消息总线技术，解决了直播活动系统的模块灵活组合、消息治理与伊不履约等问题，希望能给你带来启发。一、技术背景对于老生常谈的复用，我们可以对大部分人为比较共性的场景做好系统级别的封装，封装成一个个复用度较高的服务，然后通过接口和扩展点的方式进行一部分的能力开放。但是有一种场景是解决不了的，就是当一个功能级别的代码执行结束后，希望触发到另外一个功能，同时希望这个功能是可以通过配置去解决的，并且不需要通过开发的手段去解决这类问题。二信鸽服务的组合能力。与其说组合，更倾向于用履约这个词形容会比较恰当一点，因为对于活动来说，信鸽只做履约这一次的功能比较重要。

他要解决的是异步场景的分发类问题，而不是对一些系统做一些adapter组合集成的能力。信鸽服务主打一步履约与消息分发，依托配置实现模块数据路由。以音乐人活动为例，依托他灵活拼装已有业务模块，高效编排活动流程。三、整体架构设计。那么如何设计这样一个组合能力的架构呢？研发的重心可以分为四个层面，违约能力、SDK接入能力，全局的标识字典系统的自动注册能力。从图中可以看到，左侧虚线框代表了一个系统的触发，右边虚线框代表了最终另外一个系统的触达。信鸽系统充当了代理的服务，触发的系统只需要接入信鸽SDK，当执行完自己的职责之后，对数据做一层组装，发送给信鸽系统，信鸽系统会根据发送的信鸽ID寻找到信鸽的相关配置，信鸽ID决定了数据会流转到那个接入的子系统上。

4提供的SDK能力主要是路由触发能力和自动注册能力。对路由触发能力分活动、非活动两类业务子系统，前者接入SDK自动注册消息，监听消费路由数据，后者靠定制适配器对接，借鉴以思路，对于自动注册能力可provider为独立服务集群，阿拓等多能力服务接入SDK后，通过启动加定时拉取注解信息，经顺序消息向信鸽完成功能注册备案。五、ESB消息总线方案的比较从整个组合的能力上看，整体的设计思路是符合总线式服务，而总线式服务业内比较经典的就是ESB总线。ESB总线这个技术用今天互联网的角度来看是比较过时的，因为它本身更是应用于大型一企业内部的一些跨语言类服务架构方案，而它本身承接了系统和系统之间的桥接能力。但是信鸽本身的设计不同于ESB总线，它更注重的特点是雅管道的概念，忽略集成的适配转换，也不适合做中心化同步的集成。对比信鸽与总线ESB分开源字眼两类，偏重跨语言同步协议转换，开发繁琐。信鸽采用雅管道异步处理，统一数据字典，可视化配置编排，更适配互联网业务。6信鸽服务的消息转发能力，直播活动业务需监听海量消息，主题多，服务重复。

接入超频短期活动代码闲置后造成空消费消息直力困难，依托信鸽新增消息转发能力化解痛点。转发分为自定义业务清洗分发、注册自动分发、关键消息批量存入、TDB备份三类。信鸽可动态创建消费实例，支持配置路由生命周期活动下线后杜绝无效消费，转发失败消息单独存储重试经压测集群单机8也有16g32容器支撑下，每分钟可处理300万条消息，CPU占用约45%。后续规划对接FAS平台，借助FAS完善消息处理，优化资源调度。7、本文小结接入信鸽后研发可依托已有组件，通过后台配置快速拼装新活动，省去重复胶水代码，大幅缩短开发周期。老旧系统新增topic时存在数据结构转换，消息清洗难题初期TDB写入与消息转发我和脱。

给存储量拆分，存储服务升级，机器配置后性能显著提升，依据压测数据动态扩缩容，后续计划完善消息回放能力，以快速修复线上故障，优化跨地域机房路由，适配国际化业务，让信鸽持续实现业务模块复用与灵活编排。