图灵互娱刘龙鑫：游戏出海运维经验分享

大家好，我叫刘龙鑫，来自广州图灵科技有限公司，主要负责公司日常的运维工作。这次很荣幸能和大家一起探讨游戏出海相关的一些经验。我今天主要从以下五部分游戏出海过程中必须考虑的点进行展开分享：

• 服务器部署地域的选择

• 网络和数据库规划

• DDOS 攻击紧急处理

• 服务器和数据监控

• 国内维护小妙招

我们首先来看一下服务部署地域的选择。服务器部署的地域决定了玩家进入服务器的网络状况，也决定了玩家的体验。保证一个通畅的网络，才能让玩家在玩的时候更顺畅，体验更好。如果网络容易卡顿，则很容易造成玩家流失。

相比国内我们选择北上广任意一点就可以覆盖全国的网络情况，海外的网络就比较复杂，需要我们格外认真一些。下图是我自己测试做的时延表，我们可以清楚看到各个地域网络的时延差异非常大。

结合经验，我有两条小建议给大家选择服务器时做参考：

• 如果发行区域有本地节点，则优先选择本地节点：比如我们发行到台湾，那服务器就直接部署在台湾。这里特别需要提到的是，有些云厂商是拥有一个白名单的，这种需要找云服务申请后才可以开通对应节点。比如我们要发行到某一区域，如果你看到列表上没有，那最好可以问一下云服务商，他们可能通过相关白名单的方式提供给你想要的节点。

• 东南亚选择新加坡或香港，美洲选择弗吉尼亚，欧洲选择法兰克福。这几个是我们根据我们已有项目总结出来的经验选择，其他地域我们暂时还没遇到，如果大家有需要那一定要做好网络测试再确定选择地点。

接下来我们说一下网络和数据库的规划。因为海外玩家客户端到服务端网络的延迟比较大，同时也是为了提升他们的稳定性，我们需要对网络进行最大可能的优化，从而加速玩家的访问，提升玩家体验。

数据库的规划主要用于大数据分析。如果没有提前进行规划，当同一个游戏各区域数据集中到一起时，就会存在主键冲突和其他问题。而提到网络规划那我们必须要了解这两个产品，对等连接和 Anycast  IP。

对等连接能够打通两个 VPC 网络，使它们能进行内网通信。它的优点在于能够让两个 VPC 网络通过云服务商自建的内部网络进行通信，不受公网质量影响，这大大提升了可用性，保证了时延和丢包率。

如上图所示，如果一个游戏在欧美同时发布，但是共用一个后台，这时无论后台在美国还是欧洲，只要是走公网进行访问就没办法保证网络质量。比如把后台放在美国，美国本地的服务器在同一个 VPC 内肯定不影响访问，但是欧洲服务器走公网访问就会非常不稳定。这时候我们可以通过对等连接，走内网降低它们内部访问之间的时延和丢包。事实上我测试过，从欧洲的法兰克福到美国的弗吉尼亚时延在80毫秒左右，这是一个能够让人接受的范围。

Anycast IP 采用 Anycast 的方式，把 IP 发布到多个地域，让请求包根据传输协议到达最优的 IP 发布地域。它的优势是实现了 IP 传输的质量优化和多入口的就近接入，减少了网络传输的抖动、丢包。

如果我们在海外发布一个共用 SDK，而且还是多地域发布的话，因为海外运营商很多，很容易导致丢包时延。那么不管玩家是访问 SDK 还是游戏和 SDK 进行校验，只要 SDK 在本地没有节点，走公网进行访问的话，用户的体验就会比较差。这时我们就可以通过 Anycast IP 对 SDK 进行网络优化。或者选择对等连接+反向代理+域名分地域解析的方式，把 SDK 的域名分别解析到不同地域，让用户请求的时候可以请求到对应节点。

如上图所示，SDK 源节点在新加坡，而我们在香港、台湾、日本建立四个反向代理节点。当我们将解析分别接到这三个节点后，用户请求时就会请求到自己国家的节点，再通过这些节点反向代理走云服务商内部网络到源节点，这样就能够进行一次及时的响应，让用户在体验上有所提升。

我们前面提到的对等连接，如果需要使用对等连接则必须要提前对网络进行规划，网络规划的考虑主要基于以下两点：

• 各 VPC 网络，不在同一个网段

• 各地域根据项目的情况，预留出对应的网段。不同项目使用不同网段。

数据库规划主要是为了提前防止数据冲突，主要就是根据 auto_increment_increment 和 auto_increment_offset 两个 MYSQL 的质证参数。提前进行数据规划能够防止起点设置过长，方便大家把各个数据中心的数据导入到一起，避免大数据分析时出现数据冲突。

这是本次分享的重点，因为海外发行游戏特别是在港台地区，只要上榜就很容易受到攻击。所以我们需要在游戏上线前就做好防护预案，这样当攻击发生时我们就能按预案进行紧急处理。

对于中小型厂商来说，高防的成本较高，而且流量经过高防后会导致少量正常用户一块被清洗掉，所以导致很少有中小型厂商选择接了高防再上线游戏，一般都是遇到了攻击的时候才接入高防。但是上线后再接入高防比上线前接入，在时间上的紧迫感更大，一个刚上线的游戏不可能长时间的停服和测试来对接高防。因此在上线前我们一定要有详尽的预案和测试，这边给大家几点接入高防需要注意的地方。

一般我们上线都是新游戏和 SDK，因此需要将这两部分都考虑进去，不然不管对面攻击哪一部分都会导致游戏的不正常。

这里需要考虑到两点，首先是成本。我们要根据攻击的情况，提前考虑到自己能够接受的成本有多高，十万还是二十万，一旦超出这个成本就需要考虑其他方式。第二是考虑是否有本地高防，因为我们要把正常的流量转入高防进行清洗，这相当于网络链路的加长，如果有本地高防就可以更快的完成清洗过程，让用户体验更好。

我们大部分游戏都有黑白名单，这可能会导致游戏接入高防后无法登录。这个问题是我们前年上线一款产品时确实遇到的情况，当时在接入高防后就出现了无法登录的情况，造成了刚上线就被迫停服检查，后来才发现是游戏黑白名单出现的问题。因此我们需要提前做好测试，确保各方面都是正常的。

当攻击来临时原本暴露的 IP 会因为被攻击而无法正常连接使用。因此我们需要有另一个备用 IP，并且在上线前就让每台机器都绑定两个 IP。同时保证一个是隐藏起来的不被外界所知。

为什么要做 Nginx 转发文件准备呢？因为有些端口，比如 80、443 这类常用端口，很容易重复。而且因为高防成本的问题，很难买多个高防 IP 或者多个高防产品进行防护。所以我们的高防 IP 通常只有一个，这种时候就需要 nginx 的转发。比如我们把流量从高防 80 端口转发到某台机器的备用 80 端口，然后在通过这台机器的 Nginx 转发到其他相应机器上。这么做也可以节约我们的成本。

多提一句，除了通过高防来处理 DDoS 攻击，CDN+负载均衡的方式也可以通过把攻击分散到各个节点，从而避免需要防护的情况，这是我在和一些云厂商接触的时候发现的。但是因为我们的游戏并不是使用的这种方法，所以大家可以拿去做个参考。比如又拍云和 Couldflare 的产品是用 Anycast IP 的，我们可以使用他们的 CDN 加上负载均衡的方式来进行防护。

在游戏运行的过程中监控是必不可少的，只有做好监控才能及时发现并解决问题。而监控又分为服务器和数据监控，我们详细说下。

服务器监控主要有两方面组成，机器指标监控和进程、日志监控。

机器指标监控相信大家都比较熟悉了，包括 CPU、内存、硬盘、网络这些。目前大部分的云服务上提供的监控系统已经基本完善了，只需要完成系统配置并根据自己的需要添加一下必要脚本，就可以满足日常的监控需求。

但是如果我们因为一些特色业务需求，比如需要对数据进行汇总，进行更深次分析的话。我们可能会需要 Zabbix，或者一些其他的监控工具。这部分的相关文档市面上有很多，我们就不展开细说了。

在游戏海外发行的过程中，除了基本的监控外，网络监控是很重要的。因为我们的玩家来自很多国家，他们的丢包和时延都需要监控来看。一般这类监控都是根据脚本监控的。比如我们的监控标准是 10% 以内的丢包，400 毫秒以内的时延，然后每隔五分钟检查一次。当第一个五分钟检测到有异常时我们是不会发送告警的，因为网络有偶尔的小波动横正常。当相隔五分钟后的第二次检测依然有异常时，就代表超过了我们所涉的阈值，那么无论是丢包还是时延都会对网络进行邮件告警。这个监控逻辑非常简单，但是也非常有效。

进程的监控大家可以通过简单的脚本来实现。当进程挂掉后我们可以将进程挂掉时的情况、进程重启、重启成功或者重启失败都通过邮件进行告警，防止进程中断而不知道的情况。

日志的监控一般指的是对游戏日志的监控，常用工具是 ELK 工具，它可以对日志进行收集，进行日志分析和处理，并进行邮件告警。

数据监控属于业务监控，一般是对游戏的充值、在线、注册等数据进行监控。通常数据监控都在游戏刚上线需要重点关注的时候加入。因为有时候服务器的监控反馈不够及时，数据监控就可以保障业务的正常。比如日常晚上七点的游戏在线人数是 500，突然有一天只有 100 人了，出现了明显的下降。那我们就需要考虑是不是游戏本身有 bug，或者被攻击了。

除了数据监控外，我们也需要对相关阈值进行不断调整。因为我们的业务在不同时间点的正常值是不同队，如果我们要确保这个值能够准确反映当前的状态，就需要进行相关阈值的调整。

另外监控也需要查询数据库，我们最好不要直接在相关表上进行查询，而是创建一个数据库的视图，避免因为慢查询引发锁边等问题。

最后我给大家讲讲一个我们国内维护的小经验。因为国际出口有限，我们维护海外项目的时候，经常会发现因为线路拥堵出现丢包高达 60% 以上，甚至 100% 的情况，这导致运营和开发人员完全无法对外海项目进行维护。

其实在国内维护海外项目主要涉及到服务器登陆、数据库连线、后台登陆三方面，通过这三个方面基本可以完成正常的海外维护。而且这三个方面又都可以通过国内的云厂商来处理，因为云厂商都有一定的国际出口，假如云厂商位于香港的服务器不丢包，那就可以在香港服务器上进行代理操作。我们可以在香港服务器上面搭建一个跳板机，先用跳板机再访问项目对应的机器，从而减少丢包和卡顿问题的出现情况。

数据库也是一样的，通过对香港服务器进行授权，走香港服务器 SSH 通道进行登陆的速度就会很快。后台网站也可以在香港服务器上搭建一套反向代理，让国内的运营人员绑定 host 进行登陆。或者修改局域网域名解析，将解析解析在香港的 IP 上让国内的运营人员能够顺畅的访问海外项目。

以上是我分享所有的内容，谢谢大家。

现场视频、PPT 以及更多 Open Talk 技术干货，请点击↓↓阅读原文↓↓查看。

快 来 找 又 小 拍

---

推 荐 阅 读

设为星标

更新不错过