案例实践｜运营腾讯游戏，Proxima Beta 使用 Apache Pulsar 升级团队协作与数据治理...

文章摘要

本文整理自 Pulsar Summit Asia 2022 上，Proxima Beta 软件工程师施磊的分享《How to achieve better team integration and data governance by using Apache Pulsar》。本文首先将为大家介绍 CQRS 和 Event Sourcing 概念，便于了解为何 Proxima Beta 使用 CQRS 和 Event Sourcing 来设计系统，然后说明 Apache Pulsar 在此类架构中的独特优势，尤其针对组织架构较为复杂和数据监管严格的场景。本文将介绍 Proxima Beta 如何使用 Apache Pulsar 云原生中间件来加强团队协作，并分享提升数据治理透明度的经验。

背景简介

Proxima Beta 属于 Tencent IEG Global，主要负责腾讯游戏的海外运行业务。Proxima Beta Security Service 团队负责应对腾讯游戏运营过程中的各类风险事件，如检测作弊活动和过滤有害内容检测等。

CQRS 与 Event Sourcing

我们在介绍 CQRS 和 Event Sourcing 之前，先介绍一下 CRUD。

上图是一个典型的 CRUD 增删改查系统的架构。这类系统是存储系统为中心构建，其存储系统一般为某种关系数据库，或简单的 KV 存储和对象存储。这一架构的关键在于系统保存了所有对象，即系统的状态，很多时候只保存了当前的状态。在存储系统上会构建包含各种请求响应逻辑的应用服务器（Application Server）。实践中应用服务器与客户端之间还可能有接入层、网关等结构，存储与应用服务器之间可能有缓存等结构。此示意图的结构较为简单，主要为了展示 CRUD 的系统架构框架。

应用服务器负责定义各种业务逻辑并屏蔽底层存储系统细节。这种架构非常流行，有大量工具围绕其开发以提升开发效率。构建新系统时通常使用该架构作为默认架构。其特点有：

• • 简单直接；

• • 客户端向有应用定义的接口对齐，应用接口又由开发者设计，而开发者来自多个功能团队，会存在协作问题；

• • 这种架构面向状态，其存储系统会显式定义系统当前的状态，但很难从存储表结构中得知状态将会如何改变，因为状态改变的动作分散在应用的代码库（Code Base）中。

存在多个功能团队时，该架构会带来很多挑战：

• • 客户端需要同各个团队逐个对接，过程较为繁琐；

• • 由于不同团队内部的设计不同、关注的问题不同，客户端侧可能需要同一时间请求不同的数据，或者在不同时刻请求相同数据，甚至两者皆有，大大影响组织效率。

为解决上述问题引入了 CQRS（命令查询职责分离）理念。这里的重点在于每个方法不能既是命令又是查询。将查询比作向系统提问的话，那么在提问时不可以改变问题的答案即命令。CQRS 要求系统在接口上将所有对象严格分为两种类型，即命令和查询。CQRS 还要求读写操作背后的数据模型严格区分开，系统被分割为写入侧与读取侧，两侧各有专用的数据模型。CQRS 的写操作以异步的方式应用于读取侧的视图中，让写入侧发起的状态变更被读取侧观察到。

Event Sourcing 的核心思想是将变化（动作）用事件表达出来，将动作应用到事件模型上的顺序保存成一系列仅追加（不可变更）的日志事件流。相对典型的增删改查系统只保持最后一次变更的当前状态，Event Sourcing 则会记录所有历史动作。这样就可以从事件流中重建所有描述系统的潜在模型。银行对账单就是 Event Sourcing 理念在现实中的应用案例。总体来说，Event Sourcing 是面向变化的系统。

CQRS 与 Event Sourcing 结合有哪些好处

Event Sourcing 与 CQRS 结合有很多好处。

1. 1. CQRS 并没有定义写入侧存储模型，如果和 Event Sourcing 结合，开发时写入侧的事件模型就已经定义好了，不需要额外的操作，也就是说 Event Sourcing 可以直接嵌入到 CQRS 的写入侧。

2. 2. CQRS 读取侧的物化视图靠写入侧的事件驱动，维护当前状态的责任转移到了事件处理程序中。不同的事件处理器在同组事件流上能够以不同的方式维护自己关心的状态，得出不同的结果，可以很好地解决多个功能团队带来的冲突。不同的功能团队可以按自己的需求订阅消费客户端侧生成的事件，维护自己的物化视图，再有客户端侧使用对应的 API 查询对应的状态，满足业务需求。

上图右侧是线上游戏“幻塔”中的截图。该 UI 供玩家举报其他玩家的违规行为。表单中的举报理由可以用事件来表示，不同理由记录为不同字段，各个功能团队可以订阅该事件，配置自己的过滤规则来找出自己需要处理的举报，这样有利于团队协作集成。CQRS 与 Event Sourcing 的结合使不同团队可以同时处理同一组数据，得到各自需要的结果。这种结合还让不同的功能团队更多关注自己领域的问题，无需考虑自己定义的接口是否对客户友好，是否与其他团队的接口良好集成。

在 CQRS 与 Event Sourcing 结合的系统中，产品团队可以用自己最合适的方式生成事件，功能团队来消费同一组事件。不同的团队可以依照各自的职能和专业，提取需要的信息和结果，供产品团队查询来满足业务需求。

为什么使用 Apache Pulsar

多租户与负载隔离

Apache Pulsar 的多租户与负载隔离是原生支持、开箱即用的功能。多租户方便组织中多个团队共享单个实例。Pulsar 提供了租户、命名空间与 Topic 三个级别的隔离。租户一般用于实现部门间的负载隔离，命名空间可用于部门内按照不同负载类型进行隔离。

跨地域复制

Pulsar 的跨地域复制功能可用于在不同的数据中心之间为消费者和生产者提供一致的事件流视图，常用于容灾、数据监管、流量调配场景。

Proxima Beta 使用了多集群系统。多集群系统一般用于满足组织的容灾要求，如 RTO 和 RPO 指标。多集群系统也用于满足用户对更低延迟的需求，并可用于满足监管需求。

常见的多集群系统部署方式是将独立的集群复制到不同的区域，集群之间无法自动化协同。这样会造成集群成本和开销随着集群数量增加而快速上涨。但这种方式最容易满足合规方面的最高要求。

另一种方式是将跨集群通讯的复杂度推到应用层解决，应用层可以协调其他集群的实例。如果组织只有少量应用，这种方式的成本较低，配置文件只需配置一次即可。但多数组织会有很多应用，这种方式就不太现实。

Proxima Beta 采用的方式叫做 Global Data Ring（全局数据环），这是技术与规章的组合实现。首先，所有应用程序只能与本地端点通讯，该规则无需应用开发者自己配置，保证了应用程序不会有意外的跨地域通讯能力。需要跨地域同步写入时，全局数据环引入了全局命名空间（Global Namespace）作为配置方法。全局命名空间激活了跨地域复制，并将目标设置为所有区。这样该命名空间的写入可以被所有区域看到。

与全局命名空间相对的是区域命名空间（Regional Namespace），该命名空间禁用跨地域复制，其数据只能被与生产者同区域的消费者消费。这种命名空间主要用于处理玩家数据，以满足合规要求。还有一种是跨地域域命名空间（Cross-region Namespace），其同样激活了跨地域复制，但目标是限定为少数几个区。该设计可用于某些监管较松的区域。

这样的设计降低了数据流转的成本，也让应用开发者无需考虑数据流转、数据监管规定、底层基础设施差异等问题。底层基础设施的差异都被 Pulsar 与 CRDB 屏蔽了。开发者只需写入对应的命名空间，从对应的命名空间消费即可。

总结

我建议大家根据系统现有的查询构建物化视图，更好地理解系统在读取侧的行为预期。之后，可以再去了解客户的系统，研究客户系统可以生成哪些事件，哪些事件与自己有关。在此过程中你会了解自己的系统写入侧的事件模型，然后开发事件处理程序，由写入侧的事件驱动来更新读取侧的物化视图。

如果你的组织也允许覆盖全球的业务，需要考虑不同的监管要求，可以尝试利用 Pulsar 的命名空间隔离能力构建虚拟的地理围栏，提升数据治理的透明度，更好地服务于全球业务。

作者简介

施磊，Proxima Beta 首席软件工程师，就职于 Proxima Beta Security Service。本文由 StreamNative 协助整理发布。

---

▼ 关注「Apache Pulsar」，获取干货与动态 ▼

👇🏻加入 Apache Pulsar 中文交流群👇🏻