App Store
Steam网易游戏运维实践：服务架构及全球通服－AWS峰会演讲实录
导读：AWS作为网易游戏海外发行的重要选择之一，为网易游戏在全球运营过程中提供极大便利，在4月27日AWS游戏开发者大会深圳站上，网易游戏资深云解决方案工程师Bruce代表网易团队带来了《网易游戏海外AWS实践分享》。
上一期，学院君推送了Bruce分享的网易游戏在《阴阳师》《荒野行动》《第五人格》《明日之后》等多款游戏出海运营过程中积累的实践经验。
本次，Bruce将为大家介绍网易游戏在AWS上面的一些运维实践。
以下是分享实录：
之前提到，我们基于海外发行和国内发行的差异和挑战，会从基础架构层面出发，建立起一套标准化的云评测体系，来评估一个游戏是否能发行到公有云，以及哪个云能够满足需求标准。
我们在经过评测之后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的内网互联；
通过这一套VPC的架构，我可以实现互联，一个是跨大洲的互联，第二个混合架构互联，比如说云和第三方专线的互联，这些所有的互联都为全球通服打下了一个网络的基础。
二、全球通服务实践
第二部分简单介绍下我们在全球通服上面做的一些实践，我这里举一个最直接简单的例子：
可能最早的时候全球通服是一个非常简单的架构，比如说游戏服全部跑在一个中心的机房，全球玩家都连过来，假设就部署在新加坡，那美国的玩家，欧洲的玩家直连新加坡的网络可能是没办法得到保证的。
因为我们刚才通过玩家网络的评测跨大洲的玩家来直连这个网络的质量其实不一定满足需求。那可能玩家先通过美国加州的入口，比如就是AWS加州的Region，然后把它转发到新加坡的Region。
大家知道AWS本身跨大洲之间都是有backbone专线互联的，这样的话玩家先就近的连到本地的Region，然后再通过AWS本身的专线转化到中心机房去，这样可以提升玩家跨Region访问的稳定性；
但是这个方案有一个局限性就是延迟，比如说美国到新加坡的稳定性由于目前的物理极限，至少需要100ms，有些实战类的游戏对延迟比较高的话就无法满足需求了。
这时候我们可能就会去各地部署相应的战斗服，这一套架构本身确实是目前业界比较主流的方案。
但是需要注意一点，就是是否需要去当地部署一个服有一个前提是当地的DAU作支撑，否则玩家比较少体验不佳，可能要把几个地区综合起来决策部署，比如美服一个，欧服一个，亚太服一个，这是在实践全球通服时需要注意的地方。
关于网易游戏在AWS上的实践就介绍到这里，其实我们从14年底到现在走过了好几年海外上云的历程，在运维与基础架构层面，我们一开始是接到了业务的需求，然后针对这些需求去展开云的评测，评测完了之后可能会输出一个解决方案给到业务。
在这个解决方案的基础上进行实践，在实践的过程中我们又会遇到新的问题或者新的业务需求，针对新的业务需求再去做这一套整个的上云评估和实践，总结下来海外上云实践是这样的一个闭环。
三、下一步计划
随着网易游戏海外发行数量和规模的不断增长，业务复杂度也越来越高，现在我们也遇到了一些新的挑战，接下来分享一下我们后续计划做的一些优化或者是准备引入的AWS新技术。
第一是在新技术方面我们也会在积极调研测试AWS发布的新服务，比如说arm系列新实例，全球加速器，VPC TGW等；
第二是关于容器化，游戏是比较特别的业务，有些业务已经开始做一些微服务化的改造，这也是我们接下来会尝试的一个方向；
第三是成本优化，随着体量上去之后整个的资源利用率需要我们提升的，另外预留实例在我们这边变成了一件比较复杂的事情，因为很多游戏都做了动态的伸缩，预留实例如何采购也成了新的挑战。
以上就是我的分享，希望对大家有所启发。
提问环节
提问：老师你好，刚才你提到VPC有一个是做网络加速的，请问网易主要是在哪些方面做网络加速呢？
Bruce：网络加速其实就是我刚才提到的，AWS本身当然是有很强大的基础设施的，可能在某些点上我们还会引入一些加速。
比如说我刚才提到的从美国的用户访问新加坡的服，那默认的情况下它是不是会只连新加坡，那这时候我们就让它先就近连到美国当地的AWS Region，然后转发到新加坡实际的游戏服上面，这是其中优化的一个点。这样避免美国的玩家直连新加坡会出现一些不稳定的情况，如果说先连到美国的AWS入口再到新加坡的话就可以直接享受到AWS本身的骨干网。
提问：我想问一下你们有没有评测过通过AWS的加速。
Bruce：这个问题问的非常好，到底走这一条链路是不是能带来优化？这个东西其实是我们在客户端SDK有专门的探针，探测玩家直连新加坡跟我玩家先到美国的AWS再到新加坡的AWS这之间做一个实时探测的比较，在连之前探测一下哪条链路最优，然后去pick其中的一条链路，这是在游戏客户端的SDK中集成实现的。
提问：那你这边用的是AWCDN还是用全球网络加速那一块？
Bruce：CDN虽然说有边缘计算，但是它的边缘计算暂时来说还没办法运行我们目前的网络加速的业务逻辑，所以更多的是利用AWS的数据中心。第二个就是说我们可能会考虑一些第三方的专线，当然了AWS的Lambda其实我们最近也在做一些调研了，希望能借助这些新服务优化加速的服务。
来源：网易游戏学院
原地址：https://mp.weixin.qq.com/s/UjuuOZHJZZ-MzqpJ5Jaw0A
上一期，学院君推送了Bruce分享的网易游戏在《阴阳师》《荒野行动》《第五人格》《明日之后》等多款游戏出海运营过程中积累的实践经验。
本次，Bruce将为大家介绍网易游戏在AWS上面的一些运维实践。
以下是分享实录：
之前提到，我们基于海外发行和国内发行的差异和挑战，会从基础架构层面出发，建立起一套标准化的云评测体系，来评估一个游戏是否能发行到公有云，以及哪个云能够满足需求标准。
我们在经过评测之后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的内网互联；
通过这一套VPC的架构，我可以实现互联，一个是跨大洲的互联，第二个混合架构互联，比如说云和第三方专线的互联，这些所有的互联都为全球通服打下了一个网络的基础。
二、全球通服务实践
第二部分简单介绍下我们在全球通服上面做的一些实践，我这里举一个最直接简单的例子：
可能最早的时候全球通服是一个非常简单的架构，比如说游戏服全部跑在一个中心的机房，全球玩家都连过来，假设就部署在新加坡，那美国的玩家，欧洲的玩家直连新加坡的网络可能是没办法得到保证的。
因为我们刚才通过玩家网络的评测跨大洲的玩家来直连这个网络的质量其实不一定满足需求。那可能玩家先通过美国加州的入口，比如就是AWS加州的Region，然后把它转发到新加坡的Region。
大家知道AWS本身跨大洲之间都是有backbone专线互联的，这样的话玩家先就近的连到本地的Region，然后再通过AWS本身的专线转化到中心机房去，这样可以提升玩家跨Region访问的稳定性；
但是这个方案有一个局限性就是延迟，比如说美国到新加坡的稳定性由于目前的物理极限，至少需要100ms，有些实战类的游戏对延迟比较高的话就无法满足需求了。
这时候我们可能就会去各地部署相应的战斗服，这一套架构本身确实是目前业界比较主流的方案。
但是需要注意一点，就是是否需要去当地部署一个服有一个前提是当地的DAU作支撑，否则玩家比较少体验不佳，可能要把几个地区综合起来决策部署，比如美服一个，欧服一个，亚太服一个，这是在实践全球通服时需要注意的地方。
关于网易游戏在AWS上的实践就介绍到这里，其实我们从14年底到现在走过了好几年海外上云的历程，在运维与基础架构层面，我们一开始是接到了业务的需求，然后针对这些需求去展开云的评测，评测完了之后可能会输出一个解决方案给到业务。
在这个解决方案的基础上进行实践，在实践的过程中我们又会遇到新的问题或者新的业务需求，针对新的业务需求再去做这一套整个的上云评估和实践，总结下来海外上云实践是这样的一个闭环。
三、下一步计划
随着网易游戏海外发行数量和规模的不断增长，业务复杂度也越来越高，现在我们也遇到了一些新的挑战，接下来分享一下我们后续计划做的一些优化或者是准备引入的AWS新技术。
第一是在新技术方面我们也会在积极调研测试AWS发布的新服务，比如说arm系列新实例，全球加速器，VPC TGW等；
第二是关于容器化，游戏是比较特别的业务，有些业务已经开始做一些微服务化的改造，这也是我们接下来会尝试的一个方向；
第三是成本优化，随着体量上去之后整个的资源利用率需要我们提升的，另外预留实例在我们这边变成了一件比较复杂的事情，因为很多游戏都做了动态的伸缩，预留实例如何采购也成了新的挑战。
以上就是我的分享，希望对大家有所启发。
提问环节
提问：老师你好，刚才你提到VPC有一个是做网络加速的，请问网易主要是在哪些方面做网络加速呢？
Bruce：网络加速其实就是我刚才提到的，AWS本身当然是有很强大的基础设施的，可能在某些点上我们还会引入一些加速。
比如说我刚才提到的从美国的用户访问新加坡的服，那默认的情况下它是不是会只连新加坡，那这时候我们就让它先就近连到美国当地的AWS Region，然后转发到新加坡实际的游戏服上面，这是其中优化的一个点。这样避免美国的玩家直连新加坡会出现一些不稳定的情况，如果说先连到美国的AWS入口再到新加坡的话就可以直接享受到AWS本身的骨干网。
提问：我想问一下你们有没有评测过通过AWS的加速。
Bruce：这个问题问的非常好，到底走这一条链路是不是能带来优化？这个东西其实是我们在客户端SDK有专门的探针，探测玩家直连新加坡跟我玩家先到美国的AWS再到新加坡的AWS这之间做一个实时探测的比较，在连之前探测一下哪条链路最优，然后去pick其中的一条链路，这是在游戏客户端的SDK中集成实现的。
提问：那你这边用的是AWCDN还是用全球网络加速那一块？
Bruce：CDN虽然说有边缘计算，但是它的边缘计算暂时来说还没办法运行我们目前的网络加速的业务逻辑，所以更多的是利用AWS的数据中心。第二个就是说我们可能会考虑一些第三方的专线，当然了AWS的Lambda其实我们最近也在做一些调研了，希望能借助这些新服务优化加速的服务。
来源：网易游戏学院
原地址：https://mp.weixin.qq.com/s/UjuuOZHJZZ-MzqpJ5Jaw0A
评论
登录 后参与讨论
暂无评论，来抢沙发
闽公网安备 35020302034348号