背景介绍
![]()
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 和腾讯云能有更多的合作，分享更多的架构设计经验和上云最佳实践。
