基于CQRS的架构在答题PK小游戏中的实践案例

正文

请到「今天看啥」查看全文

3.2.1 http

使用 http 通信时，主要是约定服务端提供的 api。如下图所示，前后端使用 http 通信的步骤：

1）上报匹配请求；

2）轮询获取匹配结果；

3）得到匹配成功信息后，上报 ready 状态；

4）轮询获取 game 相关信息（主客态玩家信息等）；

5）获取下一回合题目，如果没有题目了，进入步骤 7；

6）上报玩家该回合题目答案，并获取该回合结果。轮询直至该回合结束，进入步骤 5；

7）获取该局比赛赛果信息，比赛结束。

3.2.2 websocket

如下图所示，基于 websocket 长连接通信时，前后台的通信步骤如下：

1）客户端上报玩家待配对请求；

2）服务端推送配对成功消息；

3）客户端回传 ready 信息，准备开始游戏；

4）服务端推送该局游戏相关信息，以及第一回合题目；

5）客户端上报玩家答案；

6）服务端推送该回合答案结果；

7）若该回合结束（双方玩家都已完成答题），服务端推送该回合结果，以及下一回合题目，进入步骤 5。如果所有回合已经结束，进入步骤 8；

8）服务端推送该局游戏结果，比赛结束。

4 为何选择 CQRS 和 Event Sourcing

4.1 CQRS VS CRUD

大多数情况下，我们可以把信息系统看成一个可以进行增、删、改、查的数据存储库，系统的所有功能都可以转化为在存储结构的对象模型上进行创建、查看、更新和删除（CRUD）。而当需求变复杂时，CRUD 模式就显示出了不足。我们可能想用特殊的方式查看记录：比如说把多条记录合并为一条；或把不同地方的记录整合为一条虚拟记录。而实际操作时限制重重，通常情况下我们只能进行特定数据的合并，甚至有时存储起来的信息跟我们提供的根本不一致。因此，读写分离的业务架构在解决读写模型不一致时是比较好的选择。

CQRS（Command Query Responsibility Segregation，即命令查询职责分离）是 Greg Young 最早提出来的，其本质上就是一种读写分离的机制，其架构图如下：

命令和查询分离使得我们可以更好地把握对象的细节，更好地理解哪些操作会改变系统的状态。从而使系统具有更好的扩展性，提高系统可用性。CQRS 作为一种架构思想，可以有多种实现方式：

1. 最常见的 CQRS 架构是数据库的读写分离；

2. 系统底层存储不分离，但是上层逻辑代码分离；

3. 系统底层存储分离，Command 端采用 Event Sourcing 的技术，在 EventStore 中存储事件；Query 端存储对象的最新状态，用于提供查询支持。

CQRS 架构的适用场景：

1. 应用的写模型和读模型差别比较大时；

请到「今天看啥」查看全文