直播房间服务基于CQRS的架构演进实践 _CQRS

引言房间系统是直播业务的“基石”，开播和看播两大体系都是围绕房间场景展开。
房间系统架构也经历一系列的升级和挑战，从房间读多活、混沌流量治理、热点发现、多级缓存等，支撑了S11破千万PCU的流量洪峰冲击。
为了应对业务更大的挑战，基于CQRS思想，分离大流量的用户高读场景（Query）和注重数据强一致性的开播创建房间等写场景（Command）。对于用户端可以无状态无限制的扩容服务副本，做到支持更大线上用户同时在线的目标。
背景直播业务的技术服务体系也实践过从单体到微服务化的演进之路，以技术视角看微服务体现单一职责和关注分离的思想，从大单体应用的进程模块拓展到分布式的应用服务模块化。同时微服务也是有额外成本的，微服务的拆分思路不仅仅是技术层面，更多会取决于组织和团队（以及组织如何去看待业务）。
如康威定律所说：
Organizations which design systems[…] are constrAIned to produce designs which are copies of the communication structures of these organizations.
设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。
单体架构到微服务架构是这个定律很好的体现。直播业务从一开始划分了三个大的macro service domain ，分别是用户、主播、营收。房间服务被划分在了主播这个Domain内，因其是主播创建房间、开播推流的基础载体，没有直播内容供给整个直播业务都无从谈起。
将单块架构先解耦成三块大的业务域，每个团队开发，测试和发布自己负责的服务，互不干扰，系统效率得到提升，满足了一个阶段内业务快速发展对于技术的要求。
本文后续将主播域（关注内容生产）简称为B端，将用户域（关注流量消费）简称为C端，方便理解。
现状分析大单体应用拆分之初，房间服务是从中拆出的单个php服务room-service ，不过服务中仍然耦合了过多的业务逻辑，从业务重要性/读写轻重/前后台区分/面向用户区分等几个角度上考虑都不应该继续在这个服务中继续迭代业务逻辑。
随着B站Golang微服务化演进，从room服务中陆续拆分出了几个新的微服务：

xroom/daoanchor：房间主体服务
xanchor：主播业务服务
xroom-management：房间管控服务
xroom-extend：房间扩展信息服务

从组织视角拆分是合理有效的，但是从技术视角去观察，房间服务既需要满足B端开播场景的数据强一致性要求，也需要承担来自C端用户“推荐页”、“上下滑列表页”、“进房”等业务场景的高QPS 。
【直播房间服务基于CQRS的架构演进实践】xroom作为底层服务，常态化晚高峰需要承担35W+ QPS ，单接口最大QPS 18W ，大流量Query通过服务热点主动探测+Local Cache+依赖缓存组件抗压，redis主集群QPS达到百万级别，尽量去减少DB层面回源的请求量级。
房间读多活架构和多级缓存方案实施后，又需要一些措施能够去主动探测发现偶发的数据不一致问题。
房间服务时常需要应对保障“关键事件开播管控”和“高热赛事直播”两种不同的业务场景，前者更关注房间开播平稳管控及时有效，后者关注高流量用户进房，技术服务上的降级缓存/兜底逻辑/熔断策略也会有差异。
If the same data model is not able to satisfy the read and write patterns of a system effectively, then it makes sense to decouple the two schemas by Applying CQRS.
如果同一个数据模型不能有效满足系统的读写模式，那么通过应用CQRS来解耦这两个架构是有意义的。
通过CQRS我们可以切实分离大流量的读场景和注重实时性和一致性的多写场景。尤其对于C端大流量来说，可以无状态扩容服务节点。理论上可以达到无限扩展目标，这对于千万在线的直播是尤其重要的。
The second scenario in which CQRS is helpful is in separating the read load from the write load.
第二种 CQRS 有用的情况是将读取负载与写入负载分开。
CQRS架构模式适用性主播是房间的所有者，对房间有管理权力，能够改变直播间的状态与属性。
观看用户则是房间内容的消费者，B和C视角下都会有一个叫做“房间”的内容承载体。从面向用户和权责分离角度来说，CQRS是比较好的一种思想来指导房间服务体系和业务域的拆分演进。