KMS在腾讯云的微服务实践助力其降本50%

背景介绍

KMS 是一家日本的游戏公司,主要经营游戏业务、数字漫画业务、广告业务、云解决方案业务等,出品了多款在日本畅销的漫画风游戏,同时有网络漫画专业厂牌,以内容创作为目标,拥有原创 IP 创作、游戏开发等多元化发展的业务。

KMS 曾经是微软 Azure 的标杆客户,曾经在 Azure 的 Customer story 里有详细的介绍,主要是使用了 Azure 的 App Service。

2021年,KMS 开始迁移到腾讯云,并把第一款产品部署在了腾讯云上。从 Azure 迁移到腾讯云上后,整体成本降低50%。下面我们就来讲讲他们在腾讯云上的微服务实践。

挑战与痛点

KMS 的架构主要有以下特点:

  1. KMS 的架构设计的特点是围绕不同的游戏有不同的终端。

  2. 但同时又有统一的后台管理平台、统一的底座等。

  3. 客户在游戏场景的不同的客户端主要包括安卓,iOS,Web 等。此外,客户后端又分为战斗系统、管理系统、用户系统等。

  4. 游戏业务通常都有波峰波谷,在业务高峰期的时候需要快速扩容来支持大量的游戏玩家;在业务低峰期的时候,需要缩容来节约成本。

那么基于此类场景的架构设计,面临最大的问题就是在游戏的不同时间段的弹性扩缩容问题。不同的业务模块需要弹性的频率和范围都是不一样的。不同的微服务划分会带来不一样的弹性伸缩频率和范围。这直接影响到了最终资源的用量,也就直接反应到了成本上。

架构设计

接下来就分别把 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 和腾讯云能有更多的合作,分享更多的架构设计经验和上云最佳实践。

相关推荐
Java程序之猿12 小时前
微服务分布式(一、项目初始化)
分布式·微服务·架构
Yvemil714 小时前
《开启微服务之旅:Spring Boot Web开发举例》(一)
前端·spring boot·微服务
Yvemil718 小时前
《开启微服务之旅:Spring Boot Web开发》(二)
前端·spring boot·微服务
维李设论18 小时前
Node.js的Web服务在Nacos中的实践
前端·spring cloud·微服务·eureka·nacos·node.js·express
jwolf220 小时前
基于K8S的微服务:一、服务发现,负载均衡测试(附calico网络问题解决)
微服务·kubernetes·服务发现
Yvemil71 天前
《开启微服务之旅:Spring Boot Web开发举例》(二)
前端·spring boot·微服务
一个儒雅随和的男子1 天前
微服务详细教程之nacos和sentinel实战
微服务·架构·sentinel
Yvemil71 天前
《开启微服务之旅:Spring Boot Web开发》(三)
前端·spring boot·微服务
Java程序之猿1 天前
微服务分布式(二、注册中心Consul)
分布式·微服务·consul
Hello Dam1 天前
面向微服务的Spring Cloud Gateway的集成解决方案:用户登录认证与访问控制
spring cloud·微服务·云原生·架构·gateway·登录验证·单点登录