B站IM即时通讯消息系统的新架构升级实践原创

B站I'M消息系统的新架构升级事件等要分享的是B站I'M消息系统的新架构升级实践总结，内容包括云架构的问题分析、新架构的整体设计以及具体的升级实践等。按业务全域现状，在服务端角度分成客服系统、系统通知、互动通知和私信四个业务线，每个月物线内按现状标识了服务分层。私信内分为用户单聊、b talk、批量私信、群聊和音援团小助手四类，这四类细分私信没有技术，仅有单聊和批量私信，比较接近系统天花板。私信内的几个概念解释绘画列表、绘画详情、绘画历史、收件箱私信内容timeline模型读扩散写扩散消息系统问题主要有会话慢查询、私信内容单表空间和写性能接近天花板。服务端代码有何结合B站业务现状，我觉得比较合理的架构如上图所示，一个兼顾复杂列表查询架构和I'M架构的消息域框架，整体分四层，接入层、业务层、平台层、触达层。

BFF网关吸收上浮的业务逻辑，控制需求向核心领域传导，服务端基于业务领域的能力边界，抽象出单聊、群聊、系统通知、互动通知和消息设置共5个新服务，提升微服务健康度。新服务剥离了历史包袱，也解决一些在老服务难解的功能case，优化了用户体验，比如消息页不同类型消息的功能一致性。

重新设计绘画缓存结构和更新机制，优化MYSQL索引，优化MYSQL查询语句，减少了一个量级的慢查询。服务端按4层拆分后，集中精力优化业务层和平台层，业务层按复杂查询设计系统，用于各种业务形态的支撑。一冷热分离，多级缓存readdi核心数据有无过期加patient有限明细数据加MYSQL全部数据。二读写分离95%以上复杂查询可以迁移到总库读平台层R'M架构设计系统目标是实时有序的触达用户，平台层可扩展1TIMELINE模型依赖雪花发号器成熟方案。

二读写扩散单聊写扩散，群聊读扩散。我们逐步发现，技术升级不是一蹴而就的，它是一个逐步优化的过程。设计技术方案前，设立合适和有一些挑战的目标，但这个目标要控制成本，做好可行性。设计技术方案的时候，需要清楚现有架构与理想架构的差距和具体差异点，做多个方按选型并确定一个，这个更多从技术团队考虑。其次，要保证功能在新老架构平稳过渡，保证业务的稳定性。后面持续关注新老架构的技术数据，持续优化老架构，要持续关注它的收敛替换应用系统是一个老生常谈的话题。

也是融合众多有趣技术难点的地方，欢迎感兴趣的同行交流研讨。