《海量在线游戏基于服务网格平滑演进_陈智伟.pdf》由会员分享,可在线阅读,更多相关《海量在线游戏基于服务网格平滑演进_陈智伟.pdf(34页珍藏版)》请在三个皮匠报告上搜索。
1、海量在线游戏基于服务网格海量在线游戏基于服务网格平滑演进平滑演进陈智伟腾讯光子欢乐游戏工作室/公共后台技术负责人/专家工程师陈智伟陈智伟腾讯 12 级后台专家工程师,现负责欢乐游戏工作室公共后台技术研发以及团队管理工作,擅长微服务分布式架构设计以及游戏后台研运请插入您的照片目录目录介绍做网格化的背景和意义背景介绍背景介绍按架构模块逐个拆解介绍演进过程架构演进过程架构演进过程分享网格化的效果和心得成效总结成效总结CONTENTSCONTENTS背景介绍欢乐游戏工作室概览欢乐游戏工作室概览欢乐游戏工作室旗下拥有欢乐斗地主、欢乐麻将欢乐斗地主、欢乐麻将等数款国民棋牌游戏,拥有海量在线用户海量在线用户
2、。与此同时,也在研 MMO 大世界,SLG 等多种品类游戏。原有架构概述原有架构概述中转层中转层 负责微服务进程之间的消息转发,充当着路由中转,因此整个架构是星型拓扑存储层存储层 自研一套数据缓存服务接入层接入层 使用自研客户端接入网关处理 TCP 私有协议的接入 使用 Apache 处理 HTTP 协议的接入业务层业务层 多套研发框架,不同进程模型多套研发框架,不同进程模型,积累了数百种微服务 存在较多有状态服务存在较多有状态服务CGI 同步开发框架,单机多进程协程开发框架,单机多进程2 23 31 1异步开发框架,单机单进程3 32 21 1欢乐工作室的游戏后台架构是全区全服的分布式微服务
3、架构分布式微服务架构消息中转服消息中转服客户端接入网关客户端接入网关DispatchDispatch消息分配服务消息分配服务活动A活动BGameSvrGameSvr周周边边业业务务自研存储自研存储ApacheCGI ACGI B私有 TCP 协议HTTP 协议有状态服务同机部署欢乐工作室全区全服分布式微服务架构承载着多款游戏,支撑着百万级在线和千万级百万级在线和千万级 DAUDAU,且持续平稳地运行了近十年,但也存在较多问题随着业务持续发展,原有架构的基础能力、可维护性、易用性等等都亟待提升原有架构的问题和挑战原有架构的问题和挑战流量调度能力简陋:流量调度能力简陋:因为耦合在开发框架、接入层和
4、中转层之中,使用和维护成本较高01.服务治理能力不足 缺乏服务可观测能力缺乏服务可观测能力:全局服务质量可视化能力较差,导致问题排查效率低下资源利用率极低资源利用率极低:为应对业务流量变化,大量冗余部署,集群 CPU 峰值利用率不足 15%02.服务运维成本高 运维乏力运维乏力:在应对扩容、裁撤、节点异常、容灾等问题时,都需要人工深度参与操作易用性差:易用性差:框架封装较弱,开发框架虽多,但均不够好用,且不易维护03.开发框架成熟度低 不合理的进程部署模型不合理的进程部署模型:大量的同机多进程的部署,资源隔离性较差,时常互相影响种类多,种类多,维护成本极高:维护成本极高:现网积累了千余种服务,
5、数量多,大部分服务需要人工介入维护04.巨量微服务维护困难组织架构分拆引发问题:组织架构分拆引发问题:业务膨胀,组织架构分拆,但运行服务相互牵扯,难以分拆,不同团队间影响问题频发如何改造架构如何改造架构不可行方案 小修小补:小修小补:在现有架构上继续打补丁优化,但维护成本极高,将越陷越深,并非长久之计 彻底重构:彻底重构:使用成熟的架构进行重构,但存量业务太多,改造成本巨大,根本无法接受Istio腾讯服务网格(TCM)使用 Istio 将服务管理和服务治理能力下沉服务管理和服务治理能力下沉,让现有框架逐渐退变为业务的逻辑驱动层和胶水层,升级现有架构期望以较低的改造成本,来获得成熟、可靠且可持续
6、演进的服务管理和治理能力架构演进新增的无状态服务实现网格化部署新增的无状态服务实现网格化部署存量无状态服务如何平滑迁移入网格?增加网格适配网关 MeshGateIstio云下gRPC私有协议客户端客户端接入网关接入网关云上服务云上服务A A云上服务云上服务B B消息消息中转服中转服云下服务云下服务1 1云下服务云下服务2 2MeshGate网格内外互通示意图 核心能核心能力力实现网格内外服务消息互通双向代理双向代理代理网格内服务注册至云下客户端接入网关与消息中转服代理网格外服务作为云上访问云下服务网关协议互转协议互转私有协议与 gRPC 协议互转适配 实现收实现收益益新服务可在网格中部署快速享
7、受网格红利快速享受网格红利K8s 的服务部署管理能力Istio 的服务治理能力如何迁移存量的无状态服务如何迁移存量的无状态服务进程框架改造引入引入gRPCgRPC适配适配01多线程引入业务消息投递给 gRPC 线程gRPCgRPC WapperWapper02在私有协议外包一层 gRPC业务逻辑线程gRPC适配 业务进程业务消息通道gRPC 协议进程框架改造示意图私有协议gRPC Wapper1 12 2存量业务代码重编即适配重编即适配 gRPCgRPC 协议协议利用消息中转服实现平滑迁移0101灰度流量灰度流量持续观察稳定性,实现平滑过渡网格利用消息中转服转发部分流量网格内服务B适配 gRP
8、C 线程MeshGate网格外服务A消息中转服网格外服务网格外服务B B50%流量适配 gRPC 线程50%流量流量灰度示意图0202全量全量同网格内通信采用 gRPC 协议同网格外通信采用 MeshGate 中转如同新增的无状态服务小结小结IstioIstio消息中转服消息中转服客户端接入网关客户端接入网关DispatchDispatch活动A活动B周边业务周边业务GameSvrGameSvr自研存储自研存储ApacheCGI ACGI B私有 TCP 协议HTTP 协议有状态服务sidecargRPC 协议云下云下MeshGateMeshGate周边业务周边业务活动活动B B活动活动A A
9、迁移部分架构引入 MeshGate开发框架支持和适配 gRPC无状态服务的资源成本下降下降 70%70%快速实现无状态服务网格化迁移链路变长链路变长2 2 跳变跳变 5 5 跳跳返回链路也变长,时延还要翻倍性能损耗较大,MeshGate 成为瓶颈在游戏核心交互场景中无法接受接入网关接入网关客户端接入网关迁移网格客户端接入网关迁移网格1 12 21 12 23 34 45 5原有客户端接入网关原有客户端接入网关消息路由Random,轮询,业务定制化路由等用户链接管理身份鉴权,心跳保活,反向通知等支持 TCP 长短链接,WebSocket流量治理能力不足不支持 Http 接入,无染色能力,熔断能力
10、等运维能力弱,资源利用率极低发布需要人工调度和长链接排空,全量发布持续数天时间部署不便,需冗余部署,日常高峰期 CPU 利用率仅 15%核心功能核心功能问题分析问题分析适配适配 gRPCgRPC适配适配 gRPCgRPC将接入网关直接部署在网格中,就能快速网格化,解决问题么?客户端接入客户端接入网关网关MeshGateMeshGateSideCarSideCar业务线程业务线程SideCarSideCar原有客户端与网格内业务服务通信模型适配适配gRPCgRPC线程线程客户端接入网关客户端接入网关SideCarSideCar将接入网格直接部署到网格内业务线程业务线程SideCarSideCar
11、适配适配gRPCgRPC线程线程gRPC客户端客户端接入网关接入网关私有协议转换为 gRPCKernelKernel 协议栈协议栈EnvoyEnvoy解析 gRPC Head向后端路由Lotus Pod 的请求处理模型接入网关Pod1 13 32 2上行消息接入服本身需要对链接做复杂管理,但接入服本身需要对链接做复杂管理,但 gRPCgRPC 工程封装封闭,想直接管理原始链工程封装封闭,想直接管理原始链接很繁琐接很繁琐 开发成本并不低开发成本并不低时延:时延:5 5 跳变跳变 4 4 跳跳性能:性能:gRPCgRPC 协议栈转换以及组解包性能协议栈转换以及组解包性能开销较大,但整体次数没变开销
12、较大,但整体次数没变 时延略微改善,性能未解决时延略微改善,性能未解决路由完全依赖路由完全依赖 SideCarSideCar 实现个性化路由复杂实现个性化路由复杂1 11 12 23 34 45 52 23 34 4转转1 1转转2 2转转1 1转转2 2序列化序列化1 1反序列化反序列化2 2序列化序列化3 3反序列化反序列化4 4序列化序列化5 5反序列化反序列化6 6序列化序列化1 1反序列化反序列化2 2序列化序列化3 3反序列化反序列化4 4序列化序列化5 5反序列化反序列化6 6客户端客户端接入网关接入网关MeshGateMeshGateSideCarSideCar业务线程业务线程
13、SideCarSideCar原有客户端与网格内业务服务通信模型适配适配 gRPCgRPC 线程线程客户端客户端接入网关接入网关SideCarSideCar将接入网格直接部署到网格内业务线程业务线程SideCarSideCar适配适配 gRPCgRPC 线程线程如何改造接入网关如何改造接入网关使用 Envoy 支持私有协议接入 方案指标 1 1 接入网关接入网关+MeshGate+MeshGate22 接入网关部署在网格内接入网关部署在网格内33EnvoyEnvoy 私有协议接入私有协议接入44EnvoyEnvoy 私有协议转发私有协议转发时延5 5 跳跳4 4 跳跳3 3 跳跳2 2 跳跳性能
14、协议转换2 2 次次2 2 次次2 2 次次0 0 次次gRPC协议栈6 6 次次6 6 次次4 4 次次0 0 次次1 12 2Envoy 私有协议转发,不劫持入流量EnvoyEnvoy业务服务业务服务SideCarSideCar4 4 性能时延不敏感服务性能时延不敏感服务转换 gRPC 协议栈,原生流量调度 性能时延敏感服务性能时延敏感服务使用私有协议转发不劫持业务侧入流量但损失部分流量治理以及观测能力私有协议gRPC 协议Envoy 支持私有协议接入EnvoyEnvoy3 3业务线程业务线程SideCarSideCar适配适配 gRPCgRPC 线程线程适配适配 gRPCgRPC适配适配
15、 gRPCgRPC如何改造如何改造 EnvoyEnvoy数据面扩展数据面扩展 FilterFilter ChainsChains兼容业务已有能力01控制面扩展控制面扩展 xDSxDS适配私有协议路由规则02自定义自定义 ControllerController管理 Envoy Router 的运维03私有协议解析私有协议解析业务鉴权业务鉴权业务加解密业务加解密自定义路由自定义路由.业务层业务层熔断、限流熔断、限流数据面扩展数据面扩展EnvoyEnvoyMsgRouterMsgRouter CRDCRDPilotPilotkind:MsgRouterspec:msgid:100000 svrNa
16、me:test.serviceA port:12345MsgRouter MsgRouter ControllerControllerxDS控制面扩展控制面扩展Pilot AgentPilot Agent2.gRPC1.私有协议Envoy Router处理请求流量模型KernelKernel 协议栈协议栈FilterFilter chainschainsxDSxDSRouterRouterListenerListener 私有协议转换 gRPCEnvoy转发路由转发给 filter1 12 2实现成效实现成效方案方案QPSQPS 峰值峰值P50P50 耗时耗时P99P99 耗时耗时原始接入网关
17、直连150,0004ms9ms原始接入网关+MeshGate(网格)30,00034ms50msEnvoy 私有协议接入,gRPC 转发60,0007ms13msEnvoy 私有协议接入,私有协议转发120,0005ms9ms4 核 8 G,对应的线程根据资源模型做相应的调整,使用平均 300 字节的业务协议压测压测数据压测数据2 2 倍倍2 2 倍倍时延时延接近接近性能和时延效果改善明显,使用 Envoy 私有协议接入和转发与原始接入网关相近小结小结IstioIstio消息中转服消息中转服客户端接入网关客户端接入网关DispatchDispatch活动A活动B周边业务周边业务自研存储自研存储
18、ApacheCGI ACGI B私有 TCP 协议HTTP 协议有状态服务sidecargRPC 协议云下云下MeshGateMeshGate周边业务周边业务活动活动B B活动活动A A迁移部分解决敏感业务时延和性能要求接入服的资源成本减少减少 50%50%大幅提升接入服务的治理能力EnvoyEnvoy RouterRouter有状态服务有状态服务 GameSvrGameSvr如何进网格?如何进网格?GameSvrGameSvr将Envoy改造成网格接入网关原有原有 GameSvrGameSvr 架构架构负责玩家对局撮合和对局逻辑的服务多层业务架构多层业务架构多个游戏每个游戏下多种玩法每种玩法
19、下多个版本有状态服务有状态服务用户长 Session使用共享内存做数据缓存服务需热更新,冷启动慢消息路由特殊消息路由特殊定点路由全双工,非请求应答式调度管理复杂调度管理复杂数百个不同能力的 GameSvr 节点,针对它们做负载压力管理和对局调度十分繁琐服务运维繁琐且低效服务运维繁琐且低效01上架一个节点需人工操作 10 多次每年应对机器裁撤需投入 1 个月宕机还需人为介入,MTTR 长资源利用率极低资源利用率极低02冗余部署,平均利用率不足 20%不同节点负载高低差距大云下 GameSvr 问题如何改造如何改造 GameSvrGameSvr 架构架构自定义自定义 WorkloadWorkloa
20、d自定义 Controller 管理多层 CRD:游戏、玩法、版本、GameSvr0101GameZoneGameZoneGameGroupGameSetGameSvr0202部署能力部署能力容器热更新Group 间金丝雀、蓝绿发布Group 内可控滚动更新镜像预热停旧容器起新容器耗时较长耗时较长,分钟级,分钟级共享内存共享内存,停启毫秒级,停启毫秒级0404优化单局调度优化单局调度撮合外置自动感知实时部署和Pod状态结合负载预测0303智能自动伸缩智能自动伸缩实时预测:突增流量离线预测:周期性流量定时扩容:定点流量自研存储和存量巨大的自研存储和存量巨大的 CGICGI 服务如何进网格?服务如
21、何进网格?小结小结IstioIstio消息中转服消息中转服客户端接入网关客户端接入网关DispatchDispatch活动A活动B周边业务周边业务自研存储自研存储ApacheCGI ACGI B私有 TCP 协议HTTP 协议有状态服务sidecargRPC 协议云下云下MeshGateMeshGate周边业务周边业务活动活动B B活动活动A A迁移部分重构 GameSvr 架构模型GameSvr 资源成本减少减少 75%75%EnvoyEnvoy RouterRouterGameSvrGameSvr自定义 Controller 管理实现智能 HPA实现运维能力自动化,大幅提升效率GameSv
22、rGameSvr自研存储服务迁移自研存储服务迁移自研存储迁移至云存储,交给专业团队维护,增强存储能力,降低维护成本0101适配协议适配协议CloudDBAdapter 适配代理自研存储的私有协议至云存储服务研发无状态适配代理服务业务服务业务服务消息中转服消息中转服MySQLMySQL自研存储自研存储MasterMasterCloudDBCloudDBAdapterAdapterCloudDBCloudDB自研存储自研存储SlaveSlave改造迁移示意图0202同步热数据同步热数据通过 CloudDBAdapter 转发,使得云存储服务中有业务热数据通过自研存储备机同步热数据0303导入冷数据
23、导入冷数据如果云存储服务已经有数据,说明是最新的,则不覆盖人工将冷数据离线导入云存储0404切换路由切换路由全量数据逐条比对,通过后切换消息中转服路由,即完成搬迁全量校验无误,切换数据访问路由迁移步骤1 12 23 34 4如何网格化存量巨大如何网格化存量巨大 ApacheApache CGICGI根据流量大小,实施不同改造方案v5%5%头部流量:头部流量:协程化改造虽耗时,但数量少。大幅提升吞吐能力,并减少资源开销。v15%15%普通流量:普通流量:单独 CGI 打包镜像改造成本较低。在资源开销和可维护性之间寻求平衡。v80%80%长尾流量:长尾流量:整体 CGI 打包镜像 无需改造,但也不
24、影响业务。同时减少对集群 IP、内存以及路由配置等等资源的占用吞吐极低:吞吐极低:同步阻塞框架稳定性差:稳定性差:负载波动大,易过载隔离性差:隔离性差:同机超多进程部署存量巨大:存量巨大:五百余种 CGI云下 Apache CGI 问题收益稳定性提升资源成本减少减少 70%70%快速实现网格化小结小结IstioIstio消息中转服客户端接入网关客户端接入网关DispatchDispatch活动A活动B周边业务周边业务自研存储自研存储ApacheApacheCGI ACGI B私有 TCP 协议HTTP 协议有状态服务sidecargRPC 协议云下云下MeshGateMeshGate周边业务周
25、边业务活动活动B B活动活动A A迁移部分EnvoyEnvoy RouterRouterGameSvrGameSvrGameSvrGameSvrCGICGI A ACGICGI B BCloudDB全量服务平滑演进入网格SideCarSideCar 性能问题性能问题内存占用过高CPU 开销占比过大SideCarSideCar 的性能问题的性能问题内存篇内存篇只部署千余个 Pod,SideCar 的平均内存就接近普通业务容器,约 500M 左右,且还有持续增长的态势未优化前 Pod 容器内存占比4242%5858%业务容器业务容器SideCarSideCar相当于业务内存整体翻番,并且实际上内存
26、还随 Pod 数量在持续增加,最终开销可能无法接受资源占用过多资源占用过多SideCar 内存占比过高且持续增长,对 HPA 伸缩计算以及调度节点 CPU/内存计算都有影响影响影响 PodPod 调度调度内存持续增长,加上流量上来之后,有可能超过原先预设的 limit 限制,导致 OOM 或者驱逐。OOMOOM 或驱逐或驱逐为什么内存占用这么大为什么内存占用这么大原因之一原因之一:默认全量下发默认全量下发 xDSxDS 数据数据Istio 会将全量服务发现数据(xDS)下发给每一个 SideCar即便是完全不会对外产生请求的服务,它的 SideCar 也存放着全量 xDS 数据集群规模越大,数
27、据量越大,同时 xDS 变化还易引发 CPU 开销抖动测试一个完全没有请求的 Pod,其 SideCar 内存也有 500MxDSxDS 根据服务按需加载根据服务按需加载使用开源项目使用开源项目 AerakiAeraki LazyLazy xDSxDS 方案方案无 xDS 时,通过 lazy xDS Egress 转发Lazy xDS Controller 分析所需 xDS,并同步给该 SideCar有 xDS 后,走点对点通信,并实时监听所需 xDS 变化 无需设置依赖关系 无侵入 实现精细化的 xDS 管理优点优点 暂不支持私有协议不足不足LazyLazy使用使用 SideCarSideC
28、ar CRDCRD 限制服务可见性限制服务可见性以 namespace 为维度限制服务可见性跨 namespace 服务调用,需显式指定 简便快速 原生支持 支持多集群优点优点不足不足 粒度依然较粗 需要梳理依赖关系为什么内存占用这么大为什么内存占用这么大原因之一原因之一:一致性:一致性HashHash导致的问题导致的问题默认 ring hash 算法,使用 uid 作为一致性 hash key,虚拟节点少,导致负载不够均衡调整 ring hash 虚拟节点至 10 万个,导致内存开销过大(100个真实节点,一个环大概占用 2M 左右)默认改用默认改用 Maglev HashMaglev Ha
29、sh 算法,减少虚拟节点数量算法,减少虚拟节点数量负载均衡性负载均衡性数据迁移量数据迁移量查找效率查找效率一致性 hash 算法的权衡原因之一原因之一:设置不合理的监听端口:设置不合理的监听端口不同的业务和框架,使用的端口种类和数量都不同基础 helm 模板上设置监听端口,最终所有服务都开了这些端口网格会为这些监听端口都创建 xDS,也会在 SideCar 上建环,内存开销很大统一相同作用的监听端口,端口按需开启统一相同作用的监听端口,端口按需开启SideCarSideCar 内存占用减少了内存占用减少了 70%70%优化效果SideCarSideCar 的性能问题的性能问题CPUCPU篇篇未
30、优化前大扇出 PodCPU 开销占比7474%2626%业务容器业务容器SideCarSideCar未优化前流量型 PodCPU 平均开销占比5050%5050%业务容器业务容器SideCarSideCarSideCarSideCar CPUCPU 开销过大开销过大大部分情况之下,不需要复杂的流量治理能力原因分析业务逻辑线程gRPC线程协议栈业务进程1 1EnvoygRPC协议栈gRPC协议栈请求方 Pod响应方 PodEnvoygRPC协议栈gRPC协议栈业务逻辑线程gRPC线程协议栈业务进程2 23 34 45 56 609 98 87 7组包解包请求响应普通请求应答
31、流程示意图请求1响应1gRPCgRPC编解码次数过多编解码次数过多01在一次普通的 Req、Rsp 有 12 次之多大部分只是在适配 Istio 原有协议体系gRPCgRPC协议栈开销较大协议栈开销较大02通过热力图分析,发现主要还是 Envoy 的 gRPC 协议栈的开销加乘编解码次数,总体开销过大SideCarSideCar 的性能问题的性能问题CPUCPU篇篇减少编码次数减少编码次数使用使用 gRPCgRPC proxylessproxyless跳数明显减少,性能提升明显业务进程会融入 xDS 相关信息不同开发框架的接入和维护不便个人认为从某种意义上脱离网格最初的设计理念优点优点不足不足
32、业务逻辑线程gRPC线程协议栈业务进程1 1请求方 Pod响应方 Pod业务逻辑线程gRPC线程协议栈业务进程2 23 34 4组包解包请求响应gRPC proxyless 示意图xDS 处理xDS 处理请求响应业务原生支持;节省业务进程内的适配开销减少转换适配以及跳数默认不完全解包,基于原始码流的偏移读取或设置字段Istio 本身缺乏一个良好的七层协议扩展机制,对接控制面和数据面成本较高优点优点不足不足业务逻辑线程业务进程私有协议码流操作请求方 Pod响应方 PodEnvoy1 1基于原始码流的偏移读取或设置字段请求响应使用私有协议栈私有协议码流操作Envoy业务逻辑线程业务进程请求响应2
33、24 43 3减少协议栈开销减少协议栈开销使用开销极小的私有协议栈使用开销极小的私有协议栈使用使用 AerakiAeraki 解决私解决私有协议对接有协议对接 SideCarSideCar问题问题使用使用 AerakiAeraki 支持私有协议支持私有协议方案QPS 峰值原生 Sidecar gRPC 协议栈15000MetaProtocol Sidecar 私有协议栈700002 核 8 G,对应的线程根据资源模型做相应的调整,使用平均 300 字节的业务协议压测 Sidecar 配置 2 个 worker 线程 核心能核心能力力Aeraki Meta Protocol 是一种网格中通用协议
34、适配框架,可在 Service Mesh 中管理任意七层协议对接数据面对接数据面提供服务发现、负载均衡、熔断、路由、权限控制、限流、故障注入等公共的基础能力对接控制面对接控制面提供 MetaProtocol Proxy 配置和 RDS 配置下发,以实现高级路由和服务治理能力,例如流量拆分、灰度/蓝绿发布、地域感知负载均衡、流量镜像和基于角色的权限控制。接入开发简便接入开发简便只要进行少量二次开发,便可在 mesh 中接入支持私有协议4.64.6 倍倍小结小结IstioIstio消息中转服客户端接入网关客户端接入网关DispatchDispatch活动A活动B周边业务周边业务自研存储自研存储Ap
35、acheApacheCGI ACGI B私有 TCP 协议HTTP 协议有状态服务sidecargRPC 协议云下云下MeshGateMeshGate周边业务周边业务活动活动B B活动活动A A迁移部分EnvoyEnvoy RouterRouterGameSvrGameSvrGameSvrGameSvrCGICGI A ACGICGI B BCloudDB解决了云上 SideCar 问题,真正实现全面平滑演进入网格成效总结核心成效总结核心成效总结升级架构和团队技术升级架构和团队技术通过网格化,我们对过去积累了十年的业务系统进行重构,实现微服务架构和团队技能的全面提升。这不仅只是服务的容器化和网
36、格化,还从一个封闭的体系融入技术社区,实现技术的快速迭代更新。高效的高效的 DevOpsDevOps 能力能力通过自动化和标准化的服务网格,以及定制化的Controller,我们降低了人工干预,显著提高了DevOps效率和研运一体化。这有助于实现快速迭代、故障排查,确保系统的稳定性和可靠性。强大的服务治理能力强大的服务治理能力以及可观测性以及可观测性服务网格不仅加强了服务治理,支持流量控制、故障注入和安全策略等功能。同时,它提高了可观测性,包括监控、追踪和日志,有助于微服务架构的稳定运行。大幅减少资源成本大幅减少资源成本资源利用率峰值从 15%左右,提升至 55%左右;资源使用量减少了 60%;仅资源成本每年节省数百万;减少 60%总之,我们在一个历史包袱异常沉重的游戏业务复杂架构中,通过细致分析和改造,完成整体架构的平稳平滑上云以及网格化;提升资源利用率,提高研运效率,沉淀游戏各类业务场景上云经验。感谢倾听Q&A