海量在线游戏基于服务网格平滑演进_陈智伟

海量在线游戏基于服务网格平滑演进 陈智伟 腾讯光子欢乐游戏工作室/公共后台技术负责人/专家工程师 陈智伟 请插入您的照片 腾讯12级后台专家工程师，现负责欢乐游戏工作室公共后台技术研发以及团队管理工作，擅长微服务分布式架构设计以及游戏后台研运 目录 背景介绍 介绍做网格化的背景和意义 CONTENTS 架构演进过程 按架构模块逐个拆解介绍演进过程 成效总结 分享网格化的效果和心得 背景介绍 欢乐游戏工作室旗下拥有欢乐斗地主、欢乐麻将等数款国民棋牌游戏，拥有海量在线用户。与此同时，也在研MMO大世界，SLG等多种品类游戏。 欢乐工作室的游戏后台架构是全区全服的分布式微服务架构 同机部署有状态服务 私有TCP协议 HTTP协议 2 3 1 1CGI同步开发框架，单机多进程3异步开发框架，单机单 活动 活动 B A … 消息分配服务 Dispatch CGIB CGIA … 自研存储 消息中转服 GameSvr … 周边业务 存储层 •自研一套数据缓存服务 中转层 •负责微服务进程之间的消息转发，充当着路由中转，因此整个架构是星型拓扑 业务层 •多套研发框架，不同进程模型，积累了数百种微服务 •存在较多有状态服务 Apache 客户端接入网关 接入层 •使用自研客户端接入网关处理TCP私有协议的接入 •使用Apache处理HTTP协议的接入 欢乐工作室全区全服分布式微服务架构 2 协程开发框架，单机多进程 进程承载着多款游戏，支撑着百万级在线和千万级DAU， 且持续平稳地运行了近十年，但也存在较多问题 01.服务治理能力不足 02.服务运维成本高 03.开发框架成熟度低 04.巨量微服务维护困难 •流量调度能力简陋：因为耦合在开发框架、接入层和中转层之中，使用和维护成本较高 •资源利用率极低：为应对业务流量变化，大量冗余部署，集群CPU峰值利用率不足15% •易用性差：框架封装较弱，开发框架虽多，但均不够好用，且不易维护 •种类多，维护成本极高：现网积累了千余种服务，数量多，大部分服务需要人工介入维护 •缺乏服务可观测能力：全局服务质量可视化能力较差，导致问题排查效率低下 •运维乏力：在应对扩容、裁撤、节点异常、容灾等问题时，都 需要人工深度参与操作 •不合理的进程部署模型：大量的同机多进程的部署，资源隔离性较差，时常互相影响 •组织架构分拆引发问题：业务膨胀，组织架构分拆，但运行服务相互牵扯，难以分拆，不同团队间影响问题频发 随着业务持续发展，原有架构的基础能力、可维护性、易用性等等都亟待提升 不可行方案 •小修小补：在现有架构上继续打补丁优化，但维护 成本极高，将越陷越深，并非长久之计 •彻底重构：使用成熟的架构进行重构，但存量业务太多，改造成本巨大，根本无法接受 期望以较低的改造成本，来获得成熟、可靠且可持续演进的服务管理和治理能力 使用Istio将服务管理和服务治理能力下沉，让现有框架逐渐退变为业务的逻辑驱动层和胶水层，升级现有架构 Istio 腾讯服务网格（TCM） 架构演进 • 实现网 gRPC 私有协议 Istio 云下 客户端接入网关 消息中转服 云下服务1 云下服务2 网格内外互通示意图 MeshGate 云上服务B 云上服务A 核心能力 格内外服务消息互通 双向代理 •代理网格内服务注册至云下客户端接入网关与消息中转服代理网格外服务作为云上访问云下服务网关 协议互转 •私有协议与gRPC协议互转适配 增加网格适配网关MeshGate 新服务 实现收益 可在网格中部署 快速享受网格红利 •K8s的服务部署管理能力 •Istio的服务治理能力 存量无状态服务如何平滑迁移入网格？ gRPC 适配 01 引入gRPC适配 •多线程引入 •业务消息投递给gRPC线程 02 gRPCWapper •在私有协议外包一层gRPC 存量业务代码重编即适配gRPC协议 进程框架改造 2 业务逻辑线程 业务消息通道 gRPC协议私有协议 gRPCWapper 业务进程 1 进程框架改造示意图 利用消息中转服实现平滑迁移 利用消息中转服转发部分流量 •持续观察稳定性，实现平滑过渡网格 如同新增的无状态服务 •同网格内通信采用gRPC协议 •同网格外通信采用MeshGate中转 网格外服务A 网格内服务B 适配gRPC线程 消息中转服 适配gRPC线程 MeshGate 50%流量 50%流量 网格外服务B 流量灰度示意图 01灰度流量 02全量 活动A 架构引入MeshGate 无状态服务的资源成本下降70% 活…活周 动动 AB边业 Dispatch务 客户端接入网 GM周 ae s …mh G ea St e v 2r 1关接 客户端接 边业 sidecar 迁移部分有状态服务 私有TCP协议 HTTP协议gRPC协议 自研存储 云下 Istio 消息中转服 链路变长——2跳变5跳 返回链路也变长，时延还要翻倍性能损耗较大，MeshGate成为瓶颈在游戏核心交互场景中无法接受 4 5 3 务 … 2 活动B Apache 1 入网关 入网关迁移网格 CGIB CGIA 小结 开发框架支持和适配gRPC 快速实现无状态服务网格化迁移 原有客户端接入网关 用户链接管理 身份鉴权，心跳保活，反向通知等支持TCP长短链接，WebSocket 消息路由 Random，轮询，业务定制化路由等 核心功能问题分 运维能力弱，资源利用率极低 发布需要人工调度和长链接排空，全量发布持续数天时间部署不便，需冗余部署，日常高峰期CPU利用率仅15% 流量治理能力不足 不支持Http接入，无染色能力，熔断能力等 析 将接入网关直接部署在网格中，就能快速网格化，解决问题么？ 业务线程 gRPC 线程 5转2 适配反序列化6 •时延略微改善，性能未解决 时延：5跳变4跳 接入网 2私有协议 3解析gRPCHead deC 4Siar 序列化5 业务线程 性能：gRPC协议栈转换以及组解包性能 Pod 换为gRPC 向后端路由 RPC 关 转 线程 2 反序列化44转 开销较大，但整体次数没变 原 有客 3 序列化3 SideCar反序列化2 适配g 反序列化6 将接入网格直接部署到网格内 序列化5 Envoy 配gR 户 端与网格 PC Gate 适 2Mesh转1 序列化1 3SideCar 反序列化4 •开发成本并不低 接入网关 客户端 Kernel协议栈 接入服本身需要对链接做复杂管理，但 户端 业 务服务 内 通信模型 1 客接入网关 2Siar 配gR deC 客 C 网关 户端接入 转 P 适 1 序列化3 1 序列化1 反序列化2 gRPC工程封装封闭，想直接管理原始链接很繁琐 •实现个性化路由复杂 •路由完全依赖SideCar 上行消息 1 LotusPod的请求处理模型 gRPC 使用Envoy支持私有协议接入 业务线程 RPC 适配g线程 deC RPC Siar •性能时延不敏感服务 度 转换gRPC协议栈，原生流量调 •性能时延敏感服务 使用私有协议转发 不劫持业务侧入流量 但损失部分流量治理以及观测能力 私有协议 SideCar 原有客户端与网格内业务服务通信模型 适配gRPC shG Meate 户 客端接入网关 gRPC协议 1 deC Envoy Siar deC 将接入网格直接部署到网格内 适配gRPC 客户端接入网关 2 业务线程 RPC 业务线程 适配g线程 Siar 适配g线程 deC 支持私有协议接入 Envoy Siar nvo Ey 3 业务服务 私有协议转发，不劫持入流量 SideCar nvo Ey 4 方案 指标 [1] 接入网关+MeshGate [2]接入网关部署在网格内 [3] Envoy私有协议接入 [4]Envoy私有协议转发 时延 5跳 4跳 3跳 2跳 性能 协议转换 2次 2次 2次 0次 gRPC 协议栈 6次 6次 4次 0次 01 数据面扩展FilterChains 兼容业务已有能力 02 控制面扩展xDS 适配私有协议路由规则 03 自定义Controller 管理EnvoyRouter的运维 1. MsgRouterCRD kind:MsgRouterspec: msgid:100000svrName:test.serviceAport:12345 2 xDS PilotAgent Pilot Envoy MsgRouterController 1 数据面扩展 ... 业务加解密 业务层熔断、限流 业务鉴权 自定义路由 私有协议解析 私有协议转换gRPC Filterchains 转发给filter Envoy 转发路由 私有协议 2.gRPC Listener Kernel协议栈 Router xDS EnvoyRouter——处理请求流量模型 控制面扩展 压测数据 方案QPS峰值P50耗时P99耗时 原始接入网关直连 原始接入网关+MeshGate（网格）Envoy私有协议接入，gRPC转发 150,000 30,000 60,000 2倍 4ms34ms 7ms 9ms50ms 13ms 时延接近 9ms 5ms 2倍 120,000 Envoy私有协议接入，私有协议转发 4核8G，对应的线程根据资源模型做相应的调整，使用平均300字节的业务协议压测 性能和时延效果改善明显，使用Envoy私有协议接入和转发与原始接入网关相近 将Envoy改造成网格接入网关 sidecar迁移部分 有状态服务 活…活周 动动 AB边… 业 Dispatch务 客户端接入网关 私有TCP协议HTTP协议gRPC协议 CGIB CGIA … 自研存储云下 GameSvr 消息中转服 解决敏感业务时延和性能要求 接入服的资源成本减少50% 大幅提升接入服务的治理能力 Istio 有状态服务GameSvr 如何进网格？ MeshGate 周边业务 活动A 活动B ApacheEnvoyRouter 原有GameSvr架构 负 责玩家对局撮合和对局逻辑的服务 有状态服务 用户长Session 使用共享内存做数据缓存 服务需热更新，冷启动慢 消息路由特殊 定点路由 全双工，非请求应答式 调度管理复杂 •数百个不同能力的GameSvr节点，针对它们做负载压力管理和对局调度十分繁琐 多层业务架构 多个游戏 每个游戏下多种玩法 每种玩法下多个版本 云下GameSvr问题 01 服务运维繁琐且低效 •上架一个节点需人工操作10多次 •每年应对机器裁撤需投入1个月 •宕机还需人为介入，MTTR长 02资源利用率极低 •冗余部署，平均利用率不足20% •不同节点负载高低差距大 01 自定义Workload •自定义Controller管理 GameSet GameZone •多层CRD：游戏、玩法、版本、GameSvr GameSvr 镜像预热 共享内存，停启毫秒级 耗时较长，分钟级 停旧容器起新容器 部署能力 •容器热更新 •Group间金丝雀、蓝绿发布 •Group内可控滚动更新 03 智能自动伸缩 •实时预测：突增流量 •离线预测：周期性流量 •定时扩容：定点流量 优化单局调度 •撮合外置 •自动感知实时部署和Pod状态 •结合负载预测 p 02 04 GameGrou 自定义Controller管理 重构GameSvr架构模型GameSvr资源成本减少75% 实现智能HPA实现运维能力自动化，大幅提升效率 sidecar迁移部分 有状态服务 私有TCP协议HTTP协议gRPC协议 CGIB CGIA … 自研存储云下 周边业务 活动B MeshGate 消息中转服 Istio 自研存储和存量巨大的CGI服务如何进网格？ GameSvr 活动A