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

如果无法正常显示，请先停止浏览器的去广告插件。

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

2. 01 腾讯游戏SRE支撑体系 02 复杂异构业务的云原生改造 03 GitOps云原生时代运维方式的变革 04 SRE云原生服务场景扩展

3. 01 腾讯游戏SRE支撑体系

4. 腾讯游戏研发模式大规模业务 + 多样化场景腾讯游戏业务主要分为自研和代理，部分合作研发 • • • • 游戏开发厂商众多，开发语言多样化游戏类型众多，游戏架构差异大不同游戏间相互独立，业务场景上各不相同每个运维同学的技术栈和运维方式也不同问题思考：技术团队如何在不增加人力资源的情况下服务更多业务？

5. 腾讯游戏SRE支撑体系技术运营的三个阶段 SRE 理论借鉴 SRE 工程化思维 SRE 项目落地云原生改造项目 CI - 持续集成 DevOps工程 GitOps持续部署 Everything as Code 发布工程 CD- 持续部署 CO- 持续运营自动化工程 Site Reliability Engineering 工程化思维与工程化工作：运营/开发/运维协同发布计划/发布协调可观测工程消除琐事/OnCall 容量工程稳定性:SLI/SLO 可靠性工程数据评估/成本控制安全工程 MTBF/MTTR/应急 AIOPS工程辅助运营/辅助决策 MLOPS工程数据治理/隐私合规 1. 通常是有创新性和创造性的，着重通过设计来解决问题，解决方案越通用越好； 2. 符合长期战略，对服务进行长久性的改善的工作； 3. 有助于使团队维持同等配备情况下接手更大或更多的服务；

6. 02 复杂异构业务的云原生改造

7. 业务上云到底有什么业务价值？

8. 典型游戏架构（MOBA） DS Agent Seed DS 用于加载地图等公共资源；利用写时复制让多个DS进程共用，从而节约内存 Seed DS DS 每个DS进程就是一场单局 DS DS center DS Server DS center DS战斗集群大厅集群

9. 典型游戏上云的实践-DS Pod模型设计 Lobby Lobby Lobby K8S Pod K8S Pod K8S Pod DS Agent DS Agent DS Agent DS Agent container DS Agent container Seed DS K8S Pod DS K8S Pod DS K8S Pod Seed DS DS container DS DS DS DS container DS DS container DS container 优点业务侵入少，整体架构稳定不变，更新流程简单降低单个DSA的压力，DSA与DS互不影响， Pod异常只影响同一个Seed DS下的进程 DS进程粒度更细，异常情况只影响此对局内的玩家缺点单个Pod异常影响玩家数较多 DSA与DS的交互流程变长；业务修改复杂度高，更新流程复杂 DSA与DS的交互流程变长，功能更复杂；并且不适用于Seed DS模式，同模式DS无法共享资源，DS性能降低，DS启动时间变长

10. 典型游戏上云的实践：上云痛点无损变更游戏房间服务需要等待玩家完成对局后，再合理回收 LB 状态保持 Lobby 玩家数据保存至共享内存，基础组件/资源容器更新时，业务容器不需重启 DS Fleet K8S Pod K8S Pod DS DS Agent DS Agent Seed DS Seed DS DS DS 无损变更状态保持 DS DS container DS container sidecar container sidecar container 流量接入 Pod需独立对外服务独立外网IP资源稀缺流量接入弹性伸缩 Pod弹性节点弹性用户在线数潮汐显著资源严重浪费

11. 游戏服务云原生方案蓝鲸容器平台（BCS，Blueking Container Service）针对游戏业务场景实现Workload扩展，Ingress扩展、弹性计算扩展三个方面，从业务互动管理、到流量动态接入以及资源弹性伸缩三个层次保障业务基于容器环境实现全方位弹性计算。游戏应用编排-Workload扩展针对游戏业务场景实现有状态应用(GameStatefulSet)、无状态应用 (GameDeployment)管理，支持原地重启、镜像热更新、滚动更新、金丝雀发布等多种更新策略；支持PreDeleteHook、PreUpdateHook、StepHook等精细交互控制，保障容器稳定迭代；游戏流量接入-Ingress扩展根据业务场景需求，提供有状态动态网络映射、无状态端口池方案满GameServer 接入游戏资源弹性-GPA扩展扩展通用Pod扩缩能力提供集群节点弹性伸缩

12. 游戏服务云原生方案：无损变更 “游戏房间服务需要等待玩家完成对局后，再合理回收” Workload扩展- 基于hook的无损变更 DS在缩容或者更新前，需要完成一系列优雅退出动作 1. 完成路由变更 2. 等待实例上的所有对局结束 3. 停止游戏主服务进程，然后停止其他进程 K8s原生提供preStop（容器级别）优雅退出方式，但存在以下不足 1. 必须指定最长等待时间 2. 不同容器并发执行退出，难以控制容器退出顺序基于Hook的无损变更（Pod级别） 1. 用户事先定义好Hook内容 2. 当GameDeployment需要删除或更新Pod前会执行对应的Hook，通知该实例进行优雅退出。

13. 游戏服务云原生方案：状态保持 “玩家数据保存至共享内存，基础组件/资源容器更新时，业务容器不需重启” 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. 通知资源加载 DS:1.0 DS-cfg:1.0 DS:1.0 DS-cfg:2.0 DS:1.0 DS-cfg:2.0

14. 游戏服务云原生方案：流量接入 ingress扩展- 端口池 “DS的每个Pod需独立对外服务，独立外网IP资源稀缺” 1. 维护云负载均衡器端口资源池，能够动态地向资源池中增加和删除云负载均衡器 2. Pod通过简单的annotation进行端口资源绑定，自动将 Pod 的一个或一段端口绑定到 LB 上 3. 将 Pod 的同一端口绑定到多个云负载均衡器上，实现多运营商接入 4. 在 Pod 完成端口绑定后，Pod 可以感知自身的端口段绑定信息

15. 游戏服务云原生方案：Pod弹性伸缩弹性扩展- GPA（ GeneralPodAutoscaler ）与原生HPA保持兼容对扩缩策略、交互方式进行扩展 GPA webhook模式 1. 业务侧部署一个web server用于计算推荐的副本数 2. GPA向web Server发送post请求 3. web Server接受请求，根据Pod实时负载和上限以及在线人数计算期望的副本数 4. GPA对期望副本数进行处理后设置GameDeployment

16. 游戏服务云原生方案：节点弹性伸缩只有节点自动伸缩，才能真正降低成本集群弹性扩缩 - Cluster-Autoscaler Cluster Cluster 节点扩容 Pod 扩容 Cluster CA 扩容 Pod Pod Pod Pod Pod Pod Pod Pod Pod Pod Pod Pod Pod Pod GameDeployment 支持按 Pod 维度（pod deletion cost）和节点维度（node deletion cost）排序，达成优先清空节点且优先缩容负载低 Pod 目的。 Node A Node A Node B Node B 缩容2个Pod 节点缩容 Pod 1 Pod 4 Pod 2 Pod 3 Pod 1 Pod 4 Pod 2 Pod 3

17. 游戏服务云原生改造效果网络管理根据业务场景需求，提供有状态动态网络映射、无状态端口池方案满足GameServer接入可复用云原生技术在60+业务及8个运维团队中落地改造耗时对比之前降低37%-43% CA/HPA 共享资源池降低业务备机量弹性伸缩降本30-54% 弹性管理打通最后一公里，扩展通用Pod扩缩，提供集群节点弹性伸缩基础管控基于CRD实现workload扩展，通过各类Pod生命周期Hook方式达成与业务容器状态互动实现无损控制；提供丰富更新策略满足业务变更需求

18. 03 GitOps

19. 云原生应用交付和管理的挑战版本控制手动或者半自动的流程的如果需要回滚时难度大，并且不可靠。环境的部署有多个来源，导致变更内容容易遗漏。或者由于临时修改配置并没有进行统一的存储，导致了一系列的问题配置一致性多人协作在应用管理环节缺乏一种标准的、共同认可的抽象模式，协作效率低

20. GitOps持续部署 CI持续集成蓝盾CI流水线蓝盾制品库蓝盾CI流水线执行修改应用代码代码拉取提交PR 开发人员编译加速代码检查镜像打包和推送镜像V1 镜像V2 代码开发仓库镜像拉取不可变防火墙 CD 持续部署 Git是唯一的事实来源 Review审核声明式配置文件 • • • PR驱动 Review机制 Commit记录 GitOps控制器发布集群 lobby/ game 提交PR 应用配置仓库 SRE/DEV PULL模式主动拉取完成权限隔离和自治期望状态自动同步实际状态 SRE/DEV Kubectl apply DS/ lobby game

21. GitOps持续部署：健康检查和同步顺序 “我希望在部署和更新应用的时候能按照特定的顺序进行？” 自定义资源健康检查

22. GitOps持续部署：多应用和集群的自动化部署 “测试环境的部署模型是否也能通过Git目录结构来定义？” 通过Git 文件生成器渲染部署来源和部署目标 cluster-guangzhou app-a app-b cluster-nanjing app-c 对values文件进行分层： • general.yaml 为整个业务通用的配置，例如game-id • cluster.yaml 为单个集群的配置项，例如cluster-id • a.yaml b.yaml等为单个应用的配置项，例如zone-id 单个应用由以上三部分组成。 app-d app-e

23. GitOps持续部署：部署前检查 “是否可以在PR/MR过程中查看实际的变更差异以及模拟运行结果？” 自动触发部署前检查 Review审核创建PR Read/Sync Argo CD 代码合并 DEV SRE/开发 1. PR自动触发部署前检查，PR被锁定，任何人不能进行合并 2. 在PR的会话中回写检查结果，包含helm diff 、模拟运行的结果、是否合规 3. 确认异常原因并修复 4. 重新提交PR 5. Review配置变更

24. GitOps持续部署：密钥管理 Yaml配置中只需要填写对应的placeholder “敏感信息不能上传到Git中” Argo CD argocd-repo-server 环境配置仓库 vaultplugin-server argocd--server apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: annotations: secretManager: default:vault-secret-game name: game apiVersion: v1 data: VAULT_TOKEN: kind: Secret metadata: name: vault-secret-game type: Opaque

25. GitOps持续部署落地效果声明式应用定义结合GitOps，确保交付的一致性，带来应用交付以及开发运维协作的变革可复用 GitOps在40+业务中落地人均业务数传统业务人均3款 GitOps业务人均5款发布变更效率提升6倍每天变更次数 900次

26. 04 SRE云原生服务场景扩展

27. Everything as Code 面向服务的DevOps理念业务A 实践SRE文化：通过软件工程化的思维，把业务中的工作场景业务B 扩缩策略发布策略监控策略流量策略扩缩策略发布策略流量策略监控策略拢，做到可衡量、可管理、可复用，并且持续优化和创新。应用的基础设施 Pod Tcaplus Manger Deployment Service Node GcloudMaple Auto BCS Manger Shuntdown rollout Custom Resource 声明式API对象控制器 BCS monitor 容器明式的服务场景，用软件的方式定义运维操作，帮助开发团队平台服务虚拟机网络安全组负载均衡存储数据库 SRE能力团队 SRE团队基于Kubernetes CRD Operator扩展和构建一系列声云基础设施和平台服务云服务工程化，抽离相对通用的方法论、自动化流程等，向平台化靠蓝鲸监控 DB 蓝鲸容器服务 DNS 服务发现 … 屏蔽复杂的底层基础设施，并可靠的管理应用。

28. SRE服务场景- DB变更管理 “DB变更能不能更自动一些？” • DB的变更总是遗漏 • 每次需要手动到控制台手动提单操作 • 新增一个环境需要在DB控制台手动创建游戏区和建表 • 通过声明式的方式定义DB变更，将DB的表结构定义 xml/tdr 配置随Helm Chart一起交付 • 自动进行DB游戏区的创建和表结构的变更 • 自动处理异常变更，并通过企业微信发送变更通知 Pod NoSqlDB System 1. 提交更新 GitOps 自动部署 Read/Sync kube-apiserver Argo CD 业务运维 2. sidecar 注入 ETCD iniitContainer Wait-for-db gamesvr gamesvr:1.2 环境配置仓库 NoSqlDB- webhook 3. 更新表结构 NoSqlDB- contrallor NoSqlDB Configmap TabeleA.xml TabeleB.xml Tcaplus DB 4.查询DB变更状态，并完成 initC启动

29. SRE服务场景- 声明式可观测 “指标的可观测能力能不能更近一步？” • • • • 一个业务运维同时负责多款业务手动配置上百个dashboard需要花费数个小时业务缺乏对基础组件的监控能力业务监控场景复用程度低 • 通过声明式的方式定义可观测能力，包含数据采集、告警策略、通知策略以及Dashbard面板 • 可观测标准模版跨业务可复用 • 通过Git进行版本管理和协作共建 • GitOps自动部署 Read/Sync 配置场景模版 SRE能力团队 Git Repo Read/Sync Push CR Argo CD SRE 服务团队 Git Repo BCS Monitor System GitOps 自动部署 kube-apiserver CR CR ETCD BKM as code Sync 蓝鲸监控 BCS-Monitor- contrallor 模版ConfigMap

30. SRE服务场景- 声明式可观测可观测场景库自动创建的蓝鲸监控Dashboard CR中定义需要的监控场景自动创建的蓝鲸监控告警策略

31. SRE服务场景-测试集群成本优化 “大量测试集群的成本可以优化吗？” 1. HPA和CA适用于业务的正式集群 2. 内部仍然有较大数量的新业务，以及长尾业务的测试和开发集群，这些集群的装箱率普遍较低。 3. 云原生的本质实际就是将资源池化，资源解耦发挥到极致，基于业务的需求按量交付和使用。 vcluster优势 vcluster部署架构 vcluster-a vcluster-b namespace-a namespace-b namespace-a lobby lobby lobby ds ds ds matchsvr matchsvr matchsvr syncer Vcluster Control-plane Node-1 Node-2 Node-3 共享集群 CA

32. SRE服务场景-测试集群成本优化 “成本还可以继续优化吗？” • • • • 项目组每人一套测试环境为了验证一个新特性有需要额外创建一个环境大量的测试环境长期闲置，无法察觉到测试集群成本越来越高大量的测试环境长期处于闲置状态测试环境在长时间不用后可以自动销毁，避免服务器资源的占用” 获取蓝鲸监控上的metric指标（在线人数），判断是否符合清理条件

33. 云原生SRE分层服务模式业务通用场景建设，例如 Operator、可观测场景以及 terraform-module等 SRE能力团队配置代码库 SRE服务团队贴近业务，复用现有能力完成业务模型的构建。简单特性的扩展。共建 TF 配置监控策略扩缩策略发布策略组件库引用模版/插件 CRD Operator & TF Module & Monitor 创建服务模块 & 建设流程代码合并 SRE基础团队主动拉取（PULL）平台通用能力建设，例如 gameworkload扩展、 argocd、terraform的平台级建设和能力扩展蓝鲸容器服务部署前检查 GitOps 引擎持续分析自动同步提交PR 变更YAML Review变更 Oncall团队 Kubernetes SRE服务团队业务开发团队 Argo CD Terraform

34. 腾讯游戏SRE在云原生服务实践中收益容器化和资源弹性基于异构服务场景推动业务模块容器化，并根据业务容量快速调配资源，实现资源弹性伸缩，帮助业务降低成本 GitOps提升交付质量和交付效率声明式应用定义结合GitOps，确保交付的一致性，带来应用交付以及运维协作的变革云原生SRE服务场景扩展围绕游戏生态构建一系列声明式的自助式的服务场景，向平台工程靠拢，做到可衡量、可管理、可复制，并且持续优化和创新

35. 谢谢