客户案例公司图标
BpClientCase(id=87, title=广州小迈网络科技有限公司, thumbnail=https://channel-static-resource-online.oss-cn-hangzhou.aliyuncs.com/bp-admin/sr-A41GIDWJ5KZO5MID.png, status=1, sort=1, tagList=[BpClientTag(id=1, name=互联网, status=1, sort=1), BpClientTag(id=5, name=游戏, status=1, sort=1)], extensionList=[BpClientCaseExtension(id=4302, title=客户简介, description=

小迈于2015年1⽉成⽴,是⼀家致力以数字化领先为优势,实现业务高质量自增长的移动互联⽹科技公司。始终坚持以⽤户价值为中⼼,以数据为驱动,为用户开发丰富的⼯具应⽤、休闲游戏、益智、运动等系列的移动应用。累计开发400余款产品,累计⽤户下载安装量破七亿。而在未来三年内,小迈以成为全球领先开发者增长服务平台为愿景及使命,希望通过标准化的产品和服务赋能,为开发者提供全链路解决⽅案,以技术+服务全⽅位保驾护航,助燃产品持续增长,帮助⼯具和休闲游戏的开发者提升产品的成功率。
在小迈内部,实⾏扁平化的管理风格,每个业务团队都可以独立选择采⽤更适合自己的技术栈和基础架构,因此内部出现了ECS,K8S,SAE(Serverless 应⽤引擎) 三种不同计算平台共存的局⾯,而且都在跑微服务架构,不同的计算平台都有自己独特的优势和价值,而同样也会面临各⾃的挑战,⽬前主要在使⽤SAE平台的主要是游戏团队。

, sort=4, simpleDescription=小迈于2015年1⽉成⽴,是⼀家致力以数字化领先为优势,实现业务高质量自增长的移动互联⽹科技公司。始终坚持以⽤户价值为中⼼,以数据为驱动,为用户开发丰富的⼯具应⽤、休闲游戏、益智、运动等系列的移动应用。累计开发400余款产品,累计⽤户下载安装量破七亿。而在未来三年内,小迈以成为全球领先开发者增长服务平台为愿景及使命,希望通过标准化的产品和服务赋能,为开发者提供全链路解决⽅案,以技术+服务全⽅位保驾护航,助燃产品持续增长,帮助⼯具和休闲游戏的开发者提升产品的成功率。在小迈内部,实⾏扁平化的管理风格,每个业务团队都可以独立选择采⽤更适合自己的技术栈和基础架构,因此内部出现了ECS,K8S,SAE(Serverless 应⽤引擎) 三种不同计算平台共存的局⾯,而且都在跑微服务架构,不同的计算平台都有自己独特的优势和价值,而同样也会面临各⾃的挑战,⽬前主要在使⽤SAE平台的主要是游戏团队。), BpClientCaseExtension(id=4301, title=为什么选择SAE, description=

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

1. 系统的稳定性和容灾能⼒

2. 平台的⾃动弹性伸缩能⼒

3. 对微服务架构的⽀持

4. 便捷的发布回滚能⼒,甚⾄是不停服升级

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

, sort=3, simpleDescription=对于大部分休闲类游戏来讲,⾸先游戏本⾝存在自己的⽣命周期,而在生命周期内,游戏本⾝会出现非常⼤的波峰波谷。⽐如,⽩天⽐晚上流量大的多,白天流量⼜集中在⼏个时间点,而晚上8点是业务的最⾼峰,凌晨2点到6点⼏乎没有流量,但是⼜不能停服。另外,在游戏刚上线的时候,每次运营活动又会拉来⼤量的新客户涌⼊,就需要后台服务能够快速响应流量的变化,所以业务⽅就期望能有⼀种⾃动弹性伸缩的计算平台。其次,⼤部分休闲类游戏都是⽆状态的,还可以拆分成不同的服务模块来提升服务性能和质量,如聊天、红包、背包、升级、⽤户数据获取、视频处理、⼴告投放等,因此就可以采⽤微服务架构来部署。最后游戏在上线期间,也会迭代增加很多新的功能模块,需要频繁的发布升级。所以业务方在选型的时候,就会综合考虑:1.系统的稳定性和容灾能⼒2.平台的⾃动弹性伸缩能⼒3.对微服务架构的⽀持4.便捷的发布回滚能⼒,甚⾄是不停服升级这些能力,其实通过ECS或者K8S⾃建也都能实现,但是会给业务团队带来⼤量的运维成本,⽽且很难平衡成本的投入。尤其是在弹性⽅⾯,⾃建弹性效率很难满⾜流量的快速变化,往往还是需要冗余⼤量的资源。而SAE 可以⾮常好的满⾜以上 4 个需求。其实⼩迈的游戏团队早在 SAE 公测期间,就开始关注试⽤ SAE 了。截止到⽬前,在 SAE 上累计已经部署了 50 多个服务和应⽤,涉及十几款游戏,⽐如爱上猜成语、成语最强答⼈、我找茬贼快、答多多、欢乐找找茬、多多短视频等,感兴趣的话可以下载 APP 试玩下。), BpClientCaseExtension(id=4300, title=SAE落地实践, description=

Serverless 应⽤引擎 SAE 定位是容器之上的⼀站式应⽤托管平台,核心价值是给⽤户提供全应⽤⽣命周期管理、微服务治理、弹性免运维的K8S运⾏环境。本质上,⽤户的代码最终还是运⾏在容器里,只是这个容器不⽤去维护管理。因此对于存量的游戏服务来讲,可以零改造直接迁移部署到 SAE 上,参考阿⾥云最佳实践《微服务应⽤的Serverless(SAE)部署》,⼩迈快速完成了接⼊SAE的过程。⽽且 SAE 针对 JAVA 应⽤,还提供了 JAR 包直接部署的模式,省去了小迈打镜像的步骤,和原有使⽤ ECS 的模式⾮常接近,但是使⽤体验上会更加简单,⼤概的对⽐如下:


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


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


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