做者 | 山猎、王勇猛、张羽
来源|阿里巴巴云原生公众号前端
江娱互动是一家新兴的游戏企业,自 2018 年成立伊始,江娱互动就面向广阔的全球游戏市场,经过创造有趣的游戏体验,在竞争激烈的游戏市场占得一席之地。仅仅 2 年的时间,江娱互动就凭借 Topwar(口袋奇兵)单款产品跻身中国游戏厂商出海 30 强。在“中国游戏,将来可期”的使命下,江娱互动正在不断丰富旗下的游戏品类,但愿把更多的快乐带给全球玩家。缓存
随着业务的飞速增加,游戏服务端的系统规模和系统复杂度正在经历着翻天覆地的变化。幸运的是,江娱互动拥有一支极具战斗力的技术团队,虽然团队的总体规模不大,但他们一直保持着对前沿技术领域的探索,经过多种手段维持系统架构的技术先进性,以更好地支撑业务需求,并下降 IT 成本。安全
在技术架构的屡次迭代升级中,有一项很是重要的工做,就是将游戏场景中通用的业务能力进行抽象,从游戏主服中进行剥离,沉淀到统一服务层,以模块化的方式同时支撑江娱互动的多个游戏品类。从主服中剥离出来的业务能力包括帐号管理、IM、内容安全、会员体系、信息推送、游戏行为分析等多个方面,这样作首先下降了游戏主服的业务复杂度,使主服专一于对核心游戏场景的支撑。此外,通用的能力能够在多个游戏品类中获得复用,从而下降研发成本,提高研发效率。服务器
能力拆分和业务耦合度下降,为持续迭代和新技术预研提供了便利,也为江娱互动在云原生 Serverless 领域深刻探索创造了契机。Serverless 架构能够充分发挥计算资源的快速弹性能力,是云计算的重要发展方向。在游戏领域,游戏主服承载着复杂的核心业务逻辑,须要长期运行,并与多个玩家终端进行极低延迟的数据交互,所以仍然须要经过虚拟机或容器的方式承载。从主服中剥离的游戏周边业务场景,就成为了试点 Serverless 技术架构的首选目标。网络
在线翻译业务是最先进行 Serverless 试点的场景,这和江娱互动的全球化战略有关。江娱互动的旗舰做品《口袋奇兵》是一个面向全球市场的游戏,吸引着世界各地的玩家。每次进入游戏界面,咱们都能看到用着不一样语言、顶着不一样国旗标志的玩家,愉快的交流着各类和游戏相关的话题。架构
在这个业务场景中,经过提供一个简单的在线翻译功能,就将全球各地的玩家凝聚到一块儿,带来史无前例的用户体验。这类简单易用的设计也是《口袋奇兵》在各大应用市场都能屡获高分好评,获得玩家的盛赞的缘由之一。并发
对于江娱互动而言,从 0 到 1 开发一款包含全球几十种语言的实时翻译工具显然是不现实的。好在游戏玩家之间的相互交流每每言简意赅,翻译的结果并不须要 100% 准确就能心照不宣,反而对于后台处理的及时性有比较高的要求。像 Google Translator 这样的在线平台已经提供了强大的在线翻译能力,因此只须要将玩家的请求进行简单预处理后,就能够把翻译的工做转发到第三方平台来完成。负载均衡
这是一个很是简单的功能,但在技术架构的实现上,仍是具备必定挑战的。每一个时间段同时在线的玩家数量都不是彻底均等的,存在明显的波峰波谷,当同时在线的玩家数量比较大的时候,就会产生很是大的聊天量。并且聊天量还不会简单的跟玩家在线数量成正比关系,遇到某些热点事件的时候,会引起全球玩家的热议,须要在线翻译的消息量也会陡增,这就须要一套可弹性伸缩的架构来处理玩家的翻译请求。框架
最初的架构是经过负载均衡 SLB 和基于 EasySwoole 框架的 PHP 应用集群来实现的。 less
在这个架构中,经过 PHP 编写的主体应用对玩家的翻译请求进行一系列的预处理,包括符号代码的替换以及敏感内容的过滤等,而后转发到第三方翻译平台获取翻译结果。这是一套很是被普遍采用的拥有高并发处理能力的技术架构,在云计算时代,能够借助于云资源的弹性伸缩特性,使整个集群的吞吐量随着业务量的变化而动态调整。但基于云原生的视角来看,这套架构在生产环境大规模运行的时候仍是存在一些不完美之处。
维护工做量大。整套系统的维护工做量涵盖了虚拟机、网络、负载均衡组件、操做系统、应用等多个层面,须要投入大量的时间和精力来保障系统的高可用性与稳定性。举一个最简单的例子,当某个应用实例出现故障的时候,如何第一时间定位故障并尽量迅速的将其从计算集群中摘除呢?这些都须要再配合完整的监控机制以及故障隔离恢复机制来实现。
弹性伸缩能力滞后。不管是经过定时任务,仍是经过指标阈值(CPU 利用率、内存使用率等)来触发弹性扩容,都没有办法基于实际请求量精细化管理,在遇到聊天请求密度大陡增的时候,会面临弹性伸缩能力滞后的问题。即使经过 Kubernetes 以及预留资源池等技术优化,扩容一个新的实例也每每须要几分钟的时间。
有没有一种方案能能帮助技术团队专一于业务逻辑的实现,并能够根据玩家的实际请求量进行精细化的资源分配,从而实现资源利用最大化呢?随着云计算的飞速发展,各大云厂商都在积极探索新的方案,用更加“云原生”的思路来解决成本和效率的问题,基于阿里云函数计算 FC 的 Serverless 方案就是这个领域的杰出表明。
函数计算 FC 是事件驱动的全托管计算服务,经过函数计算,开发者无需管理服务器等基础设施,只需编写代码并上传,函数计算会为自动准备好计算资源,以弹性、可靠的方式运行业务逻辑,并提供日志查询、性能监控、报警等附加功能,确保系统的稳定运行。
相比传统的应用服务器保持运行状态并对外提供服务的方式,函数计算最大的区别是按需拉起计算资源对任务进行处理,在任务完成之后自动的回收计算资源,这是一种真正符合 Serverless 理念的方案,能最大化的提高资源利用率,减小系统系统维护工做量和使用成本。由于不须要预先申请计算资源,使用者彻底不须要考虑容量评估和弹性伸缩的问题,只须要根据资源的实际使用量来进行付费。
对于在线翻译这样的简单业务逻辑实现,从传统架构迁移到 Serverless 架构是垂手可得的事情。江娱互动把每条由玩家发起的翻译请求当成函数计算的一次任务,拉起对应的计算资源进行处理,任务完成以后自动将资源释放。由于江娱互动的技术团队对 Java 语言的熟悉程度最高,在 Serverless 改造过程当中换用 Java 语言来实如今线翻译功能,同时也能充分利用 Java 系丰富的生态能力。固然,函数计算并不限制使用特定的开发语言,也不局限于特定的业务逻辑,主流的开发语言均可以很是好的支持。经过 Serverless 化改造后,在线翻译业务的系统架构变得更为简单。
配置了 HTTP 触发器的函数能够直接响应玩家发起的请求,并经过弹性可靠的方式调度相应的计算资源进行处理。因为函数计算的任务分配可以彻底匹配前端用户流量的变化,负载均衡 SLB 就再也不有用武之地,能够从架构中直接移除。同时,长驻运行的应用集群也再也不须要,函数计算平台可以快速拉起大量计算资源并发执行任务,并确保整套架构的高可用性。其中,Redis 的做用是缓存一部分高频的简单语句,减小第三方平台的依赖。这样的架构简化给江娱互动技术团队带来的最大惊喜,是再也不须要进行容量规划以及弹性伸缩管理工做,让团队能够集中精力实现业务需求,并在更多的领域实现业务创新。
相比 Node.js 等语言,Java 实例在初始化以及类加载等方面须要消耗的时间会比较长,尽管函数计算 FC 已经经过多种优化实现计算资源毫秒级拉起,但每每一个 Java 程序真正投入运行须要几秒钟的时间,这对于在线翻译这样的延时敏感型业务是一个很是不利的因素。阿里云提出的解决方案是经过单实例多并发,以及预留实例这两项技术来解决延迟敏感型业务遇到的问题。
经过单实例多并发,能让每一个拉起的函数计算实例,并发处理多达 100 个任务,以此减小平均执行时长,节省费用,并下降冷启动的几率。经过预留实例优化,可以根据函数的负载变化提早分配好计算资源,使系统可以在扩容按量实例时仍然使用预留实例处理请求,从而完全消除冷启动带来的延时毛刺。
改造后的在线翻译业务采用彻底按需使用计算资源的 Serverless 架构,可以充分利用云计算的弹性能力。在成本方面,因为应用再也不须要长期运行对外提供服务,可让云资源的使用量彻底匹配实际的业务量的变化,从而实现平均资源利用率的大幅提高。在系统的吞吐量方面,因为函数计算 FC 可以在短期内迅速调集上万个实例的计算资源,可以在业务高峰期或用户请求突增的状况下支撑海量并发,并且再也不须要有容量评估方面的前期工做;在系统维护方面,因为不须要预留计算资源,也不须要对底层的软硬件进行维护,极大地下降了运营成本,让江娱互动的技术团队更专一于复杂业务逻辑的实现以及技术创新上。在线翻译场景中,相比于传统的架构,基于函数计算 FC 的 Serverless 方案能够帮助江娱互联节省 40% 以上的 IT 成本投入。
另一个让江娱互动感觉到研发效率明显提高的,是函数计算 FC 提供的版本与别名管理功能。版本至关于服务的快照,支持使用者为服务发布一个或多个版本,配合别名机制,能够实现软件开发生命周期持续集成、持续发布,并用最便捷的方式实现服务的灰度迭代。
在后续的架构优化中,江娱互动将尝试经过机器学习技术尽量多的对原始内容进行预处理,以减小对于第三方平台的依赖。在 AI 推理领域,依然能够利用 Serverless 架构的优点,经过预先训练好的深度学习模型,在短期内调度大量计算资源进行大规模并行处理。
在线翻译场景试点 Serverless 技术成功后,江娱互动继续在更多业务领域发掘跟 Serverless 技术相匹配的场景,在 Push 推送服务、内容安全、游戏行为分析等领域都引入了 Serverless 技术。将来,江娱互动将继续基于自身的技术特色不断深刻探索 Serverless 架构,在拥抱新技术的同时充分享受到云计算的红利。