游戏案例｜Service Mesh 在欢乐游戏的应用演变和实践

作者

陈智伟，腾讯 12 级后台专家工程师，现负责欢乐游戏工作室公共后台技术研发以及团队管理工作。在微服务分布式架构以及游戏后台运维研发有丰富的经验。

前言

欢乐游戏工作室后台是分布式微服务架构，目前稳定承载着多款游戏，数千万 DAU 以及数百万级在线。原有云下架构脱胎于 QQGame 后台，核心架构已有 10 多年的历史，其中使用了多套目的不同的自研开发框架，自研基础组件，并为适应繁杂的业务场景，衍生出不同的服务模型，最终积累了数百个微服务，整体简化架构如下所示：

在这种大规模平台化的后台系统和复杂多样的业务架构下，还要持续创造更大的业务价值，这给团队带来了较大的挑战和压力。简单列举几个问题：

• 机器资源利用率极低，集群内 CPU 峰值平均利用率不足 20%；
• 服务治理能力不足，由于存在多套研发框架且服务管理方式不同，导致整体业务的维护以及基础服务治理能力的研发成本较高；
• 服务部署十分繁琐，自动化不足，耗时耗力，且容易出外网问题；
• 大量的陈旧业务服务缺乏维护，陈旧服务可视化能力不足，质量不易保证；
• 整体架构较为复杂，新人上手成本较高，可维护性不足；
• 每年机房裁撤都要耗费较大人力成本；

在云原生时代，借着公司全面“拥抱云原生”的东风，我们深度结合 K8s 以及 Istio 能力，逐模块拆分，细致梳理，经历过各类有状态、无状态服务的上云，协议改造，框架改造适配，服务模型云原生化，数据迁移，完善云上周边服务组件，建立云上服务 DevOps 流程等等众多系统性工程改造。最终，在不停服、平滑兼容过渡的前提下，将整体架构的服务云化以及网格化。

在整体架构上云技术方案选型上，我们权衡了各类方案的完备性、可扩展性以及改造维护成本等因素，最终选择使用 Istio 服务网格作为整体上云的技术方案。

接下来，我将按照原有架构演进的线路，简单介绍部分模块的上云方案。

研发框架以及架构升级，实现低成本无感平滑演进至服务网格

为了接入 Istio 以及服务能够平滑过渡，在基础框架和架构上做了较多适配性调整，最终可以实现：

1. 存量业务代码无需调整，重编即可支持 gRPC 协议;
2. 网格服务之间调用，使用 gRPC 通信；
3. 云下服务调用网格服务，既可以使用私有协议也可以使用 gRPC 协议；
4. 网格服务调用云下服务，使用 gRPC 协议；
5. 旧业务可平滑灰度迁移至网格内；
6. 兼容 Client 侧的私有协议请求；

接下来，对其中部分内容做简要说明。

原有架构引入 gRPC

考虑到需要更全面应用 Istio 的服务治理能力，我们在已有开发框架中引入了 gRPC 协议栈。同时为了兼容原有的私有协议的通信能力，使用 gRPC 包装私有协议，并在开发框架层以及架构层都做了兼容性处理。开发框架结构示意图如下所示：

使用 MeshGate 桥接网格以及云下服务

为了使得云上 Istio 中的服务，能够与云下服务互通，我们研发了 MeshGate 服务桥接云上网格以及云下服务。