年 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。
今天分享的内容就这么多,感谢大家聆听!
阿里云网络解决方案架构师任江波:全球一张网,支撑游戏业务高效互联