如今,游戏行业对于云原生技术的使用越来越广泛。特别是那些拥有海量玩家在线的游戏,使用云原生技术可以轻松做到高可用、弹性扩容和降低成本。在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万在线的目标。同时收获了一套易扩容、快迭代、一键部署、占用人力少的新架构。
在分享最后,分享者谈了他对微服务的理解。有种观点认为,微服务是万能的,不管什么服务,只要去拆可以了。他认为这样会容易掉入陷阱,因为微服务也会增加架构复杂度,而且很多大型单点应用并不适合拆分成分布式。正确的做法应该是传统方式和微服务的结合,既有大型单点应用,也有若干微服务,根据实际情况来灵活处理。文章来源:https://www.toymoban.com/news/detail-471072.html
文章来源地址https://www.toymoban.com/news/detail-471072.html
到了这里,关于近年GDC服务器分享合集(三): 《Sky光·遇》实现百万在线:一种云原生的扩容方法的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!