背景介绍
KMS 是一家日本的游戏公司,主要经营游戏业务、数字漫画业务、广告业务、云解决方案业务等,出品了多款在日本畅销的漫画风游戏,同时有网络漫画专业厂牌,以内容创作为目标,拥有原创 IP 创作、游戏开发等多元化发展的业务。
KMS 曾经是微软 Azure 的标杆客户,曾经在 Azure 的 Customer story 里有详细的介绍,主要是使用了 Azure 的 App Service。
2021年,KMS 开始迁移到腾讯云,并把第一款产品部署在了腾讯云上。从 Azure 迁移到腾讯云上后,整体成本降低50%。下面我们就来讲讲他们在腾讯云上的微服务实践。
挑战与痛点
KMS 的架构主要有以下特点:
那么基于此类场景的架构设计,面临最大的问题就是在游戏的不同时间段的弹性扩缩容问题。不同的业务模块需要弹性的频率和范围都是不一样的。不同的微服务划分会带来不一样的弹性伸缩频率和范围。这直接影响到了最终资源的用量,也就直接反应到了成本上。
架构设计
接下来就分别把 KMS 在腾讯云上的架构设计实践的几个部分分开来介绍一下。
整体设计
游戏业务通常都有各种客户端,比如安卓、iOS、网页等,为了应对不同的场景,架构设计上也应该有一定的区别。
首先,必须有 CDN 来提供静态文件的分发,包括游戏资源、安装包、图片等。这些文件底层都是存储在 COS 上的。
然后对于不同的客户端,会有不同的后端实例来承载它的流量。比如战斗系统,iOS 客户端在同一个战斗里的用户,会在同一套战斗系统的实例里。
那对于管控端来说,压力没那么大,可以所有的客户端都用同一套管控端的实例,因为它只负责一些通用的用户设置的管理等。所以通常访问的 QPS 不会太高。
下图就是 KMS 大致的整体架构图。
弹性伸缩
在游戏高峰期,对于访问压力大的服务,怎么去解决这样的流量波峰波谷呢?
KMS 是选择使用腾讯云的弹性微服务来解决。
弹性微服务(Tencent Cloud Elastic Microservice)是面向微服务应用的 Serverless PaaS 平台,实现资源 Serverless 化与微服务架构的完美结合,为用户提供一整套开箱即用的微服务解决方案。
由于它已经 Serverless 化了,因此用户不需要再关心底层资源,只需要按照自己的使用量,配置对应的弹性伸缩策略,就可以在流量波峰来的时候,实现秒级的扩容。
弹性伸缩的策略也非常丰富,支持定时伸缩与指标伸缩。
定时伸缩可以根据业务的时间特征来设置,比如游戏的高峰通常是在晚上,而上午通常都是低峰期,那么就可以定时设置,上午只保留基本的资源量,保障较小的流量正常进行,以节约资源成本。在晚上高峰期,就可以提前拉起更多的资源,以保障晚上高峰期的资源充足。
指标伸缩可以用来应对突发的流量。比如某个时间段因为某种原因突然来了大量的用户玩游戏,如果资源不足,等发现问题再扩容,可能导致用户体验差。这时就可以设置指标扩容,比如当服务的 CPU 或内存使用率达到60%用户就开始扩容,同时可以设置扩容范围,比如让实例数在1-50之间扩容。这样,就可以根据指标动态的保障用户的资源充足了。
经过 KMS 实际的测试发现,在单个实例的测试场景中,同等规格的实例,性能上腾讯云的弹性微服务比 Azure 的 App Service 高15%,游戏响应延迟降低50%。KMS迁移到腾讯云后,整体成本降低50%以上。
DevOps
游戏业务通常都会有较频繁的发布周期,以满足快速发展的游戏市场,和满足不同玩家的游戏体验。
因此快速且安全的发布也必不可少。于是 KMS 搭建了一套能在弹性微服务上快速部署的 CICD 流程。如下图所示。
首先,KMS 编写了大量的自动化测试,包括单元测试和集成测试。因为 KMS 是使用的GitHub,所以在代码提交后,就会自动触发GitHub Actions运行测试、构建、上传等操作,实现自动打包构建镜像等,最后 CD 流程会把构建好的镜像部署到弹性微服务中去。
这里的部署就需要说到 KMS 的分批发布实践了。
分批发布
KMS 原来在 Azure 的时候,做发布需要自己准备资源,并自行完成更新,同时需要自己保障过程中的滚动更新。而当他们使用了弹性微服务的发布之后发现,这个过程是如此丝滑。
首先,弹性微服务会根据当前已有的实例数,选择分几批进行升级更新。每批次的发布都可以自动执行或者手动执行。在关键的发布时,KMS 会选择手动执行,这样每批次完成后,先手动验证一下功能的正确性,再进行下一批次的发布。
如果某个批次的发布有任何问题,可以马上选择回滚,不会影响线上业务。
以上就是 KMS 在腾讯云上基于弹性微服务的分批发布实践。
其他设计
除了上面介绍到的实践之外,KMS 结合自身的业务特性,还做了很多额外的其他工作,来保障游戏服务的正常运行。
比如,为了更好的优化资源成本,KMS 会在夜间把测试环境的资源一键归零,然后在早上上班的时候一键开启。同时,此过程已经被 KMS 集成到自动化流程中,每天自动触发了。
另外,在 App Service 之前若有实例存在内存问题时,需要重启。一般都需要1个小时左右。
而 KMS 使用了弹性微服务之后,弹性微服务会对实例进行检测,若有问题会自动进行重启。这里主要是利用了弹性微服务的健康检测能力。
此外,KMS 一共有4个游戏发行平台,4套环境,KMS利用弹性微服务的环境管理,合理的分配了不同的平台,便于管理与运维,极大的提升了运维效率。
总结
KMS 是一家以内容创作和原创 IP 创作为目标的专业厂牌,曾是微软 Azure 的标杆客户,如今已经在腾讯云稳定运行超过2年了。
他们在2021年迁移到腾讯云后,通过合理的架构设计和产品使用,让他们成本降低了50%。
未来也期望 KMS 和腾讯云能有更多的合作,分享更多的架构设计经验和上云最佳实践。
往期
推荐
《腾讯云消息队列产品9月产品动态,CKafka 专业版分区上限提升》
《腾讯云微服务产品9月产品动态,TSE 云原生 API 网关日志体验全面升级》《Apache Pulsar 技术系列 - PulsarClient 实现解析》
《腾讯云消息队列 RocketMQ 5.x 系列产品重磅发布 | 新品优惠》
扫描下方二维码关注本公众号,
了解更多微服务、消息队列的相关信息!
解锁超多鹅厂周边!
戳原文,查看更多弹性微服务 TSE
的信息!
点个在看你最好看