游戏案例|Service Mesh 在欢乐游戏的应用演变和实践
陈智伟,腾讯 12 级后台专家工程师,现负责欢乐游戏工作室公共后台技术研发以及团队管理工作。在微服务分布式架构以及游戏后台运维研发有丰富的经验。
前言
机器资源利用率极低,集群内 CPU 峰值平均利用率不足 20%; 服务治理能力不足,由于存在多套研发框架且服务管理方式不同,导致整体业务的维护以及基础服务治理能力的研发成本较高; 服务部署十分繁琐,自动化不足,耗时耗力,且容易出外网问题; 大量的陈旧业务服务缺乏维护,陈旧服务可视化能力不足,质量不易保证; 整体架构较为复杂,新人上手成本较高,可维护性不足; 每年机房裁撤都要耗费较大人力成本;
研发框架以及架构升级,实现低成本无感平滑演进至服务网格
存量业务代码无需调整,重编即可支持 gRPC 协议;
网格服务之间调用,使用 gRPC 通信;
云下服务调用网格服务,既可以使用私有协议也可以使用 gRPC 协议;
网格服务调用云下服务,使用 gRPC 协议;
旧业务可平滑灰度迁移至网格内;
兼容 Client 侧的私有协议请求;
原有架构引入 gRPC
使用 MeshGate 桥接网格以及云下服务
架构演变
网格内私有协议的接入服务
Lotus 集群的运维十分繁琐;因为为了防止用户游戏过程中出现链接的断开导致的不好体验,Lotus 进程的停止,需要等待用户侧主动断开,而新链接则不会发送给待停的 Lotus 中,简而言之,Lotus 的停止需要排空已有长链接,这也导致 Lotus 的更新需要等待较长的时间。我们有统计过,每次全网更新发布 Lotus 版本需要持续数天的时间。而遇到问题、裁撤或者新增节点时,其变更需要人工调整全网配置策略,且需要执行十多项步骤,整体效率较低。 Lotus 集群的资源利用率低;由于 Lotus 是最基础的服务,且部署不方便,因此为了应对业务流量的变化,就要预留出充足的机器资源。但这也导致了 Lotus 的资源利用率较低,日常 CPU 峰值资源利用率仅 25% 左右;
核心业务场景下的私有协议转发性能以及延迟开销与云下环境接近;针对核心的业务场景,我们做过相应的压力测试,Envoy 在支持私有协议之后,其接入转发的性能开销以及时延与云下直连属于同一个量级。其中测试时延,如下表所示: 场景 平均耗时 P95 耗时 云下直连 0.38ms 0.67ms K8s pod 间转发 0.52ms 0.90ms Istio + TCP 转发(私有协议) 0.62ms 1.26ms Istio + gRPC 转发 6.23ms 14.62ms 天然支持 Istio 的服务治理能力,更贴近云原生 Istio 下的使用方式; 通过 Helm 部署以及定义 Controller 管理,实现一键服务上架以及滚动更新;整个升级是自动的,且过程中实现排空更新能力,并考虑会负载能力,排空效率更优。 由于支持自动伸缩能力,接入服务无需预留过多的资源,因此可以大幅降低资源开销;全量云化后接入集群的 CPU 节省 50%-60%,内存节省了近 70% 左右。
架构演变
GameSvr 上云
运维繁琐;单台 GameSvr 上下架需十余步人工操作,每年不停服机器裁撤需要耗费数周的人力,且容易发生事故;
资源利用率低;同样因为扩缩不易,就需预留足够的资源,做冗余部署,导致高峰期 CPU 利用率仅 20% 左右;
整体的容灾能力弱,宕机后需人工介入处理;
对局调度不灵活,都是依靠人工配置静态策略;
资源利用率上获得大幅提升;整体 CPU 以及内存的使用都减少了近 2/3。 运维效率获大幅提升;通过自定义 CRD 和 Controller 的管理,实现 Helm 一键部署整个集群,上下架十分便捷,仅一个业务项目组每个月因发布 GameSvr 都可以有效节省人力近 10 人天; GameSvr 可根据当前集群的负载压力变化以及历史负载压力的时间序列实现可靠自动伸缩; 实现了灵活可靠的单局调度能力;通过简单的配置,即可实现单局根据不同的属性,调度到不同的 Set 中。且在调度的过程中,也会考虑负载和服务质量,最终实现整体调度的较优选择。
架构演变
数量庞大的 CGI 上云
业务种类较多,现网部署约 350 种 CGI 服务,且流量巨大; CGI 同步阻塞的进程模型,导致其单进程的吞吐量极低;大部分 CGI 业务的 QPS 仅个位数,且存在 Apache 的服务调度以及消息分发的性能开销; CGI 之间的资源隔离性差;因为 CGI 是同机多进程部署,极易出现由于某个业务 CGI 突然资源开销暴增,影响其他业务 CGI 的情况;
针对头部流量 CGI 进行协程异步化改造,剥离 Apache,使框架性能获数十倍提升。
在框架层实现监听 http 请求以及异步化:
使用 http-parser[4] 改造,使得框架自身就支持 http 监听以及处理; 基于 libco[5] 改造,使框架底层支持协程,从而实现异步化; 在业务层,也需要针对性做各类适配性处理:
针对全局变量,进行私有化或者关联至协程对象管理;
后端网络、io、配置加载以及内存等资源做各类复用化优化,提升效率;
架构演变
自研存储业务迁移
研发了适配代理服务,即上图所示的 Cube2TcaplusProxy,将 CubeDB 私有协议适配转换至 TcaplusDB,那么新业务的存储就可以直接使用 TcaplusDB 了; 在 CubeDB 的备机同步业务的热数据,在开启同步之后,TcaplusDB 就有业务的最新数据; 将冷数据导入至 TcaplusDB,如果 TcaplusDB 中有记录数据,说明它是最新的,则不覆盖; 全量比对 MySQL 与 TcaplusDB 的数据,多次校验全量通过后则切换 Proxy 的路由;
架构演变
多集群的部署模式
总结
参考资料
Istio: 【https://istio.io/latest/about/service-mesh/】
[2]服务治理能力: 【https://istio.io/latest/about/service-mesh/】
[3]Envoy: 【https://www.envoyproxy.io/】
[4]http-parser: 【https://github.com/nodejs/http-parser】
[5]libco: 【https://github.com/Tencent/libco】
[6]腾讯云服务网格 TCM:【 https://cloud.tencent.com/product/tcm】
往期精选推荐