2022 年 8 月 30 日，阿里云用户组（AUG）第 9 期活动在北京举办。活动现场，阿里云网络解决方案架构师任江波，向参会企业代表分享了全球一张网，支撑游戏业务高效互联。本文根据演讲内容整理而成。

在座的很多我都认识，因为我自己就是看游戏行业的。大家其实有过很多次交流，包括一些产品、技术和方案。

之前每次去交流，大都是针对具体某个问题，你问我答，或者深陷某个细节去讨论，比较离散，所以还是想借着今天这个机会，相对体系化的和大家分享讨论下。

游戏业务场景分布图

上一位同事已经讲过公网、加速、还有资源布局，我这边主要分享内网的场景。我们去看游戏业务场景的分布，其实就这么几个，比如说玩家通过公网去访问游戏大厅、访问游戏服，游戏服内网调用平台服。游戏项目的业务系统有可能是在阿里云上，也有可能在 IDC，或者是在其他云上。

除此之外，还有线下的分支职场，海外的研发中心等，很多客户还不止一个分支职场，这些云下分支如何与云上不同地域的业务系统内网打通，实现高效开发、测试和运维的闭环？其接下来的分享我们重点讨论内网互联这一块最佳方案实践。

游戏出海的关键网络挑战

这张图上的 5 大网络挑战，大家重点关注橙色的 3 个：

第一个挑战是：跨服、跨平台的数据传输质量和稳定性如何保证；

第二个挑战是：平台服的高可用集群如何搭建，容器化改造的长远规划；

第三个挑战是：开发和运维人员，如何管理跨域、甚至跨境的服务平台，以及设备的远程运维。

针对这几个问题，我们接着往下看。

业务全球互联实践大图

首先看一个大图，这张图基本上覆盖了云上业务，云下分支职场、IDC、以及海外分支、研发中心等，用这张图分层去看每个小的业务场景。虽然很多客户是一开始就长在云上的，但还有不少客户带着一些历史包袱，比如 IDC 内有业务系统，甚至说有一些是异构云上的业务系统，这个时候势必涉及到多云互联或者说混合云的这种架构。所以说整体方案框架提前规划很重要。

第一个是账号的划分：

对于一个客户来说，可能有很多个账号。账号的划分原则是什么？可以有两个维度，一是不同的子公司用不同的账号，二是不同的项目组用不同的账号。比如游戏客户，大多是按照一个又一个游戏项目来划分的。

第二个是 VPC 划分：

账号开好了，如何合理设计和规划 VPC？粒度是啥？有三个维度：

维度一：按业态划分，把不同的项目部署在不同的 VPC 里面。也有客户会在一个账号里面部署所有的资源，这个适合于小游戏。

维度二：按业务层次划分，比如游戏客户，从游戏服、平台服到后面的数据库，你可以分层去部署。这个有点类似于传统 IDC 内的分区架构设计，把不同的业务层就在不同的 VPC 里面。对于大的业务层，可以考虑按照功能模型再次拆分。

维度三：按照生产关系划分，开发、测试、生产，放在不同的VPC里面，方便管理，减少故障影响面。

第三个是路由互通设计：

VPC 内部本身是天然互通的，VPC 之间相互隔离。虚拟专有网络 VPC，可以认为它是一个虚拟的 mini IDC，它横跨阿里云上单个地域 Region 内的所有可用区 AZ。所以，VPC 内部署好不同的业务系统后，另一个重要的事情就是跨 VPC 之间的路由如何打通？

每个账号有独立的云企业网 CEN（类似一个超级虚拟路由器，进行路由学习和传播），VPC 接入 CEN 的转发路由器 TR 实现 VPC 之间的相互路由学习和传播。

还有一个很重要的点，云下可能存在多个不同形式的分支，对于一个运维人员来说，如何打通云上云下这么多复杂的路由节点？这里也是需要通过 CEN-TR 来实现云上云下的路由学习和访问互通。云下分支入云有三种姿势，分别是专线、SDWAN、VPN 隧道，质量依次降低，费用也依次降低，我们可以根据云下分支的规模、业务量、稳定性要求等维度按需选择。

打通之后，可能有人还会问，说 CEN 之间能不能打通？NO！CEN 之间明确是不能打通的，CEN 即是最大的一个路由边界。这个是我们做云上网络规划时的基础之一，虽然是基础的，但如果规划不好，后续的业务演进可能都会受到一些限制。

两个特殊的互通场景：

1、跨账号、跨主体的业务互通：第一个小场景：对于大型的游戏公司，可能会有总线型的服务，类似大数据平台、算法分析训练平台等，为不同的子公司/项目/游戏提供资源共享，大家都会去调用它。不同的游戏服，不同的项目组，对于共享平台的资源消耗也会有不同的考核，需要独立核算成本支出，做资产划分，成本分摊。

第二个小场景：游戏其实也是一个产业链，涉及到众多上下游伙伴之间的业务互通，比如有一些提供 AI 算法模型的公司，为游戏开发公司提供支持，这个如何快速互通实现数据获取，且要方便管理，还能最小入侵。

针对这两种场景，我们可以使用私网连接 privatelink 方案，它是一个服务化，4 层互通的方式，可以做到跨账号，也可以跨公司互连。

2、跨路由域的互通：第一个小场景：

因为业务需要，需要和其他子公司 or 其他项目的业务系统路由互通，但又不能相互影响；
方案：采用多 VPC 方式，让该 VPC 同时接入其他账号下的 CEN 中，实现按需的路由打通；
第二个小场景：

跨项目之间做融合创建业务，需要共同投入资源，分解开发，组合使用；
方案：采用 ShareVPC，提供一个共享的私有网络环境，参与的项目各自部署资源。
这几个特殊场景的方案实践，我们在后续的章节展开介绍。接下来我们按照平台服搭建、业务间内网互通、运维管理几个场景展开讨论：

平台服搭建

平台服集群部署方案选择

游戏的平台服作为后端的数据支撑，重要程度不亚于战斗服。不少客户会使用 Nginx 构建平台服的集群，因为灵活性强，比如说修改报文头、添加路由调度规则等，但是你要为此付出更高的运维成本，以及学习和试错成本。阿里云的最佳实践也是负载均衡，是一个产品族，这个产品族里面有不同定位、匹配不同场景的产品。

以前的 SLB，我们现在叫 CLB，它是一个经典产品，相比现在 ALB 和 NLB 使用的云上 NFV 架构，CLB 属于老一代的物理架构。使用过 CLB 的客户都知道，他既能做 4 层的负载，也能做 7 层的负载，但是它的 7 层能力较弱，只有 HTTP/HTTPS 两种监听模式。新一代云原生弹性架构，我们按照使用场景把产品拆的更细，功能和特性也更加场景化，所以就有了 ALB 和 NLB。

ALB 面向应用层，主打 7 层，能监听更多协议像 HTTP/HTTPS/QUIC，路由规则也非常丰富。NLB 面向网络层，主打 4 层，可以监听 TCP/UPD/TCP SSL，拥有更加出色的弹性能力和并发能力。

新架构的 LB 还有一个更大的好处就是随业务的自动弹性伸缩，以前买 CLB 时，要选规格，所以客户要提前去评估业务模型和性能指标，QPS 是多少，CPS 是多少，并发是多少，吞吐是多少，然后再去计算到底买哪个规格比较划算。现在这些烦恼都没有了，你只要买一个实例就 OK 了，纯按量付费，如何计量呢？

我们有一个最小的计费单元 LCU（也是最小的性能单元），里面包含 QPS、CPS、并发数量、以及对应的吞吐量。业务在涨的时候，会触发阈值，LCU 就会弹出来更多，这个时候你的成本也会上升。业务在波谷的时候，流量减少，他自己也会随着缩回去，自动删除多余的 LCU，这时候费用自然就降下来了。所以说你不用算，也不用管，创建一个实例，把业务挂上去就 ok 了，剩下交给 LB 自动驾驶就好了，他会给你一个最优的性价比。

在游戏的平台服建设场景中，我们更推荐使用 ALB，因为更匹配业务需求：

第一：ALB 提供两种接入方式，一个是 Cname 域名，另一个是 vIP（公网 EIP 或着私网 IP），公网型实例会自动弹出 EIP，并自动加入指定的共享带宽包中。DNS 侧可以按需配置 A 记录或者 Cname 记录即可。

第二：后端 RS 类型丰富，ECS、ECI、 ENI、IP target，IP target 就是你可以自己写一个后端 IP，最大的好处是可以跨地域挂载机器，甚至挂载 IDC 内的机器。

第三：丰富的路由转发规则，你在 Ngnix 上面能配出来的规则，ALB 基本都可以。除过正向的路由规则，还有反向的路由规则。比如 client 请求 server 的时候，有固定的 action 动作，在回包时，可以再做一个反向的路由规则保证原路原格式返回。

第四：天然的容器入口，容器是一个趋势，大家都在做容器的技术体系升级改造，让业务弹性、灵活、降本增效。容器前面一定是要有一个入口的，叫做 Ingress 入口，ALB 可以天然做这个 Ingress 入口，而且可以做双份的，比如做预发环境，蓝绿发布，灰度发布等。

平台服安全联动最佳组合

在游戏场景里面，安全防护也非常重要，特别是对于新上线的游戏，公网的入口都是重点防护的对象。

其中平台服，可能承接玩家的注册、登陆、交易、排行榜等，网络和安全的能力结合起来才能更好的保障业务运行，一个是跟 WAF 结合，另一个是跟 DDOS 结合。

ALB 和 WAF 联动，ALB 可以一键开启 WAF 防护能力，避免繁琐的配置，目前 WAF 演进到 3.0 版本，它是服务化的方式，无需再在 WAF 上配置防护的 IP，在 WAF 的服务模块可以直接在下拉框里面去选择 ALB 实例。

ALB 和 DDOS 联动，比如新游上线，被攻击的概率比较高。DDOS 串联部署，可能影响正常玩家的访问体验，我们可以把它旁挂在旁边，就变成终端请求到 DNS，DNS 解析之后，会到 DDOS，DDOS 上流调器会去识别出正常流量和攻击流量。如果是正常流量，直接给到 ALB，转发到到后面的业务服务器上。如果触发防护阈值，会引到 DDOS 池做清洗，然后再按 IP 的方式转发给 ALB，再转发到业务服务器上。这样就可以在安全防护和玩家访问延迟之间形成了一个平衡点。

业务间内网互通

跨地域业务间内网互通模型选择

平台服务部署完成后，游戏服和平台服有可能分布在不同的地域的，也有可能是云上云下的架构，这时就要保证高效稳定的内网互通。内网互通我们提供了两种方式：第一种是对等连接 peering；第二种云企业网转发路由器 TR，这两个方案高低搭配，按需使用。怎么个高低搭配法呢？

左边的架构图中有三个 VPC，一个 VBR 是（挂专线），需要在任意两个实例之间去建 peer，然后手工配置静态路由。实例数量越多，配置也就约繁琐，而且它的适用规模比较小，更友好于 IDC 初步上云的场景。

右边的这个架构比较灵活，中间有一个 CEN，CEN 里面有北京地域的 TR 和上海地域的 TR，云上有很多的开发、测试 VPC，也会涉及到多个地域之间的互联，可以把 VPC 和 VBR 都加入各自地域的 TR，实现自动/手动的按需互通。这个架构比较灵活，而且规模大，更方便业务的长期演进。

云上云下业务间内网互通方案实践

看左边这个似曾相识的图，是一个传统的 IDC 机房，里面的网络架构是一个简化图，从 IDC 拉一条专线接到阿里云的任意一个 POP 点即可实现云上云下的内网互通。

互通简单，如何有效简单的满足 IDC 上云的各种诉求，比如路由端到端隔离，业务专线带宽保障等，这个需要精细化去设计。对于一个大型的公司，以前 IDC 承载多个子公司的业务系统，直接物理分区隔离即可，但是上云需要一个过程，长期云上云下共存不可避免，端到端隔离的诉求一下子就出来了。上云后的业务系统通过多个 UID、多 VPC 的设计很容易实现，在云上云下共存期间，总不能拉多条专线，太浪费了。其实复用一条专线就可以，直接给专线上做一个二层通道的划分，操作也简单，就是在 VBR 上增加一个 VLAN 的配置，和 IDC 侧专线互联设备上路由子接口的 VLAN ID 匹配即可，配置简单又省钱。

有的客户说还不够，虽然专线通了，但我觉得还不够安全，我还想给它加一个安全防护。当然必须可以，只需在云上搞一个私网 VPN 网关，IDC 侧利旧已有的防火墙，在专线之上打一个 IPSec 加密隧道即可。

高效利旧+演进三步走

IDC 业务搬站上云过程中，推荐的三步走：

第一步：部分系统上云，云上云下都有，单通道覆盖的时候，建议还是对等连接搞定了，因为便宜，而且规模比较简单。

第二步：云上业务比重逐步增大，可以考虑我们刚才提到的多个二层通道，多个 VBR 的方式，加入 CEN-TR 中，利用 TR 上面的多张路由表能力，实现简单的端到端隔离。

第三步：业务快速发展，业务规模会越来越庞大。这个时候建议采用多个账号的架构，做到完全的资产隔离，业务隔离。对于一些特殊的互通需求，前面提到的多 VPC 和共享 VPC 即可搞定。

这是一个发展的过程，大家可以选择最适合自己的一个阶段去使用。

上下游伙伴间业务互通最佳姿势

举个例子：公司 A 和公司 B 因为业务发展需要，有数据共享和业务接口相互调用的诉求；但是考虑到数据安全性，不希望双方的网络直接互通。传统实现方式有两种：

第一种：为了简单，直接通过互联网访问，但这样做数据容易被恶意窃取、或者攻击。

第二种：进行内网打通，但需要各自配置前置的数据交换 VPC，在两个前置 VPC 之间做 peer，并且在业务 VPC 和前置 VPC 之间配置复杂的安全访问策略，这样做缺点是配置复杂，管理困难。当然也有直接把两边三层路由打通的，但是这样网络侵入太大，很难管控，安全隐患极高。

针对此场景，我们推荐使用私网连接 private-link，简单说，它是四层通三层不通，而且是单向访问，所以可以有效避免网络侵入、地址冲突、公网不安全等问题。

还是上面的这个例子，A 公司是数据提供方，B 公司是数据使用方，那我们在 A 公司的账号里面创建终端节点服务，B 公司的账号里面创建终端节点，然后终端节点发起向终端节点服务的单向访问请求即可。这个过程中可以做安全控制，比如说服务端要给访问端加白名单，访问端才能可见服务端，比如访问端发起对服务端的连接，需要经过服务端审批，才能成功连接。

假如某一天，服务端想主动去访问客户端，推送一些数据，也可以轻松搞定。在这个服务里面，加一个私网 NAT，就可以反向去访问了。但是这个权限控制也是很严的，首先不能做三层的路由侵入，而且权限必须要双方同意之后，才能反向连接成功。

同时，还可以通过这个能力做到资产划分、账单划分等能力。相比于传统的实现，私网连接使用更加简单、更加安全、更加灵活。

运维管理

游戏出海，运维通道搭建运维通道搭建，业务系统可能在国内，也有可能在海外。

运维人员去做配置、管理和维护，首先需要把职场和云上打通。如果有专线直接利用专线就好，没有专线架个 VPN 也行，如果觉得 VPN 配起来麻烦，也可以用 SD-WAN 解决方案，放一台硬件设备在职场，它会自动且就近的连到阿里云，和云上内网打通。内网上云之后，开一台堡垒机去跳转一下，按需访问云里面的资源即可。简单、方便、又不安全性地做运维。

万一业务运行中出现故障，抓不住现场，难以定位。没关系，我们提供流量日志和流量镜像的能力，让你像使用 IDC 一样，轻松完成 troubleshooting。

今天分享的内容就这么多，感谢大家聆听！

阿里云网络解决方案架构师任江波：全球一张网，支撑游戏业务高效互联