Game On Serverless：SAE 助力广州小迈提升微服务研发效能

Game On Serverless：SAE 助力广州小迈提升微服务研发效能

作者：洛浩

小迈于 2015 年 1 月成立，是一家致力以数字化领先为优势，实现业务高质量自增长的移动互联网科技公司。始终坚持以用户价值为中心，以数据为驱动，为用户开发丰富的工具应用、休闲游戏、益智、运动等系列的移动应用。累计开发 400 余款产品，累计用户下载安装量破七亿。而在未来三年内，小迈以成为全球领先开发者增长服务平台为愿景及使命，希望通过标准化的产品和服务赋能，为开发者提供全链路解决方案，以技术+服务全方位保驾护航，助燃产品持续增长，帮助工具和休闲游戏的开发者提升产品的成功率。

在小迈内部，实行扁平化的管理风格，每个业务团队都可以独立选择采用更适合自己的技术栈和基础架构，因此内部出现了 ECS，K8s，SAE（Serverless 应用引擎）三种不同计算平台共存的局面，而且都在跑微服务架构，不同的计算平台都有自己独特的优势和价值，而同样也会面临各自的挑战，目前主要在使用 SAE 平台的主要是游戏团队。

为什么选择 SAE

对于大部分休闲类游戏来讲，首先游戏本身存在自己的生命周期，而在生命周期内，游戏本身会出现非常大的波峰波谷。比如，白天比晚上流量大的多，白天流量又集中在几个时间点，而晚上 8 点是业务的最高峰，凌晨 2 点到 6 点几乎没有流量，但是又不能停服。另外，在游戏刚上线的时候，每次运营活动又会拉来大量的新客户涌入，就需要后台服务能够快速响应流量的变化，所以业务方就期望能有一种自动弹性伸缩的计算平台。其次，大部分休闲类游戏都是无状态的，还可以拆分成不同的服务模块来提升服务性能和质量，如聊天、红包、背包、升级、用户数据获取、视频处理、广告投放等，因此就可以采用微服务架构来部署。最后游戏在上线期间，也会迭代增加很多新的功能模块，需要频繁的发布升级。所以业务方在选型的时候，就会综合考虑：

系统的稳定性和容灾能力平台的自动弹性伸缩能力对微服务架构的支持便捷的发布回滚能力，甚至是不停服升级

这些能力，其实通过 ECS 或者 K8s 自建也都能实现，但是会给业务团队带来大量的运维成本，而且很难平衡成本的投入。尤其是在弹性方面，自建弹性效率很难满足流量的快速变化，往往还是需要冗余大量的资源。而 SAE 可以非常好的满足以上 4 个需求。其实小迈的游戏团队早在 SAE 公测期间，就开始关注试用 SAE 了。截止到目前，在 SAE 上累计已经部署了 50 多个服务和应用，涉及十几款游戏，比如爱上猜成语、成语最强答人、我找茬贼快、答多多、欢乐找找茬、多多短视频等，感兴趣的话可以下载 APP 试玩下。

SAE 落地实践

Serverless 应用引擎 SAE 定位是容器之上的一站式应用托管平台，核心价值是给用户提供全应用生命周期管理、微服务治理、弹性免运维的 K8s 运行环境。本质上，用户的代码最终还是运行在容器里，只是这个容器不用去维护管理。因此对于存量的游戏服务来讲，可以零改造直接迁移部署到 SAE 上。而且 SAE 针对 JAVA 应用，还提供了 JAR 包直接部署的模式，省去了小迈打镜像的步骤，和原有使用 ECS 的模式非常接近，但是使用体验上会更加简单，大概的对比如下：

SAE 比较核心的能力就是高可用和自动弹性，对于小迈的游戏团队，在部署 JAR 包的时候可以勾选多可用区，就能达到跨可用区的容灾。SAE 底层其实是会提供多个分布在不同可用区的 K8s 集群，承载业务的容器实例可以在多可用区自动调度。对于弹性的配置同样也非常简单，可以基于 CPU、内存、QPS、RT 等指标来进行设置，对于小迈的线上游戏，主要还是通过CPU和内存的使用率来触发扩缩，同时还能指定最大实例数和最小实例数，非常的便捷。而且目前定时弹性和监控指标弹性还可以混用，那么对于有运营活动时，就可以通过两种弹性方式共同使用的方式，来确保资源的弹性。但是这里需要注意的是监控指标的阈值，需要根据业务的实际情况来配置，建议上线前，通过压测来明确。

另外通过应用监控，也能非常方便的查看到服务接口的调用情况，这些能力都已经默认集成到了 SAE 的平台上，对业务排障很有帮助。

最后在小迈的游戏团队，主要采用的是 Spring Cloud 和 Dubbo 技术栈，因此对微服务治理能力的支持，也是非常必要的。目前 SAE 的控制台上，可以直接配置微服务的健康检查、优雅下线脚本、配置管理、微服务的灰度发布、一键回滚等。但是在实际使用的过程，也踩过一些坑，比如在做服务发布的时候，健康检查有时候会超时导致实例不停重启，因为有时候服务会加载大量的数据和类库，启动比较耗时。加大健康检查的超时时间可以降低出现概率，但是发布时间就会拉长。而且在服务刚启动的时候，初始响应比较慢，其实是服务还没有完全 ready，这里就比较依赖 SAE 提供微服务优雅上线的能力，可以确保服务的正常上线。另外对于分批发部，为了避免负载的流量突然打到新实例，这里比较推荐使用微服务流量百分比灰度能力。经过一段时间的实践，最后落地的业务架构大致如下：

小迈的游戏团队基本只用关注业务逻辑，资源层面托管给了 SAE 平台，极大的简化了运维复杂度。另外为了应对业务的快速迭代，小迈还采用 Jenkins 封装了 SAE 的 API 接口，实现了 CI/CD 能力，极大加速了服务的上线速度。对比原来的弹性效率和部署效率，整体研发效能有了极大的提升，弹性速度从分钟级缩短到了妙级，新项目上线速度从天级缩短到了分钟级。

总结和展望

1、SAE 在微服务领域提供了 Serverless 化的运行平台，给用户提供了降本增效的新选择。另外 SAE 底层采用的是托管的 K8s 集群，也给用户做容器化转型提供了最简单的方式。

2、SAE 在应用管理和微服务治理方面的加成，使得 SAE 成为有别于容器服务的一站式应用 PAAS 平台，让用户可以专注在业务迭代。

3、针对应用的管理，SAE 还提供了环境“一键启停”功能，比如针对开发测试环境，可以设置定时关闭和开启，优化非线上环境的资源占用，可以帮助小迈进一步优化费用。

4、针对 JAVA 应用，SAE 提供了 DragonWell JDK 版本，可以加速 JAVA 应用的启动速度和线程资源的消耗，启动速度大约可以节省 40% 的耗时。

5、未来，SAE 还会不断提升弹性效率、加强应用管理层面的功能迭代，期望给用户带来更多的增值体验，比如刚发布支持 PHP 的 ZIP 包部署能力，可以简化 WEB 应用上云的复杂度。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。