腾讯游戏SRE在复杂异构业务中的云原生服务实践

王杰 ⚡➃➝絏 桬匊艗雴康䧬SRE넞紩䊨玐䋗 艗雴康䧬SRE넞紩䊨玐䋗2014䎃⸈Ⰶ艗雴剣⚪㺢涸䪮助鵘蠒絑낉⚺㼋㛇✵覰둊㺂㐼䎂〵涸✻⾲欰SaaS霃雦ㄤ䒓〄䊨⡲곡ⵄ䌐⸔侨⼧妴⚌⸉㹊梡✻⾲欰佖鸣կ湡⵸翸搋✵㢕勇䒗匬⚌⸉✻⾲欰♧⡤⻊倰呩衅㖑⟄⿺SRE✻⾲欰剪⸉⡤禹匬䒊կ 艗 雴 康 䧬S R E佅 丒 ⡤ 禹 1 目录 撑 勇 䒗 匬 ⚌ ⸉ 涸 ✻ ⾲ 欰 佖 鸣 2 CONTENTS G i t O p s✻ ⾲ 欰 傞 ➿ 鵘 絶 倰 䒭 涸 」 ꬠ 3 S R E✻ ⾲ 欰 剪 ⸉ 㖞 兞 的 㾝 4 01艗雴康䧬SRE佅丒⡤禹 腾讯游戏研发模式 腾讯游戏业务主要分为自研和代理，部分合作研发 •游戏开发厂商众多，开发语言多样化•游戏类型众多，游戏架构差异大•不同游戏间相互独立，业务场景上各不相同•每个运维同学的技术栈和运维方式也不同 问题思考： 技术团队如何在不增加人力资源的情况下服务更多业务？ 1.通常是有创新性和创造性的，着重通过设计来解决问题，解决方案越通用越好；2.符合长期战略，对服务进行长久性的改善的工作；3.有助于使团队维持同等配备情况下接手更大或更多的服务； 02撑勇䒗匬⚌⸉涸✻⾲欰佖鸣 业务侵入少，整体架构稳定不变，更新流程简单 DS进程粒度更细，异常情况只影响此对局内的玩家 降低单个DSA的压力，DSA与DS互不影响，Pod异常只影响同一个Seed DS下的进程 DSA与DS的交互流程变长，功能更复杂；并且不适用于Seed DS模式，同模式DS无法共享资源，DS性能降低，DS启动时间变长 DSA与DS的交互流程变长；业务修改复杂度高，更新流程复杂 缺点单个Pod异常影响玩家数较多 典型游戏上云的实践：上云痛点 无损变更 游戏房间服务需要等待玩家完成对局后，再合理回收 状态保持 玩家数据保存至共享内存，基础组件/资源容器更新时，业务容器不需重启 流量接入 Pod需独立对外服务独立外网IP资源稀缺 弹性伸缩 用户在线数潮汐显著资源严重浪费 游戏服务云原生方案 蓝鲸容器平台（BCS，BluekingContainer Service） 针对游戏业务场景实现Workload扩展，Ingress扩展、弹性计算扩展三个方面，从业务互动管理、到流量动态接入以及资源弹性伸缩三个层次保障业务基于容器环境实现全方位弹性计算。 游戏应用编排-Workload扩展 针对游戏业务场景实现有状态应用(GameStatefulSet)、无状态应用(GameDeployment)管理，支持原地重启、镜像热更新、滚动更新、金丝雀发布等多种更新策略；支持PreDeleteHook、PreUpdateHook、StepHook等精细交互控制，保障容器稳定迭代； 游戏流量接入-Ingress扩展 根据业务场景需求，提供有状态动态网络映射、无状态端口池方案满GameServer接入 游戏资源弹性-GPA扩展 扩展通用Pod扩缩能力提供集群节点弹性伸缩 游戏服务云原生方案：无损变更 “游戏房间服务需要等待玩家完成对局后，再合理回收” Workload扩展-基于hook的无损变更 DS在缩容或者更新前，需要完成一系列优雅退出动作 1.完成路由变更2.等待实例上的所有对局结束3.停止游戏主服务进程，然后停止其他进程 K8s原生提供preStop（容器级别）优雅退出方式，但存在以下不足 1.必须指定最长等待时间2.不同容器并发执行退出，难以控制容器退出顺序 基于Hook的无损变更（Pod级别） 1.用户事先定义好Hook内容2.当GameDeployment需要删除或更新Pod前会执行对应的Hook，通知该实例进行优雅退出。 游戏服务云原生方案：状态保持 “玩家数据保存至共享内存，基础组件/资源容器更新时，业务容器不需重启” Workload扩展-原地升级 业务DS架构稳定，通过DSAgent管理多个DS，DS开放端口对外进行服务。实际部署时，根据业务负载需求DSAgent与DS以1:N(例如1:10)放入Pod中。日常更新管理主要以更新DS包以及相关资源为主，热更新为最佳实践。 配置拆分与组合 将资源文件打包为DS-cfg镜像，通过postStart将资源文件复制到存储卷中，提供给DS进程使用 原生的K8s提供只支持滚动更新，更新过程Pod会重建 原地升级 1.调整Pod内镜像定义，触发更新2.HookOperator确认是否可以更新3.清理旧资源镜像，拉取并启动新镜像4.镜像启动完成，资源完成注入5.通知资源加载 游戏服务云原生方案：流量接入 ingress扩展-端口池 “DS的每个Pod需独立对外服务，独立外网IP资源稀缺” 1.维护云负载均衡器端口资源池，能够动态地向资源池中增加和删除云负载均衡器2.Pod通过简单的annotation进行端口资源绑定，自动将Pod的一个或一段端口绑定到LB上3.将Pod的同一端口绑定到多个云负载均衡器上，实现多运营商接入4.在Pod完成端口绑定后，Pod可以感知自身的端口段绑定信息 游戏服务云原生方案：Pod弹性伸缩 弹性扩展-GPA（GeneralPodAutoscaler） 1.业务侧部署一个webserver用于计算推荐的副本数2.GPA向webServer发送post请求3.webServer接受请求，根据Pod实时负载和上限以及在线人数计算期望的副本数4.GPA对期望副本数进行处理后设置GameDeployment 游戏服务云原生方案：节点弹性伸缩 GameDeployment支持按Pod维度（pod deletion cost）和节点维度（node deletion cost）排序，达成优先清空节点且优先缩容负载低Pod目的。 游戏服务云原生改造效果 可复用 云原生技术在60+业务及8个运维团队中落地 改造耗时对比之前降低37%-43% CA/HPA共享资源池降低业务备机量弹性伸缩降本30-54% 03GitOps GitOps持续部署 GitOps持续部署：健康检查和同步顺序 “我希望在部署和更新应用的时候能按照特定的顺序进行？” GitOps持续部署：多应用和集群的自动化部署 “测试环境的部署模型是否也能通过Git目录结构来定义？” 对values文件进行分层：•general.yaml为整个业务通用的配置，例如game-id •cluster.yaml为单个集群的配置项，例如cluster-id•a.yamlb.yaml等为单个应用的配置项，例如zone-id单个应用由以上三部分组成。 GitOps持续部署：部署前检查 “是否可以在PR/MR过程中查看实际的变更差异以及模拟运行结果？” 1.PR自动触发部署前检查，PR被锁定，任何人不能进行合并2.在PR的会话中回写检查结果，包含helmdiff、模拟运行的结果、是否合规3.确认异常原因并修复4.重新提交PR5. Review配置变更 GitOps持续部署：密钥管理 “敏感信息不能上传到Git中” GitOps持续部署落地效果 声明式应用定义结合GitOps，确保交付的一致性，带来应用交付以及开发运维协作的变革 04SRE✻⾲欰剪⸉㖞兞的㾝 EverythingasCode 实践SRE文化：通过软件工程化的思维，把业务中的工作场景工程化，抽离相对通用的方法论、自动化流程等，向平台化靠拢，做到可衡量、可管理、可复用，并且持续优化和创新。 SRE团队基于KubernetesCRDOperator扩展和构建一系列声明式的服务场景，用软件的方式定义运维操作，帮助开发团队屏蔽复杂的底层基础设施，并可靠的管理应用。 SRE服务场景-DB变更管理 “DB变更能不能更自动一些？” •DB的变更总是遗漏•每次需要手动到控制台手动提单操作•新增一个环境需要在DB控制台手动创建游戏区和建表 •通过声明式的方式定义DB变更，将DB的表结构定义xml/tdr配置随Helm Chart一起交付•自动进行DB游戏区的创建和表结构的变更•自动处理异常变更，并通过企业微信发送变更通知 SRE服务场景-声明式可观测 “指标的可观测能力能不能更近一步？” •一个业务运维同时负责多款业务•手动配置上百个dashboard需要花费数个小时•业务缺乏对基础组件的监控能力•业务监控场景复用程度低 •通过声明式的方式定义可观测能力，包含数据采集、告警策略、通知策略以及Dashbard面板•可观测标准模版跨业务可复用•通过Git进行版本管理和协作共建•GitOps自动部署 SRE服务场景-声明式可观测 可观测场景库 CR中定义需要的监控场景 SRE服务场景-测试集群成本优化 1.HPA和CA适用于业务的正式集群2.内部仍然有较大数量的新业务，以及长尾业务的测试和开发集群，这些集群的装箱率普遍较低。3.云原生的本质实际就是将资源池化，资源解耦发挥到极致，基于业务的需求按量交付和使用。 SRE服务场景-测试集群成本优化 “成本还可以继续优化吗？” •项目组每人一套测试环境•为了验证一个新特性有需要额外创建一个环境•大量的测试环境长期闲置，无法察觉到•测试集群成本越来越高 测试环境在长时间不用后可以自动销毁，避免服务器资源的占用” 获取蓝鲸监控上的metric指标（在线人数），判断是否符合清理条件 腾讯游戏SRE在云原生服务实践中收益 容器化和资源弹性 基于异构服务场景推动业务模块容器化，并根据业务容量快速调配资源，实现资源弹性伸缩，帮助业务降低成本 GitOps提升交付质量和交付效率 声明式应用定义结合GitOps，确保交付的一致性，带来应用交付以及运维协作的变革 云原生SRE服务场景扩展 围绕游戏生态构建一系列声明式的自助式的服务场景，向平台工程靠拢，做到可衡量、可管理、可复制，并且持续优化和创新 开放运维联盟高效运维社区DevOps时代 荣誉出品