在技术架构的多次迭代升级中，有一项非常重要的工作，就是将游戏场景中通用的业务能力进行抽象，从游戏主服中进行剥离，沉淀到统一服务层，以模块化的方式同时支撑的多个游戏品类。从主服中剥离出来的业务能力包括账号管理、IM、内容安全、会员体系、信息推送、游戏行为分析等多个方面，这样做首先降低了游戏主服的业务复杂度，使主服专注于对核心游戏场景的支撑。此外，通用的能力可以在多个游戏品类中得到复用，从而降低研发成本，提升研发效率。
能力拆分和业务耦合度降低，为持续迭代和新技术预研提供了便利，也为在云原生Serverless领域深入探索创造了契机。Serverless架构可以充分发挥计算资源的快速弹性能力，是云计算的重要发展方向。在游戏领域，游戏主服承载着复杂的核心业务逻辑，需要长期运行，并与多个玩家终端进行极低延迟的数据交互，因此仍然需要通过虚拟机或容器的方式承载。从主服中剥离的游戏周边业务场景，就成为了试点Serverless技术架构的首选目标。
每次进入游戏界面，我们都能看到用着不同语言、顶着不同国旗标志的玩家，愉快的交流着各种和游戏相关的话题。
在这个业务场景中，通过提供一个简单的在线翻译功能，就将全球各地的玩家凝聚到一起，带来前所未有的用户体验。
从0到1开发一款包含全球几十种语言的实时翻译工具显然是不现实的。好在游戏玩家之间的相互交流往往言简意赅，翻译的结果并不需要100%准确就能心领神会，反而对于后台处理的及时性有比较高的要求。像Google Translator这样的在线平台已经提供了强大的在线翻译能力，所以只需要将玩家的请求进行简单预处理后，就可以把翻译的工作转发到第三方平台来完成。
这是一个非常简单的功能，但在技术架构的实现上，还是具有一定挑战的。每个时间段同时在线的玩家数量都不是完全均等的，存在明显的波峰波谷，当同时在线的玩家数量比较大的时候，就会产生非常大的聊天量。而且聊天量还不会简单的跟玩家在线数量成正比关系，遇到某些热点事件的时候，会引发全球玩家的热议，需要在线翻译的消息量也会陡增，这就需要一套可弹性伸缩的架构来处理玩家的翻译请求。
最初的架构是通过负载均衡SLB和基于EasySwoole框架的PHP应用集群来实现的。
在这个架构中，通过PHP编写的主体应用对玩家的翻译请求进行一系列的预处理，包括符号代码的替换以及敏感内容的过滤等，然后转发到第三方翻译平台获取翻译结果。这是一套非常被广泛采用的拥有高并发处理能力的技术架构，在云计算时代，可以借助于云资源的弹性伸缩特性，使整个集群的吞吐量随着业务量的变化而动态调整。但基于云原生的视角来看，这套架构在生产环境大规模运行的时候还是存在一些不完美之处。
1. 维护工作量大。整套系统的维护工作量涵盖了虚拟机、网络、负载均衡组件、操作系统、应用等多个层面，需要投入大量的时间和精力来保障系统的高可用性与稳定性。举一个最简单的例子，当某个应用实例出现故障的时候，如何第一时间定位故障并尽可能迅速的将其从计算集群中摘除呢？这些都需要再配合完整的监控机制以及故障隔离恢复机制来实现。
2. 弹性伸缩能力滞后。不论是通过定时任务，还是通过指标阈值（CPU利用率、内存使用率等）来触发弹性扩容，都没有办法基于实际请求量精细化管理，在遇到聊天请求密度大陡增的时候，会面临弹性伸缩能力滞后的问题。即便通过Kubernetes以及预留资源池等技术优化，扩容一个新的实例也往往需要几分钟的时间。
3. 资源利用率低。滞后的弹性伸缩能力会导致伸缩策略制定得相对保守，造成资源利用率的下降，最直接的表现是增加了资源成本：
基于阿里云函数计算FC的Serverless方案有什么优势？
有没有一种方案能能帮助技术团队专注于业务逻辑的实现，并可以根据玩家的实际请求量进行精细化的资源分配，从而实现资源利用最大化呢？随着云计算的飞速发展，各大云厂商都在积极探索新的方案，用更加“云原生”的思路来解决成本和效率的问题，基于阿里云函数计算FC的Serverless方案就是这个领域的杰出代表。
函数计算FC是事件驱动的全托管计算服务，通过函数计算，开发者无需管理服务器等基础设施，只需编写代码并上传，函数计算会为自动准备好计算资源，以弹性、可靠的方式运行业务逻辑，并提供日志查询、性能监控、报警等附加功能，确保系统的稳定运行。
相比传统的应用服务器保持运行状态并对外提供服务的方式，函数计算最大的区别是按需拉起计算资源对任务进行处理，在任务完成以后自动的回收计算资源，这是一种真正符合Serverless理念的方案，能最大化的提升资源利用率，减少系统系统维护工作量和使用成本。因为不需要预先申请计算资源，使用者完全不需要考虑容量评估和弹性伸缩的问题，只需要根据资源的实际使用量来进行付费。
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架构，在拥抱新技术的同时充分享受到云计算的红利。