系统简介
我们在《江湖X:汉家江湖》系统中设计了一个每晚9点-10点的论剑系统，它的核心是一个带实时BAN/PICK的服务端自动计算的RANK框架。
如图：
根据双方分数匹配上之后，双方轮流进行BAN人、选人。最后服务器计算自动战斗，并且下发录像，双方进行播放。
我们使用服务器组架构，当下的峰值数据大概是单服同时在线1万人，一个小时内触发的战斗量级可达数十万场。我们的战斗参数非常复杂，整场战斗在一台I7的PC机上计算约需要3-4秒，吃满一个core。所以这种量级的处理，放在单台服务器上是非常不科学的，估计同时一百人战斗就可以随便down掉这台服务器。
我们的设计目标是世界同服，所以需要一个架构来支撑理论上无限扩展的用户并发量级，所以在此设计一个分布式的处理架非常重要。
今天给大家分享一下，我们是如何设计和实现这套系统的。
汉家江湖的服务器组结构
先说一下设计前提：汉家江湖使用的是基于redis为核心的服务器组架构。一个逻辑服务器的实体下挂接了若干台ECS、DB、redis，以及一台双备的索引服务器。这样是为了提高同服在线玩家数和服务器稳定性，不了解的玩家可以看我们这篇文章：
两万人在线服务器架构和一些公有云使用心得(http://www.jianshu.com/p/608da9336acb)
分布式的论剑计算系统
然而我们希望论剑系统是独立于服务器组之外的，也就是未来可以实现跨服务器组的论剑交互。所以我们给该玩法系统设定的是一个完全独立的玩法系统
1、系统架构
其中proxyServer可以认为是来自于不同服务器组的ECS实体，直接处理与客户端长连接的session。
其中各个名词解释如下：
1、Client 指unity游戏客户端；
2、RankProxy：Rank客户端在服务器上的代理，指当前的游戏服（SCUT SERVER），由于是世界服的，所以游戏服只充当代理角色；
3、RankDb 指RANK相关的数据库，同一个RANK群落（跨服战斗）指向同一个RANK数据库；
4、ComputeNode：RANK的计算节点，指一台服务器上部署的用于计算RANK战斗结果的程序；
5、RankComputeCluster:指ComputeNode的集合。
6、MatchServer配对服务器，一个Rank群落只有一个实例。
7、MessageBus：消息总线，提供订阅/发布接口，实现松耦合的分布式通信机制
2、功能要点：
- RankProxy
- 接受终端用户的所有行为（登录、登出、匹配、BAN/PICK、查询等）
- 与终端用户交互
- RankDb
- 一个RANK DB集中存储一个RANK群落的所有数据（从部署架构来说，我们可以实现同一区内的RANK战斗、甚至是跨大区的RANK战斗，区别只是在于RankDb）
- RANK DB自身高可用
- ComputeNode
- 集群计算（可以以集群的方式接受任务，任务可以分步到各个节点去分别计算）
- 幂等（任何一台实例计算结果一致，并且不会重复计算）
- MatchServer
- RANK匹配配对
- 主动清理过期RANK
- 为了防止单点故障，其自身应该是高可用的
- 各个服务器应该都是无状态的
- 原因是支持客户端断线重连，而客户端连接是根据网关路由分配RankProxy的，所以这里要求连到任何一个RankProxy都可以继续流程
- MessageBus、MQ
- 见消息总线说明
3、业务时序
带颜色部分为使用消息总线通信
1、橙色部分使用MessageBus
2、绿色部分使用MQ
4、消息总线
我们使用互联网中间件来实现各个分布式模块的通信，以及分布式计算的集群消费模式。同时使用以下两种方案：
MessageBus
MessageBus使用redis的发布/订阅作为服务器间的实时通信信道，所有的通信均采用广播，根据业务属性，该广播信息为一次性的（可丢弃）。每个服务器根据自己的需要过滤消息。
MQ
战斗计算任务由于占用大量的CPU计算资源，我们需要搭建计算集群。使用阿里云MQ提供的集群消费模式，保证数据下发到一台计算节点。
成果
汉家江湖上线近2个月以来，我们以弹性的云计算资源实现了峰值DAU10万用户规模的论剑，并发上千场战斗计算，一小时内十万级别的计算规模。在仅1个程序员维护服务器系统的情况下，保证系统稳定运行。
其中云服务器提供商（阿里云）出过几次MQ和Redis的BUG，导致我们的系统紊乱之外，没有任何运营事故。并且此框架未来足以支撑更大量级的用户，目前来看其理论瓶颈在于基于redis pub/sub的消息总线（MessageBus）的IOPS，未来需要的时候可以在这个点做基于业务逻辑的水平拆分。
