通用解决方案 全球同服手游解决方案

游戏开发商可能会遇到以下问题：

• APP启动慢
• 游戏加载慢
• 延时高
• 移动/联通/电信用户互访慢
• 运营商IP库混乱
• 用户访问服务失败率高
• 用户在非WiFi网络环境下服务质量差
• 丢包率高、域名劫持
• 交互体验差
• 不同地域用户体验差异大

综上所述，移动加速产品应需而生。移动加速从本质上来看，是解决整条链路上的最后1公里，即从游戏客户端到加速点的加速问题，如下图所示。

针对已提出的全球同服游戏解决方案，客户需要在加速区域所在的阿里云节点手工部署流量加速转发代理，配置工作非常繁复，需要花很多时间进行调试。同时，您还需要考虑代理的高可用、扩容、性能、调度等问题，由此全球加速产品应需而生。

全球加速的实现原理是EIP（弹性IP）通过高速通道映射远端VPC下的ECS或者私网SLB实例，实现点到点的加速。全球加速解决了跨区域跨国的网络加速问题，如下图所示。

将移动加速组合全球加速，从游戏客户端到游戏服务器实现全链路加速。其中移动加速负责游戏客户端到加速点的基于动态路由和协议优化的Internet公网加速，而全球加速负责加速点到游戏服务器所在区域的专线加速。具体如下图所示。

目前针对全球同服类型游戏，全集中部署是针对网络延迟不敏感游戏的主要架构选择。该架构下游戏的接入层、逻辑层和数据层全部集中部署到某一区域，全球所有玩家均通过Internet公网接入游戏。具体部署架构图如下所示。

适用场景

该架构适用于重点覆盖某区域的玩家，实现真正的全球玩家同服，且所设计的游戏玩法对网络延迟不敏感。此种游戏的服务器架构在设计初期不适合作分布式部署，如在逻辑架构里未设置数据同步机制，因此在游戏上线时只能选择全集中部署。

架构优缺点

• 架构优点：

  • 部署简单。
  • 主要覆盖区域的玩家游戏体验较好。
  • 没有数据一致性问题。

• 架构缺点：

  无法实现所有玩家就近接入。

该架构中游戏的接入层、逻辑层和数据层将集中部署到某一区域，然后在游戏所需覆盖区域的阿里云节点部署全球加速。通过智能DNS进行调度后，各区域玩家实行自动地就近接入，游戏服务与各接入点通过阿里云的高速通道进行内网互连。具体的部署架构图如下所示。

适用场景

适用于游戏服务器架构不适合作分布式部署，而运营发行方又想覆盖尽量多的区域，同时游戏网络延迟需要在200ms以内的游戏。

架构优缺点

• 架构优点：

  • 部署简单。
  • 可以实现网络加速。
  • 没有数据一致性问题。

• 架构缺点：

  延迟固定（固定延迟差异对于某些类型游戏来说会带来玩法上的公平性，需要采用帧同步等方法来消除延迟差异。）

该架构中数据层集中部署到某一机房，然后在全球其他所需覆盖的区域分别部署一套游戏的接入层、逻辑层和缓存层。详细分布架构图如下所示。

适用场景

适用于游戏玩法上尽量是同区域玩家间互动，并且对网络延迟要求较高（如120ms以下，人的肉眼一般最小可感知延迟是120ms）的游戏类型，如动作类游戏，希望全球各区域都同等覆盖。

架构优缺点

• 架构优点：

  • 玩家可就近接入。
  • 游戏逻辑就近计算（本地缓存服的数据同步机制：玩家退出时实时回写数据库和每5秒回写100条脏数据）。
  • 基本不存在数据一致性问题。
  • 灵活调整分布式节点。

• 架构缺点：

  • 需要多区域部署。
  • 跨区域玩家互动时会有一方玩家网络延迟变大（会有专题方案解决延迟差异问题）。
  • 需要有完善的脏数据回写机制以保证数据一致性。

关键设计说明

下面对数据集中、逻辑分布架构的一些关键设计点进行详细的说明。

• 关键点1：游戏数据库集中部署

  全球同服类型的游戏，任意玩家之间会有玩法交互，玩家游戏数据、游戏账号数据和全局类游戏数据（如排行榜），都需要在某IDC集中部署。

  玩家游戏数据读写频率较高且单条记录较大，所以最好采用分布式存储架构，比如使用阿里云DRDS和RDS产品进行分库分表，避免数据库单实例的性能瓶颈。

• 关键点2：全球分区域接入玩家

  由于此类游戏是面向全球玩家提供服务，其他国家到中国内地的网络情况参差不齐，所以需要在全球分多个区域进行玩家的就近接入。

  比如依据阿里云的数据中心分布情况，接入点可分为华南、华北、东南亚、欧洲和北美，可在华东2、华北2、新加坡、德国和美东地域分别部署一套接入服务。

• 关键点3：玩家数据分区域缓存，定期回写中心数据库

  各区域内玩家间在一起游戏，为了避免远程读取数据的网络延迟降低游戏体验，玩家数据也需要分区域缓存，并分批定期回写中心数据库，这样各区域游戏逻辑服只需在玩家登录时远程读取一次数据，此后只需快速从缓存服读取玩家数据即可。

  比如缓存可以使用阿里云Redis产品，既可以做缓存也可以做持久化，即使专线链路不可用，也不会丢失数据。

• 关键点4：智能DNS实现就近接入

  对于全球玩家接入游戏时最好借助智能DNS服务来自动实现调度，也可以自建调度服务，调度玩家时需要根据玩家所在位置将同区域玩家调度到同一接入点，如果是基于匹配的玩法，需要在匹配算法中考虑玩家所在位置。

• 关键点5：尽量控制同区域玩家间可战斗

  由于每个区域都部署游戏逻辑服，也缓存对应区域玩家的数据，所以尽量从后端控制只让同区域玩家可互相PK。

• 关键点6：全局数据集中存储

  由于需要汇总所有区域的数据来生成像排行榜之类的全局数据，所以这部分数据也需要集中存储，每个区域可以定期来拉取需要的全局数据（需要根据排行榜生成的周期来设定拉取数据的时间间隔），但是在拉取到最新数据之前，本地缓存的上一版数据暂时不能删除，生成全局数据的相应服务也集中部署。

• 关键点7：玩家跨区域接入

  由于有可能出现玩家连续2次登录不同区域，所以每次玩家登录都需要检查其本地登录接入点和上次登录接入点是否相同，如果不同，需要先到上次接入点对应缓存将其数据回写数据库，然后再允许玩家在新接入点登录，防止出现数据不一致情况。

该架构中的游戏逻辑和游戏数据都是分布式部署的，只有全局类的游戏和数据是集中部署。读写不频繁，对网络延迟要求不高。具体部署架构图如下所示。

适用场景

适用于对网络延迟要求较高的游戏类型，不同区域间玩家有较多互动，希望全球各区域都同等覆盖，游戏架构中有完善的数据同步机制。

架构优缺点

• 架构优点：

  • 玩家可就近接入。
  • 游戏逻辑就近计算。
  • 游戏逻辑层完全无状态化设计。
  • 数据读写速度快。

• 架构缺点：

  • 需要多区域部署。
  • 不同区域间会有较多数据同步。

关键设计说明

下面对全分布式架构的一些关键设计点进行详细的说明。

• 关键点1：全局数据集中存储

  由于需要汇总所有区域的数据来生成像排行榜之类的全局数据，所以这部分数据也需要集中存储，每个区域可以定期来拉取需要的全局数据（需要根据排行榜生成的周期来设定拉取数据的时间间隔），但是在拉取到最新数据之前，本地缓存的上一版数据暂时不能删除，生成全局数据的相应服务也集中部署。

• 关键点2：全球分区域接入玩家

  由于这类游戏是面向全球玩家提供服务，其他国家到中国内地的网络情况参差不齐，所以需要在全球分多个区域进行玩家的就近接入，比如依据阿里云的数据中心分布情况，接入点可分为中国南方、中国北方、东南亚、欧洲和北美，可在华东2、华北2、新加坡、德国和美东地域分别部署一套接入服务。

• 关键点3：智能DNS实现就近接入

  对于全球玩家接入游戏时最好借助智能DNS服务来自动实现调度，也可以自建调度服务，调度玩家时需要根据玩家所在位置将同区域玩家调度到同一接入点，如果是基于匹配的玩法，需要在匹配算法中考虑玩家所在位置。

• 关键点4：游戏数据库实时同步

  此架构允许不同区域玩家可跨服游戏，所以需要在不同区域的游戏数据库间进行数据同步，可使用阿里云DTS进行数据实时同步，也可在玩家跨服务器时被动迁移数据，关于此方案中数据同步的详细方案后续会有专题方案。

世界排行榜服务在设计时需要从需求、分析、数据结构、Rank数据持久化、RankServer单点问题等方面考虑，以下是排行服务的架构图：

该架构使用Redis定时落地数据，GameServer将参与排名的数据上报RankServer，客户端从GameServer拉取排名数据，GameServer从RankServer拉取排名数据。

游戏服务器都使用距格林威治标准时间1970年1月1日00：00：00的偏移量（一般是1个绝对的秒数）来表示游戏内时间。此时间会同步给游戏客户端，游戏客户端取手机所设置的时区来计算出在游戏客户端里应该显示的游戏时间。具体情况如下图所示。

游戏时间同步的必要性：

• 防止客户端修改本地时间造成游戏逻辑混乱，客户端使用的时间必须是服务器时间。
• 几乎所有解决游戏状态同步问题的技术，如预测拉扯技术、服务器验证同步技术，都需要以时间同步作为基础。
• 游戏内一些定时的活动或与时间相关的游戏玩法，为了游戏公平性，必须以统一的游戏服务器时间为标准。
• 在客户端与服务器通信时更为安全的做法是，在每一个数据包中都添加时间戳，用于服务器验证数据包的有效性。

《方案一：利用缓存即时回写数据》

本方案主要特点是数据集中存储，本地设缓存，数据即时回写数据库。具体架构图如下所示。

目前主要有2种场景涉及到数据同步：

场景一：玩家在本地区域登录（如上图流程中红色字体所示）。

1. 数据库代理从数据库读取角色数据。
2. 数据库代理将角色数据插入缓存。
3. 从缓存读取角色数据参与计算。
4. 数据有变化时，同时更新缓存数据和数据库数据。
5. 玩家退出游戏时删除缓存数据。

场景二：玩家跨区域登录。

1. 先检查玩家是否已在其他区域登录，是，执行2，否，执行3。
2. 将玩家的角色数据回写数据库并删除缓存和退出登录。
3. 数据库代理从数据库读取角色数据。
4. 数据库代理将角色数据插入缓存。
5. 从缓存读取角色数据参与计算。
6. 数据有变化时，同时更新缓存数据和数据库数据。
7. 玩家退出游戏时删除缓存数据。

《方案二：分区数据库实时同步》

各分区数据库实时同步，可通过消息服务或者阿里云DTS实现实时同步，各分区数据库都存有游戏所有玩家数据。

• 方案优点：

  玩家跨区游戏时不用再迁移玩家数据，所有分区都是本地数据读写。

• 方案缺点：

  由于是异步同步，有可能存在数据不一致情况。如玩家使用VPN进行游戏，若VPN闪断，会造成玩家跨区重登录。如果数据同步消息丢失或有延迟，会造成重登录时读取的数据不是最新。

  各分区都存有全部玩家数据，实时同步可能会对数据库造成一定压力。各分区间数据库实时同步会使用较多跨区域专线带宽。

《方案三：跨区域数据更新》

跨区域登录时，从玩家本地服务器远程读取战斗数据，战斗结果通过接口调用方式触发本地服务器进行数据更新。

• 方案优点：

  本区域玩家均是就近本地进行角色数据读写。

• 方案缺点：

  实现逻辑较复杂，需要把所有战斗结果抽象成接口，统一由原服的接口来进行数据变更。

《方案四：远程数据迁移》

玩家跨区域登录时，从玩家上次登录的服务器远程迁移玩家数据，每次玩家登录时均需检查是否需要迁移数据。

游戏本地化是游戏出海的一个重要点，无论是游戏出海发行还是游戏的地区外发行，都需要注重本地化工作。一般做法是打一个统一的客户端安装包，里面包含若干基础的素材包，各种不同语种的美术素材包，以及一些程序素材，可通过手机的语言版本来动态渲染。

以下是常见的3种安装策略：

• 下载客户端安装包后玩家自行设置语言版本。这种大安装包包含各种语言包，软件内置一键切换语言。
• 客户端安装时根据手机所设置的语言种类进行动态安装。安装包一般会内置一套default语言，需要其他语言时，通过网络下载语言包。
• 分别提交不同语言版本的客户端安装包到应用商店。针对不同区域投放不同的安装包，每种安装包都需要定制化。

游戏A是一款全球同服卡牌游戏。目前游戏服务器部署在阿里云美国西部1地域，由于游戏玩法对网络延迟要求不高，300ms以下的延迟都不会影响游戏体验，所以客户没有优化网络接入或者施行分布式部署的计划，采用的是全集中部署的全球同服游戏架构。

游戏B是一款全球实时多人战争游戏，游戏采取集中部署、优化网络的全球同服游戏参考架构。

游戏接入层、逻辑层和数据层服务均部署在阿里云美国西部1地域，中国玩家通过阿里云公网BGP接入高速通道连接美国西部1地域的VPC，在华北2部署全球加速设置接入层公网入口，通过智能DNS来进行流量调度，这样就可以提高中国内地玩家访问游戏的速度。