腾讯游戏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. 谢谢

首页 - Wiki
Copyright © 2011-2024 iteam. Current version is 2.124.0. UTC+08:00, 2024-04-25 09:02
浙ICP备14020137号-1 $访客地图$