乐趣区

关于阿里云:Game-On-ServerlessSAE-助力广州小迈提升微服务研发效能

作者:洛浩

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

在小迈外部,履行扁平化的治理格调,每个业务团队都能够独立抉择采纳更适宜本人的技术栈和基础架构,因而外部呈现了 ECS,K8s,SAE(Serverless 利用引擎)三种不同计算平台共存的场面,而且都在跑微服务架构,不同的计算平台都有本人独特的劣势和价值,而同样也会面临各自的挑战,目前次要在应用 SAE 平台的次要是游戏团队。

为什么抉择 SAE

对于大部分休闲类游戏来讲,首先游戏自身存在本人的生命周期,而在生命周期内,游戏自身会呈现十分大的波峰波谷。比方,白天比早晨流量大的多,白天流量又集中在几个工夫点,而早晨 8 点是业务的最高峰,凌晨 2 点到 6 点简直没有流量,然而又不能停服。另外,在游戏刚上线的时候,每次经营流动又会拉来大量的新客户涌入,就须要后盾服务可能疾速响应流量的变动,所以业务方就冀望能有一种主动弹性伸缩的计算平台。其次,大部分休闲类游戏都是无状态的,还能够拆分成不同的服务模块来晋升服务性能和品质,如聊天、红包、背包、降级、用户数据获取、视频解决、广告投放等,因而就能够采纳微服务架构来部署。最初游戏在上线期间,也会迭代减少很多新的功能模块,须要频繁的公布降级。所以业务方在选型的时候,就会综合思考:

  1. 零碎的稳定性和容灾能力
  2. 平台的主动弹性伸缩能力
  3. 对微服务架构的反对
  4. 便捷的公布回滚能力,甚至是不停服降级

这些能力,其实通过 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 利用上云的复杂度。

对 Serverless 感兴趣的同学,还能够点击​​ 此处 ​​查看更多案例和文章。

退出移动版