在游戏运维实战中摸索前行的“异地双活”架构

2018 年 2 月 1 日 DBAplus社群 lyonger

本文转自运维军团订阅号（id：ywjtshare），专注游戏行业的运维技术探索和传承，汇聚历史沉淀的运维实战经验，分享丰富的原创一线运维干货。

写在前面

最近由于游戏业务的迫切需求，我们需要启用一套可靠的异活双活方案，降低业务的单点。大世界类型游戏的特点是组件模块化，战斗节点、数据节点、登录认证服务器多为独立部署，这样的设计有利于高在线的承载能力。但问题来了，这样的架构要求在同一个内网里通信，我们常规部署都是把所有服务器集中在一个机房里。这样一来，一旦机房受到攻击或者机房出口异常再加上国内骨干网的间歇性抽风，这会对业务将带来全局的影响，严格来说存在一个非必然但不合理的单点。

经济学里有一句谚语：“Don’t put all your eggs into the same basket!”——不要鸡蛋全部放在一个篮子里。

异地双活之演进

第一阶段（伪异活）

由于大世界架构的游戏有个很明显的特征，功能性的服区分比较明显，例如有战斗节点server、日志节点log、登录节点center、数据节点data、缓存节点cache，其中有些功能服需使用数据库，有些服不需要使用数据库只承担玩家的战斗功能。这些不同的功能服无论部署在南方机房还是北方机房都存在以下2个比较严重的问题，具体如下：

为了保障业务在单机房遭受DDOS攻击、南北骨干网抖动故障场景下的正常运行和稳定，我们构思出如下方案：

我们采用的一些技术手段：

南北两地架设一条处于公网之外的专线，专线走服务器的内网卡通讯，相比公网缩小了10ms的延迟。将大世界的入口节点分别部署在南北两个机房，避免外网登录入口程序单点。
南方机房利用反向代理通过内网专线全部转发到业务所在的北方机房，内网专线断开时反向代理服务自动切换到公网进行转发，实现转发过程中的高可用。
玩家进入游戏均通过域名+端口的形式，域名针对省级做智能解析，达到玩家就近访问的效果。
应用D监控，如果检测到域名解析故障时，切换解析到正常的另一方，形成自动故障转移。

这个方案虽然在设计上显得草根，但在线上正式应用后，已经取得了一些效果，最严重的情况就是专线中断，这时我们的业务仍然可以保证正常的运行，由反向代理服务自动切换到公网转发。当然，我们只能称它为“伪异地双活方案”。如下图所示：

第二阶段（理想的异活）

随着业务的长久运行，第一阶段的方案虽然能解决机房遭受DDOS攻击、南北骨干网抖动等故障场景，但也暴露了不少其它问题。例如：

要解决“真正异地双活”的问题，实际上主要是解决数据同步的问题，底层的数据要求强一致性同时实现多写。而在我们的业务场景，数据有缓冲层数据、非缓冲层数据。缓冲层数据“双活”我们计划采用Redis集群+Sentinel的方案来实现。非缓冲层的数据“双活”我们计划采用MySQL集群方案。

那么问题来了，业界上主流的MySQL集群方案有MySQL Cluster和Percona Xtradb Cluster。

为什么不是MySQL Replication或MySQL Group Replication？

因为无论是MR、MM、MGR架构都是基于Binlog同步原理，涉及MySQL Binlog复制机制的方案均有延时的可能性。因为我们需要实现多写，如果无法保证数据实时一致性，业务将无法正常运作。

于是我们针对MySQL集群选型采取了一些压测，主要对比两种集群在高并发下写场景下的吞吐量、数据一致性、平均操作延迟等情况。

具体使用说明可以参考我们前面的公众号文章《MySQL VS MongoDB 你会如何选择？》

我们来看看压测结果：

单看测试结果，当数据量和并发数越大，MySQL Cluster集群的插入吞吐量、平均操作延时都越优于Percona Xtradb Cluster集群。这一点也不意外，因为NDB引擎主要使用内存存储数据，而PXC是需要落地磁盘的。但NDB引擎有很多劣势，例如巨耗内存、管理维护麻烦、容易崩溃出错、容易丢数据等，Oracle MySQL官网也强调NDB不建议应用于生产环境。这点有些纳闷……

PXC与传统MySQL区别不大，大部份日常的维护是相同的，也比较贴合游戏的应用场景。关于性能方面，我们可以用SSD来代替普通机械盘，提高IO性能。最终认为Percona Xtradb Cluster更适用于我们的业务场景。

因此，我们衍生出了第二阶段的方案，具体实现的架构：

基于第一阶段之上，新增了一些关键技术点：

PXC集群通过内网专线连接，专线故障时能自动切换到公网通讯。
非缓冲层数据通过PXC集群保持数据一致。
游戏节点同时部署在南北机房，除了入口节点以外，任何一方的游戏节点故障，程序可自动转移。
玩家进入游戏均通过域名+端口的形式，域名针对省级做智能解析，玩家就近访问。
入口节点通过D监控实现故障自动转移。
原反向代理服务仅用于用户战斗节点的分配，不再作为全链路转发。
（由于南北战斗节点完全地理分离，原则上南北用户不能在同一个战斗节点配对，这是策划上不允许的，所以需要利用内部转发让南北用户能够同时连接上同一个战斗节点）