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