如今，游戏行业对于云原生技术的使用越来越广泛。特别是那些拥有海量玩家在线的游戏，使用云原生技术可以轻松做到高可用、弹性扩容和降低成本。在GDC 2022上，来自《Sky光·遇》项目的工程师分享了相关的经验——《《Sky光·遇》实现百万在线：一种云原生的扩容方法》（Sky’s Journey to 1MM CCU: A Cloud Native Approach To Scaling）。PPT可点击链接获取。
《Sky光·遇》是著名华人游戏设计师陈星汉的作品。这位才华横溢的游戏设计师曾经依靠《风之旅人》获得过GDC 2013年度游戏大奖。《Sky光·遇》是他旗下的Thatgamecompany在手游领域的第一次尝试。
分享者在TGC工作了两年，目前领导微服务架构和云平台开发，在此之前有6年的软件工程师经验。
100万在线峰值就像是《Sky光·遇》山顶上最高的建筑顶端，到达这个目标前有很多有挑战性的问题需要解决，例如：
- 有限的工程资源。
- 遗留架构。
- 单点应用：包括非分布式的Erlang、6千行的Postgres函数、同步API（读写强一致性、HTTP Post通信）。
- 功能有限的游戏引擎。
- 单一的Postgres分片。
- 缺少持续集成（CI）、持续部署（CD）。
PostgreSQL：简称Postgres，一种常见的关系型数据库，具有丰富的数据类型和强大的索引，在国外应用比国内更多。
CI：持续集成（Continuous Integration），意为多名开发者并行开发不同功能时，可以频繁将代码合并而互不影响工作。
CD：持续部署（Continuous Deployment），意为基于工具实现代码从构建、测试到部署上线的自动化全流程。
他们的解决方案有：
- 划分微服务：包括高QPS的NoSQL、MongoDB按特性分片、分布式事务、命令查询职责分离（CQRS）、异步API。
- 引入基于事件的系统：Kafka、最终一致性。
- 改进游戏引擎：包括引入Gameplay工程师、非关键资源调用静默失败、核心游戏循环使用同步API、非核心游戏循环使用异步API、通过WebSocket处理局部更新。
CQRS：命令查询职责分离（Command Query Responsibility Segregation），一种读写分离的架构模式，将请求API分为读（查询）和写（命令）两种不同类型。
分享者刚接手项目时，遗留架构是这样的：
- 开发、QA、产品都在同一个虚拟私有云（VPC）中。缺点是不同应用环境没有隔离，不安全且容易出错。
- 每个可用区（AZ）只有一个子网（Subnet）。问题是没有做公有私有子网分离，部分对内服务也能被外部访问，不安全。
- 部分应用部署在单AZ上，部分应用横跨多个AZ。缺点是单AZ无法保证高可靠性。
云服务中的三个概念：
Region：区域。提供云服务的一个物理区域，用户就近接入，通常一个Region包含多个AZ。
AZ：可用区（Availability Zone）。一个资源隔离和容错区域，是一个或多个物理中心的集合。为了高可用性，一个Region中通常包含多个AZ，从而做到同城物理容灾。
VPC：虚拟私有云（Virtual Private Cloud）。面向租户的私有虚拟网络环境，VPC之间相互隔离。VPC一般位于同一个Region中，但可能横跨多个AZ。
为了解决原有架构中的问题，新的基础设施平台被设计成包括如下特性：
- 云原生：快速迭代。
- 高可用性：跨多个AZ。
- GitOps：使用Git 来管理基础架构和应用配置，是实现DevOps的一种方式。
- 开源软件（FOSS）：使用开源软件来做云诊断。
- 被管理的服务：DB、计算以及合作方。
新的基础设施平台如下图所示，可以看出它具有原架构所没有的几个优点：
- 每个环境一个VPC，开发、QA和产品彼此隔离。
- 每个AZ下都有公有和私有子网，公有子网对外，私有子网对内。
- 所有应用都部署在多个AZ上。
- 每套环境中都有独立的数据层和事件总线。
位于新基础设施平台上的应用架构有如下特点：
- 云原生。
- 厂商中立：各种厂商的同类产品可以自由替换。
- 十二要素应用（The Twelve-Factor App）：定义了应用开发应遵循的原则。
- 六边形架构（Hexagonal Architecture）：使得组件之间可以自由替换，并且在开发组规模扩大时方便协同工作。
The Twelve-Factor App：十二要素应用，又名12-Factor，它定义了一个优雅的、适应云环境的互联网应用在设计过程中，需要遵循的一些基本原则。具体可参见它的官网。
Hexagonal Architecture：六边形架构，也称为端口适配器架构（Ports and Adapters Architecture），是一种软件设计模式，旨在将业务逻辑与技术实现分离开来，从而使系统更易于测试、维护和演化。
使用微服务并使用容器部署，会带来如下优点：
- 单独的仓库及数据库。
- 提升可测试性和可维护性。
- 方便快速部署。
- 清晰的代码责任划分。
- 方便使用不同的技术栈：例如在客户支持系统中使用了ExpressJS。
CQRS可以保证读写分离，主节点负责写，从节点负责读，这样有助于降低主节点的压力。数据一致性方面，保证强一致性写和弱一致性读。
再来谈谈分布式事务。分布式事务本质上是对于多个DB的写，希望整体保证ACID特性。一种实现方式是通过多次调用和重试，但这样是不可靠的。另一种实现方式是两阶段提交（Two-Phase Commit），它能保证强一致性，但是会阻塞而且较慢，所以并不推荐。分享者推荐的实现是使用Saga，它具有稍弱的一致性，但是非阻塞而且执行速度快，能保证最终的数据一致性。
Saga是一种补偿事务，它的运行逻辑是：将分布式事务看作一组事务组成的事务链，链中的每一个正向事务操作，都对应一个可逆的事务操作。Saga 事务协调器负责按照顺序执行事务链中的分支事务，分支事务执行完毕，即释放资源。如果某个分支事务失败了，则按照反方向执行事务补偿操作。
以下是使用Saga处理收件箱中物品赎回的示意图：
微服务需要有效的监测手段，大致可分为数据监测、分布式追踪、日志三类。分别有不同的开源工具可供使用。
还需要持续地对线上服务做性能剖析，包括对CPU、堆和协程。这样有助于定位问题，发现线上性能瓶颈。
最终，《Sky光·遇》团队实现了支撑100万在线的目标。同时收获了一套易扩容、快迭代、一键部署、占用人力少的新架构。
在分享最后，分享者谈了他对微服务的理解。有种观点认为，微服务是万能的，不管什么服务，只要去拆可以了。他认为这样会容易掉入陷阱，因为微服务也会增加架构复杂度，而且很多大型单点应用并不适合拆分成分布式。正确的做法应该是传统方式和微服务的结合，既有大型单点应用，也有若干微服务，根据实际情况来灵活处理。
