架构实战营 4 期 - 模块七作业

作业要求

【背景】

假设现在决定要实现王者荣耀里面的商城的异地多活架构，请你分析设计一下。

【作业要求】

1. 分析王者荣耀商城的业务特点，设计其异地多活架构；

2. 按照模块 7 第 5 课的方法来设计异地多活架构。

【提示】

1. 王者荣耀的商城是虚拟物品商城，和淘宝这种实物电商有两个很大的区别，注意识别出来；

2. 用户要先调用微信钱包或者 QQ 钱包充值点券，然后在商城里面用点券支付；

3. 用户买英雄和皮肤的时候同样的英雄和皮肤只能买 1 个，不能重复购买；

4. 用户买鲜花、改名卡之类的道具可以买多个；

5. 分析步骤参考模块 7 第 6 课的案例。

业务分析

业务特性

1. 虚拟商品不受库存影响；

2. 虚拟商品不受物流影响，所以所有的商品购买后都即时到账户；

3. 不同区服数据要能互通，但并没有很严格的强一致性要求；

4. 用户买英雄和皮肤的时候同样的英雄和皮肤只能买 1 个，不能重复购买；

5. 用户买鲜花、改名卡之类的道具可以买多个；

业务分级

主要涉及业务有：

1. 用户账号管理

2. 商品管理

3. 用户购买商品

4. 用户充值

按核心程度，优先级为：用户账号管理 > 用户充值 ≈ 用户购买商品 > 商品管理

用户账号管理可复用王者荣耀整体架构，作为商城子系统主要考虑用户充值和用户购买商品业务

数据分类

基础信息

1. 用户信息，全局唯一，不可丢失

商品类

1. 英雄+皮肤，全局唯一，可恢复

2. 其他道具（鲜花、改名卡），可重复，可丢失，可恢复

点券

1. 充值点券：最终一致性，不可丢失；

2. 退还点券：最终一致性，不可丢失；

点券最终一致性设计分析：

1. 对于充值后未到账的情况：本身就是非实时到账，充值界面也应有相应提示知悉用户

2. 对于透支的情况：并没有实物，一切商品皆为“数据”，那么可以在一定金额范围内允许透支。即使用户退游，账号也将闲置，没有任何损失

数据同步

同步方案

数据库同步为主，消息队列同步为辅

商品

1. 商品 ID：每次新建，全局唯一，不会修改，用算法生成，数据库同步+消息队列同步；

   商品数据：和商品 ID 绑定，可修改，数据库同步+消息队列同步；

订单

1. 订单 ID：每次新建，全局唯一，不会修改，用算法生成，数据库同步+消息队列同步；

   订单数据：和订单 ID 绑定，不会修改，数据库同步+消息队列同步；

充值

1. 账户余额：全局一致性，采用数据库同步，充值只能在归属地充值；

   充值记录：每次新建，不会修改，数据库同步即可；

异常处理

充值

1. 无法充值？

2. 支付通道问题，换支付通道

3. 自身服务问题，挂公告。

4. 如果用户在南方机房充值了，没有同步到北方机房怎么办？

5. 最终一致性，请用户等待一段后刷新查看

6. 记录好充值日志，人工恢复

7. 如果用户在北方机房充值消费，记录在临时事务表，等故障恢复后，同步临时事务表

8. 容忍一定程度的透支

购买

1. 如果用户在南方机房购买了英雄/皮肤，没有同步到北方机房，用户在北方机房再次购买怎么办？

2. 多次购买记录，退点券即可

3. 也可以在业务上进行数据合并，只要保证最终一致性即可

4. 如果用户在南方机房购买了非英雄/皮肤商品，没有同步到北方机房，用户在北方机房再次购买怎么办？

5. 同英雄/皮肤方案，在业务上考虑合并数据

整体架构图