网易游戏《荒野行动》《阴阳师》等出海实践－AWS技术峰会演讲实录
2019-06-12 孙国良
孙国良
2013 年加入网易游戏，早期是做游戏运维的工作，是端游《天谕》、手游《楚留香》等游戏的运维负责人，后来主要负责了网易游戏出海对接公有云的运维架构，以及国内外混合云解决方案方面的工作。
大家好，今天非常高兴能够分享网易游戏海外在 AWS 云上的实践情况，可能有些同学还没有在 AWS 上部署相关业务，希望我的分享可以为这些同学提供解决方案层面的参考，可能还有一些同学已经在 AWS 有过部署经验，也希望我分享的内容能给大家提供一些线上最佳实践优化的思路，当然也非常欢迎大家对我分享的内容提出建议帮助我们一起改进在云上的业务架构。
历程
首先简单介绍一下网易游戏出海的历程，这里主要是指手游，我们差不多是从 14 年底 15 年初开始做海外发行，比较典型的游戏有《阴阳师》《荒野行动》《终结者》《第五人格》等等， 今年我们也会有更多的游戏出海发行，比如最近发布的《明日之后》《量子特工》等，后续还会有更多的重磅游戏，敬请期待。
根据第三方统计，去年中国的游戏发行商在海外的收入排行榜中网易取得了第三的成绩，并且中国出海手游收入榜单前 30 中我们有两款游戏上榜，《荒野行动》和《终结者》。特别是《荒野行动》在上线一周年时收入超过了 3.7 亿美金，74% 来自于日本，注册用户超过了 2.5 亿，并且下载量突破了 5800 万次，在日本的畅销榜上稳定在前五，当然我们也还有其它很多游戏在全球多个地区取得了不错的成绩。
我们回到刚开始出海的时间点，也就是 14 年底，从运维和基础架构层面出发，当时我们面临了国内发行和海外发行的一些根本性的差异：
第一点就是网易游戏在国内是有自建数据中心的，但是游戏出海我们不可能去每一个发行的地方自建机房，所以会考虑引入公有云的基础设施；
第二点就是因为要引入公有云，海外使用的资源是虚拟化的，而我们原来在国内还有比较多的使用物理资源；
第三个就是云上的资源是弹性的，而物理资源是固定的，最后一点就是国内发行的游戏只要覆盖国内网络，但是发行到海外的话我们面临的是全球范围的网络情况。
挑战
这些差异化给我们带来了新的挑战，总的来说就分为这几点：
第一，性能，国内可以直接用物理网络设备和服务器承载高性能的业务，如果在海外用公有云的虚拟网络和服务器，这些虚拟化的资源能否满足游戏业务需求，这对我们来说其实是一个未知数；
第二，动态弹性，因为云资源大都是按时收费的，所以从成本考虑会引入动态伸缩的方案，而动态伸缩对于游戏业务和基础架构来说也是一个全新的内容；
第三，安全性，国内我们有自建的数据中心，安全性比较容易掌控。在公有云上我们就需要考虑很多安全方面的因素，除了网络安全，还有数据安全等；
第四，全球通服，游戏海外发行给我们带来一个全新的需求就是全球通服，后面也会介绍我们在全球通服方面的一些实践。
基于这些海外发行和国内发行的差异和挑战，从基础架构层面出发，我们一直在做的一件事情就是建立起一套标准化的云评测体系，来评估一个游戏是否能发行到公有云，以及哪个云能够满足需求标准，并且在实践过程当中根据我们遇到的问题不断迭代这套体系。
测评
我们的评测大概会分为这几个方面：
第一是基础设施层面，例如对于计算、存储的性能/可靠性/可用性方面的考量，还有对于网络质量的评估，会分为数据中心网络以及玩家网络两方面；
第二个就是安全性，刚才也已经有提过。另外也会有技术支持，成本等多方位的评估，由于今天分享的时间有限，这次会集中讲我们在计算性能以及网络延迟方面是怎么做的。
首先是计算性能的评测，对于 CPU 可能很多同学都已经比较熟悉了，常规评估会从硬件架构/型号/核数/主频等指标出发，然后做一些 Benchmark 性能测试，但我今天要讲的重点不是在这些方面。
我想先讲一个案例，在 16 年底当时《阴阳师》有在海外部署两个服，一个是日服，第二个是北美的全球华人服，两个服都跑在 AWS，用了相同的机型，运行相同的操作系统和游戏程序代码，但是很奇怪的一个现象是日服的性能只有美服的十分之一，日服在一开始完全无法支撑当时的发行需求。
从运维的角度，硬件/系统/软件代码层面都没有什么差异，就先从业务进程这边先入手排查一下。这是当时阴阳师代码压测的情况，上面是日服，可以看到在空跑的状态下 CPU 总体使用率就超过 60%，下面是美服，在空跑状态下它 CPU 总体使用率不到 5%。
通过 Perf top 或者是 strace 之类的工具去分析进程到底消耗在哪些系统调用，我们发现大部分的调用在 hrtimer，这是获取时钟源的指令，其实对很多游戏引擎来说可能都会依赖这个调用，因为需要加程序插桩用于性能 profile，所以当时我们就怀疑到可能是时钟源设置上的差异，一看果然是。
上面是性能有问题的时钟源，设置成了 hpet，下面是正常服的时钟源，它设置的是 xen，但是 Hpet 是读主板的时钟的，而 Tsc 这些是直接读 CPU 寄存器的，两者性能相差悬殊。
而两个服支持的时钟源完全一样，这里其实引伸出另一个问题，网易游戏是有一套服务器初始化的自动化标准流程的，当时我们的流程没有把 AWS 时钟源统一设置为高性能 tsc 的原因是 AWS 的机型少支持某一个 cpu 指令，我们会根据有没有这些指令 flag 去设置时钟源，初始化流程没有去设置就导致它用了 AWS 自动设置的时钟源，而 AWS 会自动随机设置成 hpet/xen/tsc 的任意一种；
解决方案是很简单的，我们在初始化流程里去定制 AWS 的机器要把它设置成我们想要的时钟源。
在经过这个问题之后我们就把 CPU 所支持的指令集以及时钟源作为一个关键的评测指标，如果说新的平台需要改用新的时钟源，比如 5 系实例是一个新的 nitro 平台，它引入了全新的时钟源叫做 kvm-clock。那么针对这个时钟源我们就需要做游戏引擎的压测，确认这个时钟源的性能能够满足业务的需求。
接下来再看另外一个案例，在 2018 年初 Intel 的两个漏洞 Spectre&Meltdown 全面爆发，所有云商都跟进修复这个漏洞，当然 AWS 也很快修复了这个漏洞，修复这个漏洞需要底层打上几个补丁，当时我们发现漏洞修复后 3 系，4 系的实例都出现不同程度的 CPU 性能损失，尤其是对于网络密集型的业务，最多会出现 50% 的下降，而《荒野行动》的游戏服恰好是网络密集型的业务，并且 18 年初正好是《荒野行动》在春节期间人数一直上升的阶段，所以这个性能下降导致了当时玩家承载量上不去，需要排队。
这里截取了游戏压测的 CPU 负载情况，最下面的那条线就是某一个 CPU 的 SI 的软中段已经到达瓶颈，pps 已经撑不住了会开始丢包，玩家的体验没办法保证，但整体的 CPU 性能并没有达到瓶颈，大概是百分之四、五十还没有被充分利用，但就是因为某一个 CPU 的 si 吃满导致了网络软中段的性能瓶颈。
这里第一个想到的方案可能就是堆机器，是不是增加机器就可以提升承载量？
这个方案不是很可行，或者是它的效果不佳。
因为我一旦增加机器的话整个集群内部的通信反而会增加，而且瓶颈仍然会在那个 CPU 核上。增加机器是一种提升效率不佳，而且成本又很高的方式。接着我们就尝试从系统层面去优化，当时我们专门跟 AWS 的架构师进行探讨，4 系的实例是支持多少个网卡队列？
结论是应该有两个队列，然而我们在系统里面看到只有一个队列，我们怀疑可能是因为用的网卡的驱动版本太老了，然后就把它做了升级，确实就有两个队列，并且开启了 Irq，Irq 是从 linux 2.6.22 内核开始引入的一个新特型，它可以把硬件多个网卡队列的数据包处理分散到多个 CPU 核上去，这样一来两个队列可以分散到两个 CPU 核上，这个优化可以提升约 50% PPS 承载量，但是光靠这个还不够，还没有达到漏洞修复前的性能，我们继续寻找其它的优化方式，考虑引入 RPS 跟 RFS，它是从 linux 2.6.35 开始进入 linux 内核的，通过软件模拟的方式实现更多多队列的功能，把软中断负载分散到多个 CPU 核上去。
但是默认情况下我们不会去开 RPS，因为它会造成额外 CPU 的开销，这个分散本身就会消耗一定的 CPU。基于两个队列确实已经不够，那我们就选择开启，开了之后大概能提升 40% 左右的 PPS，这里也再提一下 RFS，虽然说我们把网卡分散到了多个 CPU，但是有可能出现这样的情况，即给该数据流分发的 CPU 核和执行处理该数据流的应用程序的 CPU 核不是同一个，这样对于 CPU CACHE 的性能影响较大，RFS 就是保证应用程序处理的 cpu 跟软中断处理的 cpu 是同一个，从而保证 CPU CACHE，当然这两个特性一般来说都是结合一起开的。
做了这两个提升之后系统的网络包处理性能差不多已经达到了之前说的因漏洞修复以前的状态，但是这个状态仍然没办法满足需求。因为当时《荒野行动》在日本的人数一直新高，数据流的量级其实已经超出了我们所用的 4 系实例的极限，我们开始思考当前的 4 系列虚拟化体系的性能可能已经无法满足现在的业务需求。
这时候刚好离 AWS 推出 5 系 Nitro 新平台不久，这个平台本身它有很多重大升级，包括硬件底层，hypervisor 层等都是全新的，尤其需要注意的一个是网络性能优化从 SRIOV 改成了 ENA，第二个是磁盘驱动改成了 NVMe。
这两个改变理论上来说是能够本质的提升网络处理性能，所以我们开展了测试：
可以看到上面是 4 系，下面是 5 系。
5 系最多有 8 个网卡队列，它的网卡软中断负载可以更均衡的分散到多个核上去，所以能更加均衡的承载业务网络数据，整体的实例性能也是可以继续往下压榨的，可以去到 70-80% 的总利用率，我们还对比了他们的成本，4 系到 5 系实例的替换比例接近 2：1，可以节省不少成本。
于是我们就进行了升级操作，包括操作系统、驱动、软件依赖包等都做了升级，然而升级并没有那么的顺利，我们在 1 个月内就遭遇了 8 次各种类的故障，其中有硬件底层的，有 hypervisor 层的，也有上层应用兼容性的问题。
所以这里也想提一点，对于一个新技术或者新平台，我们还是需要用敬畏的心态面对它，而不是说好像觉得很厉害很牛，就去用它。
其中有一个疑难问题我们也通过 AWS 的 enterprise support 跟 EC2 产品团队直接进行了沟通，我们定制了一个调试用的 linux 内核，并且 EC2 团队为我们定制了一个调试用的 hypervisor，加了很多的 debug 设置，然后在 dedicated host 上绑定这个 hypervisor 去跑应用来定位到底这个问题是什么，虽然最后还是没有能定位到精确的问题，不过好在我们找到了一个 workaround，线上暂时来说可以有解决办法，当然我们也仍然在寻找更优雅的解决方案。
经过这次实践之后我们就实例支持的队列数/网卡数，包括支持的 IP 数都把它加到了我们的评测体系里面，以及它的带宽和 PPS 指标，其中多网卡，多 IP 是有一些其他的应用场景需要的。
第二方面是存储，主要就是可用性，IOPS，吞吐量等方面的评测。这里要说一点的就是我们会更加追求性价比，举一个例子，假设有一个数据库的应用它的需求是需要一个 600G 大小的快存储，IOPS 要求是 10000，吞吐量要求是 200MB/s。
因为这是一个高 IOPS 的应用，我们第一个想到的方案可能就是用 IO1 EBS，因为 IOE 是一个可以制定 IOPS 的高性能方案。
但其实还有一个方案是用一个很大的 GP2 的磁盘，GP2 是一种 IOPS 随容量增大的 EBS，比如这里写的 3.3T 这么大的磁盘，它的 IOPS 也能够达到 10000，但是它的价格不到 IO1 的一半，这时候我们可能就倾向于用 GP2 去承载存储密集型的业务。
接下来是网络评测，这一块分为两方面：一个是 IDC 网络，一个是玩家网络。
IDC 网络就会比较直观了，比如说要在新加坡部署一个服，那新加坡的服跟日本的服互相之间可能需要交互，例如跨服战斗。那这时候就需要评估新加坡到日本这些地方的数据中心的网络延迟能否满足游戏需求？
通常来说不同的游戏可能会有不一样的需求，这个游戏是 100 毫秒，那个游戏可能是 200 毫秒，所以就需要我们有这样的评测数据作为决策支撑。
图里是举例在 AWS 上面的一个评测案例，我们评测了 AWS 新加坡到日本和韩国 AWS 节点之间的网络情况；当然实际的评测会更加复杂和庞大一些。
第三方面就是玩家网络评测，这个也很直白，比如说我还是在新加坡部署一个服，但是我面向的玩家可能是东南亚地区，越南，泰国，马来，印尼，菲律宾等。
那这些地方的玩家到数据中心的网络是否能够满足到我们游戏需要的延迟/丢包的要求，这就需要我们做一个全面的评测。
通过我们在各地玩家客户端 SDK 中加入探针去探测这些地区的玩家到数据中心网络的延迟和丢包情况，一般的会测游戏本身流量基于的协议，比如说 TCP 或者是 UDP 或者是其它自研协议，图中就是一个玩家网络评测样例，数据是伪数据，请勿参考。
其它我们也会有很多方面的标准化评测，包括刚才提到的安全性是一个非常重要的方面，因为我们多款游戏在 DDOS 上吃过很多亏，也做了一些优化方案，其他的还有例如基础设施可编程，因为我们有数十上百款游戏，光在 AWS 上面可能就有成千上万台服务器，我们需要用到云的 API 或者是 SDK 来开发我们的自动化管理工具。
还有技术支持，除了售前的架构咨询，还有就是售后的 7*24 故障响应等等。另外成本也会做一个综合的评估，包括收费模式，费用对比等；基于时间关系，这些方面就不一一展开了，网易游戏对云的标准化评测大概就是这一些方面了。
经过评测之后 AWS 是一个符合业务需求的选择，因为 AWS 有广泛的全球基础设施，在计算存储网络等方面都有高性能的方案，所以很自然 AWS 成为我们海外发行比较重要的选择之一，接下来我会介绍一下网易游戏在 AWS 上面的一些运维实践。
运维实践
大概分两部分介绍：第一是服务层面的架构。第二是全球通服的实践。
在 AWS 服务层面我们可能不会用到非常多或者复杂的服务，主要是依赖 AWS 比较底层的基础服务。比如说 EC2，VPC，ELB，S3 还有 CloudFront 这些，这些核心服务承载了主要业务，当然也会用到安全或者是监控方面的周边服务，以及贯穿始终的 Support 支持体系。
接下来为大家介绍我们在 VPC 层面做的业务网络架构实践以及我们中间遇到的问题和改进的方案：
首先 On Premise 是指网易会有自建的机房或者是一些其它其他的第三方的供应商，这个可以认为是非亚马逊的基础设施。
举个例子我需要在 AWS Virginia 的 Region 部署一个游戏服，通常来说我们会为一个游戏单独分配一个独立的 VPC，这是为了做网络三层的隔离。
一开始我们的架构是比较简单粗暴的，比如说我划分一个 public subnet 部署游戏服，再划分一个 private subnet 给我的纯内网业务，例如数据库之类的服务部署，public subnet 通过 Internet gateway 访问 Internet，这个也是比较通用的做法。
然后 VPC 内的实例通过 Endpoint 访问 AWS S3 等服务，这里需要注意 private subnet 内的实例也是需要访问公网的，比如说我一个数据库的应用虽然不需要对外提供服务，但它也需要更新软件包或者是做一些 DNS 查询等，我们抽取出一个 vnf gateway 来实现，它是一个虚拟的网关，其实就是拉一台虚拟机专做网络的转发和联通。
这里大家可能有一个疑问我们为什么不用像 Cloud NAT 这种比较原生的方式，后面大家就会明白为什么我们需要这么做。
接下来需要把我自建的数据中心，或者是其它第三方的数据中心跟 AWS 的 VPC 网络进行打通的，因为有一些数据是需要做互通，这时候我们引入了 Transit VPC，在每个地区专门拉一个 VPC 做中转，同 region 的 VPC 之间可以直接通过 Peering 互联，而 Transit VPC 跟我的业务 VPC 以及跟我 on premise 的数据中心之间互联，就是通过刚才提到的 VNF gateway 以及在 Transit VPC 里面加的 VNF router 这些 VNF 的实例实现。
我们通过 gre + ipsec 协议做隧道和安全加密，跟其它地区的互联也通过这一条 VNF gateway 跟 VNF router 做互通的，当时设计这个方案的时候 AWS 的跨 Region 的 Peering 还没有支持，所以我们当时跨 Region 之间如果要访问内网其实是要走一条比较长的链路的。
随着游戏越来越多，游戏的规模越来越大，这个方案出现了一些问题和局限性，在这里列举几个比较典型的案例给大家分享；
第一点就是我刚才提到的跨 region 访问内网需要绕 region1 vnf gateway->region1 vnf router -> region2 vpf router -> region2 vnf gw 这样一条长长的链路，中间链路越多故障率越高，而且我们知道跨 az、跨 region 的流量都是要收费的，这个方案的成本也比较高；
第二点是由于每一个游戏 VPC 都需要划分一个单独的私有子网放数据库之类的内部服务，随着游戏越来越多，几十上百个，每一个游戏都要规划这些内部服务用的子网、AZ，对于游戏来说它的接入成本越来越高，而且对内部 SAAS 团队来说也是个问题，对于 DBA 来说，如果说这些网络都是在业务的 VPC 下面的话它的管理也有很大的问题，无法统一去规划，所以说这个随着规模的扩大有比较大的局限性。
第三点是由于我们用 gre 协议打隧道互联，用 ipsec 做加密。这一套方案经过线上实际运行下来经常会出现丢包断线，而且一旦出问题排查起来比较麻烦。另外就是 gre 这个协议有些云或第三方机房并是不支持的，所以它的稳定性和通用性不佳；
针对这些问题我们做了一些优化，首先我们做的就是把公共内部的 SaaS 服务抽出独立的大 VPC 来承载，假设数据库的业务我们就会单独为它画一个比较大的 VPC，比如说用一个 20 位的 cidr，下面分 az 去划分子网，这样的一个好处就是 DBA 团队可以统一的规划好 VPC 的网络，subnet 和 az 的关系，统一做到高可用，且权限规则清晰，方便做自动化的部署，业务的 VPC 跟 SAAS 服务的 VPC 还是通过 Peering 来互通(这一点其实也会引发新的坑，先在这里卖个关子)
针对刚才提到的 gre + ipsec 容易出现丢包断线的情况，我们后来引入了 uu 加速器的 ure 自研协议，它是基于 UDP 的协议，基本上是所有的云平台和机房都支持的，而且它自带加密，通过引入这个协议可以提升混合架构互联的质量。
最后一点就是跨 Region 的互联，AWS 是去年推出了跨 Region peering，我们毫不犹豫的引入这个特性，就不要绕一圈的 VNF gateway 实现跨 region 的内网互联；
目前我们在 AWS 上运行的情况差不多是 400 多个业务的 VPC，我们内部的 SaaS 服务可能会有像数据库，大数据，网络加速等等。
通过这一套 VPC 的架构我可以实现一个是跨大洲的互联，第二个混合架构互联，比如说云和第三方专线的互联，这些所有的互联都为全球通服打下了一个网络的基础。
第二部分简单介绍下我们在全球通服上面做的一些实践，我这里举一个最直接简单的例子：
可能最早的时候全球通服是一个非常简单的架构，比如说游戏服全部跑在一个中心的机房，全球玩家都连过来，假设就部署在新加坡，那美国的玩家，欧洲的玩家直连新加坡的网络可能是没办法得到保证的，因为我们刚才通过玩家网络的评测跨大洲的玩家来直连这个网络的质量其实不一定满足需求。那可能玩家先通过美国加州的入口，比如就是 AWS 加州的 Region，然后把它转发到新加坡的 Region。
大家知道 AWS 本身跨大洲之间都是有 backbone 专线互联的，这样的话玩家先就近的连到本地的 Region，然后再通过 AWS 本身的专线转化到中心机房去，这样可以提升玩家跨 Region 访问的稳定性；
但是这个方案有一个局限性就是延迟，比如说美国到新加坡的稳定性由于目前的物理极限，至少需要 100ms，有些实战类的游戏对延迟比较高的话就无法满足需求了，这时候我们可能就会去各地部署相应的战斗服，这一套架构本身确实是目前业界比较主流的方案，但是需要注意一点，就是是否需要去当地部署一个服有一个前提是当地的 DAU 作支撑，否则玩家比较少体验不佳，可能要把几个地区综合起来决策部署，比如美服一个，欧服一个，亚太服一个，这是在实践全球通服时需要注意的地方；由于时间的关系，这部分内容就不再展开描述了。
关于网易游戏在 AWS 上的实践就介绍到这里，接下来我想对我刚刚分享的内容做一个回顾，其实我们从 14 年底到现在走过了好几年海外上云的历程，在运维与基础架构层面，我们一开始是接到了业务的需求，然后针对这些需求去展开云的评测，评测完了之后可能会输出一个解决方案给到业务。
在这个解决方案的基础上进行实践，在实践的过程中我们又会遇到新的问题或者新的业务需求，针对新的业务需求再去做这一套整个的上云评估和实践，总结下来海外上云实践是这样的一个闭环。
随着网易游戏海外发行数量和规模的不断增长，业务复杂度也越来越高，现在我们也遇到了一些新的挑战，接下来分享一下我们后续计划做的一些优化或者是准备引入的 AWS 新技术。
第一是在新技术方面我们也会在积极调研测试 AWS 发布的新服务，比如说 arm 系列新实例，全球加速器，VPC TGW 等；
第二是关于容器化，游戏是比较特别的业务，有些业务已经开始做一些微服务化的改造，这也是我们接下来会尝试的一个方向；
第三是成本优化，随着体量上去之后整个的资源利用率需要我们提升的，另外预留实例在我们这边变成了一件比较复杂的事情，因为很多游戏都做了动态的伸缩，预留实例如何采购也成了新的挑战。
最后我想分享一下经过这几年海外上云实践的心得总结，希望能对大家有所启发：
第一点是实践永远是检验技术的唯一标准，一项新的技术是否值得引入需要评估测试，经过线上实践验证，能明确它能够对我们业务产生价值我们才会认为它是一项很好的技术；
第二点是我们会在满足业务需求的前提下不断寻求成本优化的解决方案；
第三点是不管是云还是游戏，每天都在快速发展，这就需要我们不断学习，寻找业务的切入点，切实满足业务需求或优化线上服务，我觉得这是我们做云架构或云解决方案的核心价值。
提问环节
我的分享差不多就到这里，大家有兴趣可以关注此公众号，里面有很多技术干货的文章，现在大家如果说有什么问题可以提出来。
主持人：机会难得，我们谢谢网易游戏的孙老师。我们这边开放给大家问答的时间，因为时间有限，所以我们限制三个问题。刚才听完这么精彩的分享之后不知道大家有没有问题可以趁这个机会请教孙老师，包括可能有游戏架构或者是海外碰到问题，或者是说可能在采取某些服务或者是策略的时候会有一些想法，欢迎大家举手发问。
提问：孙老师好，我刚才听到你说的 VPC 那边有一个是做网络加速的，我想知道网易那边网络加速这一块主要在哪些事情方面做网络加速？
孙国良：网络加速其实就是我刚才提到的，AWS 本身当然是有很强大的基础设施的，可能在某些点上我们还会引入一些加速。比如说我刚才提到的从美国的用户访问新加坡的服，那默认的情况下它是不是会只连新加坡。那这时候我们做的话让它先就近的连到美国当地的 AWS Region，然后转发到我新加坡实际的游戏服上面，这个就是其中优化的一个点。这样子避免美国的玩家直连新加坡会出现一些不稳定的情况，因为如果说先连到美国的 AWS 入口再到新加坡的话就可以直接享受到 AWS 本身的骨干网，这是其中的一点我们做的网络加速的服务。
提问：我想问一下你们有没有评测过通过 AWS 的加速。
孙国良：这个问题问的非常好，到底走这一条链路是不是能带来优化？这个东西其实是我们在客户端 SDK 有专门的探针探测玩家直连新加坡跟我玩家先到美国的 AWS 再到新加坡的 AWS 这之间做一个实时探测的比较，在连之前探测一下哪条链路最优，然后去 pick 其中的一条链路，这是在游戏客户端的 SDK 中集成实现的。
提问：那你这边用的是 AWCDN 还是用全球网络加速那一块？
孙国良：CDN 虽然说有边缘计算，但是它的边缘计算暂时来说还没办法运行我们目前的网络加速的业务逻辑，所以更多的是利用 AWS 的数据中心。第二个就是说我们可能会考虑一些第三方的专线，当然了 AWS 的 Lambda 其实我们最近也在做一些调研了，希望能借助这些新服务优化加速的服务。
往期精彩
﹀
﹀
﹀
转载自原文链接, 如需删除请联系管理员。
原文链接：网易游戏《荒野行动》《阴阳师》等出海实践－AWS技术峰会演讲实录，转载请注明来源！