1、 腾讯大规模云原生技术实践案例集 腾讯大规模云原生技术实践案例集 目录 前言.6 案例一：揭秘日活千万腾讯会议全量云原生化上 TKE 技术实践.7 腾讯会议业务特性.7 StatefulSetPlus 强大的灰度发布能力.7 如何保证有状态服务的升级只有 ms 级抖动.13 多地域部署和升级，变得更简单.14 平台资源管理能力增强.16 提升自愈能力.18 容器网络增强和调度能优化.20 总结.20 案例二：腾讯广告 AMS 的容器化之路.21 项目背景.21 上云方案选型.21 容器化历程（困难及应对）.22 困难一：通用性.22 困难二：CPU 密集型检索.23 困难三：有状态服务升级中的

2、高可用.23 整体收益.35 案例三：日 PV 超百亿级的游戏营销服务云原生容器化之路.36 背景.36 自研上云实践.36 大规模配置文件分发.40 成果.42 案例四：成本最高降低 70%，腾讯大规模业务集群的云原生成本优化实践！.43 背景.43 优化措施.45 行业现状与方案选型.47 方案设计与实现.50 方案落地与效果.54 总结.59 案例五：腾讯文档业务上云，Serverless 架构应用最佳实践.61 腾讯大规模云原生技术实践案例集 腾讯文档 x Serverless 云函数.61 Serverless 架构方案优势.65 腾讯文档 x Serverless 架构更多场景探索

3、.66 案例六：QQ 全量上云，你想了解的技术细节都在这.67 一、整体规划.67 二、方案执行.67 三、里程碑中的挑战.71 四、找对方法，加速上云.73 五、小结.77 案例七：和平精英自研上云 UDP 数据包乱序回顾.78 问题背景：.78 分析过程：.78 逐流和逐包.85 总结：.87 案例八：王者荣耀背后的腾讯自研数据库 TcaplusDB 实践.88 面临的问题.88 解决之道.88 PB 级数据微秒级延迟.88 3 小时扩容 400 万 PCU，用户无感知.90 存储层扩容采用无损搬迁方式进行的业务完全无感知.91 接入层扩缩容是无损的业务无感知.92 结语.92 案例九：作

4、业帮云原生成本优化实践.93 项目背景.93 解决方案.94 实践价值.95 案例十：作业帮云原生降本增效实践之路.96 为什么要进行降本增效.96 降本增效的关键点.96 应用层降本增效.97 核心系统云原生改造.99 资源调度层降本增效.101 腾讯大规模云原生技术实践案例集 自定义调度器.101 在离线混部.101 Serveless 广泛使用.102 案例十一：斗鱼直播云原生实践之注册中心篇.104 业务背景和痛点.104 注册中心多活难点分析.109 整体方案落地.114 总结.121 案例十二：助力知乎大数据集群无缝升级.124 项目背景.124 项目挑战.124 腾讯云原生大数据

5、解决方案.124 实践价值.125 案例十三：小红书 AI 搜索推荐场景 容器化实战.126 项目背景.126 项目挑战.126 腾讯云原生 容器解决方案.126 同城多可用区双活架构.127 实践价值.128 案例十四：Unity+腾讯云 Severless：重构计算模型，打造构建元宇宙的核心引擎.129 Unity&云函数云端分布式算力方案.129 云函数&Unity-云端分布式算力方案三大优势.130 1.高性能，提效率.130 2.易部署，免运维.132 3.节约成本.132 案例十五：揭开微盟百万商家营销大战背后的数据库秘密.133 1.高并发、低延时需求.134 2.确保稳定性及高

6、可用性.134 3.数据安全.134 4.海量实例数据库运维.134 利用云数据库弹性满足高并发和快速调整需求.135 腾讯大规模云原生技术实践案例集 集中式+分布式架构设计.136 更安全、更稳定、性能更强.137 案例十六：最伟大的作品，解密周杰伦新专辑背后的数据密码.140 海量数据场景下，如何保证用户体验？.140 借助腾讯云数据库完善基础设施和服务.141 深入业务，向数据库智能化运维演进.142 案例十七：“微盟式”SaaS，让商业变得更智慧.143 腾讯大规模云原生技术实践案例集 前言前言 经过多年磨砺与创新，腾讯内部海量自研业务已实现全面上云。近三年来，腾讯的自研业务上云规模已

7、经突破已经突破 5 5000000 万核，累计节省成本超过万核，累计节省成本超过 3030 亿亿。包括 QQ、微信、腾讯视频、王者荣耀等在内的腾讯内部业务腾讯内部业务，和腾讯云百万级和腾讯云百万级外部外部客户一客户一样基于公有云的模式来样基于公有云的模式来开发运营开发运营，腾讯全面开启业务云端生长新时代。“这是腾讯自研上云战略的一个里程碑。”腾讯集团高级执行副总裁、云与智慧产业事业群CEO 汤道生表示：“把腾讯内部海量业务搬上云端，不仅帮助腾讯构建面向未来的技术架构和研发文化，推动科技成为公司业务发展和产品创新的动力与支撑，也全面锤炼了腾讯云的产品、技术和综合服务能力，这些能力将加快推动产业的

8、数字化升级，助力实体经济全面发展。”大部分业务都是在保持高速增长的过程中上云。比如，QQ 是腾讯首个全面上云的内部业务，把如此庞大和复杂的业务搬上云端，技术团队实现了对用户零感知，被外界称为“开着飞机换引擎”。同时，腾讯云也为新兴业务的高速发展提供有力支撑。以视频号为例，借助腾讯云的弹性扩容能力，视频号稳健支撑诸如西城男孩、周杰伦、崔健等明星的大型线上演唱会活动；得益于对象存储 COS 和腾讯云直播服务，视频号在春节等特殊时段抗住了超平时 3 倍以上业务高峰。腾讯会议凭借生于云、长于云的大规模实践，现在已经成为中国最受欢迎的云视频会议产品，依托业界领先的实时音视频产品 TRTC，腾讯会议可以有

9、效保障数亿用户在复杂网络环境中流畅清晰的视频会议体验。腾讯自研业务上云，打造出了国内国内最大规模的云原生实践最大规模的云原生实践。三年来，数千万核的自研业务上云规模，推动腾讯云的自研产品能力不断优化，多项产品性能达到业界领先水平，也推动腾讯云在全球的基础设施不断完善。腾讯自研上云明确基于云原生来构建明确基于云原生来构建面向未来的技术架构面向未来的技术架构。例如，通过容器和微服务等技术，腾讯构建了统一的技术底座和算力调度平台，有效促进公司内部技术团队的协作与创新。目前，腾讯云的 TKE 平台拥有国内最大规模的 Kubernetes 集群，以及最为领先的在离线混部技术，腾讯上云打造了国内最大规模的

10、云原生实践。为了向开发者更好的介绍腾讯自研业务、外部客户如何通过云原生技术产品支撑业务发展的，特别推出亿级用户的“原”动力亿级用户的“原”动力 腾讯大规模云原生腾讯大规模云原生技术技术实践实践案例案例集集，包括 QQ、腾讯会议、腾讯广告、和平精英、腾讯文档、作业帮、小红书、知乎、Unity、斗鱼、微盟等十多个海量产品和大规模场景的云原生技术实践。希望在给业界带去参考的同时，能够一起推动国内大规模场景下云原生技术实践的有效落地。腾讯大规模云原生技术实践案例集 案例一：案例一：揭秘日活千万腾讯会议全量云原生化上揭秘日活千万腾讯会议全量云原生化上 TKETKE 技术实践技术实践 点此阅读原文 腾讯会

11、议，一款联合国都 Pick 的线上会议解决方案，提供完美会议品质和灵活协作空间，广泛应用在政府、医疗、教育、企业等各个行业。8 8 天扩容天扩容 100100 万核，腾讯会议是如何做到的？万核，腾讯会议是如何做到的？都知道腾讯会议背后的计算资源已过百万核，如此体量的业务，如何通过云原生技术提升研发和运维效率，是一个非常有价值的课题。这里我将为大家揭秘腾讯自研上云容器平台 TKEx 在支持腾讯会议全量云原生化上云背后的技术。TKEx 平台是以腾讯云容器服务（Tencent Kubernetes Engine,TKE）为底座，服务于腾讯自研业务的容器平台。腾讯自研业务类型众多、规模超大，云原生上云

12、面临的挑战可想而知。TKEx 平台在腾讯自研业务上云的过程中沉淀的最佳实践和解决方案，我们将会在 TKE中提供给客户。腾讯会议腾讯会议业务特性业务特性 在 Kubernetes 中，我们习惯把应用分为无状态和有状态两类，有状态应用主要指实例标识、网络、存储的有状态。腾讯会议的一些服务有如下特性：使用 IPC 共享内存，里面存放的有状态数据从 MB 到 GB 大小不等。o 升级时 IPC 数据不能丢失；o 升级时只能允许 ms 级的抖动，用户无感知；部分服务最多的实例数过万，要求高效完成一次版本升级；全球多地域部署，要求部署高效；部分服务要求每个实例都分配 EIP；这对 Kubernetes 管

13、理这种有状态服务提出了更高能力和性能要求。TKEx 平台抽象出业务特性背后的产品需求，在灰度发布、多集群工作负载管理、计算资源管理运营、Node 稳定性等方面进行了增强和优化，沉淀出了通用的音视频业务容器编排能力。StatefulSetPlusStatefulSetPlus 强大的灰度发布能力强大的灰度发布能力 StatefulSetPlus 是我们 2018 年研发并投入生产的首批 Operator 之一，核心特性包括：兼容 StatefulSet 所有特性，比如按序滚动更新。支持分批灰度更新和回滚，单批次内的 Pods 可并发更新、可串行更新。o 支持各个批次手动待升级勾选 Pods。腾讯

14、大规模云原生技术实践案例集 o 支持用户配置各个批次待升级 Pods 的比例进行灰度。o 支持分批回滚和一键失败回滚。o 发布过程可暂停。支持单个 StatefulSetPlus 对象管理上万个 Pods。支持 ConfigMap 的分批灰度发布。对接了 TKE IPAMD，实现了 Pod 固定 IP。支持 HPA 和原地 VPA。升级过程中的扩容使用 LastGoodVersion。支持 Node 核心状态自检，Node 异常时 Pod 能自动漂移。支持容器原地升级。支持升级失败 Pods 的容忍率控制，大规模升级过程中升级失败 Pods 占比小于x%时可继续升级。这里主要介绍为腾讯会议上

15、TKE 新增的两个发布能力增强：大规模自动分批灰度发布和 ConfigMap 分批灰度发布。支持单个支持单个 StatefulSetPlusStatefulSetPlus 上万上万 PodsPods 的自动分批发布能力的自动分批发布能力 TKEx 平台在原来 StatefulSetPlus 手动分批发布能力基础上，这次又开发了自动分批发布的特性，解决像腾讯会议这种大体量业务灰度发布的痛点。用户只要在发布时配置各个批次更新副本的百分比，比如第一批 40%，第二批 60%。StatefulSetPlus-Operator 会根据 Readiness 探针完成情况，自动进行下一批次的更新，其原理如下

16、。腾讯大规模云原生技术实践案例集 自动分批原理图 StatefulSetPlus 核心 Field 说明如下：batchDeployConfigbatchDeployConfig：o batchNum：分几批升级 o batchAuto：是否自动分批发布，true 表示自动分批发布 o batchIntervalMinutes：两次分批发布之间的间隔分钟数 o podsNumToUpdate：各批次发布的 pod 数量，如果不设置则将 pod 平均到每批次发布 StatefulSetPlus 对发布过程进行了精细化的监控，提供 staus.batchDeployStatus 查询发布详细状态，

17、这使得通过 CI Pipeline 发布变得更显示和可控。batchDeployStatusbatchDeployStatus：o action：当前操作，o Next o 表示进行下一批发布，o WaitToConfirm o 表示等待确认该批次发布是否成功，o Completed o 表示所有批次均已确认发布成功。腾讯大规模云原生技术实践案例集 o batchDeadlineTime：本批次发布的 Deadline，如果超过该时间，本批次的 Pod 仍然未 Running&Ready，那么本批次发布失败，进入自动回滚流 o batchOrder：当前批次 o batchOrdinal：本批

18、次发布 pod 的 Index 的起点 o batchReplicas：本批次发布的 pod 的数量 o currentDeployComplete：本批次发布是否完成 o currentOrderSuccessPer：成功升级的 pod 所占百分比 o currentOrderProgress：本批次发布是否成功 o currentRollbackProgress：本批次回滚是否成功 o generalStatus：本次发布全局状态 可在 annotations 加上 platform.tkex/pause-auto-batchDeploy:true 来暂停自动分批发布和失败自动回滚。在 T

19、KEx 平台上，通过如下操作流程即可轻松完成自动分批发布。腾讯大规模云原生技术实践案例集 腾讯会议最大的模块需要支持上万个 Pods 的灰度发布，这是前所未有的挑战。这一次，我们对 StatefulSetPlus-Operator 进行了优化，性能得到大幅提升。对于一万个 pod 的 StatefulSetPlus，分 5 批自动升级，单批次 2000 个 pod，不挂载 cbs 盘的场景，表现如下：1.非原地升级方式：单批次升级处理耗时 40-45 秒，单批次升级从发起升级到升级完成耗时三分半钟，升级过程中单次同步 StatefulSetPlus status 耗时 10秒左右。腾讯大规模云

20、原生技术实践案例集 2.原地升级方式：单批次升级处理耗时 30 秒左右，单批次升级从发起升级到升级完成耗时一分十秒左右，升级过程中单次同步 StatefulSetPlus status 耗时 10 秒左右。3.正常情况下（非升级过程），同步 StatefulSetPlus status 毫秒级。支持支持 ConfigMapConfigMap 的分批灰度发布和版本管理的分批灰度发布和版本管理 Kubernetes 原生的 ConfigMap 更新是一次性全量更新到容器内的对应的配置文件，所以通过原生的方式更新配置文件是极其危险的事情。Kubernetes 1.18 支持了Immutable Co

21、nfigMap/Secret，可以保护关键配置被误改导致业务受影响。业务对容器环境下配置文件的发布同样有着分批灰度发布的极高诉求。于是我们给 StatefulSetPlus 赋予了分批发布配置文件的能力，提升了云原生场景下配置文件发布的安全性，原理如下:configmap 灰度发布 方案概述方案概述:用户修改 ConfigMap 后提交，后台自动创建一个新的 ConfigMap，其中ConfigMap Name 后缀是 data 内容的 hash 值，防止同样的 data 内容创建出多个 ConfigMap，然后在 Lable 中添加没有 data hash 值的真正的 ConfigMap 名

22、字，另外在 lable 中添加 version，或者允许业务自定义一些 lable 以便标识 腾讯大规模云原生技术实践案例集 ConfigMap 的版本。Kubernetes 对 Pod 的 修 改 只 支 持 更 新 栏 位 spec.containers*.image,spec.containers*.resources(if inplace resources update feature enabled),spec.initContainers*.image,spec.activeDeadlineSeconds or spec.tolerations(only additions to

23、 existing tolerations)，因此需要修改kube-apiserver 代码，使得允许 update/patch volumes。通过 StatefulSetPlus 的分批灰度发布能力，逐个批次的对 Pods 引用的ConfigMap 进行修改，由 kubelet volumemanager 自动 reload configmap，因此 ConfigMap 的更新不需要重建 Pods。为防止 ConfigMap 累积过多，影响 etcd 集群的性能，我们在自研组件 TKEx-GC-Controller 增加 ConfigMap 的回收逻辑，只保留最近 10 个版本的 Conf

24、igMap。用户只要在更新 Workload 页面，选择手动分批或者自动分批更新，在数据卷选项重新选择新版本的 ConfigMap 即可。可以在更新业务镜像的同时也更新 ConfigMap 配置文件，或者只更新 ConfigMap 配置文件。ConfigMap 配置文件更新，需要容器内业务进程能 watch 到配置文件的变更进行重启加载或者热加载。然而有些业务当前并没有这个能力，因此 TKEx 在 ConfigMap 发布的入口提供配置文件更新后的 ProUpdate Hook，比如业务进程的冷/热重启命令。如何保证有状态服务的升级只有如何保证有状态服务的升级只有 msms 级抖动级抖动 拒绝

25、胖容器模式（把容器当虚拟机用）是 TKEx 平台的原则，如何使用镜像发布并且提供像进程重启一样的 ms 级业务抖动，这是腾讯会议容器化上云最有挑战性的需求之一。TKEx 平台在灰度发布能力上已经做了长期的技术沉淀，上万个业务模块在使用，但当前能力仍无法满足这一需求，镜像预加载+容器原地升级的方案，仍与这目标差距甚远。经过多个方案的设计、分析、测试对比，考虑通用性、云原生、发布效率多个因素，最终使用如下方案：快速升级 Pod 里面有 3 个关键容器，它们的职责分别如下:biz-sidecar:Sidercar 容器职责很简单，检测 Pod 是否在升级中。通过 腾讯大规模云原生技术实践案例集 Re

26、adyness Probe 比较 EmptyDir Volume 中的业务发布版本文件 version1 和version2 的内容是否相等，相等则 Ready，否则 notReady。biz-container：容器启动脚本会将环境变量（预注入）里的一个版本号写到versionX 文件中，然后开始循环等文件锁，如果成功获取文件锁则启动业务进程。文件锁是防止 Pod 内同时运行多个版本的业务 Container 的关键，用文件锁来做不同版本容器的互斥。biz-pause：启动脚本会将环境变量里的一个版本号写到 versionX 文件里，然后就进入无限 sleep 状态。这个容器是备用容器，当业

27、务升级时，它就会通过原地升级的方式切换到 biz-container 的角色。升级流程概述升级流程概述 以业务容器镜像从版本 V1 升级到版本 V2 为例，升级流程描述如下：1.用户第一次部署业务，如上最左边的 Pod,一共有 3 个容器。biz-sidecar，biz-container（配置环境变量版本号为 1）以及 biz-pause（配置环境变量版本号为 1）。所有 2 个容器启动之后会分别将 version1,version2 文件的内容更新为 1，biz-sidecar 此时为 Ready。2.更新 Pod 之前的 biz-pause 容器为业务 V2 版本的镜像同时环境变量版本号

28、为2，等该容器原地升级之后把 version2 文件的内容更新为 2 之后开始等文件锁。此时 biz-sidecar 探针转为 notReady 状态。3.StatefulSet-Operator Watch 到 biz-sidecar 为 notReady 之后再将之前的 v1版本的业务镜像替换成 biz-pause 镜像同时环境变量版本号为 2。等 pause 镜像容器原地重启之后会将之前 v1 业务镜像占的文件锁释放，同时 version1 内容更新为 2。此时 sidecar 探针为 Ready,整个升级结束。需要说明以下两点：1.原生 Kubernetes apiserver 只允许

29、修改 Pod 的 image 等 field，不支持修改resource 以及环境变量等，所以该方案需要改 K8s apiserver 的相关代码。2.另外为了保证 Pod Level Resource 以及 Pod QoS 不变，StatefulSetPlus-Operator 在升级时需要对容器状态变更过程中进行 Container Resource 调整。多地域部署和升级，变得更简单多地域部署和升级，变得更简单 在多地域服务管理上，我们主要解决两个诉求：1.同一个服务需要部署在很多的地域，提供就近访问或者多地容灾，如何进行服务在多个集群的快速复制；2.部署在多个地域的同一个服务，如何进行

30、快速的同步升级；TKEx 提供了便捷的多地域多集群业务部署和业务同步升级能力。支持一次性部署到多个地域多个集群。腾讯大规模云原生技术实践案例集 多地部署支持部署在多个集群的 Workload 同步升级。多地域统一视图 腾讯大规模云原生技术实践案例集 多地域升级 平台资源管理能力增强平台资源管理能力增强 TKEx 平台的集群资源是所有服务共享的，各种服务混部在集群和节点中。各个产品都有自己的资源预算，平台接受各个产品的预算，然后根据自动生成对应的资源配额，以此控制各个产品在整个平台上的 Quota。产品部署后，涉及到成本核算，平台会根据真实使用的资源量，以小时为时间计量粒度，跟踪统计每个业务产品

31、下面各个Workload 的资源使用情况。DynamicQuotaDynamicQuota-OperatorOperator Kubernetes 原生用 ResourceQuota 来做资源限制，但是它与我们的期望相比存在如下问题：ResourceQuota 是基于 Namespace 的，无法做到产品基本的限制。ResourceQuota 是基于集群内的限制，无法做到平台级的，无法进行多集群联动 Balance。只有限制能力，无法保障业务有足够的资源可以使用。基于我们对于业务产品的管理需求及期望，TKEx 的配额管理系统须满足如下特性：使用简单，用户无需关心底层细节，比如配额如何在各个集群

32、间分布及调配都由系统来自动完成。腾讯大规模云原生技术实践案例集 分配给产品的配额，必须保障产品始终有这么多资源可以使用。满足平台在离线混合部署场景诉求，配额要有限制离线任务配额的能力。为了避免某一个产品占用配额而不使用导致平台资源浪费，要有在产品间配额借和还的能力。我们设计了一个 DynamicQuota CRD，用来管理集群中各个业务产品的 Quota，实现以上能力。DynamicQuotaQuota Rebalance Worker:该 Worker 会定期根据产品在各集群的配额使用情况，动态的将产品配额在各集群间调配。比如有个产品的服务因为配置了弹性扩缩容，当产品在某个集群因为扩容导致配

33、额用完但是在其他的集群还有比较多的配额，这时 Worker 就会将配额从空闲集群调配到该集群。DynamicQuota Operator:负责维护自定义 CRD DynamicQuota 的状态，同时会收集各产品在集群中的使用情况暴露给 Prometheus。DynamicQuota ValidatingWebhook:截获集群中所有向 kube-apiserver 的pod 创建请求，并阻止那些超配额的产品 Pod 创建请求。OfflineTask QueueManager:负责从离线作业队列（ActiveQ）中根据作业优先级进行消费，并判断各个集群的离线作业资源占比是否超过水位线，以达到控

34、制所有离线作业资源占比的目的，防止离线作业消耗过多的集群资源。pod-resource-compressor 和 VPA 组件，根据集群和节点实际负载、资源分配情况，对离线作业进行资源压缩和原地升降配，以保护在线任务的资源使用。在离线混部时，我们还在内核层面对 Cpu 调度进行了优化，以达到离线任务快速避让，以保证在线任务的服务质量。预算转移自动生成产品预算转移自动生成产品 QuotaQuota 产品完成预算归属到 TKEx 平台后，平台将自动为产品增加对应的产品配额，自动修改 DynamicQuota。用户可以在 TKEx 监控面板中查看归属产品的资源配额。腾讯大规模云原生技术实践案例集 产

35、品 Quota 业务核算自动化和可视化业务核算自动化和可视化 TKEx 会以*核*时*为业务使用资源的计量粒度进行成本核算，用户可以在 TKEx 监控面板中查看具体的各个 Kubernetes Workload 的详细资源使用情况。产品核算 提升自愈能力提升自愈能力 随着集群规模和节点部署密度越来越高，集群平均负载超过 50%，高峰期很多节点的负载甚至 80%以上，一些稳定性问题开始显现，为此 TKEx 针对节点稳定性做了如下优化：主动探测 dockerd 的可用性，异常时主动重启 dockerd，防止 dockerd hung 住导致 Node 上 Pods 自动销毁重建，主动监控 kube

36、let 的可用性，异常时主动重启 kubelet，防止 kubelet hung 住导致 Pods 大量漂移重建。因为 Kubernetes 在 pids.max,file-max 等内核参数隔离机制不完善，在 kubernetes 1.14 中虽然支持了对 Pods 内 Pids numbers 的限制，但实际落地时很难为业务指定默认的 pids limit。集群中仍会出现因为节点 Pids 和 file-max 耗尽导致同一节点上其他业务容器受影响的问题。对此，我们在 Node-Problem-Detector（简称 NPD）组件中增加了节点 pids,file-max 的监控，达到相关资

37、源使用水位线时，会自动检测消 腾讯大规模云原生技术实践案例集 耗 pids 和 file-max 最多的 Container 并上报，主动触发告警并对 Container 进行原地重启。以上几项能力都在 NPD 组件中实现，负责监控节点的工作状态，包括内核死锁、OOM频率、系统线程数压力、系统文件描述符压力等指标，做节点驱逐、节点打 Taint 等动作，并通过 Node Condition 或者 Event 的形式上报给 Apiserver。当前 NPD 组件会在节点中增加如下特定的 Conditions：Condition TypeCondition Type 默认值默认值 描述描述 Rea

38、donlyFilesystem False 文件系统是否只读 FDPressure False 查看主机的文件描述符数量是否达到最大值的 80%PIDPressure False 查看主机是否已经消耗了 90%以上的 pids FrequentKubeletRestart False Kubelet 是否在 20Min 内重启超过 5 次 CorruptDockerOverlay2 False DockerImage 是否存在问题 KubeletProblem False Kubelet service 是否 Running KernelDeadlock False 内核是否存在死锁 Freq

39、uentDockerRestart False Docker 是否在 20Min 内重启超过 5 次 FrequentContainerdRestart False Containerd 是否在 20Min 内重启超过 5 次 DockerdProblem False Docker service 是否 Running（若节点运行时为 Containerd，则一直为 False）ContainerdProblem False Containerd service 是否 Running（若节点运行时为 Docker，则一直为 False ThreadPressure False 系统目前线程数是

40、否达到最大值的 90%NetworkUnavailable False NTP service 是否 Running 有些事件是不适合在 NDP DaemonSet 做分布式检测的，我们就放在 TKEx Node Controller 中去做中心式检测，由其生成 Event 并发送到 Apiserver。比如：快速检测 Node 网络问题，而不依赖于 5min 延时的 NodeLost Condition，这个问题 NDP 检测到也无法把事件发送到 Apiserver。Node Cpu 持续高负载导致业务服务质量下降，会有 TKEx Node Controller 做检测，并将 cpu 负载

41、Top N 的 Pods 通过 Event 发送到 Apiserver，由 TKEx-descheduler 来决定驱逐哪些 Pods。做驱逐决策时，需要考虑 Pods 所属Workload 是否是单副本的，Pods 是否能容忍 Pods 漂移重建等。TKEx-descheduler 则负责 ListWatch NPD 和 TKEx Node Controller 发送的 Events，做出对应的行为决策，比如对 Pod 内某个问题 Container 进行原地重启、问题 Pod 的驱逐等。腾讯大规模云原生技术实践案例集 节点自愈 容器网络增强和调度能优化容器网络增强和调度能优化 容器网络支持

42、 EIP TKEx 之前提供的 VPC+ENI 的 Underlay 网络方案，使得容器网络和 CVM 网络、IDC 网络在同一网络平面，并且支持容器固定 IP，极大地方便自研业务上云。这次 TEKx 平台的容器网络能力再升级，支持在使用 HostNetwork 和 VPC+ENI 容器网络方案上，再为Pod 分配 EIP（弹性公网 IP）的能力。调度优化 当后端集群资源池耗尽，会有大量的待调度的 pending pods，此时使用任何类型的Workload 进行镜像更新时都会出现资源抢占导致升级失败的情况。为了解决这个问题，提升业务升级的稳定性，我们优化了 Kubernetes Schedu

43、ler Cache 的逻辑，给 StatefulSet/StatefulSetPlus 升级时提供了资源预抢占的调度能力，很好的保证了在不新增资源的情况下 StatefulSet/StatefulSetPlus 能正常升级成功，不会被调度队列中的 Pendnig Pod 抢占资源。后面团队会单独输出一篇技术文章对此进行详细分析，感兴趣的同学请关注腾讯云原腾讯云原生生公众号，加小助手 TKEplatform，拉你进腾讯云容器技术交流群。总结总结 本文总结了腾讯会议在 TKE 容器化部署时用到的平台相关特性，包括业务镜像自动分批灰度发布、ConfigMap 分批灰度发布、Pod 内 A/B 容器

44、ms 级切换发布、多集群发布管理、基于 DynamicQuota 的产品配额管理、探测节点和集群稳定性问题以提升自愈能力等。腾讯自研业务在 TKE 上沉淀的优秀组件和方案，后面会在公网 TKE 产品中提供给公网客户，也在计划开源，敬请期待。腾讯大规模云原生技术实践案例集 案例二：案例二：腾讯广告腾讯广告 AMS AMS 的容器化之路的容器化之路 点此阅读原文 项目背景项目背景 腾讯广告承载了整个腾讯的广告流量，并且接入了外部联盟的请求，在所有流量日益增大的场景下，流量突增后如何快速调配资源甚至自动调度，都成为了广告团队所需要考虑的问题。尤其是今年整体广告架构（投放、播放）的条带化容灾优化，对于

45、按需分配资源、按区域分配资源等功能都有着更强的依赖。在广告内部，播放流系统承载了整个广告播出的功能，这里的稳定性直接决定了整个腾讯广告的收入，以下为架构图：业务特点：请求量大，日均请求量近千亿级别，机器量占了 AMS 自有机器量的 60%以上，整体性能即使是少量的上下波动都会涉及大量机器的变动。链路拓扑复杂及性能压力极大，整个播放链路涉及 40+的细分模块。在 100200 毫秒（不同流量要求有差异）的极短时间内，需要访问所有模块，计算出一个最好的广告。计算密集型，大量的使用了绑核和关核能力，来面对上百万个广告订单检索的压力。上云方案选型上云方案选型 在 20 年腾讯广告已经在大规模上云，主要

46、使用的是 AMD 的 SA2 cvm 云主机，并且已经完成了对网络、公司公共组件、广告自有组件等兼容和调试。在此基础 腾讯大规模云原生技术实践案例集 上，基于 CVM 的 Node 云原生也开始进行调优和业务使用，弹性伸缩、Docker 化改造，大量使用各种 PAAS 服务，充分发挥云的高级功能。以下为广告使用的 TKE 架构：前期资源准备（左上）：从腾讯内部云官网平台申请 CVM 和 CLB 等资源，并且同时云官网申请 master，node，pods 所需要的 subnet 网段（subnet 是区分区域的，例如深圳光明，需要注意 node 和 pods 在区域上的网段分配，需要一致）。C

47、VM 和 CLB 都导入至 TKEx-teg 中，在选择 FIP 模式的时候，产生的 PODS 从分配好的 subnet 中获取自己的 EIP。仓 库 及 镜 像 的 使 用（右 上）：广 告 运 维 侧 提 供 基 础 镜 像（mirrors.XXXXX.com/XXXXX/XXXXXXX-base:latest），业务在 from 基础镜像的同时，拉取 git 后通过蓝盾进行镜像 build，完成业务镜像的构建。容器的使用模式（下半部分）：通过 TKEx-teg 平台，拉取业务镜像进行容器的启动，再通过 clb、北极星等服务进行对外使用。容器化历程（困难及应对）容器化历程（困难及应对）困难

48、一：通用性困难一：通用性 a.面对广告 84 个技术团队，如何实现所有业务的适配 腾讯大规模云原生技术实践案例集 b.镜像管理：基础环境对于业务团队的透明化 c.腾讯广告容器配置规范 困难二：困难二：CPUCPU 密集型检索密集型检索 a.广告订单数量：百万级 b.绑核：各个应用之间的 CPU 绑核隔离 c.关核：关闭超线程 困难三：有状态服务升级中的高可用困难三：有状态服务升级中的高可用 a.广告资源在容器升级过程中的持续可用 b.在迭代、销毁重建过程中的持续高可用 通用性通用性 1.1.广告基础镜像介绍广告基础镜像介绍 广 告 运 维 侧 提 供 了 一 套 覆 盖 大 部 分 应 用 场

49、 景 的 基 础 镜 像，其 中 以 XXXXXXX-base:latest 为基础，这里集成了原先广告在物理机上面的各个环境配置、基础 agent、业务 agent 等。并且基于这个基础镜像，提供了多个业务环境镜像，镜像列表如下：mirrors.XXXXX.com/XXXXX/XXXXXXX-base:latest mirrors.XXXXX.com/XXXXX/XXXXXXX-nodejs:latest mirrors.XXXXX.com/XXXXX/XXXXXXX-konajdk:latest mirrors.XXXXX.com/XXXXX/XXXXXXX-python:3 mirror

50、s.XXXXX.com/XXXXX/XXXXXXX-python:2 mirrors.XXXXX.com/XXXXX/XXXXXXX-tnginx:latest 具体镜像使用情况如下：腾讯大规模云原生技术实践案例集 在广告的基础镜像中，由于权限集设置未使用到 systemd，所以使用启动脚本作为 1 号 PID，并且在基础镜像中内置了一份通用的腾讯通用 Agent&广告独有 Agent 的启动脚本，在业务镜像启动过程中，可以在各自的启动脚本中选择是否调用。2.2.容器化容器化 CI/CDCI/CD 原先大量使用了其他平台的 CD 部分，但现在使用 TKE 后，其他平台已经无法使用。而 TKEx

51、-teg 上的持续化集成部分对于自动化流水线实现较弱，需手动参与，所以在广告内部引入的 CI/CD 方案是腾讯内部的持续化集成和持续化部署方案：蓝盾。这里全程实现流水线发布，除了审核外无需人工参与，减少人为因素的问题影响。stage1stage1：主要使用手动触发、git 自动触发、定时触发、远程触发 a.手动触发：容易理解，需要手动点击后开始流水线。b.自动触发：当 git 产生 merge 后，可自动触发该流水，适用于业务的敏捷迭代。c.定时触发：定时每天某个时间点开始整个流水线的触发，适用于 oteam 协同开发的大型模块，预定多少时间内迭代一次，所有参与的人员来确认本次迭代的修改点。d

52、.远程触发：依赖外部其他平台的使用，例如广告的评审机制在自己的平台上（Leflow），可以在整个发布评审结束后，远程触发整个流水线的执行。stage2&stage3stage2&stage3：持续化集成，拉取 git 后进行自定义的编译 a.蓝盾提供了默认的 CI 镜像进行编译，不进行二进制编译的可以选择默认（例如 php、java、nodejs 等），而后台业务腾讯广告内部大量使用 blade，通常使用 mirrors.XXXXXX.com/XXXXXX/tlinux2.2-XXXXXX-landun-ci:latest 作为构建镜像，此镜像由腾讯广告效能团队提供，内部集成了腾讯广告在持续化

53、集成过程中的各种环境和配置。编译完成后通过镜像插件，依赖 git 库中的 dockerfile 进行镜像 build，然后推送至仓库中，同时保留一份在织云中。stage4stage4：线上灰度 set 发布，用于观察灰度流量下的数据表现。a.通过集群名、ns 名、workload 名来对某个工作负载进行镜像 tag 的迭代，并且使用一份 TKEx-teg 内部的 token 进行认证。stage5stage5：确认 stage4 没问题后，开始线上的全量，每次都经过审核确认。stage6&stage7stage6&stage7：数据统计。腾讯大规模云原生技术实践案例集 另外有一个蓝盾中机器人群

54、通知的功能，可以自定义把需要告知的流程信息，推送到某个企业微信群中，以便大家进行确认并审核。3.3.腾讯广告容器配置规范腾讯广告容器配置规范 广 告 内 部 的 母 机 都 是 用 的 腾 讯 云 星 星 海 AMD（SA2），这 里 是 90 核 超 线 程 cpu+192G 内存，磁盘使用的是高速云硬盘 3T，在日常使用中这样的配置这个机型是腾讯云现阶段能提供的最大机型（已经开始测试 SA3，最高机型配置会更大）。所以业务在使用的时候，不建议 pods 核数太大（例如超过 32 核），由于 TKE亲和性的默认设置会尽量在空闲的母机中拉取各个容器，这样在使用到中后期（例如集群已经使用了 2/

55、3）导致的碎片化问题，会导致超过 32 核的 pods 几乎无法扩容。所以建议用户在拉取容器的时候如果可以横向扩容，都是把原有的高核服务拆分成更多的低核 pods（单 pods 核数减半，整体 pods 数两倍）。在创建 workload 的时候，对日志目录进行 emptyDir 临时目录的挂载，这样可以保证在升级过程中该目录不会丢失数据，方便后续的问题排查。(销毁重建仍旧会删除该目录下的所有文件)如果是已经上线的 workload，则可以通过修改 yaml 来增加目录的挂载：-mountPath:/data/log/adid_service name:adid-log volumes:-em

56、ptyDir:腾讯大规模云原生技术实践案例集 name:adid-log 在腾讯广告内部，大量使用了条带化功能，也就是服务不在受限于上海、深圳、天津这样的范围。条带化可以做到更细化的区分，例如上海-南汇这样以机房为单位的部署，这样可以实现容灾的实现（大部分的网络故障都是以机房为单位，这样可以快速切到另一路）。也可以实现条带化部署后的耗时减少，例如同上海的两个机房，由于距离的原因自带 3ms 的耗时，在大包传输的过程中，跨机房部署的耗时问题会被放大，在广告内部有出现 10ms 的 gap 出现。所 以 在 广 告 的 TKE 条带化使用过程中，我们会去通过 label 的方式来指定机房选择，腾讯

57、云对各个机房的 CVM 都默认打了 label，可以直接调用。存量的 workload 也可以修改 yaml 来进行强制的调度。spec:affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:-matchExpressions:腾讯大规模云原生技术实践案例集 -key:failure-domain.beta.kubernetes.io/zone operator:In values:-370004 广告内部后台都是建议使用 416 核的容器配置，前端平台大多使用 1 核，这样

58、可以保证在集群使用率偏高的场景下，也可以进行紧急扩容。并且如果希望亲和性强制隔离各个 pods，也可以使用如下配置进行隔离（values 为具体的 workload 名称）：affinity:podAntiAffinity:preferredDuringSchedulingIgnoredDuringExecution:-podAffinityTerm:labelSelector:matchExpressions:-key:k8s-app operator:In values:-proxy-tj topologyKey:kubernetes.io/hostname weight:100 4.HP

59、A4.HPA 设置设置 在容器化的使用过程中，有两种方式可以面对业务流量的突增。设置容器的 request 和 limit，request 资源可以理解为确定 100%可以分配到业务的，而 Limit 则是超卖的资源，是在 buffer 池中共享的资源部分。这样的好处在于每个业务可以配置平时正常使用的 request 资源，当发生流量突增时由 limit部分的资源来承担超过 request 之后的性能问题。注：但这里的超卖并不是万能的，他有两个问题也非常明显：a.在当前 node 剩余使用的资源如果小于 limit 设定的值，会发生 PODS 自动迁移到其他 node。b.如果需要使用到绑核功

60、能，是需要 qos 的功能，这里强制 request 和 limit 必须设置一样的配置。设置自动扩容，这里可以根据大家各自的性能瓶颈来设置阈值，最后来实现自动扩容的功能。腾讯大规模云原生技术实践案例集 大部分的业务都是 cpu 的性能为瓶颈，所以通用方式可以针对 cpu 的 request 使用率来设置扩容。百万广告订单检索 1.1.广告核心检索模块广告核心检索模块 广告对于每个流量都存在一个站点集的概念，每个站点集分了不同的 set，为了区分开各个流量之间的影响和不同的耗时要求。在 20 年我们对每个模块都拆出了一个 set 进行了 CVM 的上云，在此基础上，21 年我们针对核心模块 s

61、unfish 进行了容器化的上云。这个模块的特点就是 CPU 高度密集型的检索，所以他无法使用超线程（超线程的调度会导致耗时增加），并且内部的程序都进行了绑核处理（减少多进程之间的 CPU 调度）。腾讯大规模云原生技术实践案例集 2.容器绑核 这里是广告最大的一个特性，而且也是 TKE 和 CVM/物理机的最大区别。在 CVM/物理机的场景中，虚拟化技术是可以从/proc/cpuinfo 中获取到正确的 cpu 单核信息，所以在原先的业务绑核过程中，都是从/proc/cpuinfo 中获取 cpu 的核数和信息，进行每个程序的绑核操作。但在容器中 cpu 信息产生了很大的偏差，原因是/proc

62、/cpuinfo 是根据容器自身的核数进行的排序，但这个顺序并不是该容器在母机上的真实 cpu 序列，真实的 cpu 序列需要从/sys/fs/cgroup/cpuset/cpuset.cpus 中获取，例如下图两个举例：/proc/cpuinfo 中的 CPU 序号展示（虚假）：/sys/fs/cgroup/cpuset/cpuset.cpus 中的 CPU 序号展示（真实）：从上面两张图中可以看到，/proc/cpuinfo 中只是按照分配到的 cpu 核数进行了一个排序，但并不是真正对应母机的核数序列，这样在绑核的过程中，如果绑定了 15 号核，其实是对母机的 15 号核进行绑定，但母机

63、的第 15 个 CPU 并不是分配给了该容器。所以需要从/sys/fs/cgroup/cpuset/cpuset.cpus 中获取在母机中真正对应的 cpu 序列，才能实现绑核，如上图 2。并且可以通过在启动脚本中加入下面的命令，可以实现对 cpu 真实核数的格式转换，方便绑定。cpuset_cpus=$(cat/sys/fs/cgroup/cpuset/cpuset.cpus)cpu_info=$(echo$cpuset_cpus|tr,n)for cpu_core in$cpu_info;do echo$cpu_core|grep-/dev/null 2&1 if$?-eq 0;t

64、hen first_cpu=$(echo$cpu_core|awk-F-print$1)last_cpu=$(echo$cpu_core|awk-F-print$2)cpu_modify=$(seq-s,$first_cpu$last_cpu)cpuset_cpus=$(echo$cpuset_cpus|sed s/$first_cpu-腾讯大规模云原生技术实践案例集$last_cpu/$cpu_modify/g)fi done echo export cpuset_cpus=$cpuset_cpus /etc/profile source/etc/profile 调用环境变量，转换后的格式如

65、下：注意：绑核依赖 qos 配置（也就是 request 和 limit 必须设置成一致)3.3.关闭超线程关闭超线程 超线程在大部分场景下都是打开的，但在计算密集型的场景下需要关闭，此处的解决方法是在申请 CVM 的时候就选择关闭超线程。然后对关核的母机做污点并打上 label，让普通的拉取不会拉到关核母机，在需要分配关核资源的时候，在 yaml 中打开容忍和设置 label，就可以获取到相应的关核资源。yunti 资源申请时的关核配置：有状态服务升级中的高可用 无状态容器的升级最为简单，业务端口的可用即为容器的可用。但有状态业务的启动较为复杂，需要在启动脚本中完成状态的前期准备工作。在广告

66、这里主要涉及在广告订单资源的推送和加载。1.1.广告资源在容器升级过程中的持续可用广告资源在容器升级过程中的持续可用 容器的升级较于物理机最大的区别就在于容器会销毁原有的容器，然后从新的镜像中拉起新的容器提供服务，原有容器的磁盘、进程、资源都会被销毁。但广告这里的广告订单资源都是百万级别，文件如果在每次升级都需要重新拉取，会直接导致启动过慢，所以我们在容器中都加入了临时挂在目录。腾讯大规模云原生技术实践案例集 这样的挂载方式，可以让容器在升级过程中保留上述目录下的文件，不需要重新拉取。但 emptyDir 只能在升级场景下保留，销毁重建仍旧会销毁后重新拉取，以下为存量服务直接修改 yaml 的

67、方法：volumeMounts:-mountPath:/data/example/name:example-bf volumes:-emptyDir:name:example-bf 2.2.升级过程中的业务高可用升级过程中的业务高可用 在业务迭代的过程中，其实有两个问题会导致业务提供了有损服务。如果针对 workload 关联了负载均衡，这里容器在执行启动脚本的第一句话就会变成 running 可用状态，这时候会帮大家投入到关联过的负载均衡中，但这时候业务进程并未就绪，尤其是有状态服务必须得完成前置的状态后才可以启动。这时候业务就会由于加入了不可用的服务导致业务报错。在升级的过程中，除了 de

68、ployment 模式的升级外，其他都是先销毁原有的容器，再拉取新的容器服务。这时候就产生了一个问题就是，我们在升级的时候是先从关联过的负载均衡里剔除，然后立马进入到销毁阶段。如果上游是 L5调用那其实并不能快速同步到该 pods 已经剔除，会继续往下游已经销毁的容器中发送请求，这时候整个业务就会报错。所以我们这里的一个最主要的思路就是：如何把业务的状态，和容器状态进行绑定。在升级/销毁重建的过程中，是否可以做一个后置脚本，在销毁之前我们可以做一些逻辑处理，最简单的就是 sleep 一段时间。这里我们引入业务的两个升级的概念：探针就绪 后置脚本 腾讯大规模云原生技术实践案例集 a.探针就绪 需

69、要在 workload 创建的时候，选择针对端口进行做就绪探测，这样在业务端口启动后才会投入到关联好的负载均衡里。也可以在存量的 workload 中修改 yaml readinessProbe:failureThreshold:1 periodSeconds:3 successThreshold:1 tcpSocket:port:8080 timeoutSeconds:2 出 现 类 似 的 unhealty，就 是 在 容 器 启 动 后，等 待 业 务 端 口 的 可 用 的 过 程 b.后置脚本 后置脚本的核心功能就是在从关联的负载均衡中剔除后，到销毁容器之间，可以执行一系列业务自定义

70、的动作。执行顺序是：提交销毁重建/升级/缩容的操作 剔除北极星/L5/CLB/service 执行后置脚本 销毁容器 最简单的一个功能就是在上游使用 L5 调用的时候，在剔除 L5 后 sleep 60s，可 腾讯大规模云原生技术实践案例集 以让上游更新到该 pods 剔除后再进行销毁操作。lifecycle:preStop:exec:command:-sleep -60 lifecycle:preStop:exec:command:-/data/scripts/stop.sh 长期的使用经验来看，主要问题在 L5 这方面，如果是大流量的服务，那 sleep 60s 内就行，如果是请求量较小的

71、，希望一个报错都没的，需要 sleep 90s。成果展示成果展示 CVM CVM 和和 TKE TKE 的使用率的使用率和耗时对比和耗时对比 这里在相同配置下，对比了普通机器 CVM 和 TKE 容器之间的 CPU 和耗时，可以看到基本没太大差异，耗时也无变化。CVM：腾讯大规模云原生技术实践案例集 TKE：腾讯大规模云原生技术实践案例集 整体收益整体收益 结语结语 不同于其他从底层介绍云原生的分享，本文主要从业务角度，来介绍云原生在大型线上服务中的优势和使用方法，并结合腾讯广告自有的特点及策略，来实现腾讯广告在高并发、自动化等场景下的容器化实践。对于业务团队来说，任何的工作都是从质量、效率以

72、及成本出发，而云原生则是能从这三个方面都有所提升，希望未来能有更多来自于我们腾讯广告的分享。腾讯大规模云原生技术实践案例集 案例三：案例三：日日 PVPV 超百亿级的游戏营销服务云原生容器化之路超百亿级的游戏营销服务云原生容器化之路 点此阅读原文 背景背景 游戏营销服务通过分析玩家在游戏内的行为数据，精准发起运营活动，实现拉新、拉活跃、拉付费、拉回流等效果，使游戏获得更大的收益。服务有如下特点：节奏快节奏快，比如五五开黑节，九九战斗之夜，周年庆，活动仅持续数日 数量多数量多，平均每天都会有几十个活动上线，而且活动种类繁多 访问量无法精准预估访问量无法精准预估，很难精准的预测一次活动的访问量，玩

73、家参与度经常超预期 访问量大访问量大，王者荣耀、和平精英等全部游戏运营活动日 PV 超百亿级 活动逻辑复杂活动逻辑复杂，模块多，上下游依赖多，并且对依赖服务有 N 倍放大，容量评估工作量大，涉及的开发和运维人员多，紧急突发可能性大 大量重复开发工作大量重复开发工作，活动之间相互割裂，缺乏沉淀复用和共享 运营活动快上快下的特点非常适合跑在 TKE 环境，利用其弹性伸缩、快速扩缩容特性应对活动突发流量。自研上云实践自研上云实践 游戏数据营销活动 单可用区裁撤热迁移 IDC 时代，机房裁撤是个痛点，需要要梳理机器上业务代码逻辑，服务依赖以及新机器的部署测试等，带来的迁移风险和迁移工作量都非常大。相对

74、而言，TKE 集群的机器裁撤，只需增加集群资源池下线机器即可，Pod 是无损秒级迁移，极大提升了裁撤效率。服务热更新发布，容量评估效率提升 游戏数据营销活动所用的 TKE 集群流量入口增加了 Envoy 网关服务，网关和后端 Pod 都 腾讯大规模云原生技术实践案例集 在 TKE 集群内，出于性能考虑全部走长链接，为了实现后端服务热更新，放弃了 K8s 原生 service/ingresses 负 载 均 衡，采 用 了 网 关 直 通 服 务 Pod 的 路 由 方 式。网关的服务发现组件 Finder 通过 apiserver 实时 watch 服务的 Endpoint，检测到变化则下发给

75、网关。后端 Pod 的添加、删除完全由网关管理，整个过程请求无丢失，服务实现了热更新；对比物理机的通过 L5 摘除流量后发布、测试验证、接入流量，大大提高了发布效率。游戏业务活动都是周期性很强的业务发布，一个游戏活动可能一周后就得下线腾出资源或者上线活动期间需要大量资源，相比物理机的机器准备，TKE 集群仅需增加集群资源，业务副本数的扩容可在秒级扩容或配置 HPA 自动扩缩容，极大的提升了周期性游戏活动资源准备效率。服务全链路高可用及故障自愈服务全链路高可用及故障自愈 TKE 集群组件都是容灾部署的，且业务可跨地区迁移集群部署；任何单点故障都不影响服务，并且是同地区跨可用区（机房）容灾的，单个

76、机房故障不影响服务，服务具备全链路的高可用容灾能力。主要体现在如下方面：网关和业务 Pod 都是多副本部署，且集群内多可用区节点部署 TKE 集群外的 CLB 主动探测网关的存活，自动剔除故障网关 Pod 网关通过配置下发管理组件 Finder 检测 Endpoint，TKE 根据就绪探测检测服务 Pod 的存活 宿主机容灾，宿主机故障后，该机器的 Pod 会自动迁移调度到其他可用宿主机节点 跨可用区（机房）容灾，集群内宿主机节点多可用区部署接入。腾讯大规模云原生技术实践案例集 服务运营指标可视化服务运营指标可视化 服务接入上线 TKE 集群后，我们会对服务请求 QPS、响应时间、成功率、Po

77、d 负载等指标进行监控展示；网关主动采集上报指标到 Promethues 并将其可视化嵌入至发布平台。如下图所示，服务 QPS、耗时、成功率、负载情况一目了然；业务可通过自定义字段生成对应的监控指标报表；并且所有性能指标和 QPS 成功率都会有默认告警策略，还可根据业务特性自定义更改业务的告警阈值。网关运营监控指标网关运营监控指标 腾讯大规模云原生技术实践案例集 业务容器性能监控指标业务容器性能监控指标 官网营销活动官网营销活动 官网营销活动官网营销活动 HPAHPA 实践实践 业务需求场景：营销活动有定点开启特性，开启时流量会突增，且生命周期内流量波动较大，对资源有弹性扩缩容需求。需求需求

78、最终效果最终效果 分钟级扩容 优化后的 HPA 直接从 Metrics Server 取负载数据，扩容可以做到 1 分钟左右 原生 HPA 仅支持 Pod 粒度的 metric 计算,需要针对业务容器进行扩缩容 同一 Pod 多个 container 时业务容器负载高，但是 Pod 整体负载低情况下可以扩容 支持 request、limit 多种方式触发 HPA 支持按 request、limit 的方式 HPA，覆盖不同的业务场景 扩缩容事件，开发侧需要感知 优化后的 HPA，扩容、缩容都有事件通知 腾讯大规模云原生技术实践案例集 GeneralPodAutoscaler(GPA)(GPA)

79、架构图架构图 大规模配置文件分发大规模配置文件分发 问题描述问题描述：营销场景下总配置文件超过百万，每秒峰值数千个文件，需要将文件分发到 K8s 集群的所有节点，保证每个业务容器都能读到相同的配置文件，对实时性和稳定要求都很高，通过优化分发系统，能做到 5 秒内文件分发到 300+节点，通过定期校验和全量校验及时纠正，出现不一致后进行补录，保证文件的一致性。存储方案选项存储方案选项：腾讯大规模云原生技术实践案例集 问题分析问题分析：CFS 属于网络存储，读写存在一定的性能损耗 容灾能力，需要另外一种存储能够做备份（本地目录最佳）CFS 故障时能够快速切换到本地存储（或者直接读取本地存储）中转机

80、的同步程序保障高可用 根据可靠性、性能要求、隔离性可靠性、性能要求、隔离性要求，最终使用 CFS+CBS，业务从 CBS 读取，CFS 作为中转，容器通过 hostPath 方式挂载宿主机的 CBS，即使出现一个节点异常，可以通过设置污点或者驱逐的方式快速迁移业务。中转机高可用采用中转机高可用采用 K8s lease K8s lease 资源作分布式锁和租约，实现资源作分布式锁和租约，实现 HA HA 和切换功能。和切换功能。总体架构图如下：业务上云后业务上云后 IP IP 授权与授权与 NAT NAT 问题问题 业务上 TKE 后，容器环境 IP 不固定，且容器虚拟网络无法与外部直接通讯，在

81、面临 IP 授权、业务模块授权等场景时需要新的解决方案；由于容器宿主机 IP 关联业务相关信息，可以满足业务模块授权方式，并对比其他方案的效率和运维成本，最终选择了宿主机网段授权方式，因此容器访问外部实例需要在宿主机网络栈做 SNAT 转换。腾讯大规模云原生技术实践案例集 NAT 转换带来了以下几个问题：(1)业务高并发访问外部接口超时问题 问题描述：业务调用 Redis 或者其它接口，在传统环境下机器内核参数配置开启端口快速回收，工作正常；但 K8s 环境的容器在请求量大的情况下会造成容器源端口迅速被占满导致拒绝访问。问题分析：同时开启 tcp_timestamp 和 tcp_tw_recy

82、cle 时，NAT 网络环境下不同客户端的时间戳不能保证一致，会在 NAT 网关收发包时遇到乱序问题,因此在 K8s 集群的 NAT 环境下，不能开启 tcp_tw_recycle 快速回收。容器内的客户端程序频繁建立短连接与外部 server 通信时，容器内本地端口会快速耗尽，同时容器宿主机作为 NAT 网关也会大量消耗本地端口，端口耗尽后宿主机上的其他容器也会无法建立新连接。解决方式：修改程序代码，改为使用连接池方案，避免频繁建立短连接。(2)非对称回包问题 问题描述：业务容器调用某接口，一直未响应，抓包后客户端未收到回包响应。问题分析：业务架构为服务方有统一接入层，但有多个业务层，服务方

83、接入层负责收包，服务方业务层负责回包，调用方为容器环境；容器内调用方调用一个服务，服务方回包直接以网络连接上的对端 IP:port（即母机的 IP:port）作为回包地址 接入层只负责收包转发给业务层，由业务层处理完消息后直接回包给调用方，在服务方接入层的视角中，调用方地址为 SNAT 后的主机地址，之后接入层将源地址传递给业务层，业务层往源地址回包；这种架构在原有网络环境下调用方和服务方可以直连，没有问题，但在容器网络环境下的对外地址是 NAT 转换后的，而在容器宿主机的 conntrack(连接跟踪)表中，没有业务层的连接记录，因此会丢弃回包，回包无法到达容器。解决方案：直接的方案是使用

84、TKE 独立网卡 direct-eni 模式可以绕开宿主机，容器直连服务方；另一种方案是修改 IP Masquerade Agent 配置，将服务方地址段加入 nonMasqueradeCIDRs 中，也可以绕开 NAT 规则。成果成果 目前王者荣耀、和平精英等全部游戏的营销运营活动已经 All IN TKE，服务开发、运营效率提升明显，服务稳定性、抗压能力进一步增强。云原生的效能优势和技术红利不断释放出来，实现了低成本、高效率构建支持高并发场景的在线服务，让游戏运营活动支撑更快更稳，已经支持了每日数百亿服务请求。腾讯大规模云原生技术实践案例集 案例四：案例四：成本最高降低成本最高降低 70%

85、70%，腾讯大规模业务集群的云原生成本，腾讯大规模业务集群的云原生成本优化实践！优化实践！点此阅读原文 背景背景 2021 年下半年以来，在新冠疫情和互联网政策的冲击之下，各大互联网公司都在进行降本增效。降本增效的一大核心手段就是优化计算资源成本，本文将以腾讯某内部 Kubernetes/TKE 业务为案例，详细阐述如何从 0 到 1（成本数据采集与分析、优化措施、行业现状与方案选型、方案设计与实现、落地与效果、总结）进行大规模、高可靠、高效率的成本优化的实践，并在这过程中实现了零故障突发，CPU 最高节省 70%，Memory 节省 50%的成果。本文所介绍的成本优化整体方案实现是腾讯云开源

86、项目 Crane 的内部雏形版，我们在内部成功实践的基础上，将相关设计方案与最佳实践进一步输出给对外开源项目 Crane（https:/ 业务现状业务现状 数据采集与分析数据采集与分析 本文提及的若干业务全部容器化部署在 TKE 集群中，在经历了两三年的用户大规模增长后，扩容了大量节点，账单高峰期费用每月千万级，为了搞清楚高昂成本背后的缘由，以及正确的选择收益大的优化方向，我们需要基于一系列数据做科学的决策，因此成本优化的第一步，就是进行成本数据的采集与分析，如下图所示：上图我罗列了成本采集与分析的核心几个维度：成本账单，搞清楚各产品、各模块每月总成本、趋势，找准成本大头所属业务和云资源，同时

87、了解每月的新增费用主要源自什么云计算产品，在对存量资源进行成本优化时，同时也需要尽量堵住新增的。当前成本大头云资源的明细数据分析，这里我以 CVM 节点为例，核心数据如下:o CVM 节 点 总 规 模，各 地 域 各 集 群 的 CPU/Memory/Extended Resource 资源总量 o 节点 CPU/Memory/Extended Resource 资源使用率，也就是节点实际负载 o 节点 CPU/Memory/Extended Resource 的资源分配率，kubernetes Node 中的 Request 分配率，kubernetes 调度器是基于 Pod 的Reque

88、st 来调度的，只有当节点剩余足够的 Request 资源时，才能将 Pod 调度到节点上运行 业务 Pod 组件负载 o 业务 Pod 的 CPU/Memory 分配资源总量，可以直观了解到当前集群占用资源大头的组件名 o 业务 Pod 的 CPU/Memory 等各资源实际使用资源总量，与业务 Pod 分配的资源相比，可获得资源分配的实际有效率 o 业务 Pod 异常状态统计，如 OOM 次数 HPA 有效性数据分析 o 覆盖度 腾讯大规模云原生技术实践案例集 o 最小最大副本是否合理 o 是否有触发过 HPA 等 业务分析 o 负载特点，是否具备周期性特点，这个决定着资源预测算法等 o

89、服务类型，无状态服务类型，一般由延时敏感型和异步服务组成，有 状 态 服 务 类 型 一 般 由 Master/Slave 类 型 如 单 机 主 备 版 Redis/MySQL、中心化分布式集群如 Codis、去中心分布式集群如 Redis Cluster 组成，不一样的服务类型决定着上层不同的扩缩容策略、更新 Pod 策略 o Workload 组 成，像 kubernetes 常 见 的 Deployment、StatefulSets、自研 Operator，不一样的 Workload 对应上层的更新策略也是不一致的 通过以上核心数据的采集与分析，此内部 Kubernetes 平台基本信

90、息如下：核心成本是 CVM 资源，占据了 80%的成本，核心资源被三大头部业务所使用 CVM 节点 CPU 负载平均峰值 5%左右，高峰 15%，集群节点资源分配率 55%左右，节点之间负载不均衡 业务 Pod Request 与实际使用值差异较大，但少部分 Pod 还出现过 OOM，各个业务 Pod OOM 无扩容机制，根据此数据分析，我们可以通过 VPA 技术可以节省大量资源 HPA 覆盖率不高，最小和最大副本设置不合理 业务负载类型主要由 Deployment、自研 Operator 组成 业务模块既含无状态服务，又含有状态服务，无状态服务中有对延时敏感的 API 网关服务、又有非敏感性

91、的异步后台服务 业务 Pod、容器数百万级缺少 业务维度的 HPA 机制 优化措施优化措施 通过对一系列核心成本数据进行采集和分析后，我们针对现状，从业务 Pod 资源使用率提升、节点分配率提升、节点负载提升、计费优化四个方面梳理了如下优化措施：腾讯大规模云原生技术实践案例集 业务 Pod 资源使用率提升 o 引入 VPA 垂直扩缩容组件，基于用户实际使用资源的画像来进行扩缩容，覆盖所有组件，一方面可以解决业务 Pod Request 与实际使用值差异较大的问题（成本浪费大头），另一方面也可以解决少量 Pod OOM 后无自动扩容的不可用问题 o HPA 覆盖所有业务组件，优化最小最大副本数，

92、推荐合理的初始副本 o 针对周期性、活动性特点业务，使用 CronHPA 组件 节点分配率提升 o 基于业务实际负载模型选择最佳机型，而不是人工经验、直觉，从成 本 数 据 分 析 中，我 们 发 现 部 分 节 点 CPU 资 源 未 分 配 完，但 Memory 已 基 本 分 配。从 实 际 业 务 负 载 数 据 看，业 务 CPU 与 Memory 比例应是 1:4，而不是线上大规模使用的 CPU 与 Memory 1:2 比例的机型。o 将 调 度 策 略 从 默 认 的 LeastRequestedPriority 优 化 成 MostRequestedPriority，优先将

93、Pod 调度到分配资源比较多的节点（剩余资源较少的节点），提升单节点 Pod 的密度 o 修改 Kubelet Pod CIDR,提升单节点能支撑的 Pod 数 o 在提升分配率的同时，我们还需要一系列模块保障业务稳定性。动态调度器，可以在调度的时候，将高负载节点过滤掉。Descheduler,可以在节点运行过程中，对异常高负载的节点进行业务驱逐。节点负载提升 o 通过 Admission Webhook 拦截 Node 的 Patch 资源请求，基于节点实际负载等，将 Node 已分配的资源调低，此方案对 Pod QoS 策略没有强制的要求，但是细节若处理不好，会产生非常严重的故障，节点重启

94、时，可能会导致大规模的 Pod 驱逐。o 通过扩展资源封装节点可超卖的 CPU 资源，新建的 Pod 声明的 CPU Request/Limit 改成对应的扩展资源，Pod Qos 策略必须为 Best Effort。o 基于业务资源画像缩容，通过此技术业务 Pod Request 与实际使用的真实值更加接近，极大降低浪费空间 o 非敏感核心业务的 Pod QoS 策略可调整为 Burstable,Limit 资源 适 当 大 于 Request,对 CPU/Memory 资 源 进 行 超 额 使 用（overcommit）。如扩容的一个触发因子是 CPU 利用率，如果扩容是基于 Reque

95、st 计算使用率，当使用率大于 125%时阈值时再触发扩容。o 节点资源静态和动态超卖，节点可超卖资源=节点总资源-节点当前已经使用的-节点预留资源，一般实现方案主要有两种:o 在离线混布，是节点资源超卖的一种特殊形式，一般在线业务具有明显的潮汐效应，通过在离线混布技术（如腾讯开源的 Caelus）实现错峰部署离线任务提升节点 CPU 使用率 计费优化 o 各大云厂商云服务节点都提供三种计费模式，价格分别是竞价实例（可能随时会被云厂商释放）包年包月 按量付费，可根据 腾讯大规模云原生技术实践案例集 业务类型、场景选择合适的计费模式，达到成本节省的目的。o 根据自身业务需求，各机型优缺点，选择最

96、具性价比的机型。行业现状与方案选型行业现状与方案选型 从我们成本数据分析中我们得到的结论核心优化大杀器是 VPA 和 HPA。那么业界当前有哪些 VPA、HPA 方案呢？是否能满足我们期望的目标呢？VPAVPA VPA 是社区开源的垂直扩缩容开源项目，它的架构图如下，主要由如下几个组件组成：Metrics Server，提供 Pod/Node 的实时 CPU/Memory 负载数据查询服务 History Storage，默认为 Prometheus,提供 Pod/Node 的 CPU/Memory 的历史负载数据查询服务 VPA Controller，由 Recommender 和 Upda

97、ter 组件组成，Recommender 组件负责生成对应 Workload 的画像数据，Updater 组件负责监听 Pod，并通过驱逐 Pod 的方式来更新 Pod 的资源。VPA Admission Controller，负 责 拦 截 Pod 的 创 建 请 求，并 使 用 Recommender 推荐的资源来覆盖 Pod 中的容器资源。VPA 有如下的局限性或待优化点：大规模集群下存在性能和稳定性问题 不支持基于更多业务指标等设置扩缩容条件，控制扩缩容时机等 需要为每个 Workload 创建对应的 VerticalPodAutoscaler 资源 通过 Evict 的方式触发 Po

98、d 资源更新 不支持多种画像算法，内置的指数级衰减直方图算法当 CPU 瞬间高负载的时候，响应较慢 可观测性等能力较弱.腾讯大规模云原生技术实践案例集 HPAHPA HPA 是 Kubernetes 项目内置的水平扩缩容开源项目，它会基于 HPA 资源中业务声明的各种 Metrics 指标和扩缩容条件，周期性计算副本数，判定是否需要扩缩容，它的架构图如下：扩容数据源 Metrics API:o metrmetrics.Kubernetes.io1ics.Kubernetes.io1,数据源一般由 metrics-server 提供，提供了基本的 CPU、Memory 指标 o custom.m

99、etrics.Kubernetes.io2custom.metrics.Kubernetes.io2,开 源 的 数 据 源 实 现 如 prometheus-adapter，提供了集群对象资源相关的指标，如 Pod 的 HTTP QPS 和延时。o external.metrics.Kubernetes.io3external.metrics.Kubernetes.io3,监 控 指 标 的 来 源 跟 Kubernetes 本身无关，metrics 的数据完全取自外部的系统，如消息队列的任务数。HPA API o autoscaling/v1,指定最小最大副本数，关联的 Deploymen

100、t 服务，v1 只支持基于 CPU 利用率（targetCPUUtilizationPercentage）一个指标 o autoscaling/v2，支持多种数据源指标，并且支持自定义多种指标，缩容和扩容的详细规则。o 扩容算法 desiredReplicas=ceilcurrentReplicas*(currentMetricValue/desiredMetricValue)比如当前 QPS Metrics 指标值为 1000，期望的 QPS Metrics 指标值为 500，那么副本数将翻倍。o 下面是配置多个扩容指标的 yaml 例子，HPA 将依次计算多个指标下的期望副本数，然后选择具

101、有最高副本的指标进行扩容。APIVersion:autoscaling/v2 kind:HorizontalPodAutoscaler metadata:腾讯大规模云原生技术实践案例集 name:php-apache spec:scaleTargetRef:apiVersion:apps/v1 kind:Deployment name:php-apache minReplicas:1 maxReplicas:10 metrics:-type:Resource resource:name:CPU target:type:Utilization averageUtilization:50 -typ

102、e:Pods Pods:metric:name:packets-per-second target:type:AverageValue averageValue:1k -type:Object object:metric:name:requests-per-second describedObject:apiVersion:networking.Kubernetes.io/v1 kind:Ingress name:main-route target:type:Value value:10k HPA 也存在一定的缺陷，如弹性不够及时，是对监控数据的被动响应，这使得 HPA 天生具有滞后性，进而可

103、能影响业务稳定。另外，它的可观测性待提高，不支持 Dryrun 测试，一旦使用便会实际修改应用的实例数量，存在一定风险等。Google AutopilotGoogle Autopilot 介绍完 kubernetes 生态社区的 VPA 和 HPA 组件原理后，我们再来看看他们的鼻祖 Google Autopilot。Google 2020 年发表了一篇论文Autopilot:Workload autoscaling at Google，其中这样介绍 Autopilot：Google uses Autopilot to configure resources automatically,adj

104、usting both the number of concurrent tasks in a job(horizontal scaling)and 腾讯大规模云原生技术实践案例集 the CPU/memory limits for individual tasks(vertical scaling).同时在 Google 2020 年发表的另外一篇论文Borg:the Next Generation提到 Autopilot 提供的 VPA 机制是非常有效的。Our findings show that Borg features such as alloc sets are used for

105、 resource-heavy workloads;automatic vertical scaling is effective;从中我们可以看到 Google Autopilot 是集 VPA 与 HPA 与一体的弹性伸缩组件，主要目标是减少申请资源和实际资源使用之间的差异，同时最大程度地降低因 Memory 不足（OOM）错误、CPU 高负载导致的其性能和可用性下降。Autopilot 它的架构图如下（引用自 Google Autopilot 论文），它由如下组件组成:Recommender 推荐组件，负责 Request/Limit 推荐，包含多种算法，如滑动窗口、机器学习、定制化的算

106、法等。Autopilot 服务，从 Recommender 组件读取推荐的 Request/Limit 信息，通过 Borgmaster API 更新任务资源 Borgmaster 类似 kubernetes master 三大组件 Borglet 类似 Kubelet Google Autopilot 的论文和相关实践数据给我们带来了一定的启发，尤其是其业务画像推荐组件的设计，在实际场景中，我们会面临各种各样的业务场景，需要结合各自业务特点使用不同的负载预测算法等。方案设计与实现方案设计与实现 在介绍了当前行业的一些解决方案后，那我们业务场景需要一个怎样的弹性伸缩系统呢？这里我从扩展性、可观

107、测性、稳定性方面列就了一些期望的目标。设计目标设计目标 扩展性 o 支持多业务，每个 namespace 就是一个业务模块，期望弹性伸缩组件能管控任意业务组件，实现上抽象出 ComponentProvider 接口，各业务可扩展精细化设置每个组件扩缩容规则（如特殊处理有 腾讯大规模云原生技术实践案例集 状态服务组件等)。系 统内置提供自动纳管 Namespace 下任意 Pod/Container 级别的组件 Provider。o 支持多种画像数据算法(Portrait Algorithm)，从 Moving Window 到机器学习算法，再到自定义的算法等 o 支持多种扩缩容触发器(Scal

108、er Provider)，从常见的 CPU/Memory 利用率、OOM 事件，再到业务指标维度的 QPS、延时、队列堆积长度等 o 支 持 多 种 更 新 策 略(Updater Provider)，如 Evict Pod+Admission Webhook 修改 Request/limit、Deployment 的滚动更新、原地更新、先扩容再指定 Pod 缩容、修改 Operator 触发对应的 Workload 更新等。o 支持多种扩缩容记录存储策略(Record Provider)，如存储到 db、日志文件、Event 输出。o 支持多样化的扩缩容规则，如精细化到每个容器级别的 VPA

109、 扩容规则、缩容规则、HPA 扩缩容规则等，以及全局的扩缩容 Dryrun 开关 可观测性 o 扩缩容效果，可预测，比如通过 Dryrun 模式提前预测缩容能节省的资源明细、业务画像的 CPU:Memory 比例、最佳机型等 o 核心的 VPA 扩缩容次数、HPA 扩缩容此时、延时等视图 o 扩缩容队列长度 o 组件 OOM 次数 o 当前处于扩缩容过程中的组件数 o 各个业务平均使用的 Request 资源、缩容后 CPU/Memory 资源利用率等 稳定性和高效 o 整体发布策略是先 Dryrun 模式运行，然后灰度，再通过自适应限速、巡检等实现大规模缩容，同时业务 Workload 遵循

110、缓慢缩容，快速扩容策略，如有异常，可及时自愈 o 组件部署后，自动为集群中所有业务组件生成画像资源 CR，生成描述整个业务模块 Namespace 的扩缩容策略资源 CR，精细化到组件容器级别的 VPA 和 HPA、EHPA 扩缩容策略，无需运维人工做任何操作 o 支持空运行提前获取成本优化后的预测数据，各个组件扩缩容行为预测数据，并可视化的展示 o 支持多种灰度算法，如按业务重要性、规模、Workload 类型、客户敏感度 o 支持分批、自适应限速，如在缩容过程中，若大量业务满足缩容规则，则会进行自适应限速，当前处于缩容过程中的组件数小于某个阈值才能继续进行其他组件缩容 o 缩容过程中，会通

111、过亲和策略将 Pod 调度到最佳目的机型节点，老节点一般情况下只会剩下少量 Pod o 安全的节点下线，通过滚动更新、Evict 方式下线老节点上的 Pod，若业务 Pod 存在单点，则会先扩容成多副本再进行 Evict（或 腾讯大规模云原生技术实践案例集 通过滚动更新的方式安全销毁旧 Pod）,避免影响服务可用性 方案实现方案实现 基于以上设计目标和对行业各方案的选型，解决社区版 VPA 和 HPA 的若干不足之处，我们设计实现了如下架构，整体架构是画像模块和 KMetis 模块（负责弹性伸缩与节点下线及自愈）组成。画像模块画像模块 画像模块架构图如下所示：其主要由以下组件组成:Worklo

112、ad-Controller 通过监听集群下的 Deployment/Statefulset/Job/CronJob Workload,为它们自动生成对应的画像 Portrait 资源,具备高效、自动化的特点。Workload-Recommender 核心由两部分组成，数据源 data-source 模块和 algorithm 算法模块组成。数据源模块包含实时数据模块 metrics-server,OOM 事件，历史数据源 promethues、es、以及云厂商对应的监控模块等。算法模块如 VPA 的指数级衰退直方图算法、基于机器学习算法预测未来负载曲线的算法 XGBoost 等、以及自定义的高

113、实时响应级的SMA 算法等。Workload-Recommender 模块会周期性将预测的画像数据更新到画像 Portrait 资源中。业务可根据不同特点的 Workload，选择对应的算法，如 API 网关对延时非常敏感，期望极速的扩容，数据源则可以使用 metrics-server，链路短，实时响应性高，算法使用自定义的 SMA 算法，取最近几分钟的平均负载，则负载上升时响应更快，具有更高的稳定性。KMetis KMetis 模块模块 KMetis 模块架构图如下：腾讯大规模云原生技术实践案例集 KMetis 是一个集 VPA+HPA/EHPA+节点下线与一体的弹性扩缩容与节点自愈服务。核

114、心 API 资源是 CSetScaler（ComponentSetScaler）和 NodeScaler API。o CSetScaler 它描述了管理的业务服务列表、VPA 和 HPA、EHPA 的详细策略信息（扩缩容开关、触发条件、稳定时间）。o NodeScaler 它描述了节点扩缩容任务信息，主要用于节点下线，主要使用场景是成本优化和节点故障自愈。首先是成本优化，当通过画像缩容了大量的 Workload 后，集群中存在大量低负载节点，我们可以下发策略，将这些节点上的少量 Workload 安全“驱逐”，然后下线节点。其次是节点 npd 检测到某节点存在异常后，我们也可以通过 NodeS

115、caler 任务进行自愈。KMetis 核心流程如下：o KMetis 组 件 部 署 到 Kubernetes 集 群 后，默 认 使 用 的 ComponentProvider 为NamespaceAllContainer，它 会 为 每 个 Namespace 下 的 生 成 CSetScaler 资 源，它 包 含 了 这 个 Namespace 下面的所有容器，如果 Workload annotation 声明了对应的扩缩容策略（如只扩不缩），则依据声明设置规则，如果没有则采用默认规格（比如扩容稳定窗口为 180 秒、缩容随机为 12-24h、扩容 CPU/Memory 阈值为 90

116、、缩容为 30%、HPA 最小最大副本数等）。o KMetis 会周期性检查各个 Namespace 下的 Workload 负载和副 腾讯大规模云原生技术实践案例集 本数是否符合 CSetScaler 资源所期望的，若不一致，则进行一致性协调操作，主要包括 VPA 和 HPA 操作。o 优先进行 VPA 协调操作，扩缩容核心流程由 ScalerProvider、ResourceEstimator、UpdaterProvdier、RecordProvider 组成。o ScalerProvider 定义了一系列触发扩缩容的条件，如 Overload，CPU/Memory 使用率超过阈值，OOM

117、，则是 Pod 发生了 OOM 事件，Custom 则是业务基于自定义的指标，如 gRPC 服务的 P99 延时等。o ResourceEstimator 用于评估扩容、缩容后的最佳资源，缩容主要基于业务画像，扩容在业务画像、OOM 事件的基础上，结合各个业务自定义的如 gRPC QPS 指标实现的 ResourceEstimator 进行判定，依次遍历多个 ResourceStimator,取最大值作为扩容后的最佳资源。o 在 通 过 ScalerProvider 判 定 可 以 缩 容/扩 容 后，基 于 ResourceEstimator 获 取 最 佳 目 标 资 源 后，下 一 步

118、则 是 基 于 UpdaterProvider 进行资源更新，如常见的 Evict、RollingUpdate、In-Place Update,根据服务的敏感度采取不一样的策略。最后通过 EventProvider 接口，将扩缩容记录保存到日志等存储中。o 在 VPA 协调操作完成后，则会尝试进行 HPA 协调操作。HPA 基于 ReplicasEstimator 预测当前副本数，一方面它会确保当前 Pod 副本数满足业务期望最小副本数，另一方面它会优先基于业务指标判定是否需要执行 HPA 操作，避免与 VPA 发生冲突。若 VPA 扩容的最大资源已达到期望的最大规格，当 CPU/Memory

119、 负载满足 HPA 扩容规则时，也会进行 HPA 操作。o 当组件之前存在依赖关系时，同时高负载的时候，还需要通过根因分析 RootCause 模块，判断导致高负载的核心瓶颈模块，优先对其进行扩容。o 各业务也可通过配置指定自定义的水平扩展组件，如 Crane 的EHPA，它通过 Dsp 算法，可以实现提前扩容，预测未来。方案落地与效果方案落地与效果 基于以上方案选型、设计目标与实现后，我们实现了自己期望的 VPA/HPA/EHPA 混合弹性伸缩套件 KMetis，那么如何实现将 KMetis 和优化建议中提到的其他措施，在大规模 Kubernetes 集群中高效、稳定落地呢？高效、可控发布高

120、效、可控发布 为了确保成本优化方案能在大规模 Kubernetes/TKE 集群中平稳、快速落地，我们在方案设计时其实已经明确了落地四部曲：首先空运行获取预测数据，检验系统的稳定性 然后通过灰度，提前发现扩缩容过程中的隐患点 其次通过按比例、自适应限速实现大规模扩缩容 最后通过安全的节点下线流程实现成本的优化 空运行空运行/预测数据预测数据 在系统上线初期，我们会设置整个 KMetis 系统基于空运行模式运行，也就是不实际更新 Workload 资源、只存储扩缩容记录。通过空运行模式，一方面我们可 腾讯大规模云原生技术实践案例集 以验证整个系统核心流程的正确性、性能、稳定性，提前发现潜在的 B

121、ug，另一方面，我们可以直观的获取优化效果，基于业务画像数据选择合理机型，而不是靠经验、或者随意使用机型。在我们的场景中，业务 CPU 与 Memory 比例为 1:4，某核心业务机型从优化前的 8c16g 优化成了 4c16g。下图是其中一个小业务集群的在空运行发布后，获取得成本节省视图：腾讯大规模云原生技术实践案例集 某个小业务组件级 CPU 节省视图:灰度与自适应限速 在经历了空运行阶段后，我们解决了 KMetis 在大规模集群下的准确性和性能（提升 client-go qps、随机化扩缩容稳定窗口时间、读全部通过 Informer 的Cache 机制等）问题后，接下来当然就是关闭空运行

122、模式，开始为业务降本了。在这一阶段，我们基于空运行阶段，所获取的数据，按集群规模、业务重要度、业务规模、业务地域进行了一定规模的灰度。同时，因不少业务之前长期没关注成本和负载问题，大量业务模块会触发缩容操作，为了控制缩容的并发度和潜在的风险，我们实现了按比例和自适应限速能力，可实现无人值守的安全变更。什么是自适应限速呢？什么是自适应限速呢？若我们允许最大并行中的扩缩容服务为 20，KMetis 会周期性检查当前集群有多少个组件处于更新中（服务 Pod Pending、Crash、OOM 等异常），若更新中的组件数大于 20 个，则对常规的扩缩容操作进行熔断。为什么需要自适应限速呢？一方面大规模

123、 Kubernetes 集群中，大量 Pod 含亲和性规则会影响 Kubernetes 调度器性能，扩缩容过快会导致整个 Kubernetes 集群调度模块不可用，性能急剧恶化。另一方面，个别业务 Pod 缩容更新后，当前基于画像分配的负载不一定能够完全扛得住，因为这些业务在重启时可能会触发大量的 client 查询操作，尤其是基于 List-Watch 模型的类 etcd 业务场景。针对极小部分这类业务，我们需要能及时发现异常并进行熔断和告警，并在画像的基础上增加一定的安全阈值，以确保缩容操作的安全性。腾讯大规模云原生技术实践案例集 在整个变更过程中，KMetis 对外暴露了丰富的 metr

124、ics，如下图所示，总缩容次数、缩容组件名、总扩容次数、扩容组件名、队列长度、组件 OOM 次数、扩缩容延时、处于更新中的总组件数等。节点安全下线 通过大规模灰度进一步验证系统稳定性和准确性后，通过按比例、自适应限速，我们对线上大规模集群实施了几十万次的缩容操作，那么在这过程中，如何将之前的不合适的老机型替换掉呢，并尽量提高节点的资源分配率呢？答案是定制调度策略定制调度策略。针对老节点下线问题，我们根据业务模块画像对应的资源，当老节点上的 Pod 触发缩容的时候，会为其打上不同规格的亲和性标签。affinity:nodeAffinity:preferredDuringSchedulingIgn

125、oredDuringExecution:-preference:matchExpressions:-key:level Operator:In values:-small-key:x.y.z/component Operator:In values:-normal weight:10 腾讯大规模云原生技术实践案例集 为 了 提 高 节 点 的 资 源 分 配 率，我 们 将 调 度 策 略 从 默 认 的 LeastRequestedPriority 优化成 MostRequestedPriority，确保 Pod 优先调度到资源分配比较多的节点上，提到节点的分配率。为了解决节点之间负载不均衡

126、的问题，我们还引入了动态调度器和 Descheduler。动态调度器可以帮助我们避免新 Pod 调度到较高负载的节点，而 Descheduler 则可以协助我们将高负载节点 Workload 打散，下线低负载节点上的 Pod 等。通过一系列调度策略的定制和优化，老节点的 90%的 Pod 已经通过缩容操作更新到了新节点上，那么这些老节点上的 Pod 如何安全“驱逐”掉呢？节点如何安全下线呢？这就是 KMetis NodeScaler 所做的事情，它通过提交一个 Scaler Task，声明需要下线的节点列表或者 SourceNodeProvider（如低分配率节点、包年包月即将到期节点等 Pr

127、ovider），进行自动化的 Pod 安全驱逐，它的核心流程如下:获取待下线的源 node 列表，若某 node 上有禁止任何变更的业务模块，则过滤掉此节点 设置为禁止调度 获取受影响的业务模块 关闭业务模块的缩容副本功能 若采用 Evict 方式驱逐，若是单副本则扩容至多副本（通过 Rolling Update 方式更新的方式销毁旧 Pod 则无需扩容）检查扩容后的组件是否 Ready 给节点打上可安全驱逐的标记 通过 Descheduler 或人工 kubectl Drain 方式驱逐节点上的 Pod 检查驱逐是否完成，完成后打开缩容副本开关 效果效果 通过以上一整套的高效、可控、可观测、

128、安全的发布变更，我们零故障的实现了以上成本优化方案的在大规模 Kubernetes/TKE 集群中的落地，并取得了显著的优化效果。在此业务 Kubernetes 平台中，核心的三大业务，因各自具有不同的特点，优化效果也略有差异。A 业务节省了节省 70%CPU 核心,B 业务节省了 45%CPU 核心，C 业务节省了 50%CPU 核心，整体上大幅降低业务 IT 成本，并提升了各个模块在异常情况下的可用性。节点分配率上，从之前的 50%左右提升到了下图中的最高 CPU 99%，Memory 88%。CPU 利用率上，从之前的平均5%提升到21.4%。腾讯大规模云原生技术实践案例集 总结总结 稳

129、定性稳定性 成本优化的难点不是将节点分配率和资源利用率提上去，而是在高分配和资源利成本优化的难点不是将节点分配率和资源利用率提上去，而是在高分配和资源利用率的前提下，同时保障好业务稳定性。用率的前提下，同时保障好业务稳定性。在整个成本优化过程中，我们面临最大的挑战是在节点 Pod 密度上升后，个别负载较高的节点遭遇了节点内核 Bug、Docker、Kubelet Bug，这些挑战部分是我们始料未及的，并曾在一定程度上影响了我们优化进度和效果。为 了 解 决 这 些 挑 战，一 方 面，通 过 部 署TKE集 群 的 自 带 的 NodeProblemDetectorPlus 组 件，及 时 发

130、 现 各 类 节 点 底 层 问 题。比 如 NodeProblemDetectorPlus 若发现节点出现 Docker Hang 等 Bug 后，会给对应 节 点 打 上 KernelDeadLock Condition，KMetis 组 件 监 听 到 对 应 的 异 常 Condition 后，会给节点打上禁止调度，并尝试驱逐上面的业务 Pod,实现故障自愈。另一方面，TKE 团队通过一个个案例的深入分析，确认社区 Bug 原因和制定修复方案，随后通过分批升级节点内核、节点运行时组件等版实现彻底根治。另外一个大的稳定性问题则是通过滚动更新的方式，“安全”驱逐业务 Pod 时，发 现 一

131、 些 业 务 有 受 一 定 程 度 的 影 响，核 心 原 因 是 这 些 业 务 Pod 未 遵 循 Kubernetes 最佳实践和 LB 解绑 RS 存在延时，导致未能实现优雅销毁 Pod。Kubelet 销毁 Pod 流程和业务最佳实践如下:Pod 进入 Terminating 状态后，Pod 从对应的 Service 和 LB 上删除，确保新请求不会转发到销毁的 Pod 上，在这过程中，可能会因控制面负载、iptables 规则数量、LB 组件性能等出现解绑 RS 延时。为 了 解 决 解 绑 RS 延 时 等 问 题，业 务 最 好 配 置 preStop 脚 本，在 Kubel

132、et 发送 SIGTERM 命令前先 Sleep 30s。Kubelet 会优先调用业务自定义的 preStop 脚本，再向 Pod 的 Pid 1号进程发送 SIGTERM 信号，实现优雅关闭进程。腾讯大规模云原生技术实践案例集 业务需确保 Pid 1 号进程能接受处理 SIGTERM 信号，而不是搞个 Shell 进程拉起或者循环检查业务进程，异常就拉起之类的非标准用法。当 terminationGracePeriodSeconds 时间到达后（默认 30s)，若容器未正常退出，Kubelet 会发送 SIGKILL 强制杀掉尚未退出的容器。未来方向未来方向 当前 CPU 利用率依然有优化

133、空间，下一步我们将结合节点资源超卖来实现 CPU 使用率进一步提升。本文系统的阐述了基于 Kubernetes 平台的云原生成本优化方法论，详细介绍了我们如何从 0 到 1 的实践之路，相信其中的数据分析、方案设计思想、落地与最佳实践、稳定性问题反思能给你带来一定的启发。想更深入了解成本优化，可以关注下腾讯开源的 Caelus 和 Crane 项目。腾讯大规模云原生技术实践案例集 案例案例五五：腾讯文档业务上云，腾讯文档业务上云，Serverless Serverless 架构应用最佳实践架构应用最佳实践 点此阅读原文 近两年，国内文档类 SaaS 产品层出不穷，协作云文档作为云时代办公的一种

134、工具和方式。与传统的离线办公软件不同，协作云文档更加注重协作的沟通和效率，同时作为工具类产品也同样关注性能和体验。就在不久以前，一个救命文档的一个救命文档的 24 24 小时小时刷屏朋友圈，在河南暴雨灾情中，腾讯文档快速响应灾区需要，提升稳定性，确保产品体验。腾讯文档脱胎于 QQ 家族旗下一款团队协作 IM 软件 TIM 的在线文档模块，最初基于开源软件搭建的技术架构，随着业务的高速发展，已无法完全满足业务的需求，且积累下了比较沉重的技术债务。团队经过慎重的讨论，决定从底层开始，分模块，逐步重构整个技术体系。在技术迭代的过程中，团队也在不断探索和尝试业内一些先进成熟的技术解决方案。腾讯文档整个

135、技术体系内集成了许多微服务为腾讯文档提供业务支持，比如 图像识别、图像识别、SSRSSR、截图、文档预览、截图、文档预览 等，这些微服务需要从效率和成本需求出发考虑解决方案，以实现可扩展、易维护、降低开发成本的目标。伴随着公司自研上云的浪潮，在近来的开发中，团队在多个微服务项目中深入使用 腾讯云腾讯云 Serverless Serverless 架构，满足了业务的需求，取得了架构，满足了业务的需求，取得了不错的效果。不错的效果。腾讯文档腾讯文档 x Serverless x Serverless 云函数云函数 多场景应用多场景应用 1.1.应对流量高峰低谷应对流量高峰低谷 办公类产品是有明显的

136、流量潮汐的，比如上午 8 点到 12 点，下午 2 点到 6 点这几个时段是流量比较大的时候，其他时间段尤其是凌晨没什么流量。随着用户量快速增加，这种潮汐规律尤为明显，高峰时期海量用户的实时修改对服务器造成巨大的压力。传统架构下可以通过增加虚拟机，实现应用的可扩展。但由于预估容量不足，导致业务流量高峰期时，大量用户出现请求超时的情况，这意味着品牌声誉受损、用户流失。虽然可以通过创建虚拟机实例的方式进行扩容，但是仍然要做很多额外的配置。应用底层有很多依赖的框架或语言运行时需要安装，安装完成之后还需要配置和部署应用，这个周期至少需要这个周期至少需要 1 1-2 2 个小时，这种情况下传统的部个小时

137、，这种情况下传统的部署架构无法做到资源与流量的匹配。署架构无法做到资源与流量的匹配。Serverless Serverless 解决方案腾讯文档借助解决方案腾讯文档借助 Serverless Serverless 云函数搭建文档页面直出服务，将文档的云函数搭建文档页面直出服务，将文档的内容渲染能力实现为函数，内容渲染能力实现为函数，部署在云函数环境上，当文档业务流量激增，由云函数的负载均衡系统自动分配执行环境，处理海量用户触发的内容更新请求负载，动态扩缩容能力为微服务提供最合理的资源分配。同时通过设置云函数预置并发，可预先启动多个函数实例，保持设置云函数预置并发，可预先启动多个函数实例，保持云

138、函数的活性，消除冷启动，降低在运行环境初始化和业务代码初始化产生的耗时。云函数的活性，消除冷启动，降低在运行环境初始化和业务代码初始化产生的耗时。腾讯大规模云原生技术实践案例集 2.SSR 2.SSR 前端渲染前端渲染 腾讯文档自推出以来，已达千万月活，为了支持用户打开页面时能快速看到页面内容，浏览器直接解析 HTML 直出的字符串模版显示页面，流量激增导致集群负载、前端渲染压力增加，首屏加载时间慢等问题。SSR 团队需要实现一套弹性高可用性的直出解析服务来处理文档和表格的页面内容，满足可扩展、易维护、降低开发成本满足可扩展、易维护、降低开发成本 的目标。文档的渲染能力几乎都是前端同学在负责，

139、而前端同学大多服务端知识积累比较浅，对于服务的开发运维经验比较少，长期的运维成本是新的架构设计重要的评估维度，从而让前端团队可以更加聚焦于业务逻辑本身。ServerleServerless ss 解决方案解决方案 SSR（Server-Side Rendering）需要依赖 Node.js 服务渲染页面，显然会比仅仅提供静态文件的 CSR（Client-Side Rendering）应用需要占用更多服务器 CPU 资源，借助 Serverless 方案，前端同学无需关注无需关注 SSR SSR 服务器的部署、运服务器的部署、运维和扩容，通过云函数对底层服务进行封装，极大地减少部署运维成本，更加

140、聚焦业维和扩容，通过云函数对底层服务进行封装，极大地减少部署运维成本，更加聚焦业务开发，提高开发效率。务开发，提高开发效率。腾讯大规模云原生技术实践案例集 全新 Serverless Web Funciton Serverless Web Funciton 服务开发模式服务开发模式，只需简单修改监听端口，即可将目前流行的 Node.js 框架直接部署上云，享受 Serverless 技术带来的免运维、低成本、按需扩缩容的众多优势，欢迎体验。3.3.外部服务调用外部服务调用 -OCR OCR 图像识别图像识别 腾讯文档幻灯片支持编辑公式的能力，OCR 图像识别是腾讯文档幻灯片结合外部的 OCR

141、服务能力来完成文档内的公式图片转换为公式，进而方便用户进行公示编辑。问题点在于：外外部提供的部提供的 OCR OCR 服务做了限制，不支持前端请求，仅支持服务端请求。服务做了限制，不支持前端请求，仅支持服务端请求。传统的解决方案需要后台同学接入，进而增加了人员排期、对接等项目管理的复杂度。Serverless Serverless 解决方案解决方案腾讯文档将外部提供的 OCR 用云函数 SCF 做一层转发，腾讯文档再对接联调云函数的接口。解决了外部服务的限制，同时节省了后台开发资源，前端业务开解决了外部服务的限制，同时节省了后台开发资源，前端业务开发同学可以自己快速对接上外部服务，大大提升了开

142、发效率。发同学可以自己快速对接上外部服务，大大提升了开发效率。4.4.插件中心插件中心 -第三方服务接入第三方服务接入 腾讯文档插件 1.0 的方案是基于对文档前端封装到前端插件 SDK 的方案，在内部插件业务严重耦合文档实现的前提下，无法将文档能力以安全、成体系的方式对外提供，持续去开放前端文档的编辑的能力，会使前端 SDK 和文档侧的实现逐步变得臃肿，最后有可能会在变成巨石应用上长期存在的技术债务。Serverless Serverless 解决方案解决方案插件 2.0 方案的核心是基于后台内容编辑的能力开放，利用文档的 腾讯大规模云原生技术实践案例集 数据响应式的更新机制，云函数便成为云

143、函数便成为 前端前端 -云函数云函数 -后台内容编辑后台内容编辑 中关键环节，中关键环节，将开放的实现从前端剥离，通过云函数承载进行开放。将开放的实现从前端剥离，通过云函数承载进行开放。同时，不同服务的调用量级不同，云函数带有天然的服务隔离和动态修复能力，可针对不同服务相互隔离，分别进行升级拓展，避免服务间的影响。5.5.灰度发布灰度发布&环境隔离环境隔离 在进行应用版本更新及切换时，为了保证线上整体系统业务稳定，及时发现业务代码的问题，研发团队会采取灰度发布的方式测试迭代。通过云函数针对特定的版本进行逐步的流量切换，可以实现某个版本的平滑灰度，保证新上线的版本能够 在可控的范围能进行发布迭代

144、。通过云函数版本隔离测试环境和生产环境，线上通过对$LASTEST 进行版本的固化，可以把测试环境的 API 网关对接到 TEST 版本，将生产环境对接都固化的版本上，保证生产环境的代码质量安全。腾讯大规模云原生技术实践案例集 Serverless Serverless 架构方案优势架构方案优势 研发效率提升研发效率提升 本地开发测试后，触发 CI/CD 流程，就可以完成部署流程。同时，云函数提供了日志监控、灰度、发布回滚等能力，可以通过接口或者插件实现完全自动化的流程。云函数基于腾讯云专业的保障集群，自带负载均衡和弹性伸缩，开发同学基本不需要再关心运维等问题，可以有更多的时间聚焦业务的优化。

145、服务端经验较少的前端开发工程师也可以较为轻易的开发维护服务。成本节约成本节约 云函数实现 1ms 计费粒度，按实际用量计费，帮忙用户获得显著的成本优势，在没有访问量时实现自动缩容，节约部署成本。灵活度高灵活度高 凭借腾讯云函数的多版本能力，可以灵活部署多个在线版本，通过和网关的配合的，轻松做到多版本共存，提供定制化的处理能力。加速业务迭代加速业务迭代 使用 Serverless 方案之后，极大减少了运维和监控的负担，开发同学可以把更多的精力放在方案的优化和技术迭代中，快速验证产品特性，推动团队技术业务的发展。腾讯大规模云原生技术实践案例集 腾讯文档腾讯文档 x Serverless x Ser

146、verless 架构更多场景探索架构更多场景探索 当下浏览器环境是有性能瓶颈的，对于较为复杂的异步逻辑可以考虑使用云函数将逻辑服务化，接下来，腾讯文档计划对前端浏览器逻辑 Fass 化，可以从前端分离到服务端，进而降低浏览器性能压力。在协作办公的赛道上，团队业务还在快速的成长，面对快速变化的技术迭代，低成本、快速面对快速变化的技术迭代，低成本、快速开发、快速部署、快速上线的开发、快速部署、快速上线的 Serverless Serverless 解决方案成为了团队在微服务技术选型中优先解决方案成为了团队在微服务技术选型中优先考虑的架构。考虑的架构。借助云函数 SCF 的能力，团队不用再担心后台计

147、算资源的问题，可以更加有信心应对更多突如其来的事件。未来，随着腾讯文档开放平台的建设，会有更多的使用云函数 SCF 的微服务跑在腾讯文档的业务中，为广大用户提供更好的服务。腾讯大规模云原生技术实践案例集 案例案例六六：QQQQ 全量上云，你想了解的技术细节都在这全量上云，你想了解的技术细节都在这 点此阅读原文 腾讯的业务体量非常庞大，在 2019 年，腾讯已拥有超过了 100 万台服务器，其中，社交业务包括 QQ 和空间的体量有近 20 万台服务器，且分布在全国三地。把 QQ 这头大象搬到云上并非易事。作为腾讯最庞大、最悠久、最复杂的业务之一，QQ 各系统间存在强耦合。上云过程中需要确保对用户

148、零影响，其难度可想而知。面对重重挑战，面对重重挑战，QQQQ 是如何迎难而上的呢？是如何迎难而上的呢？本文即将从整体规划、方案执行、里程碑中整体规划、方案执行、里程碑中的挑战的挑战等方面介绍其中的技术细节，希望能为大家提供借鉴。一、整体规划一、整体规划 1.1.上云整体规划上云整体规划 QQ 上云规划时进行了系统化的梳理，包括业务评估、容量评估、业务架构、组织体系业务评估、容量评估、业务架构、组织体系（比如运维职责的变化、研发流程的变化、资源预核算的变化、故障处理流程的变化）。最重要的是，QQ 的技术体系技术体系跟着公有云进行了转变，确定迁移方案、迁移工具、风险预案、回滚预案、混合云预案、多云

149、预案等。以过程划分，QQ 上云整体规划包含以下三个阶段。(1)基础设施上云，简单说就是把基于物理网络的自研 IDC 设备搬到云上，使用基于虚拟网络的云 CVM 来搭建。(2)微服务和容器化改造，支持自动扩缩容。(3)架构和存储升级，全面融入云生态。其中，基础设施上云是最底层、最基础的第一步，本文将重点介绍。2.2.基础设施上云规划基础设施上云规划 基础设施上云的规划分为两个阶段。(1)完成所有核心功能模块在云上的搭建，并调度 1000 万在线用户到云上。(2)完成整体基础设施上云，并做好云上的三地调度演习。在计划推行的过程中，腾讯内部多个技术团队精诚合作，共同应对复杂挑战。然而，随着 QQ 逐

150、步放量上云，面向海量服务的挑战才刚刚开始。二、方案执行二、方案执行 QQ 上云方案执行前，有预测试、预验证的过程。一些核心模块（譬如高并发，或延迟非常敏感的模块）在云上经过了充分压测。真正迁移后，还有更多挑战需要灵活应对。1.QQ1.QQ 后台服务搬迁上云主要挑战后台服务搬迁上云主要挑战 QQ 后台服务搬迁到云上部署，有这几类主要挑战：腾讯大规模云原生技术实践案例集 0101 安全问题 腾讯云提供的官网 VPC 可以通过配置反向代理被外网访问，相比受自研环境保护的内网环境，缺乏自我保护的能力，搬到云上貌似更容易被恶意入侵。0202 依赖问题 QQ 后台服务依赖关系复杂，无法一次性将全部服务都迁

151、到云机房。统计后发现，QQ 后端主要的核心模块平均依赖 40+个后端模块。其中很多是外部的模块，比如安全、架平存储，这些模块云上支持的时间未定，前期只能先穿越到自研 IDC 访问。0303 容灾问题 部署到云上的模块，需要通过云机房到自研机房的专线进行通信，若专线发生故障，可能导致云机房成为孤岛。一开始云机房只在广州部署，无法做到云环境内部多地容灾而后云自研云机房。0404 灰度问题 QQ 即时通讯的特点，决定了用户对 QQ 的实时性要求很高，怎样合理灰度，做到用户对上云过程零感知，是一座需要跨越的大山。2.2.面临挑战，如何解决面临挑战，如何解决 0101 应对安全问题 结合云上的安全产品，

152、以及原来自研的安全服务和安全策略，腾讯有一套混合云的安全通用体系。首先在公有云的大网里，划出独立的私有网络首先在公有云的大网里，划出独立的私有网络 VPCVPC-X X 即有外部访问的模块（如 QQ 接入层 SSO、内网接入层 OIDB 等），可以部署在普通的VPC 中，而核心业务需要做外部隔离部署。为此，QQ 运维和腾讯云一起建设了没有外网环境的 VPC-X 专用云环境，并通过策略打通了普通 VPC 和 VPC-X 之间必要的访问路径，拒绝其他访问。腾讯大规模云原生技术实践案例集 在此之上，使用网络防护以及网络安全的产品服务在此之上，使用网络防护以及网络安全的产品服务 云上有丰富的安全产品：

153、主机上有主机防护，漏洞扫描；业务层有应用防护；运维有运维安全。QQ 内部积累的一些安全方案，也已回馈到云上。事实上，整个公有云的安全策略和私有云是一样的，没有什么根本性的差别。0202 应对依赖和容灾问题 上云过程要需要进行灰度迁移，而迁移过程会不可避免地造成自研机房和云机房的带宽穿越，为此，需提前评估自研机房到云机房所需的带宽。假如使用城市方案，专线带宽应该跟现有的三地部署方案对齐。QQ 核心系统大概需要几十 G 的带宽。若采用 IDC 方案，QQ 里面有很多业务使用有状态的寻址方式，把同城内的机房全部打散访问（类似一致性哈希）。因此，把广州云当做深圳的 IDC 后，广州云和深圳的专线穿越会

154、增大。参考深圳内部的 IDC 穿越带宽，预计需要增加几十 G 的带宽。腾讯大规模云原生技术实践案例集 为此，开发者们评估了自研到云机房的带宽：支持 QQ 几大核心系统（接入、消息、状态、资料、关系链、登录）所需要的带宽为 N。而所有 QQ 基础功能都迁移到云上，则至少需要 2N 的带宽。考虑到容灾问题，实际上拉了两条专线互备（防止专线被挖断形成孤岛），即为 QQ 上云专门搭建 4N 的带宽专线。0303 应对灰度问题 QQ 后台的模块众多，一下子上云并不现实，为了确保服务切换的平滑稳定，需要考虑以下情况：(1)有问题时影响尽可能少的用户。(2)用户数据完好性：有问题时不能导致用户数据丢失或错乱

155、。(3)机器维度回退：云上环境有问题时，可以随时禁用，全部切回自研环境。(4)用户维度回退：用户登录云 IP 有问题，能够自动切换到自研 IP，不影响用户使用 QQ。为此，需从 3 个维度制定灰度的 3 条主线：(1)(1)用户维度用户维度 简单说，就是灰度的用户量级。主要考虑用最少用户量级来发现问题。(2)(2)后台模块维度后台模块维度 其实就是哪些模块先上，哪些模块后上。主要考虑哪些模块出问题对用户的影响最小。基本思路是：(1)先上接入层，验证云上的链接能力；(2)再上逻辑层，逻辑层通过一定用户量级验证没问题；(3)再上数据层，确保用户数据一致性。(3)(3)后台后台 SetSet 维度维

156、度 一个 Set 可以认为是一套闭环的系统，比如资料后台的一个 Set，包含“接入层+资料逻辑层+资料数据层”。这个维度的灰度，可用来确定一套系统里需要多少机器上云。对于纯逻辑层来说，每个模块上两台机器（两台是为了考虑故障容灾，只需确保有一台在工作），就可以构造一个闭环的 set，但对于数据层来说，一个 set 需要的机器包含一份全量用户的数据拷贝。从灰度的角度来说，逻辑层就是堆机器的过程，数据层是先上一份最小的数据拷贝，并且先只放开“读”服务，等到其他所有环境都验证可行，才切“写”服务到云上。腾讯大规模云原生技术实践案例集 结合上面 3 个维度，总体的灰度过程是：(1)内部验证+接入层（验证

157、三通接入、用户级和机器级调度能力）(2)0-100 万用户+接入层灰度扩容（小规模验证，观察用户反馈）(3)100W+逻辑层灰度及扩容(4)100W500W+数据层同步数据(5)500W+数据层读(6)500W1000W+数据层写(7)1000W5000W+广州云 1 亿在线演习(8)南京云+天津云+05000W(9)天津云/南京云+5000W1 亿(10)天津云/南京云/广州云新 3 地调度演习(11)天津/上海自研机房下架，保留深圳自研机房观察 1 年(12)深圳自研机房下架 灰度过程中，通过客户端服务质量、服务间调用延迟、全网拨测等监控指标判断业务是否有问题。另外，此时整个服务运营体系已

158、经转变，QQ 必须适应相应的调整：(1)基础运维和公共运维团队变成由公有云的运维团队来支持。(2)运营流程也发生很大的变化，服务 SLA 要跟公有云服务商一起制定。(3)监控工具的选择，或改造原有的监控工具，或者换用云上成熟的监控 SaaS 服务。三、里程碑中的挑战三、里程碑中的挑战 基础设施上云，从用户量级的角度来考虑，主要有几个里程碑：(1)500 万是速度和质量的平衡。(2)1000 万开始迎接海量的挑战。这里分析下每个里程碑里会遇到的重点问题：里程碑里程碑 1 1：五百万在线：五百万在线 在 0 到 500 万在线的这个阶段，需要重点关注可行性的问题，即各个系统怎样做好充分的验证，才能

159、确保在云环境里成功跑起来。0101 丢包问题 丢包问题一般只是表象，真实的丢包原因隐藏着各种环境的适配问题、稳定性问题、质量问题。在 QQ 上云的过程中，丢包问题频繁出现，是所有问题中最棘手的。这里列举在这个阶段遇到的两个丢包 case：case 1case 1：网关问题。：网关问题。在资料后台的搭建过程中，曾发现 UDP 的丢包率较大，且可稳定复现在某些用户上。腾讯大规模云原生技术实践案例集 通过问题定位发现，发包和收包逻辑均正常，于是怀疑数据在链路上丢了。最终发现是物理网关的问题：只要是 UDP 分片，且 IP 头后面第三个第四个字节为 3503（0D AF）就必然导致丢包，同时也发现这个

160、问题只在第一代网关设备（VSG）出现。于是腾讯找到网关设备厂商协商，把一代网关升级为二代网关（NGW），解决了该问题。case 2case 2：VPCVPC 缓存会话问题。缓存会话问题。这其实是上个问题的延续。在一代网关（VSG）升级到二代网关（NGW）的过程中，触发了 VPC 在宿主机 SDN 转发实现上的一个 bug，导致 UDP 丢包。一开始腾讯云在切换路由时是先删后加，当 VPC 内有 NAT 网关的默认路由时，就会导致流量转发到 NAT网关。当路由加回来时老会话不会更新路由，因此老会话中断，而新发起的会话能正常工作。刚好自研机房有几台机器访问 OIDB 的 UDP 四元组一直不变，会

161、话就会一直不老化，导致业务一直异常。最后这个问题靠重启业务进程解决，后续腾讯云团队也修复了这个 bug。这个时候遇到的其他丢包 case 还包括“专线被挖断、机器故障、机器性能问题”等，不过大多不是大面积问题，其影响范围较小，相关技术负责人能及时地解决大部分问题。0202 获取 VIP 问题 QQ 调度系统依赖用户侧上报接入 IP 的可用性和耗时，来判断接入服务是否健康，并做最优的调度策略。因此，调度系统需要知道用户实际链接的对外 IP（从后台角度看是 TGW 对外提供的 VIP）。在自研环境中，TGW 把 VIP 通过 IP 层的目标 IP 传给 QQ 接入层 SSO，SSO 通过 gets

162、ockname 系统调用就可以获得外网用户看到的 VIP。但到了云上环境，接入层使用 CLB 接入，CLB 传给 SSO 的时候，目标 IP 填写的是 SSO 所在虚拟机自身的内网 IP。因此，在客户端不做升级，不修改登录协议的情况下，调度系统无法获得 VIP。解决办法之一是客户端升级协议，但这样的话老用户无法上云，无法保证上云的进度。另一个办法是修改 CLB 的实现，对齐 TGW，把外网 IP 传给 SSO。在多方技术团队的努力下，最终决定按此方案实现。不过因为 CLB 依赖 TGW/GRE 的实现，还需要 TGW 团队、TLinux 内核团队的配合，并需要将全网腾讯云的机器进行内核升级，整

163、个修复的周期比较长，预期是 3 个月。但 QQ 上云的进度，不能因此推迟 3 个月，为此，开发者们制定了一个临时方案：通过配置文件，配置 VIP 到 RIP（Realserver IP，虚拟机内网 IP）的映射关系。这个方案要 RIP 与 VIP 一对一映射，但在现网环境中，RIP 到 VIP 的映射关系是多对多的（为了降低 TGW 和 SSO 的相互依赖，保证 SSO 多通路负载均衡）。在上云初期 SSO 机器较少的时候，人工确保一对一映射是没问题的，但随着上云机器数和用户数增多，一对一映射将无法满足现网质量要求。腾讯大规模云原生技术实践案例集 里程碑里程碑 2 2：一千万在线：一千万在线

164、从 500 万到 1 千万的阶段，云设施的基础能力已经验证没有问题，但网络质量、时延的问题更为凸显。0101 丢包问题 随着云上用户量的增长，很多新的问题被暴露出来，比较典型的还是丢包问题。这个时候遇到的丢包问题，大概有如下这几种情况：(1)虚拟机默认缓冲区太小。(2)物理母机缓冲区大小设置太小。(3)VPC 会话数限制太小，VPC 在实现上会存储网络访问的五元组会话，QQ 后台大量使用 UDP，而且因为 QQ 体量比较大，五元组的数量很大，超过 VPC 的限制。0202 批量死机问题 这是群 Server 在部署的时候遇到的一个问题：3 台机器一起死机，定位后发现是同一台云主机死机了。在自研

165、环境中，群 Server 是使用实体机 M10 来搭建的，到了云环境，采用相同内存大小的虚拟机来搭建。运维在部署的时候，若把主备本应该分开部署的机器放到同一台实体机上了，这对业务来说简直是灾难。最后，技术同事们协商确定，由运维来确保同个模块分配的机器不能处于同一台物理机上，实现方式是：在业务同一个集群下的配置组别，打散母机。四、找对方法，加速上云四、找对方法，加速上云 在 QQ 上云过程的细节里，有很多方法可以选择，也离不开一些技术工具和平台的支持。这里从“数据库的迁移模式”、“MySQL 数据搬迁”、“数据中心同步”、“云管平台”、“云原生”、“TKE 引擎”这几个方面来进行简单介绍。1.1

166、.数据库的迁移模式数据库的迁移模式 在私有云到公有云的数据搬迁模式中，QQ 有三种模式可以选择。(1)(1)私有组件数据迁移到公有云私有组件数据迁移到公有云 腾讯内部有很多自研的数据库，像 QQ 的 Grocery KV 存储使用的是内部私有协议，云上没有对应服务。业务需要将数据从私有组件迁移到 Redis。QQ 采取了冷迁移的方式，先将数据全备，然后把数据导到云上 Redis 集群，导完后再做新增数据追加(用数据同步中心来实现)，数据同步完之后进行业务切割：留一个业务低峰期时间，比如晚上凌晨 2 点，花 1 分钟把数据路由服务从自研 IDC 切到公有云Redis 集群上。腾讯大规模云原生技术

167、实践案例集(2)(2)开源组件到公有云开源组件到公有云 腾讯内部有一些业务是在开源组件之上做的二次开发(如基于单机 Redis 实现自研分布式 Redis集群)。这些基于自研或开源组件的数据迁移到公有云上对应的数据服务，可通过 DTS 迁移工具来实现。腾讯云上的 DTS 也可以来做自助迁移。这个工具甚至不需要运维操作，开发团队自己在 DTS 窗口上输入几个参数，点个搬迁按纽后即可自助搬迁。搬迁完成后还可自动切换。(3)(3)私有组件直接上云私有组件直接上云 有时云上暂无一些特定组件，业务也没有资源改造私有组件为云的标准服务，此时可将组件集群直接在云上部署一套，数据通过同步中心或主备备等方式搬迁

168、到公有云上。2.MySQL2.MySQL 数据搬迁数据搬迁 QQ 的 MySQL 数据搬迁分“主从”和“主备”两种模式。主主从的模式从的模式 它通过内部的 DNS 类名字服务而非 IP 和 PORT 来寻址：先分配业务一个实例的名称，然后通过 DNS 拿到这个实例的 IP 端口，再去访问具体的实例。然后，从自研的 IDC使用腾讯云 DTS 迁移工具，把数据导到云的 MySQL。数据自动导入完成后，开发团队只需要在云上切换服务就可以完成数据实例的迁移。这种方式适合一些数据体量不大的业务数据迁移。主主备的模式备的模式 即在深圳自研有数据库服务器的主和备，在云机房新部署几台备机。通过主备同步的方式，

169、把所有数据都同步到云机房。然后将云机房的某台备机切换成主机，将自研的主机降级为备机。这样就切换为云机房主备，自研机房备的模式。腾讯大规模云原生技术实践案例集 3.3.数据同步中心数据同步中心 更复杂的是数据同步中心。它适合业务量大，有全国多地分布且对延迟不敏感的业务，譬如 QQ 空间的点赞、发表说说等。它有如下特性：服务模块写数据时，统一写到各地的接入代理，代理再统一写入一地；写服务的转发存储会将新增记录同时写到各地自研或云机房，实现最终数据一致性；用户就近读，比如华北的用户，就读华北云的这个数据存储集群，华南就读华南的数据存储集群；通过同步中心的方式完成大规模数据的混合云同步。当要增加一个成

170、都云区域，只需在当地增加一套同步服务。增加路由服务规则后，同步服务就会自动把数据同步到成都的云机房。一般从深圳自研同步到上海和天津时延迟达几十毫秒，不适合金融行业等延时高敏感业务模式。4.4.云管平台云管平台 之前腾讯内部的配置系统、监控系统、CMDB 等都是基于私有云的管理模式。业务上云之后，它们要改造成支持混合云、多云的管理模式。譬如业务模块会有 50 个实例在腾讯云上，30 个实例在海外云上，30 个实例在内部私有云里，那么 CMDB 必须要支持多云的资源管理。图中可以看到，帐号体系、预核算、企业安全、监控等应用工具或平台，都要改造以适应混合云模式。以帐号体系为例，QQ 的开发者们以公有

171、云的帐号登录云官网来购买、使用和运营公有云上的资源。但如何把帐号所使用的资源成本核算到对应的业务，员工离职或转岗后资源怎么回收或转移，帐号如何绑定给企业组织架构，云官网帐号登陆如何与内部 OA 鉴权等，都是必须提前解决的问题。腾讯大规模云原生技术实践案例集 5.5.云原生云原生 在开发方法、业务交付、云原生服务等方面，腾讯内部的 TAPD 研发管理工具、工蜂代码仓库、蓝盾、橘子 CI、QCI、coding 已集成为工具链，在云上打造了一个持续集成、持续部署的 DevOps 流水线闭环，QQ 上云也收益于此。QQ 以前是包交付，现已大量使用容器交付方式。在微服务这块（如 SF2、SPP、TAF

172、等），QQ 使用了大量的微服务框架，这些微服务框架还将进行迭代升级。6.TKE6.TKE 引擎引擎 K8S 平台上，QQ 用了腾讯的 TKE 引擎，这是一个跟 K8S 完全兼容的引擎。一个用户在腾讯云上买了 K8S 服务，自己内部也部署了 K8S 集群。他们的容器可以随时、同时交付到腾讯云和他们本身的 K8S 集群，而不用做任何改动。通过容器交付，可以不用考虑环境依赖等问题。通过将 TKE 跟 QQ 的业务特性适配，腾讯做出了一些更能满足业务场景的 K8S 应用功能：(1)(1)跨地域跨地域 QQ 是三地分布，上云后又增加了自研和云的机房属性。原生 K8S 不支持跨地域的，因此腾讯的 TKE

173、引擎增加了跨地域的特性。(2)(2)弹性伸缩能力弹性伸缩能力 TKE 有基于 CPU 负载等基础容量的弹性伸缩能力。在 TKE 优秀的伸缩能力之上，腾讯还做了功能叠加。根据业务长期的趋势和业务突发活动，通过算法来预估容量在什么时间窗会达到多少水位，以准备相应的容器资源来提前几小时扩容，应对突发流量。(3)(3)权限限制权限限制 某些业务对权限是基于 IP 鉴权的。比如内部的业务模块访问 MySQL 时，要授权 MySQL给这些 IP 放行。容器是很难去做这种基于 IP 的权限管理，QQ 的做法是将容器固定IP，交付时注册到 CMDB 上，完成鉴权等自动化交付流程。(4)(4)开发工具开发工具

174、腾讯内部有很多 CI/CD 的优秀工具，开发团队可以在镜像仓库选到自己适合的工具，在 CI、CD、CO 都能保持自己的习惯。(5)(5)海量业务海量业务 在管理体系、安全、审计、服务监控、日志、告警等功能特性上，腾讯增加和优化了近百个特性，满足 TKE 与海量业务的结合。从腾讯自研业务上云以及一些合作伙伴的案例，可以得出上云的五大趋势：(1)全面拥抱 DevOps，研发效率更高效；(2)内部的优秀工具上云，让云能提供更好的服务；(3)彻底拥抱云原生，用云来满足业务快速迭代，资源弹性伸缩的需求；腾讯大规模云原生技术实践案例集(4)开发团队心态更加开放，主动与开源社区协同，贡献更多的功能特性；(5

175、)在 QQ 全量上云的过程中，很多问题边上云边解决。整个公有云的基础设施和服务已经被锤炼得更加成熟。五、小结五、小结 QQ 上云，好比开着火车换引擎。现在，QQ 已经把了华南、华东、华北三大区域的用户全都迁到了云上，实现完整的 QQ公有云上服务。是的，“开着火车换引擎”，我们做到了！这次自研上云的成功，一方面为腾讯云的进一步壮大打下坚实的基础，另一方面，也为 QQ 自身的技术重生埋下伏笔。QQQQ 的未来，从此刻开始改变。的未来，从此刻开始改变。腾讯大规模云原生技术实践案例集 案例七：和平精英自研上云 UDP 数据包乱序回顾 导语：导语：为了响应公司自研上云战略。IEG 已于 2019 年启动

176、业务上云策略，其中已有部分新业务在云上运营。而对于存量业务来说，都在逐步迭代灰度，我们需要从云上性能、稳定性、架构适配性等诸多方便进行验证。以下仅以和平精英自研上云测试服出现 udp 数据包的乱序，来做上云过程中问题追踪与解决的回顾！问题背景：问题背景：和平精英测试服 第 1 批 20 台 M10 DS 服务器使用自研云 D24-60 替换。在使用半个月后，即将对版本全量测试过程中，发现装备满载的时候很卡，时不时出现掉线情况。测试同学，分析反馈数据包重复发包；分析过程：分析过程：1、客户端同学通过对 nprof 文件分析【ue4 中一款网络流量包分析工具】，发现 在进入对局后，不时出现重复包

177、2、开始怀疑自研云上机器包量与流量的限制，通过查看机器的包量给予排除;腾讯大规模云原生技术实践案例集 3、通过其他业务了解到在腾讯云 VPC 上内网出现过类似问题，我们也针对机器 MTU 进行了修改测试，测试发现 UDP 重复包有所降低，但是依然存在。说明修改 MTU 作用不大；腾讯大规模云原生技术实践案例集 MTU:1500 nprof 分析 UDP 重传包 MTU:1400 nprof 分析 UDP 重传包 MTU:1000 nprof 分析 UDP 重传包 腾讯大规模云原生技术实践案例集 4、进入对局后服务器对 UDP 抓包分析，没有发现特别大的包，也否决了 MTU 的影响，服务器收发包

178、正常；5、使用 udp 收发包工具分别对 IDC&自研云 CVM&自研云 Docker 进行测试验证，发现自研云上的 docker&cvm 回包出现乱序，IDC 机器正常；测试样例如下：大概 1 帧发 20 个 512 字节的包（可以理解接近 3ms 发 1 个）并持续发 5000 个。分别在CVM&Docker&IDC 测试；A、部署 UDP 回包工具，来自 task 终端项目 B、发包测试工具（根据业务发包逻辑并判断收到顺序）腾讯大规模云原生技术实践案例集 6、继续卷入腾讯云技术支持，云网络后台等同学又继续了链路抓包分析，发现母机也并未出现乱序。有可能是 vpc 路由变化时出现的少量乱序；

179、7、又开始怀疑是公司 Tencent-WIFI 导致，周末我在家用 WIFI 继续用发包工具测试也是同样乱序；腾讯大规模云原生技术实践案例集 8、继续再抓包，怀疑是 tgw 处理有问题导致的乱序；9、决定工作日来一次交换机端口镜像再分析，腾讯大规模云原生技术实践案例集 10、最根本原因，自研云中间设备的 hash 模式是逐包 hash 导致的；腾讯大规模云原生技术实践案例集 11、现网再次确认，自研出口所有设备模式都已修正；逐流和逐包逐流和逐包 （来自 https:/ Trunk 接口负载分担，都可按逐流或逐包方式进行。逐流负载分担逐流负载分担 逐流负载分担是指按照一定的规则，如根据五元组（源

180、 IP 地址、目的 IP 地址、协议号、源端口号、目的端口号），将报文分成不同的流，同一条流的报文将在同一条链路上发送。如图 8-4，假设 R1 上有 6 个报文要通过 R1 和 R2 之间的 LinkA 和 LinkB 进行负载分担，其发送顺序为 P1、P2、P3、P4、P5、P6，其中 P2、P3 和 P5 去往 R3，P1、P4、P6 去往 R4。假设负载分担采用逐流方式，则去往 R3 的报文都通过 LinkA 发送，去往 R4 的报文都通过LinkB 发送；或者去往 R3 的报文都通过 LinkB 发送，去往 R4 的报文都通过 LinkA 发送。图图 8 8-4 4 逐流负载分担示意

181、图 对称负载分担对称负载分担 对称负载分担是一种特殊的逐流负载分担。对称负载分担是指根据报文 IP 地址区分数据流，使同一条流的数据流从相连两台设备的相同序号成员链路通过。如图 8-5，对于同一条数据流，由路由器 R1 通过 Link A 链路向路由器 R2 转发,在路由器R2 设备上通过交换源和目的得到相同的链路索引。其反向流量（由路由器 R2 转发至路由器 R1）Hash 到同一条 Link A 链路上。腾讯大规模云原生技术实践案例集 图图 8 8-5 5 对称负载分担示意图 对称负载分担能保证包的顺序，但不能保证带宽利用率。逐包负载分担逐包负载分担 逐包负载分担是指在转发时，按报文到来的

182、次序，将报文均匀地分摊到参与负载的各条链路上，如图 8-6。图图 8 8-6 6 逐包负载分担示意图 逐流和逐包的比较逐流和逐包的比较 逐包比逐流的负载均衡程度好。逐流的均衡程度取决于负载分担的规则和业务流量特征。逐包的缺点是可能导致报文乱序。在逐包场景下，以下因素的影响会导致报文乱序：链路质量差导致报文乱序。当链路质量较差时，会存在不同延时，链路丢包、错包，因此导致报文到达对端后乱序；数据包大小不均，被混合发送时，在链路传输速率一定的情况下，长度较小的数据包即使后于长度较大的数据包被送到链路上，也可能会先到达对端。因此采用逐包负载分担时，需要考虑现网业务是否容忍乱序，所在链路是否有保序的功能

183、。由于逐包方式可能导致报文乱序，对报文顺由于逐包方式可能导致报文乱序，对报文顺序非常敏感的语音、视频等关键业务不建议使序非常敏感的语音、视频等关键业务不建议使用逐包方式。用逐包方式。腾讯大规模云原生技术实践案例集 总结：总结：1、业务上云先行先试，与问题排查齐头并进 2、面对问题，要做到积极响应、寻根究底 3、面对问题，工具先行，用数据说话 腾讯大规模云原生技术实践案例集 案例案例八八：王者荣耀背后的腾讯自研数据库王者荣耀背后的腾讯自研数据库 TcaplusDBTcaplusDB 实践实践 点此阅读原文 王者荣耀是由腾讯游戏天美工作室开发的 MOBA 手游大作。作为全球用户数最多的手游，无论玩

184、家什么时候上线、玩多久，王者荣耀总是如丝般顺滑。其实，每一次响起那句经典冲锋号稳住，我们能赢的时候，对网络环境、手机性能、服务器端的能力（尤其是数据库的能力）的考验就开始了。峡谷的战场，就是数据的战场，每一次团战都是在海量的数据中增删改查。接下来，就为大家解密在这款现象级手游背后的腾讯云自研游戏数据库 TcaplusDB 数据库技术。面临的问题面临的问题 对于王者荣耀而言，数据库是灵魂，承载着所有系统的信息落地。任何一款游戏的成功都不是偶然的，王者荣耀在保证游戏的挑战性、趣味性和多样性上做了很多功夫，仅系统就有几十个，包括战斗系统、玩家系统、铭文、商城、角色、物品等，目前后台数据量已高达数百

185、TB，1 个区有 100 多个表且还在不断呈几何级增加，这对数据库性能要求非常高。每一次王者峡谷爆发的大小战役中数据读写甚至每一次请求都不能超过 10 毫秒，稍有延迟，就会影响数以亿计玩家的游戏体验。如果说要实现 PB 级数据的秒级延迟，难度相当于能在 1 分钟内完成给高速行驶的汽车换轮胎，那么实现 PB 级数据的微秒级延迟，技术难度不亚于要求在一秒内把换好轮胎的汽车开到月球。另外，对于底层架构来说，相比较于其他类型业务，游戏业务除去常规的业务高峰时间预估之外，很难做到业务爆发的时间准确判断，作为国民手游的王者荣耀也存在因各类突发事件和特殊时期带来的巨大流量，这对底层数据库自动扩缩容能力提出了

186、巨大挑战。解决之道解决之道 PBPB 级数据微秒级延迟级数据微秒级延迟 传统关系型数据库显然完全无法达到这样业务要求，因为在游戏业务中要求实时返回，在涉及逻辑时需要避免关系型查询，一旦逻辑复杂，就会导致性能低下。所以通常情况下，如果使用主流开源数据库 MySQL 等，在业务的开发设计中无法享受到作为关系数据库的完备功能，却背负了由此带来的性能包袱。如果加入纯内存数据库作缓存，又会因为 cache+存储这种形式带来极高的架构成本，不仅需要考虑不同数据库的开发逻辑也要考虑不常使用的数据落盘问题。腾讯自研数据库 TcaplusDB，专为游戏而生。作为 NoSQL 数据库产品，TcaplusDB 具备

187、高性能/低成本、高可用性、无损伸缩能力，提供表的抽象描述，同时使用 ProtoBuf作为表描述语言。但其核心存储本质上是一个具备持久化能力的内存 key value 系 腾讯大规模云原生技术实践案例集 统，在内存中进行 KV 式数据存储，通过内存池共享、冷热数据分离等技术保证海量数据的微秒级返回。要实现数据的微秒级读写，关键在于扁平式的访问模式与内存池共享技术。要实现数据的微秒级读写，关键在于扁平式的访问模式与内存池共享技术。这要求数据库架构要足够简单，王者荣耀通过 TcaplusDB 提供的异步读写接口直接连接TcaplusDB 接入层，接入层直接提供路由信息连接至数据库操作数据库数据，完全

188、不用关心数据分片和主从逻辑的细节，大大避免了业务的复杂开发逻辑。在这种访问模式下，游戏服务器操作平均响应时延小于 4ms，存储层读写时延为微秒级。TcaplusDB 架构图 内存池共享逻辑则也很简单，同其他内存数据一样，将数据缓存于内存当中，用户访问数据直接从内存中读取，无需经过磁盘，这极大提升了读写效率。而一般场景下表的大小往往会直接影响查询效率，面对海量数据，通常解决办法是分库分表。在游戏业务中，需要在设计阶段就要适当的进行分表，拿角色表举例，角色的各种数据放在一张表对于逻辑开发是最简单的，但出于表大小的限制，需要把具有增长潜力的数据字段放在新的数据表里，这就意味着角色的内存对象数据要根据

189、各个表的数据合并而成。而 TcaplusDB 面对超大单表的场景下，通过分表因子将大表平均打散存放至不同的集群分片当中，访问指定数据无需完全加载全表，仅仅加载数据所在分片即可，极大提升了查询性能。王者荣耀的 PB 级数据中，40%为不常调用的冷数据，比如历史开局信息等，为提高业务响应效率，一个行之有效的办法是降低冷数据的读写次数。TcaplusDB 采用内存+SSD 盘存储的方式，单个引擎文件前 1GB 映射在内存，冷数据放在磁盘，并采用 LRU算法进行冷热数据交换，游戏服务器的 get 操作触发 LRU 换入操作，数据库 LRU 线程负责 LRU 换出，保证热数据存储在内存里，从而实现 ca

190、che 命中率高、单次读写延时低。腾讯大规模云原生技术实践案例集 3 3 小时扩容小时扩容 400400 万万 PCUPCU，用户无感知，用户无感知 春节期间，TcaplusDB 陆续对各个大区 7 个表进行了 15 次扩容，扩容集群服务只增加了 20 组（原 330 组）,最后一次扩容是在 26 日，时间紧任务重，TcaplusDBTcaplusDB 在在 1 1 小时小时内完成了突增内完成了突增 100100 万万-200200 万万 PCUPCU 的扩容，且在扩容过程中玩家无感知的扩容，且在扩容过程中玩家无感知。这是个几乎不可能完成的任务，但是 TcaplusDB 交上了满分答卷，它是怎

191、么做到的？面对随时会出现的业务高峰和低谷，人力运维存在明显弊端，这就对系统的智能化能力提出了高要求，而高频的业务忽高忽低，导致伸和缩同时出现，会使得数据库无法处理请求，严重的还会导致数据库宕机，所以要实现系统智能根据业务情况进行自动扩缩容是非常困难的。这个问题在 TcaplusDB 面前迎刃而解。TcaplusDB 云上管控系统为每一个用户设定了 腾讯大规模云原生技术实践案例集 自动扩展能力。TcaplusDB 会根据数据表的使用量情况来计算出扩容窗口时长，当扩容窗口内无法支撑业务增长的读写能力时，系统会自动发起扩容，扩容的量级由用户单位增长速度的等级、所处实例规格以及数据库处理能力来决定。系

192、统将自动对接入层与存储层进行横向扩容，拉起各个地域中空闲的服务器，根据自动扩容逻辑进行一致性 hash 数据迁移，平均每秒数据传输速度在 300M 以上，从发起扩容到完成扩容，业务侧毫无感知。TcaplusDB 采用了分布式架构，整体分为接入层、存储层、管理层。数据存放于存储层中，数据路由信息存放于管理层中，用户连接通过接入层对数据库进行访问，每一层均可实现自由的快速伸缩容。当业务请求突增，在服务能力无法支撑前进行告警，并自动进行横向扩容。当业务请求降低后，还可根据当前使用情况进行自动缩容，以降低成本。自动快速伸缩的能力足以应对业务突增峰值的痛点。存储层扩容采用无损搬迁方式进行的业务完全无感知

193、存储层扩容采用无损搬迁方式进行的业务完全无感知 无损搬迁时，首先从数据搬迁源端的 tcapsvr slave 全量扫描数据文件，现场计算hash 值，将需要搬迁的数据打包发送到目的端 tcapsvr master；当全量的数据扫描完成后，将从全量数据搬迁开始时的增量数据也搬迁到目的端 tcapsvr master，在最后切换路由前，接入层会缓存短暂的读写请求，保证完全无损。腾讯大规模云原生技术实践案例集 接入层扩缩容是无损的业务无感知接入层扩缩容是无损的业务无感知 TcaplusDB 自研了 SDK，SDK 内维护了接入层一致性 hash 环，天然支持增加或者减少接入层节点。接入层扩容时，新的

194、接入层节点启动后，再由管控节点通知 SDK 更新本地路由 hash环，则请求可能从新的接入层节点发送和接收。接入层缩容时，接入层需要进行安全退出，先告诉 SDK 不再朝自己发送新的请求，再朝与自己相连的存储层节点发送染色包，确定所有的请求的响应都成功返回后，再等待 1 秒钟后退出，确保 SDK 不会出现超时丢包现象。结语结语 综上所述，TcaplusDB 是一款腾讯自研的高性能内存式分布式数据库系统，具有无损扩缩容、高可用、易用性等特性，针对游戏业务的开发、运营需求，支持全区全服、分区分服的业务模式，提供不停服扩缩容、自动合服等功能。同时，TcaplusDB 提供完善的高可用、容灾、备份、回档

195、功能以实现 7*24 小时五个 9 的可靠数据存储服务。历经腾讯内部 8 年的游戏经验积累，广泛应用于王者荣耀、刺激战场、穿越火线、火影忍者等数百款流行游戏的 TcaplusDB，现已通过腾讯云向全球游戏业务提供服务。腾讯大规模云原生技术实践案例集 案例案例九九：作业帮云原生成本优化实践作业帮云原生成本优化实践 点此阅读原文 项目背景项目背景 作业帮教育科技（北京）有限公司成立于 2015 年，一直致力于用科技手段助力教育普惠，运用人工智能、大数据等前沿技术，为学生提供更高效的学习解决方案。随着业务需求的发展，作业帮的 IT 系统面临巨大挑战，现有基础平台架构已经无法满足快速增长的业务需求。业

196、务对快速迭代、急速弹性、调用链追踪、业务对快速迭代、急速弹性、调用链追踪、统一的监控日志平台、提升计算资源利用率等需求迫在眉睫。统一的监控日志平台、提升计算资源利用率等需求迫在眉睫。2019 年下半年，作业帮开始规划并调研容器化解决方案。在此期间，腾讯云团队和作业帮进行了多次深入的技术交流，同时作业帮也和腾讯云的其他容器客户进行了充分交流沟通，多方面了解腾讯云原生技术和腾讯云的服务质量，最终决定将其部分重要业将其部分重要业务迁移到腾讯云容器服务务迁移到腾讯云容器服务 TKETKE。企业成本管控的常规做法是将各项计算、存储、网络资源归口到具体业务单元，然后由系统运维、SRE、业务线研发以业务单元

197、为视角综合评估成本的合理性。常见的成本优化点按照架构层次从上往下，依次是以下几个方面。应用性能有待提升应用性能有待提升 对于企业主流使用的语言，如 PHP、Golang 从框架入手。应用框架的理论性能和实际业务的性能往往有很大 gap，多为业务架构缺陷或者数据存储设计的不合理导致。同时应用框架随着功能的不断迭代和更高的要求，自身性能上也需要优化。对于一些占用资源比例较重，如对于一些占用资源比例较重，如超过 10%的应用服务也是值得深入投入，其性能的提升能带来更明显的回报。应用部署模式差，带来计算资源的浪费 单应用服务机器负载率低单应用服务机器负载率低 对于高并发业务，虚机下机器峰值负载常规在

198、10%-20%，极限可提升到 30%-40%。高流量业务一般代表着公司核心业务，一方面一方面为了稳定性的考虑，整体水位不能控制的过低。另一方面另一方面，为了应对一些突增流量，要预留一定 buffer。低负载业务一般碎片化比较严重，而这些服务比较长尾，进而拉低了整体负载。时间不均时间不均 互联网业务普通有明显的波峰波谷，波峰和波谷的实际资源使用量至少有一个数量级差距，且真正的最高峰只有不到一个小时。企业不得不为这一个小时的用量而付出一天的成本。空间不均衡空间不均衡 一方面是在线集群波谷空闲了大量计算资源，另一方面是大数据离线计算需要大量计算资源。从整个公司视角来看，资源使用极不均衡。资源性能有待

199、提升资源性能有待提升 英特尔、英伟达每年都会有更强性能、更好性价比的硬件推出，云厂商也会有对 腾讯大规模云原生技术实践案例集 应产品的发布。但是企业中业务线众多，一个个去适配、验证新机型，导致更换的周期往往要 1-2 年起。无法充分享受硬件带来的成本优化红利。解决方案解决方案 云原生给企业带来一次技术重塑的机会。容器技术实现了资源和应用的解耦。业务研发和 SRE 关注 Pod 即可。底层计算资源由系统运维统一管理，对上层透明。Kubernetes 研发优化应用调度策略，实现计算利用率的最大化。大幅提升应用性能大幅提升应用性能 对公司主流的技术栈，深度优化所对应的框架。通过使用更高内核的运行态、

200、使用 Kubernetes 原生的注册发现机制、保持各类网络连接等等，实现 PHP 应用 43%的性能提升。通过使用 fluid，完成检索服务计算和存储的分离，极大提升了运维效率。过程中对内存基带的使用进行了优化，带来 30%性能提升，节省万核级别计算资源。调度优化，整体提升计算利用率调度优化，整体提升计算利用率 容器服务使用统一的集群，常态在 40%左右，在保障业务稳定的情况下极限可达 60%。机器利用率大幅度提升。碎片化问题也得到彻底解决。但中间过程是曲折的，和腾讯云一起攻克了一系列业界难题。在 2020 年上半年我们完成了一块核心业务的容器化之后，突然发现我们的运维成本居然增加了。原来在

201、虚机模式下，运维在晚高峰的时候，只需要去做一些稳定性的巡检，其实并不需要有过多的一些运维动作。但容器化后，我们在晚高峰下需要不断地对一些资源负载比较高的的去进行封锁，然后把上面的一些比较重的 Pod 进行驱逐，为什么会这样呢？就是我们分析了一下 Kubernetes 的原生调度器，还是以 request 进行调度。互联网业务都会一个明显的波峰波谷，在线教育的波峰波谷会更加剧烈，波峰波谷可能会有两个数量级的一个差异。当研发在波谷的时候进行一次发布，这时候就会触发容器的一次重新调度，比如像我这个服务有几十个 Pod 的，可能会有十多个 pod 调度到一台机器，因为这时候的机器的使用率很低，就是服务

202、怎么调度其实都可以，但是到了晚高峰的时候，我的每一个 pod 资源的使用率就上来的，CPU 使用高了，它的吞吐也高了，然后我这十个都在同一个机器上，我这台机器就会出现一些资源的瓶颈。可以看出原生的调度器只考虑了一些简单的指标，同时也没有考虑未来的一个变化。所以我们做了一个定义的调度器，将就是晚高峰的一些提前的情况进行了一些预测，以及融合了 CPU、内存、各种 io 的这些复杂指标都考虑进来做因子，同时就是我们也会定期的把历史的数据进行大数据回归更新策略。GPU 这块它是一个比较相对贵的资源，我们调研了一些方案，主要推荐的方案是 GPU 虚拟化，但至少带来 15%的性能损耗，这个是我们没法接受的

203、。我们大多数的 GPU 服务是使用的各种资源是相对比较固定，所以我们基于算力和显存去进行了一些策略的调度，其实也就是比较经典的背包问题，同时夜间的话我们也会进行一下预测再重新调度，如果中间出现一些卡的一些故障，我们也会执行转移相关的策略。当 web 业务的完成容器化改造之后，我们也把一些定时任务迁移到容器的平台。这时候新的问题又来了，很多任务会涉及到密集的计算，容器本身其实并不是一个隔离的机制，还是 腾讯大规模云原生技术实践案例集 在做 CPU 时间片的一个分配。这些计算密集的任务多多少少还是会对 web 的任务造成一定的影响。同时它也会占用主机的 IP 资源，node 上的 IP 资源是有限

204、的，定时任务调度上来之后就会分配 IP，任务销毁时 IP 资源也不会立刻销毁，如果频繁的把定时任务的 pod 的调度到主机群的节点上，就会导致主机群的 web 服务没有足够的 IP 资源。同时大规模的创建跟回收定时任务，也会触发一些内核的问题，就比如有些定时任务的内存使用比较大，大规模回收会导致陷入内核态，hang 住的时间比较长。这块我们做的一些改造是这样的，我们建立了三个池子，serverless、任务集群、主机群，我们优先会把定时任务去调度到 serverless 上，如果调入失败的话，再依次到任务集群、主集群，serverless 并不是一种完全可靠的计算模式，对于他的使用我们这里引入

205、了一种资源预占的方式，比较类似于金融领域为保证事务的两阶段提交，我们预先去申请相关的资源，当完成预占之后，我们再把真正的把任务调度过去。在离线混部是工程界一个比较经典的课题。在线资源是有明显的波峰波谷，波谷有大量的剩余计算资源。大数据离线使用了大量的一些资源，但多数的任务对计算的实时性并没有那么强的要求，说必须在几分钟内得到结果，几个小时跑出来也可以。如果我在在线集群波谷时来跑大数据离线计算，大数据离线的资源就可以节省出来，这样就可以达到一个双赢的效果。但是它会面临很多挑战，就是其实很难做到资源的完整隔离，在线资源的稳定性、延时都会受到影响。负责在线业务的同学也会有顾虑，就是我没有得到很大的一

206、个收益，然后还影响了我的业务。在内核增加了新的一个调度器，在 cfs 和 idle 之间，把大数据的任务放到这种放到这类调度器上，然后就实现了 CPU 的避让。在放量的过程中，我们也整体控制节奏，我们先在夜间在线服务没什么量的时候来跑离线计算，然后跑相对比较稳定之后，我们再在白天的波谷时间来跑大数据离线。又经过一段时间稳定之后，我们现在其实在晚高峰的时候，也在跑离线任务，只不过是控制在 10%的 CPU 使用以内。使用新硬件，大幅提升单位计算的性价比使用新硬件，大幅提升单位计算的性价比 容器环境下集群底层计算资源使用有限数量的机型，做一些机型更换时减少了业务研发适配的成本，更换效率大幅度提升。

207、实践价值实践价值 在多重举措的合力推动下，作业帮容器化的收益显著，同样业务迁移前后，使用了 HPA 和在离线混合部署后，成本下降成本下降 43%43%，稳定性提升到，稳定性提升到 99.995%99.995%，接口响应，接口响应提升提升 10%10%。由此，有效支持了作业帮业务业务的快速迭代，秒级急速扩缩容，服务运的快速迭代，秒级急速扩缩容，服务运行态规范落地和统一的运维环境，多云的环境统一，提升服务可用性行态规范落地和统一的运维环境，多云的环境统一，提升服务可用性。这也便于云间相互自由迁徙，实现单云故障的应急预案，通过优化资源碎片，在离线混合部署，自动扩缩容，整体成本进一步下降。腾讯大规模云

208、原生技术实践案例集 案例十：案例十：作业帮云原生降本增效实践之路作业帮云原生降本增效实践之路 点此阅读原文 为什么要进行降本增效为什么要进行降本增效 作业帮的技术现状可以归纳为两点，分别是规模化和复杂化。规模化：规模化：数千个应用服务，对应数万个服务实例，运行在数十万计算核心之上；复杂化：复杂化：技术栈极为丰富，涵盖多种主流语言。作业帮于 2020 年初开始走一条云原生的道路，来解决发展过程中所遇到的稳定性、成本、效率及安全方面的问题。通过云原生的改造，用基础设施接管业务当中大量的非功能逻辑，以此实现弹性、可观测性、韧性、自动化及可持续性。为什么要进行降本增效？为什么要进行降本增效？随着互联网

209、红利的消退，企业希望能够实现成本效益最大化；资源浪费现象普遍存在，节省不必要的浪费；从技术人员的角度来看，期望写出更优质、更高性能的代码。在降本增效的过程中，我们需要明确一点：降本但不能降质，在降低成本的同时，稳定性、效率、安全等均不能为此打折扣。降本增效的关键点降本增效的关键点 在多种限制条件存在的情况下，该如何开展降本增效的工作呢？应用层应用层首先要做的是提升性能，即提升单位资源能够支撑的业务并发量。对于作业帮来说，多元的技术栈给应用层的效能提升带来了挑战。资源层资源层降本增效的重点在于计算层面的优化，存在两大挑战：腾讯大规模云原生技术实践案例集 寻找更优机型，提升单位成本的算力；拥有合适

210、的机型后，实现业务平滑无感地切换。资源调度层资源调度层有着巨大的优化空间，同样也面临诸多挑战：在线资源负载不高，对于高并发业务，为了应对频繁的流量突增，需保证一定的Buffer，同时低流量业务通常长尾，进一步拉低了在线资源的利用率；资源空间不足，在线资源利用率一般在 30%，而大数据通常 100%负载；资源时间不均，互联网业务资源的使用存在明显的波峰、波谷。应用层降本增效应用层降本增效 应用技术栈改造应用技术栈改造 起初，作业帮采用 PHP 为服务端的主要开发语言，并使用 ODP 框架，能够有效地支撑新业务的快速构建及发展迭代。但随着业务的发展，以 ODP 为代表的 PHP 服务端技术栈遇到了

211、诸多问题：性能瓶颈，PHP 缺乏线程与协程的支持，在单位的并发下，资源使用率、业务成本高；欠缺微服务支撑，ODP 框架下，服务之间可以使用 RPC 进行调用，也支持混部后进行本地调用，服务之间边界模糊、权责不清等问题开始显现；云原生适配不足，云原生带来诸多技术红利，如容器化、服务治理、DevOps 等，但 PHP 适配性较低，无法与其结合。于是我们选择使用 Go 语言代替 PHP 作为服务端的主要开发语言。Go 语言框架 ZGIN 基于GIN 衍生而来，是面向 Web 服务的开发框架，提供了开箱即用的常见组件和功能，侧重通用性和稳定性，兼顾性能和时延。腾讯大规模云原生技术实践案例集 应用技术栈

212、应用技术栈整体设计整体设计 GIN 是一个通用性应用框架，我们在 GIN 的基础上做了性能优化，用来适配底层基础架构技术方案，同时带来业务场景下的性能提升。与 GIN 相比，HttpServer 中一直以性能著称的 fasthttp 具有一个显著的优势：复用连接池。但我们并未在 GIN 的二次开发中实现连接池，而是将能力下移，借助底层架构的能力使多语言栈保持同等能力。大多数服务模块目前已经接入 Service Mesh，上游请求与Mesh-Proxy 建立连接，Mesh-Proxy 和服务模块之间通过 UDS 通信且保持长链接，同时优化UDS 的零拷贝问题。效率工具方面效率工具方面，提供简单易

213、用的代码生成工具，根据脚手架快速地生成服务代码。通过代码生成工具，规范业务对框架的使用，减少业务后期追查及维护问题的成本。测试环境互通工具方面测试环境互通工具方面，提供简单的命令工具，将远端测试环境的流量代理到本地端口，也可以将本地模块的出流量转发到测试环境之上。应用技术栈应用技术栈成果成果 腾讯大规模云原生技术实践案例集 经过两年的发展，Go 语言已演变成为作业帮使用最多的服务端语言，当前基于 Go 语言构建的模块总计已达 600+，性能提升十分明显。如上图所示，使用 Go 语言重构应用模块后能够带来五倍以上的性能提升。核心系统云原生改造核心系统云原生改造 检索系统作为公司最底层的核心系统之

214、一，是 C 语言栈下的倒排索引和综合策略索引，为智能推荐、资料智能分析以及搜索等提供底层支持。机器规模千台级别，计算核心达千万核以上，时效数据达百 TB，数据日增量为 TB 级别。检索系统检索系统架构架构 检索系统底层设施主要包括两部分：数据产出服务与数据存储服务。由于检索系统对低时延、高稳定性以及高吞吐性能的要求，早期选择使用本地存储，带来了计算与存储的耦合问题。随着数据量的增大，单机无法承载所有数据量，需要对数据进行切片，每个节点存储部分数据。出于高并发、高可用的要求，每个切片还需有多个副本。当数据需要更新时，由于数据量庞大，数据产出服务无法一次将全量的数据存至线上的节点中，只能选择部分数

215、据进行同步，随后以该部分节点为基准进行二次、三次分发。这就这就导致数据更新时间长、运维成本高、占用资源多等问题。导致数据更新时间长、运维成本高、占用资源多等问题。通过对检索系统架构的分析，可以看出，当前的关键问题都是由于计算存储耦合所导致。只有引入计算存储分离的架构，才能从根本上解决复杂度的问题。而新的解决方案应该具备以下能力：腾讯大规模云原生技术实践案例集 存储读取的稳定性应和本地持平；存储读取的性能；存储读取的易用性，最好支持 POSIX 接口；数据迭代流程的可控性；数据集合的可伸缩性。基于上述要求，在技术选型方面，我们选择了 Fluid 与 JindoRuntime 的组合。Fluid

216、是开源的 Kubernetes 原生的分布式数据集编排和加速引擎，它通过数据的编排、应用数据的调度，解决云原生过程中所遇到的一些列数据问题，如访问数据的时延过高、多数据联合查询困难等。JindoRuntime 是 Fluid 的一种分布式缓存 Runtime 实现，实现了 HDFS、S3 协议的访问与缓存加速。检索系统检索系统云原生架构云原生架构 通过云原生改造，检索系统变成了一个标准的无状态容器应用，数据应用的过程得到简化。数据产出服务将数据传到对象存储中，Fluid 驱动 JindoRuntime 完成对数据的加载。检索的进程通过 Fluid 挂载的 PVC 访问 fuse，fuse 将

217、POSIX 协议转化为对远端 JindoRuntime的 RPC 访问。完成架构改造后，对检索系统的瓶颈进行分析，发现导致性能无法提升的原因在于跨发现导致性能无法提升的原因在于跨 NUMANUMA的内存访问带宽存在上限。的内存访问带宽存在上限。通过添加调度器，使进程绑定 NUMA，保证 CPU 和内存的访问不跨 NUMA，能够使该问题得到妥善解决。腾讯大规模云原生技术实践案例集 资源调度层降本增效资源调度层降本增效 资源调度层降本增效的核心在于解决上文所提到的在线集群负载不高、资源空间及时间分布不均等一系列问题。自定义调度器自定义调度器 容器化改造使得机器的平均负载得到显著提升，但不同的机器之

218、间差异较大，部分机器在业务高峰阶段还需进行额外的运维工作，如人工封锁高负载机器、人工驱逐不均衡 Pod等。为什么会出现这样的问题呢？为什么会出现这样的问题呢？主要原因在于 Kubernetes 原生调度器的调度依据以 request 为主，只考虑简单的指标，没有考虑未来的变化。于是我们通过自定义调度器来解决此问题：底层数据依赖 Prometheus 采集资源的真实使用情况；结合历史信息进行预测；除了将 CPU 和内存作为指标考虑外，添加更多因子多维考虑。在离线混部在离线混部 互联网业务都有明显的波峰、波谷，波谷时段有大量的剩余资源处在空闲状态，考虑到大数据离线计算需要大量计算资源并对实时性的要

219、求较弱，我们可以在在线集群的波谷时期运行大数据离线任务，达到节省计算资源的目的，实现双赢。但在实际实施中，存在资源隔离无法避免干扰、隔离效果差等问题。腾讯大规模云原生技术实践案例集 对此，我们使用腾讯 TLinux 的新特性，在内核的 CFS 之间，添加一个新的调度器Offline，实现 CPU 避让，并对空闲资源做预测调度。ServelessServeless 广泛使用广泛使用 Serverless 一直是作业帮技术架构探索的核心方向之一，用于解决资源分布时间不均的问题。Serverless 的主要运行方案有两种，一种是函数计算，另一种是 K8s 虚拟节点。K8s虚拟节点具有对现有服务无使用

220、差异、用户体验较好、业务服务无感知的特点，可以基于现有基础架构进行迁移。ServerlessServerless 技术挑战技术挑战调度调度 Serverless 具有较强的成本优势，将在线服务高峰期弹性调度到 Serverless 上，可以大量节省资源成本。在推进 Serveless 的过程中存在诸多挑战，在调度层需要解决两个主要问题：扩容时创建的 Pod 基于何种策略调度到虚拟节点；缩容时应如何实现优先缩虚拟节点上的 Pod。有三种方案可以解决上述两个问题。有三种方案可以解决上述两个问题。有三种方案可以解决上述两个问题。方案一：原生标签能力。方案一：原生标签能力。通过 Node Select

221、or、节点亲和等利用虚拟节点资源，但这种方式是割裂的，同一个服务无法运行在两种类型的节点上。方案二：云厂商调度扩展。方案二：云厂商调度扩展。用户无需指定 Selector，当固定节点的资源不足时再调度到虚拟节点之上。但在集群资源已满的情况下，才进行虚拟节点调度会导致 Pod 部署过于密集，节点负载过高，影响业务稳定性。方案三：自研调度器。方案三：自研调度器。将超过阈值的 Pod 调度到虚拟节点之上，其中阈值基于预测推荐+人工调整而定。这种方式可以有效兼顾稳定性和成本。腾讯大规模云原生技术实践案例集 ServerlessServerless 技术挑战技术挑战观测观测 日志采集方面，采用 CRD

222、配置日志采集，将日志发送到统一的 Kafka，通过资源的日志消费服务，消费云厂商的自有节点日志，实现虚拟节点和正常节点上的日志统一。监控方面，云厂商虚拟节点实现的 Metrics 接口和 Kubelet 完全兼容，可以无缝接入 Prometheus，完成对 Pod 实时 CPU、内存、磁盘及网络流量等的监控。在分布式追踪方面，由于无法部署 Daemonset 形式的 jeager-agent，我们在 jeager-client 端做了改造，通过环境变量识别 Pod 的运行环境，如果是在虚拟节点上运行，则跳过 jeager-agent，直接将分布式追踪的数据推送到 jeager-collecto

223、r。总结总结 作业帮基于云原生进行了一系列改造，最终实现了降本增效，整体的降本服务度已达到40%，未来会继续探索更具性价比的降本增效方式。此外，作业帮运营工作当前已实现从靠人到靠平台的过渡，将进一步向 BI 化、AI 化演进。腾讯大规模云原生技术实践案例集 案例案例十十一一：斗鱼直播云原生实践之注册中心篇斗鱼直播云原生实践之注册中心篇 点此阅读原文 业务背景和痛点业务背景和痛点 斗鱼直播作为业界领先的游戏直播平台，每天为数以亿计的互联网用户提供优质的游戏直播观看、互动和娱乐等服务。随着近年直播市场的火热，斗鱼直播平台作为业内口碑和体验俱佳的互联网公司，用户量也出现井喷式增长。海量用户给平台带来

224、的稳定性技术挑战也越发强烈，斗鱼的老架构如下图所示，无论是业务支撑还是架构设计，均存在一定的风险和隐患。斗鱼老架构斗鱼老架构 斗鱼老架构 为了给用户带来更好的可用性体验，斗鱼急需解决单一数据中心的问题，将老架构从 腾讯大规模云原生技术实践案例集 单数据中心升级到多数据中心。多数据中心挑战在实现单活升级为多活的过程中，为了确保无故障的迁移升级，我们面临一系列挑战，比如：有状态服务 etcd、zookeeper 等如何多数据中心同步？应用彼此之间存在 1 个复杂的树状或网状依赖关系，应该从哪里开始迁移？按什么维度来划分目标的边界，怎么避免业务焊死在一起，造成无从下手的局面？如果迁移后出现问题，如何

225、快速恢复，并且不牵连已迁移成功的业务？因单活升级到多活的过程中，涉及系统众多，本文将是斗鱼直播多活改造系列的第一篇，只聚焦于注册中心模块，因此我们先和你介绍下注册中心背后的 etcd 和 zookeeper。zk/etcd zk/etcd 承担的角色承担的角色 dubbo 通过注册中心来解决大规模集群下的服务注册与发现问题，以下是注册中心架构图：dubbo 默认支持 zookeeper 注册中心，虽然新版也有 etcd 实现，但该实现尚缺乏大规模投产的先例，Java 技术栈采用 etcd 作为注册中心的案例也比较罕见。当采用 zookeeper 作为 dubbo 注册中心时，其注册关系为树形结

226、构，详细结构如下图所示：腾讯大规模云原生技术实践案例集 因为 zookeeper 是基于类似文件系统的树形结构来存储数据，但 etcd 却是采用键值对存储，二者之间的差异会给注册关系同步带来较大困难。此外，如果从 zookeeper 迁移到 etcd，则在整个迁移过程中：已有的线上服务不能受损，更不能停服；如果迁移失败，还要能回退到到 zookeeper。同城双活与多活新架构 为了实现多活，我们通过跨数据中心的同步服务、服务依赖梳理与边界划分、可控变更等技术手段和运维理念，成功解决了以上挑战，设计了如下一套新的架构来实现多活，如下图所示：斗鱼多活新架构 在新的架构下，可以按域名甚至是 URL

227、来细粒度的调度流量，RPC 层面也具备了自动就近调用的能力，其中注册中心的局部架构图如下：斗鱼注册中心老架构 腾讯大规模云原生技术实践案例集 注册中心多活方案选型与目标在注册中心多活改造过程中，我们面临多个方案，如下表所示：腾讯大规模云原生技术实践案例集 由于历史原因，我们有 zookeeper（以下简称 zk）和 etcd 这 2 套注册中心，加上我们有 Java、Go、C+、PHP 这 4 个技术栈，因此在注册中心领域仍然一些不足，希望能统一到 etcd 来解决痛点问题，并达到以下目标：降低维护成本降低维护成本：此前需要运维 zk+etcd 两套注册中心，更困难的是做多活解决方案时也需要适

228、配 zk+etcd，这导致注册中心多活研发成本翻倍。由于 etcd 是 k8s 的一部分，运维 etcd 又不可避免，这是选择 etcd 的第 1 个原因。拥抱更繁荣的生态拥抱更繁荣的生态：etcd 有云原生托管解决方案，有厂商通过 etcd 管理 10K node 级别的 k8s 集群，etcd 还自带 proxy、cache、mirror 等各种周边工具，java 侧 dubbo 也支持以 etcd 作为注册中心，etcd 相对于 zk 来说发展前景更好，这是选择 etcd 的第 2 个原因。增强跨语言能力增强跨语言能力：etcd 可基于 http 或 grpc 协议通讯，并且支持长轮询，

229、具有较强的跨语言能力。而 zk 需要引入专用客户端，除 java 客户端之外，其它语言客户端尚不成熟。而我们有 JAVA、Go、C+、PHP 等 4 种研发语言，这是选择 etcd 的第 3 个原因。基于以上原因，我们选择了方案四，方案四大新架构如下图所示:腾讯大规模云原生技术实践案例集 斗鱼注册中心新架构 注册中心多活难点与挑战 为了实现新注册中心，达到我们期望的设计目标，注册中心在改造过程中，面临以下难点与挑战:如何解决 zk 的多数据中心同步问题？尤其是 zookeeper watch 机制是不可靠的，可能出现丢失 watch 事件的问题？（正确性）如何解决 etcd 的多数据中心同步问

230、题？从下面方案选型中，我们可以看到社区目前并无任何成熟、生产环境可用的解决方案。（正确性）如何解决跨数据中心读的性能问题？（性能）如何解决跨数据中心的服务稳定性问题？网络链路上，比如内网专线若中断了怎么办？同步服务设计上，是否会导致 etcd/zk 同步服务进入性能极慢的全同步逻辑，同步服务本身是否具备高可用等等？容灾测试上，我们又该如何设计测试用例验证？运维上，我们又该如何快速发现隐患、消除潜在的故障，建设可视化、灵活的多活运维系统？（稳定性、可运维性）注册中心多活难点分析注册中心多活难点分析 迁移过程中如何保证新旧服务互通？开发 zk2etcd 我们很多 java 开发的业务使用 dubb

231、o 框架做服务治理，注册中心是 zookeeper，我们希望 java 和 go 开发的业务全部都统一使用 etcd 作为注册中心，也为跨语言调用的可能性做好铺垫。腾讯大规模云原生技术实践案例集 由于业务众多，改造和迁移的周期会很长，预计持续 12 年，在此过程中我们需要将 zookeeper 中的注册数据同步到 etcd 中，实时同步，而且要保证数据一致性以及高可用，当前市面上没有找到满足我们需求的工具，于是我们和腾讯云 TKE 团队合作开发了一个 zk2etcd 来同步实现 zookeeper 数据到 etcd，并且已将其开源，整体方案落地篇我们将详细介绍。如何实现 etcd 异地容灾?通

232、过 zk2etcd 同步服务，我们成功解决了 zookeeper 数据迁移问题，使得新老业务的注册中心数据都使用 etcd 来存储。因此，etcd 的重要性不言而喻，它的可用性决定着我们的整体可用性，而斗鱼直播目前的部署架构又严重依赖某核心机房，一旦核心机房出现故障，将导致整体不可用。因此斗鱼直播下一个痛点就是提升 etcd 的可用性，期望实现 etcd 跨城容灾、异地容灾能力。斗鱼直播理想中的 etcd 跨城同步服务应该具备如下特性:etcd 跨城容灾部署后，读写性能不显著下降，能满足业务场景基本诉求。同步组件达到生产环境可用级别，具备完备的一致性检测、日志、metrics 监控等。对数据一

233、致性要求不强的业务可就近访问同地区的 etcd 集群服务、强一致诉求业务可访问主 etcd 集群。主集群故障后，业务运维能根据一致性监控等，快速将备集群提升为主集群。那么有哪些方案呢？各个方案又有哪些优缺点呢？最终评估了如下几种方案:单集群多地部署方案 etcd 社区 make-mirror 方案 etcd 社区 learner 方案 腾讯云 etcd-syncer 方案 单集群多地部署方案单集群多地部署方案图如下：在此方案中，etcd Leader 节点通过 Raft 协议将数据复制到各个地域的 Follower 节点。此方案它的优点如下：各地域网络互通后，部署简单，无需运维额外组件 腾讯大

234、规模云原生技术实践案例集 数据跨城强一致同步，3 节点部署场景中，可容忍任一城市故障，并且不丢失任何数据 介绍完它的优点后，我们再看看它的缺点，如下所示：在 3 节点部署的场景下，任意写请求至少需要两个节点应答确认，而不同节点部署在各地，ping 延时会从几毫秒上升到 30ms 左右（深圳-上海)，因此会导致写性能急剧下降。etcd 默认的读请求是线性读，当 Follower 节点收到 Client 发起的读请求后，它也需要向 Leader 节点获取相关信息，确认本地数据追赶上 Leader 后才能返回数据给 client，避免读取到旧数据等，在这过程中也会导致 etcd 读延时上升、吞吐量下

235、降。跨城部署网络之间质量也较容易波动，导致服务质量抖动等。client 访问 etcd 集群的配置，为了防止单点故障，必须配置多个 etcd 节点，而这又可能导致 client 访问到异地的 etcd 节点，导致服务请求延时增大等。etcd 社区 make-mirror 方案介绍完单集群多地部署方案后，我们再看看 etcd 社区提供的 make-mirror 方案，它的原理图如下：在此方案中，我们分别在不同城市部署了一套独立的 etcd 集群，通过 etcd 社区提供的 make-mirror 工具实现跨城数据复制。make-mirror 工具原理如下：指定数据同步的前缀后，通过 etcd R

236、ange 读接口从主集群遍历此前缀下的所有数据，写入到目的 etcd。（全量同步）随后通过 etcd Watch 接口指定读请求返回的“版本号”，监听从此版本号后的所有变更事件。make-mirror 收到主 etcd 集群推送的 key-value 变化事件后，通过 txn 腾讯大规模云原生技术实践案例集 事务接口将数据写入到热备集群。（增量同步）此方案它的优点如下：主 etcd 集群读写性能高，整体上不受跨地域网络延时、网络质量波动影响 若业务可容忍短暂不一致，可就近访问距离最近的 etcd 集群 若业务要求强一致，可通过内网专线访问主 etcd 集群 不依赖高版本 etcd 介绍完它的优

237、点后，我们再看看它的缺点，如下所示：当写请求较大的时候，备集群可能存在一定的数据落后，可能读到脏数据。社区自带的 make-mirror 同步链路中断后，退出重启会再次进入全量同步模式，性能较差，无法满足生产环境诉求。社区自带的 make-mirror 工具缺少 leader 选举、数据一致性检测、日志、metrics 等一系列特性，不具备生产环境可用性。不支持同步非 key-value 数据，如 auth 鉴权相关数据、lease 数据等。etcd 社区 learner 方案介绍完 etcd 社区的 make-mirror 方案后，我们再看看 etcd 社区提供的 learner 方案，它的

238、原理图如下：它的核心原理如下：etcd raft 算法库在 2017 年的时候就已经支持了 learner 节点，详情可参考 pr 8751。etcd 社区在 2019.8 月推出的 3.4 版本中，正式支持 Learner 节点，它作为非投票(Non-Voting)的成员节点加入集群，不参与集群选举等投票，只进行数据复制。Leader 收到写请求后，将日志同步给 Follower 和 Learner 节点，并在内存中使用一个名为 Progress 的数据结构，维护 Follower 和 Learner 节点的日志同步进展信息。当 Learner 节点的数据与 Leader 数据差距较小的时候

239、，它就可以被提升为可投票的成员节点加入集群。此方案它的优点如下：腾讯大规模云原生技术实践案例集 各地域网络互通后，部署简单，只需往 etcd 集群中添加一个 Learner 节点，无需运维额外组件 Learner 节点可同步任意类型数据，如 key-value、auth 鉴权数据、lease 数据 介绍完它的优点后，我们再看看它的缺点，如下所示：Learner 节点只允许串行读，也就是业务如果就近读，会读到旧数据。依赖高版本 etcd，etcd 3.4 及以上版本才支持 Learner 特性，并且只允许一个 Learner 节点.主集群全面故障后，无法快速将 Learner 节点提升为可写的独

240、立 etcd 集群。介绍完已有的几种方案后，我们发现它们都无法满足业务生产环境诉求，于是我们自研完成了生产环境可用的 etcd 同步服务落地，在整体方案落地章节将详细介绍。如何确保 etcd 和 zk 同步服务的稳定性、可运维性?为了确保 etcd、zk 同步服务的稳定性，模拟 5 类常见的故障，检验服务在这些典型故障场景下的自愈能力，详细测试方案如下。1.故障场景 redis redis 闪断（闪断（zk2etcd zk2etcd 服务依赖）服务依赖），例如：redis 版本升级、非平滑扩容。2.zk2etcdzk2etcd 离 线离 线，例 如：OOM、容 器 驱 逐、宿 主 机 故 障。

241、3.etcd2etcd etcd2etcd 离线离线，例如：OOM、容器驱逐、宿主机故障 4.网络闪断网络闪断，例如：OOM、容器驱逐、宿主机故障。5.弱网环境弱网环境，例如：专线断掉后临时用公网顶替。上述 5 种场景的实际触发原因有多种多样，只需要模拟出一种情况。1.演练方案 redis redis 闪断闪断：通过改 host 模拟 redis 不可达，此时自动订正停止；模拟 redis 恢复后，自动订正亦自动恢复。2.zk2etcdzk2etcd 离线离线：通过杀容器节点模拟 zk2etcd 挂掉，15 秒内 k8s 自动拉起，拉起完成后同步正常、数据一致。3.etcd2etcdetcd2

242、etcd 离线：通过杀容器节点模拟 zk2etcd 挂掉，15 秒内 k8s 自动拉起，拉起完成后同步正常、数据一致。4.网络闪断：网络闪断：通过改 host 模拟 zk、etcd 不可达，此时同步中断，后去掉 host 模拟网络恢复，恢复后同步正常、数据一致。5.弱网环境：弱网环境：通过切公网模拟弱网环境，切公网后同步效率降低在 4 倍以内，1 次全量同步仍然可在 1 分钟内完成。另外针对可运维性问题，无论是 etcd 还是 zk 同步服务，都提供了详细的 metrics、日志，我们针对各个核心场景、异常场景都配置了可视化的观测视图，并配置了告警策略。腾讯大规模云原生技术实践案例集 整体方案

243、落地整体方案落地 整体架构 etcd 集群多活架构图如下所示:说明 黑实线：正常情况下的专线访问 黑虚线：切公网方式访问 红实线：etcd 集群发生主备切换后的专线访问 红虚线：etcd 集群发生主备切换后的公网访问 腾讯大规模云原生技术实践案例集 etcd2etcd/zk2etcd 数据同步服务图如下所示:zk 同步服务工程化实践 zookeeper 与 etcd 存储结构不一致，加大了同步的实现难度。zookeeper 存储是树状结构，而 etcd v3 是扁平结构。zookeeper 无法像 etcd 腾讯大规模云原生技术实践案例集 一样按照 prefix 来 list 所有 key；e

244、tcd 无法像 zookeeper 一样通过 list chilren 来查询某个目录下的子节点，也加大了实现同步的难度。如何感知 zookeeper 中的数据变化？zookeeper 的 watch 不像 etcd 一样可以简单 的 感 知 到 任 意 key 的 新 增，需 要 递 归 的 watch 所 有 的 节 点，收 到 ChildrenChanged 事件后拿到该事件对应节点下的所有子节点，再与 etcd 中的数据进行比对，就可以得到新增的数据，并将其同步 put 到 etcd 中。类似的，可以用递归的方法 watch 所有节点的删除事件，并同步删除 etcd 中的数据。另外 z

245、ookeeper 的 watch 有着先天性的缺陷，watch 是一次性的，所以每次收到事件后又必须重新 watch，两次 watch 之间理论上是可能丢事件的，主要是在同一个 key 连续多次变更的时候可能会发生。如果丢事件发生就会破坏了数据一致性，我们引入了自动 diff 和订正的能力，即计算 zookeeper 和 etcd 中数据存在的差异，每次都会经过两轮 diff 计算，因为在频繁变更数据的情况下，一轮 diff 计算往往存在一些因不是强一致性同步导致的伪差异，当 diff 计算出了结果就会自动 fix 掉这些差异。如何解决与 etcd2etcd 共存？当同一个路径下，即有 etc

246、d2etcd 同步写入的数据，又有 zk2etcd 写入的数据，在 zk2etcd 的自动订正逻辑里面，会计算出差异并订正差异，但我们不希望因此而误删 etcd2etcd 写入的数据。我们通过为 zk2etcd 引入了 redis 来存储状态解决了这个问题，在 zk2etcd 往 etcd 中同步写入或删除数据时，也同步在 redis 中记录和删除:然后 zk2etcd 在自动订正计算差异的时候，只考虑本工具写入过的数据，避免误删其它同步工具写入的数据。腾讯大规模云原生技术实践案例集 etcd2etcd 工程化实践 为了解决 etcd 同步难题，我们调研了如下两种方案，接下来我们就详细介绍下它

247、的原理：etcd-syncer 之 mirror-plus 版首先我们介绍下 etcd-syncer 的 mirror-plus 方案，顾名思义，它是 etcd 社区 make-mirror 的加强版。为了解决 make-mirror 的各种缺陷，它实现了以下特性、优点:支持多种同步模式，全量同步、断点续传，不再担忧专线、公网网络质量抖动 高可用，负责同一数据路径复制的实例支持多副本部署,一副本故障后，其他副本将在 5 秒后获得锁，在之前实例同步的进度基础上，进行快速恢复 支持一致性检查（全量数据检查、快照检查)支持多实例并发复制提升性能（不同实例负责不同的路径），建议生产环境配置多实例，每个

248、实例负责不同路径 良好的运维能力，基于 k8s deployment 一键部署，丰富的 metrics、日志，完备的 e2e 测试用例覆盖核心场景（http/https 场景，服务异常中断、网络异常等）那么它的缺点是什么呢？因为它核心原理依然是依赖 etcd 的 mvcc+watch 特性，因此数据无法保证强一致性和只同步 key-value 数据。断点续传依赖 mvcc 历史版本保留时间，最好业务能保存至少 1 个小时的历史数据。当写请求较大的时候，备集群可能存在一定的数据落后，可能读到脏数据。不支持同步非 key-value 数据，如 auth 鉴权相关数据、lease 数据等。etcd-

249、syncer 之 Raft 版为了解决所有类型的数据同步问题以及消除对 etcd mvcc 历史数据的依赖，腾讯云还可提供基于 Raft 日志的同步方案 etcd-syncer 之 raft 版本。它的部署图如下所示,etcd-syncer 同步服务作为一个类似 learner 节点的身份，加入主 etcd 集群。腾讯大规模云原生技术实践案例集 主 etcd 集群 Leader 将 Raft 日志数据通过 MsgApp/Snapshot 等消息同步给 etcd-syncer,etcd-syncer 解 析 Raft 日 志，将 Raft 日 志 条 目 对 应 的 Txn/Delete/Aut

250、h 等请求应用到目的 etcd 集群。它具备如下优点：具备 etcd-syncer 之 mirror-plus 版本的所有特性和优点，同时不依赖 etcd mvcc 历史数据。基于 etcd 底层的 Raft 日志同步数据，可以同步 key-value、auth、lease 等各种类型的数据。不依赖高版本的 etcd。完备的容灾测试 grpc-proxy 此方案引入了 grpc-proxy 代理服务，也是头一次使用。为了了解此代理服务的性能情况，我们使用 etcd 自带的 benchmark 进行了读和写的测试，另外手写了一个小工具做了一下 watch 测试。以下为部分测试内容。写入测试写入测

251、试 直接访问 etcd 服务的负载均衡入口 走 grpc-proxy 代理访问 etcd 服务的情况 腾讯大规模云原生技术实践案例集 grpc-proxy 代理在 endpoints 配置走专线或公网情况下，都能正常写入 写入 key 总数一定的情况下，连接数和客户端数越大，总耗时越低 写入 key 总数越大，单次写入的平均耗时（Average）会有所增加，但仍为毫秒级 当一次写入 key 总数为 10 万时，直连 etcdserver 会出现 too many requests 的报错，但 grpc-proxy 没有 公网情况比专线性能有所下降 走 grpc-proxy 代理的平均耗时相比直

252、连有所增加，但满足需求 读取测试读取测试 直接访问 etcd 服务的负载均衡入口 走 grpc-proxy 代理访问 etcd 服务的情况 grpc-proxy 代理在 endpoints 配置走专线或公网情况下，都能正常读取 走 grpc-proxy 代理的平均耗时相比直连有所增加，但在可接受范围 watch watch 测试测试 根据我们自己写的一个 etcdwatcher 服务对 grpc-proxy 进行 watch 测试：可以设置总 watcher 数量，更新频率，以及测试时间，结束时打印出简报 ./etcdwatch-num=100-span=500-duration=10-end

253、point=http:/grpc-proxy-addr:23791 test done total 100 task 0 task failed current revision is 631490 least revision is 631490 0 task is not synced 参数说明：腾讯大规模云原生技术实践案例集 num 任务数量 span 更新间隔，单位毫秒 duration 总测试时间，单位秒 current revision：代表写入的 revision least revision：表示 num 个任务中同步最慢的 revision failed 为 0 说明正常；如

254、果过出现 task not sync 说明 watch 和 put 不同步 以上测试结果来看：failed 数为 0，watch 测试正常 zk2etcd 我们使用的是 1.2.5 版本，通过 k8s 的 deployment 方式部署 1.模拟模拟 zk server zk server 失联失联 场景通过将 hosts 中注入错误解析地址 现象期间没有发现 zk 失联的报错日志 监控指标没有发现异常 此后执行重启，fixed 操作数没有出现凸增情况（在 1.2.4 版本中，存在 full sync 虽然在定时执行，但是并没有感知到需要 fix 的 key 的 bug。导致重启 zk2etc

255、d 服务实例后，可能观察到 fixed 操作凸增的现象）1.模拟模拟 redis redis 失联失联 模拟操作 09:56:49 将 hosts 中注入 redis 错误解析地址 10:07:34 恢复 redis 10:16:00 重启同步服务 pod（操作重启是为了观察 full sync 是否正常）现象期间 fixed operation 数量没有增长，其他监控指标未发现明显异常 实例重启后没有出现 fixed 数凸增的情况 3.3.模拟模拟 etcdetcd 失联失联 模拟操作 16:15:10 etcd server 失联 16:30 恢复 16:45 重启 pod 腾讯大规模云原

256、生技术实践案例集 现象期间 fixed operation 数量没有增长，其他监控指标未发现明显异常 此后重启，fixed operation 数量有所增涨（不能确定是 full sync 未生效，还是重启后刚好有更新修复导致）总结总结 只要 full sync 机制工作正常，各异常场景发生后，都能在下一个 full sync 触发后被恢复 恢复的最小时间间隔取决于设置的 full sync 定时执行间隔时间（默认为 5m），业务对此间隔时间容忍情况自行调整参数 此外，为了避免异常发生后，full sync 机制定时运行但也没能感知到情况发生，保险起见事后可以第一时间重启一下 zk2etcd

257、服务 对于追加的 etcd 公网测试，full sync completed 和 zk、etcd 操作耗时，相比内网情况有一定（秒级）增长 etcd2etcdetcd2etcd 的同步服务，我采用 deployment 双副本部署 1.多副本多副本 backup backup 能力能力 期望作节点故障后备节点会在 5s 后接管同步任务 测试方案 etcd syncer 双实例部署 杀掉正在运行的工作节点进行观察 结论不论是增量同步还是全量同步过程中，主备切换都能正常工作（需要注意的是，当全量同步中发生主备切换后会变为增量同步，从而可能导致比对较慢）1.断点续传能力断点续传能力 期望故障恢复后能

258、从断点继续开始同步 其实在第 1 部分，备节点切换为主后接管同步工作，fast_path 变为 1 也证明了断点续传能力，我们还额外补充几个验证场景：(a)短时间故障 故障场景 中心 etcd 集群到热备集群的同步过程中，因作为源的中心 etcd 集群中也存在-etcd-syncer-meta-的 key，触发了同步服务报错（同 txn 中不能包 腾讯大规模云原生技术实践案例集 含相同的 key），出现了数据差异 现象 将同步服务运行参数添加对-etcd-syncer-meta-的过滤，然后观察进过一段时间追赶数据后，最终 miss 数降去达到一致(b)长时间故障 故障场景 停止同步服务的部署

259、 deployment 等待两边 etcd 集群产生数据差异，并发生一次 compact 后再启动同步服务 现象 等产生数据差异，并发生 compact 后，重新启动同步服务，其日志如下：因 compacted 发生，触发全量同步 同步服务监控指标：(a)dst miss key 很快降下去；(b)src miss key 有所增加，并持续不降 分析 同步服务停止以后，源 etcd 的 key 数量发生不少变化，监控图看出期间有下降，说明发生过 key 的删除 这里也暴露出一个小问题，当出现 src miss key 的时候，目前不能自动修复，需要人工接入清理多余的 key 3.reset r

260、eset 触发全量同步触发全量同步当同步发生重大差异（如，发生 dst miss）进行紧急修复的时候，通过配置-reset-last-synced-rev 参数删除断点续传信息，来触发全量同步修复差异 现象因某种异常，同步出现 dst miss（图中黄线实例）的情况。为了进行修复，新实例添加-reset-last-synced-rev 参数后运行 腾讯大规模云原生技术实践案例集 分析 slow_path 为 1，说明触发全量同步（图中绿线实例）绿线实例的 dst miss 值没有增长起来，说明已经达到一致 4.4.网络故障网络故障两 etcd 集群之间专线中断 增量同步中 全量同步中 测试方案

261、 当专线中断切换公网时，需要修改运行参数中的 etcd 集群访问地址，即：必会发生重启（重启场景测试前面已经涵盖，这里不再重复）总结总结 etcd-syncer 同步服务有较好的主备机制，能够及时有效的进行切换 短时间故障后的断点续传表现符合预期；对于长时间故障，同时发生 compact 的复杂情况时，恢复同步后出现 src miss 的情况，可能需要人工接入 通过配置-reset-last-synced-rev 参数对 src miss 的异常修复有较好的效果 腾讯大规模云原生技术实践案例集 案例案例十十二二：助力知乎大数据集群无缝升级助力知乎大数据集群无缝升级 项目背景项目背景 知乎是中文

262、互联网最大的知识分享平台，数亿用户通过知识建立连接，找到感兴趣的高质量内容，分享各自领域的相关知识，并进行站内互动。随着知乎商业化进程的加快，知乎希望将全平台的优质内容与终端用户更智能、更高效地连接起来，进行精准内容推荐、经营分析和用户体验改善等数据应用方向的价值探索，从而为公司运营和业务发展提供更有效的数据支撑。项目挑战项目挑战 知乎的大数据平台建设对数据工具提出了更实用要求，原来基于开源软件构建大数据集群的方式所带来的挑战也逐渐显现，如资源交付效率低、运维成本高等。知乎现有的大数据处理能力已经不能满足日益增长的数据需求。知乎选择将基于开源 Hadoop 技术栈构建的数千台规模大数据集群无缝

263、升级到腾讯云大数据云原生方案，提升整体资源利用率，并提高资源的交付效率，通过新的架构方案实现降本增效。这个过程面临着多个挑战：业务需求层面，为了保证改动对原先业务完全透明，需要在业务无感知情况下，对原大数据集群进行托管；在技术需求层面，由于知乎原本的集群是基于开源 Hadoop 构建，这与腾讯云大数据版本之间存在差异，因此需要提供一个可行的产品化方案来解决该问题；基于不同云原生框架 TKE/EKS 数据混合部署模式，面临大数据集群与 TKE/EKS 算力混合技术问题，如自动扩缩容、资源调度改造、资源隔离性等挑战。腾讯云原生大数据解决方案腾讯云原生大数据解决方案 为了应对上述挑战，腾讯云应用大数

264、据云原生方案，完成了对知乎大数据集群的全面升级管理。为了解决开源 Hadoop 版本与腾讯云大数据版本之间的差异，腾讯云采用定制化开发方案，构建基于知乎软件版本的镜像版本并产品化上线。由于在线资源 TKE 集群与离线 Hadoop 集群一般情况下均为错峰计算，为了解决原有资源的整体资源利用率，采用 EMR on TKE 方案，离线在线混合部署模式，提升整体资源利用率。为了解决资源在紧急情况下，交付效率的问题，采用 EMRon EKS 方案，可以在分钟时间内，交付数千核资源稳定投入到生产环境。在大数据 EMR 与 TKE 融合过程中，为了保证离线任务与在线任务的隔离线，采用 Cgroup、BT

265、调度算法等方式做好资源隔离。腾讯大规模云原生技术实践案例集 为了保证大数据 EMR 集群中任务运行的稳定性，对 Yarn 资源调度进行改造升级，能做到资源调度时，AM 管理节点分配的合理性，同时也能做到资源弹性扩容到队列维度。整体混合算力技术方案的架构如下图所示：图 3-21 混合算力技术方案的架构 实践价值实践价值 基于腾讯云原生 TKE 方案，腾讯云团队探索出了 EMR 离在线混合部署策略，帮助知乎极大提升了资源利用率，从而大幅降低了技术成本，低峰期资源利用率提升高达 5 倍。在腾讯云原生 EKS 方案中实现了 EMR 的混合算力部署，帮助知乎提高了资源交付效率，也大大降低了运维成本，资源

266、交付效率提升达 80%。腾讯大规模云原生技术实践案例集 案例案例十十三三：小红书小红书 AIAI 搜索推荐场景搜索推荐场景 容器化实战容器化实战 项目背景项目背景 小红书是一个生活方式平台和消费决策入口。在小红书社区，用户通过文字、图片、视频笔记的分享，记录了这个时代年轻人的正能量和美好生活。通过大数据和人工智能，小红书能够将社区中的海量内容精准、高效地匹配给对它感兴趣的用户。一个用户通过“线上分享”消费体验，引发“社区互动”，能够推动其他用户去到“线下消费”；这些用户反过来又会进行更多的“线上分享”，形成正循环。项目挑战项目挑战 小红书的高速发展，得益于社区内容与兴趣用户之间的精准高效匹配。

267、早在 2016 年初，小红书就已经将人工运营内容改成了机器分发的形式。小红书的推荐系统会根据用户的实时点击、推荐、收藏、评论等行为数据，实时更新用户笔记画像，实时产生训练样本，实时训练模型，小时级迭代更新线上模型。截至 2019 年 7 月，小红书用户数已超过 3 亿，当年 10 月，月活跃用户数过亿。2020 年 3月，小红书的移动 APP 日活排名前 50。目前日活跃用户已超过 3,500 万，日均笔记浏览量超过 80 亿次。巨大的用户量、活跃数据和基于这些数据之上的实时推荐需求，都对小红书底层系统的稳定性、低时延和弹性扩容都提出了非常高的需求。腾讯云原生腾讯云原生 容器解决方案容器解决方

268、案 核心推荐系统容器化部署核心推荐系统容器化部署 支撑这些的背后，无疑是强大的技术实力。小红书的所有系统都跑在公有云上，不仅如此，小红书团队对资源的调度和效能有更加极致的追求。从 2017 年初开始，腾讯云容器团队就与小红书一起对业务系统进行容器化改造。目前小红书社区业务的所有无状态服务、部分有状态服务都已经容器化部署。其中，小红书实时推荐系统中的模型训练、TFServing 推理服务、Redis 缓存、Flink 计算等，都部署在腾讯云容器服务 TKE 平台上。目前有接近 20 个 TKE 集群，单集群超过 4,000节点。腾讯大规模云原生技术实践案例集 解决方案架构图 当小红书的大规模分布

269、式训练场景中批量 worker 实例，同时到共享存储拉取海量训练数据时，这些对于容器网络性能包括吞吐、时延和稳定性等方面都提出了更高的要求，社区网络方案都对网络性能有影响。腾讯云 TKE 在容器网络方面先后推出了几种网络模式来进一步提高性能，包括借助智能网卡，实现了一个 Pod 独占一张弹性网卡，不再经过节点网络协议栈（default namespace），极大缩短了容器访问链路，缩短了访问时延，在保证容器网络零损耗的同时，使 PPS 可以达到整机上限。这一方案实现了短链接场景下 QPS 相比之前容器网络方案（策略路由方案，网桥方案）提升 50%-70%；长链接场景下 QPS 提升 40%-6

270、0%。面向小红书 TKE 单集群超过 4,000 节点的大集群管理，腾讯云 TKE 在 etcd 做了大量优化，提升读写效率，同时回馈社区，多个控制面组件优化，保证系统稳定性和调度效率。另外通过节点池特性，方便小红书的集群管理。考虑部分 TKE 早期创建的集群版本较低，无法使用高版本新特性。TKE 还支持控制面滚动升级，计算节点原地大版本升级，保证小红书线上大集群升级对业务完全无感知，节点和 Pod不重启。同城多可用区双活架构同城多可用区双活架构 每年 6 月 6 日，小红书都会推出促销力度最大的周年庆促销活动，届时系统稳定性必须得到保障。小红书借助腾讯云上海地域多可用区双活架构，保证系统高可

271、用。下图是小红书推荐系统部分的双活架构，主数据库在上海四区，用户特征数据来源于离线和实时流计算平台，推荐系统场景下主要是读，特征数据会被同步到各个可用区 TKE 上部署的Redis 集群，提升业务系统的访问效率。入口流量则在 LB 层面做了多可用区的平均分配。腾讯大规模云原生技术实践案例集 小红书推荐系统部分的双活架构 弹性扩缩容弹性扩缩容 每当大促时，为应对高流量，都需要提前对系统扩容，小红书借助 TKE 容器产品，能够利用容器便捷的编排能力快速扩展业务实例，可做到几分钟内快速扩容百计的节点，不需要像传统模式提前数周甚至几个月扩容。此外，小红书也会在离线训练等极速弹性需求场景中，逐步推广使用

272、腾讯云提供的无节点EKS 弹性集群产品。无需事先购买节点，即能够做到分钟级创建数以千计的 Pod 的极速扩容能力。Pod 以轻量级虚拟机的方式直接运行在底层物理机上，兼顾速度和安全性。使用服务网格，做精细化流量管控和持续发布使用服务网格，做精细化流量管控和持续发布 承载亿级用户的小红书，产品的任何改动都可能面临无数存量用户的挑战。小红书能保持稳定迭代的秘密在于渐进式交付。Kubernetes 和云原生这两项技术的出现，为“渐进式交付”在互联网的应用提供了可靠的基础设施和稳妥的实现方法。当业务发布时，选择接入网格策略，就可以借助网格做精细化的流量管控和金丝雀发布。比如设置策略先把内部客户或者部分

273、终端的请求路由到新版本，最后再全量发布，避免线上 90%的发布事故风险。腾讯云容器服务 TCM 团队与小红书团队在网格领域进行了多次技术交流，在 Redis 分片读写分离、流量预热等领域也展开了深度合作。实践价值实践价值 小红书使用腾讯云容器服务产品 TKE，为大规模模型训练和推理提供稳定高效的平台支撑，借助便捷的容器编排能力，实现了模型的每小时快速迭代，大大提升了小红书笔记展示给用户的精准性。在训练场景，借助容器服务的弹性能力，小红书也大幅降低了资源成本，节约达到 40%以上。日常只需要 2 个 AI 工程人员负责训练平台底层资源运维的相关事项，团队可以把更多的精力和人力资源聚焦在算法优化上

274、，不断提升模型的预测准确性。腾讯大规模云原生技术实践案例集 案例案例十十四四：Unity+Unity+腾讯云腾讯云 SeverlessSeverless：重构计算模型，打造构建元：重构计算模型，打造构建元宇宙的核心引擎宇宙的核心引擎 点此阅读原文 2018 年，斯皮尔伯格导演的电影 头号玩家 让“元宇宙（Metaverse）”进入大众视野；2021 年，Facebook 等在内的国内外诸多科技公司纷纷入局，“元宇宙元年”自此开启。什么是元宇宙？目前业界对元宇宙的共识是：它是从互联网进化而来的一个实时在线的世界，是由线上、线下很多个平台打通组成的一种新的经济和文明系统。通俗来说，元宇宙是一个平行

275、于现实世界的虚拟世界，人们借助数字身份，就可以在元宇宙空间展开第二人生：享受虚拟世界里的艺术、购买虚拟产品、与他人社交 元宇宙勾画出的未来令人心驰神往，逐步趋近于现实环境的 AAA 级美术光影效果表现，给用户带来极致的感官体验，但同时还带来的是游戏场景模型与光源的增多，随之而来倍增的计算量。UnityUnity&云函数云端云函数云端分布式算力方案分布式算力方案 腾讯云腾讯云 Serverless Serverless 联合全球领先的实时互动内容创作平台联合全球领先的实时互动内容创作平台 Unity Unity 推出云端分布式算力推出云端分布式算力方案，方案，重构计算模型，成为赋能未来元宇宙创作

276、者的利器。该方案基于 腾讯云云函数腾讯云云函数 SCFSCF（Serverless Cloud Function)Serverless Cloud Function)计算服务，包括 云云烘焙烘焙 (Cloud Bake)(Cloud Bake)、云端分布式资源导入与打包、大模型数据云端轻量化、云端分布式资源导入与打包、大模型数据云端轻量化。这三大方案充分利用了云函数云函数 SCF SCF 高并发的云计算资源高并发的云计算资源，帮助创作者大大提高开发效率，加快项目迭代。（云烘焙解决方案）腾讯大规模云原生技术实践案例集（云端分布式资源导入与打包方案）云函数云函数&Unity&Unity-云端分布式

277、算力方案云端分布式算力方案三三大优势大优势 1.1.高性能，提效率高性能，提效率 元宇宙的构建不乏高品质沉浸式画面和大世界场景的开发需求，但受制于单机性能的提升瓶颈，传统的工作流难以满足各个环节的开发需求，高质量的 3D 场景烘焙以及游戏资源的导入和打包，成为了许多重度项目开发迭代的主要性能瓶颈。以使命召唤手游的技术特点为例，当场景地形非常复杂的时候，如果使用Enlighten，烘焙的时间高达一整晚。如果不巧出现 Bug，同一天会卡 10 张图，时间难以估量的项目延期随之而来。腾讯大规模云原生技术实践案例集（云烘培官方定制版）如果能够提高烘焙和资源管理的效率，不仅可以减少团队的工作压力，更能够

278、多次试错，释放团队的创作力，快速打磨产品。为此，云端分布式算力方案推出了基于 Enlighten 的云烘焙解决方案和云端分布式资源导入与打包方案。二者都是基于引擎深度定制的方案，并结合腾讯云 Serverless 服务，可以实现百台计算资源的高并发，支持动态扩容，大幅提高迭代效率。在项目实测中，使用在项目实测中，使用 Unity Unity 云烘焙解决方案可节省高达云烘焙解决方案可节省高达 70%70%以上的以上的烘焙时间。烘焙时间。腾讯大规模云原生技术实践案例集 2.2.易部署，免运维易部署，免运维 Serverless 云端分布式算力方案中的云烘焙、云端分布式资源导入与打包、大模型数据云端

279、轻量化整套流程均被整合到引擎中，官方提供对应定制引擎版本及后续升级服务，快速接入，免运维，即可体验整套方案。元宇宙的概念不止于游戏，同样强调数字化、强交互的智慧城市与元宇宙也可以相互借鉴。在数字孪生、数字城市、数字工厂等场景中，云端分布式算力方案可以成为各产业加速数字化转型的通用技术平台底座。Pixyz Batch 是国际知名的三维数据轻量化工具，当前方案中的 CIDC CIDC 解决方案基于解决方案基于 Pixyz Batch Pixyz Batch 定制了整个格式转换的工作流程，结合云函定制了整个格式转换的工作流程，结合云函数数 SCF SCF，整套流程均部署在云端，无需本地部署。，整套流

280、程均部署在云端，无需本地部署。（CIDC 解决方案）3 3.节约成本节约成本 谈及构建元宇宙，意味着数百万的服务器，服务用户内容和做 3D 实时模拟，包括潜在的拟真物理模拟，这些是全新的成本构成。云端分布式算力方案所使用的算力采用按用量计按用量计费，费，支持动态扩容，当没有计算任务时不会产生任何费用支持动态扩容，当没有计算任务时不会产生任何费用，有效节省了制作成本。其中，值得一提的是成本计费的精准度：云函数 1ms 最小颗粒度和最精准的计费颗粒度，意味着所有请求调用真正实现按量计费 每一个烘培任务都可以精确地计算成本，每一个烘培任务都可以精确地计算成本，每个场景每个场景功能实现的资源消耗都能得

281、到量化。功能实现的资源消耗都能得到量化。元宇宙何时能够实现难以预测，但是它所描绘出的世界吸引了众多科技爱好者和全球科技企业为之努力。除了云端分布式算力方案，Unity Unity 性能优化解决方案性能优化解决方案 UPR UPR 也使用了腾讯云也使用了腾讯云云函数云函数 SCF SCF 计算服务，进一步释放本地计算资源。计算服务，进一步释放本地计算资源。腾讯大规模云原生技术实践案例集 案例十案例十五五：揭开微盟百万揭开微盟百万商家营销大战背后的数据库秘密商家营销大战背后的数据库秘密 点此阅读原文 又到了双十一、双十二、年终大促季，每年这个时候都是购物狂欢节，不仅促销产品多、种类全、覆盖面广，促

282、销花样也在不断翻新，直播、砍价、优惠券、加价购等，令人眼花缭乱。当全国人民沉浸在买买买的自嗨中无法自拔时，考验的不仅是百万商家的战略战术，更是各种技术平台的实力比拼，尤其是底层的数据库，将迎来流量峰值期间的高并发和快速响应挑战。微盟产品和服务布局 以微盟为例，公司承载的是多渠道的广告营销业务，提供和各个细分领域相关的垂直 SaaS 解决方案及服务。比如：双 11 期间的秒杀、拼团和砍价，需要很多专业解决方案和功能支撑，而微盟拥有丰富的产品和解决方案，处于业界最领先地位，很多优惠券、抽奖、广告牌、激励转化等功能，都有专门的数字化插件。借用微盟数据库负责人 余成真 的话来说，“虽然微盟的很多 Sa

283、aS 业务经常被模仿，但从未被超越。”从大的平台架构来看，每个业务系统都是独立应用，包括独立的后台、技术栈、数据库，并且对于库和表的设计，也各不相同。腾讯大规模云原生技术实践案例集 而对于“秒杀”类活动，每天收到的活动报备请求至少几十个，遇到重要节日以及重大营销活动时，可能会有上百个商家发起活动报备申请，无论是用户在线数，还是业务请求量，都是 TOP 级别。所以，对于数据库的性能来说，必须满足如下要求：反应要快，并且不同应用接口响应要求不一样。针对恶意刷票行为，要进行流量防控。要具备数据库的大量读写能力。大体来看，微盟数据库团队主要面临 4 大挑战：1.1.高并发、低延时需求高并发、低延时需求

284、 微盟的核心接口在平常状态下都是毫秒级响应，数据库的每条请求都是几毫秒，甚至是纳秒级响应时间。在活动高峰期，某些营销插件的场景类数据库，单实例就有超过 7 万真实 QPS 记录值。2.2.确保稳定性及高可用性确保稳定性及高可用性 稳定性和可用性是基本要求，目前主要依赖腾讯云数据库底层高可用能力，同时微盟自己也有一套针对应急场景的可用性工具，未来希望能更可靠、更稳定。3.3.数据安全数据安全 如何对人员安全、数据库安全进行治理，成为一项长期工作。需要进一步加强治理的事项，包括：数据分类分级、线上数据查询的精细授权、数据灾备的定期演练、运维操作风控等。4.4.海量实例数据库运维海量实例数据库运维

285、微盟数据库类型多、数量多、业务线多，管理好这些元数据是 DBA 做好各项工作的先决条件。同时，只有做到精细化运维，才能规避工作中遇到的数据库问题、将故障及风险降至最低。此种背景下，微盟开启了全面的云数据库转型征程，从思维模式开始，让整个架构向更弹性、更灵活的服务模式演进。腾讯大规模云原生技术实践案例集 基于云数据库的解决方案与实践“SaaS 电商业务的本质是，对数据库应用性能要求较高，必须抗住各种压力。”余成真说道。在数字化转型背景下，企业业务的核心是数据，数据驱动业务，数字即服务。而承载所有数据的数据库，既有事务 ACID 特性的要求，又有海量数据存储的要求。所以，数据库产品在具备联机事务处

286、理能力同时，数据库的读取性能也必须强悍，同时还要具备数据分析能力。另外，微盟业务发展速度飞快，资源需求呈指数级倍增，数据安全、数据库类型扩展、数据库技术能力扩展等核心问题，都需要重新考虑。微盟持续保持高速发展，创新和不断迭代是内在基因。2020 年，为了助力更多商家实现数字化转型，微盟提出了“TSO 全链路智慧增长”，从流量、SaaS 工具和运营角度，构建全域数字化商业闭环。从产品角度看，最重要的是，全面提升信息安全保护能力，防止灾害及不可抗拒因素给业务系统带来的伤害。为了配合集团业务高速发展的需求，数据库团队必须基于现代化业务架构，转变思维模式，让所有业务在充分享受云的弹性能力的同时，也要兼

287、具业务的隔离性。利用云数据库弹性满足高并发和快速调整需求利用云数据库弹性满足高并发和快速调整需求 纵观微盟数据库的发展史，主要分为纵观微盟数据库的发展史，主要分为 3 3 个重要阶段：个重要阶段：1.1.早期早期 IDCIDC 建设阶段，包括自建黑石数据库服务集群。建设阶段，包括自建黑石数据库服务集群。2016 年，微盟的数据库从阿里云全线迁移到腾讯黑石机房，实现了跨 IDC 的异地同步。在迁移之初，不仅要保证数据的一致性，对数据可用性的时间也有极高要求，数据库实例要在 30 分钟内全部切换完，具体到单套实例的不可用时间要限制到秒级。而且，迁移过程中注意的细节非常多，涉及到对项目的协调及人员的

288、动员力，在数据库同步迁移技术上，要保证数据的绝对一致性，迁移过程中也要具备更缜密 腾讯大规模云原生技术实践案例集 的思维。同时，还讲求战略战术和技巧，微盟当时使用的是主从复制技术，因为经典意味着可靠。为了更贴合业务发展，微盟还自建了数据库服务集群，用半年时间打造了一整套数据库私有云解决方案，包括具备监控、告警、备份、高可用等相关功能。不仅解决了业务问题，在技术上也有重大突破，包括借助开源工具实现了二次开发，期间还编写了大量辅助运维工具，将零散的运维工作进行了工程化建模。由于数据库硬件服务器是高效及高可用架构设计，所以数据库集群在 4 年多线上真实环境应用中，没有出现任何事故级故障，整体集群非常

289、稳定、高效。2.2.数据库全面上云以及异地多活架构升级。数据库全面上云以及异地多活架构升级。2020 年，为了配合 TSO 业务战略落地，微盟尝试探索公有云路线。因为，相对于私有云，公有云的弹性扩展能力强，更能满足业务高并发需求。经过大量调研、测试、选型、验证后，公司开始制定实施计划，全面上云。其实，当时很多云厂商提供的异地多活方案都不是非常成熟。期间，微盟数据库团队和腾讯云数据库部门保持密切沟通与互动。从最初通过线上边缘业务进行测试，到之后发展到周期性全实例的多活故障演练，最终才实现了技术上的突破，创造了成功的多活方案，高度确保了业务的稳定性。3.3.加码数据安全，实现精细化运维。加码数据安

290、全，实现精细化运维。2021 年，为了确保数据库部门拥有全线的业务支撑能力，微盟制定了很多和运维相关的规范及流程。主要包含两个维度：一方面，运维操作人员要具有可量化的操作细节;另一方面，降低风险，提升沟通效率。集中式集中式+分布式架构设计分布式架构设计 大体来看，微盟云数据库转型是企业支持数字化业务的最重要里程碑，他们开创了新的思维模式，用一个更灵活的策略，把大业务拆小，小业务拆得更细。并且，在每一个细的模块上，都做了数据库级别的支撑。这意味着，整个后台不仅拥有众多实例，能充分利用云基础设施的弹性，随时按需使用，还能确保实例之间的隔离性。即便是小商户，也能做到项目式的隔离，确保每个项目都不受影

291、响。在具体的数据库设计上，微盟采用的是集中式+分布式技术架构。腾讯大规模云原生技术实践案例集 分布式应用场景：微盟把 Redis、Kafaka 作为大型分布式系统的关键组件，这些组件在实时数据或流式数据架构中扮演着重要角色。联机事务处理应用：微盟采用腾讯自研的云原生数据库 TDSQL-C、腾讯云 MySQL、腾讯云 PostgreSQL 支撑底层全业务线存储，存储所有业务线的元数据，并提供重要数据计算及存取能力。分析型应用场景：通过 TiDB/HBase/TDSQL-H 解决实时及离线分析问题。在余成真看来，决定微盟云数据库选型的最关键因素有四点，即安全、性能、稳定和成本。微盟是基于微信生态做

292、的产品级应用，也是腾讯云华东地区头部、重要 VIP 客户，所以对腾讯云有着天然的亲和力，微盟的很多基础设施服务都在使用腾讯云提供的产品，比如：高防、LB、VPC 网络、CVM、COS、DB、EMR 等等。针对腾讯云数据库产品提供层面，微盟目前主要使用的是 MySQL 及云原生数据库 TDSQL-C，以及非关系型数据库 Redis。更安全、更稳定、性能更强更安全、更稳定、性能更强 “数据库全面上云后，不仅实现了当初规划的目标，在数据安全性、应用的稳定性以及性能方面，也有更卓越表现。”余成真对云数据库上线后的效果，给与了高度评价。总结而言，数据库上云后，获得了如下效果：全面确保数据安全。全面确保数

293、据安全。底层基础设施安全：由于数据库底层运维工作主要交给腾讯云数据库团队来做，极大地确保了底层基础设施的安全性。数据安全：为了从根本上确保数据安全，微盟在数据库权限系统上设置了最小粒度的授权原则。具体做法是，将权限绑定于资源对象上，人及业务组仅有权限查看所属的数据库资源。对这些资源的操作，会进一步细化权限，如：流程化管理，要经过“申请、一级审批、二级审批、执行”这样一个流程。腾讯大规模云原生技术实践案例集 权责到人：微盟还将所有 DBA 操作进行工单化，具体包括：查询申请工单、SQL 上线工单、数据迁移工单、数据归档工单等等。通过对人、对资源的权限控制，对数据的分类分级等方式，来保证数据安全。

294、为了与国家数据安全法保持实时同步，微盟已将数据安全法进行了平台化处理。运营能力提升。运营能力提升。为了满足更精细化的运维需求，微盟基于腾讯云数据库提供的能力，做了进一步扩展，对更贴近业务场景的功能做了处理。为了全面提升数据库运营能力，通过监控数据、告警数据、慢日志数据等进行资源评分，为资源配置提供重要依据，也可推导业务代码质量，产品响应质量等。简单理解，腾讯云数据库把底层的脏活苦活累活都干完了，微盟的数据库团队就无须再关心底层基础设施问题，而是拿出更多时间，关注业务层面的问题。性能增强。性能增强。对于微盟最关注的数据库性能，也做了进一步增强，实现了底层内核以及整体性能的优化。微盟建立了数据库性

295、能压测跟踪平台，可按照自己的标准进行快速衡量各厂商云数据库质量。在数据库上云后，微盟还建立了真实业务 SQL 模型，能推导代码质量，度量接口响应指标等。成本优势。成本优势。云数据库上面的资源弹性扩缩容能力，以及在节约成本方面，也是传统业务模式无法比拟的。腾讯云数据库拥有资源的全生命周期管理，包括：资源申请、资源创建、数据库管理、账号类型管理、账号权限管理、资源业务域归属、资源负责人管理、资源监控备份告警管理、资源下架单、资源回收站。传统 IDC 模式下，一旦活动来了，进行扩容以后，成本就一次性加进去了，即使缩容以后，成本还是那么多。但使用腾讯云就不一样，可以按需使用，随用随付。微盟云数据库不仅

296、全面拥抱了云原生，在 HTAP 融合发展趋势上也在不断探索。目前，具有业务属性的云原生数据库 TDSQL-C，已开始逐步迁移，承担的是高读 QPS类的业务;其中还有一小部分是 TDSQL-H 系列，解决了分析型应用场景的查询问题，承担一些 AP 类的业务。微盟通过腾讯云数据库的全栈服务，满足了 AP、TP 全场景需求，支撑着百万商家的大促及秒杀等核心业务。腾讯大规模云原生技术实践案例集 小结：小结：从某种角度看，微盟数据库上云旅程，其实是企业业务创新不断发展的结果。以数据库实例数量为例，上线之前是 1000 多套，现在使用了云上的资源以后，已经发展到 2000 多套，翻了至少一倍。从资源规模上

297、，已经做了一定的数量级，如果全部自己搭建，其业务的难度以及工作量，都无法想象。关于微盟：关于微盟：微盟，成立于 2013 年，虽然发展时间不长，但已成为一家领军企业云端商业及营销解决方案提供商，拥有超过 7500 名员工，全球加盟商超过 1600 家，入驻商户超过 300 万家。公司旗下业务主要包括商业云(微商城、智慧零售、智慧餐饮、智慧酒店、智慧美业)、营销云(微站、智营销、企微助手)、销售云(销氪)以及和精准营销相关的丰富的媒体资源和 DMP。媒体资源主要是指和腾讯、抖音、快手、头条、知乎、小红书等平台的对接;而 DMP，则包括精准受众定位、分析与优化和更灵活的格式等。微盟的企业理念是，致

298、力于成为企业数字化转型最佳伙伴，助力更多商家开启数字化转型征程。腾讯大规模云原生技术实践案例集 案例十案例十六六：最伟大的作品，解密周杰伦新专辑背后的数据密码最伟大的作品，解密周杰伦新专辑背后的数据密码 7 月 14 日晚间，周杰伦最新专辑最伟大的作品在 QQ 音乐正式上线，立即成为全网最大的热点事件。作为一张“六年等一回”的新专辑，最伟大的作品于 7 月 8日开启预售，截止到 7 月 18 日，已在 QQ 音乐售出超 500 万张。当全国人民沉浸在音乐的狂欢中，对于 QQ 音乐团队来却有着更多的涵义：海量的数海量的数据意味着更高标准的数据分析业务，底层的数据库，将迎来流量峰值期间的高并发和据

299、意味着更高标准的数据分析业务，底层的数据库，将迎来流量峰值期间的高并发和快速响应挑战。同时，如何通过用户行为以及音乐内容标签数据，深入洞察用户需求，快速响应挑战。同时，如何通过用户行为以及音乐内容标签数据，深入洞察用户需求，为亿万用户带来更优质的音乐体验？为亿万用户带来更优质的音乐体验？是对 QQ 音乐大数据团队的挑战以及机遇。海量数据场景下，如何保证用户体验？海量数据场景下，如何保证用户体验？作为一款国民级音乐应用，QQ 音乐月活跃用户人数超过 2.2 亿，周杰伦又是其最具号召力的歌手。从流量数据来看，专辑同名先行曲从流量数据来看，专辑同名先行曲 MVMV最伟大的作品在最伟大的作品在 QQQ

300、Q 音乐发布音乐发布1515 分钟，播放量超分钟，播放量超 120120 万次，上线仅万次，上线仅 1 1 小时小时 4747 分，播放总量突破分，播放总量突破 600600 万次，分享总万次，分享总次数突破次数突破 2020 万，评论总次数突破万，评论总次数突破 1212 万，万，MVMV 巅峰榜达成巅峰榜达成 10001000 万等级认证，均打破万等级认证，均打破 QQQQ音乐音乐 MVMV 单日数据历史纪录。单日数据历史纪录。从这也可以看出，作为音乐类应用，QQ 音乐坐拥海量数据，而且业务场景较多。大体来看，新音乐数字专辑上线，对于数据库来说可能面临如下挑战：首先是高并发低延时高并发低延

301、时的需求，活动开始的时候会有大量用户瞬间同时访问同一个歌手、同一首歌或者同一张专辑的信息，这就需要解决数据库热点更新、高并发低延迟的问题。其次是数据库快速扩缩容数据库快速扩缩容的需求，因为活动时间紧，瞬间并发量高，需要数据库能够快速支持多倍性能。最后是数据海量存储和数据安全性数据海量存储和数据安全性的需求，由于订单数据和日志流水非常多，且数据不能丢失，需要数据库既能保证数据安全又能支撑海量数据的存储。腾讯大规模云原生技术实践案例集 QQ 音乐数据库运维负责人赵新强说，此次周杰伦专辑发布活动涉及到的数据库主要此次周杰伦专辑发布活动涉及到的数据库主要是售卖专辑的订单库，在专辑预售和正售时会有大量订

302、单同时写入和更新数据库，对是售卖专辑的订单库，在专辑预售和正售时会有大量订单同时写入和更新数据库，对数据库的性能和一致性要求都较高，数据不能丢失，还需要保证高性能查询、写入和数据库的性能和一致性要求都较高，数据不能丢失，还需要保证高性能查询、写入和更新。更新。此种背景下，QQ 音乐的数据库整个架构需要更安全、更稳定的服务模式。而腾讯云企业级分布式数据库 TDSQL 正好满足了本次活动的需求。TDSQLTDSQL 支持强同步、半同步、异步三种同步方式，且强同步的性能基本接近异步复制支持强同步、半同步、异步三种同步方式，且强同步的性能基本接近异步复制方式方式。在周杰伦新专辑上线这一场景下，TDSQ

303、L 的强同步正好满足了该场景的需求。另外，TDSQLTDSQL 支持主备快支持主备快速切换和快速增加分片和副本速切换和快速增加分片和副本，在对业务透明的情况下快速扩容了多个分片和副本，即时满足了活动的要求。压测过程中也出现了多个副本和分片集中在少数几台设备的情况，通过主备切换和数据快速搬迁后，平稳和快速地解决了该问题。借助腾讯云数据库完善基础设施和服务借助腾讯云数据库完善基础设施和服务 QQ 音乐打造了“听、看、玩”的立体泛音乐娱乐生态圈，为累计注册数在 8 亿以上的用户提供多元化音乐生活体验，优质服务的背后，是每天万亿级新增音乐内容和行为数据，PB 数据量级的数据计算服务。经过 QQ 音乐和

304、腾讯云数据库双方技术团队无数次技术架构升级和性能优化，逐步形成高可用、高性能、高安全的计算分析平台。“音乐的业务场景较多，单一的数据库架构不能完全满足业务需求，所以针对不同的音乐的业务场景较多，单一的数据库架构不能完全满足业务需求，所以针对不同的业务场景，我们选择了不同的数据库架构业务场景，我们选择了不同的数据库架构”，QQ 音乐数据库运维负责人赵新强说，QQ音乐借助 TDSQL 的分布式能力部署了一主一从、一主多从一主一从、一主多从的数据库集群；针对核心业务，采用腾讯云原生数据库 TDSQL-C 的全球数据库架构，实现了多地容灾节点部署，在性能、成本和数据安全上均衡使用，满足不同业务的需求。

305、如今，QQ 音乐接入腾讯云数据库已有两年多的时间，整体数据规模已超过 100T。就业务场景来说，QQ 音乐主要的特点是离线分析场景较多，在日常的运维过程中会经常遇到一些数据库性能相关的疑难杂症或者组件管控的问题，腾讯云数据库团队能够及时地响应解决。在数据库的管理中，QQ 音乐主要面临以下几个问题：一是随着日志、流水、订单类的业务数据不断增长，原生的 MySQL 集中架构需要不断的进行分库分表，DBA 工作量大，且对业务逻辑需要适配，TDSQL 支持自动水平拆分自动水平拆分，能很好地解决该类问题；二是随着业务的增长，开发的 DDL 需求不断增多,通过腾讯云原生数据库 TDSQL-C 提供的 In

306、stant DDLInstant DDL 内核能力内核能力，1 秒内完成原先需要几十分钟甚至小时级别的变更，极大提升了 DBA 的运维效率；三是 DBA 日常频繁应对各种慢查询、低性能的排查，TDSQLTDSQL 的扁鹊的扁鹊 DBbrainDBbrain 平台平台通过对数据库实例各项指标进行综合分析和诊断，能够快速准确的找到数据库的性能瓶颈。腾讯大规模云原生技术实践案例集 目前，QQ 音乐业务在多种数据库架构的基础上，满足了实时动态、最新评论、置顶等满足了实时动态、最新评论、置顶等多业务功能，跨城读取毫秒级延迟，且支持活动弹性扩缩容，轻松应对千万级别用户多业务功能，跨城读取毫秒级延迟，且支持

307、活动弹性扩缩容，轻松应对千万级别用户基数的高并发读写，管理更轻松，更专注业务基数的高并发读写，管理更轻松，更专注业务。深入业务，向数据库智能化运维演进深入业务，向数据库智能化运维演进 当前，云端大数据基础设施产品以其技术开放性、全链路覆盖、灵活性获得了互联网企业数据 IT 团队的一致认可。借助于云端大数据基础设施推动业务创新、运营创新已成为互联网企业的共识。赵新强表示，目前 QQ 音乐处于自研上云自研上云的阶段，未来的主要方向是借助腾讯云完善的基础设施和服务脱离底层繁琐、基础的运维工作，将更多精力深入业务，另外 QQ 音乐也会不断建设自动化运维系统和工具，逐步向数据库智能化运维智能化运维努力。

308、在这方面，腾讯云原生数据库 TDSQL-C 基于计算存储分离的架构，提供 HTAP、极致弹性扩缩、海量分布式存储等能力，同时具备智能运维平台、Severless 版本等标准统一的产品服务方案，可全方位满足 QQ 音乐及业务的各类需求。腾讯云数据库智能统一管控平台，可让数据在不同引擎之间自由流动，更好地支持业务快速发展。具体包括：以丰富的接口能力，支持系统实现不同应用场景灵活调用、一键运营；实现 90%常见故障秒级诊断及 SQL 优化建议的智能运维体系，大幅降低系统运维复杂度；基于多源同步工具，实现多引擎数据秒级同步，对业务屏蔽引擎差异；实现插件式负载均衡管理，进一步提升可用性。QQ 音乐通过腾

309、讯云数据库的全栈服务，满足了 AP、TP 全场景需求，支撑着千万用户的订单、评论等核心业务，从大数据基础设施、全链路数据工具链、领域数据价值应用在内的各个环节，互利共赢，释放多元数据价值。而这也正是周杰伦新专辑带来的启示，对于互联网企业来说，需对于互联网企业来说，需要采用集数据安全、高性能、高弹性、易扩展要采用集数据安全、高性能、高弹性、易扩展等多种能力于一身的数据库，才能帮助更有效地应对未来发展等多种能力于一身的数据库，才能帮助更有效地应对未来发展。腾讯大规模云原生技术实践案例集 案例十案例十七七：“：“微盟式微盟式”SaaSSaaS，让商业变得更智慧，让商业变得更智慧 点此阅读原文 在助力

310、企业数字化转型的共同目标下，越来越多的服务商正走向更加紧密的合作。而面对海量数据爆发式的成长，以往单一的以往单一的 SaaSSaaS 产品很难直接满足企业的业务需求产品很难直接满足企业的业务需求，在某些场景下，无论是性能、安全还是稳定性，都面临着各种各样的问题。日前，拥有多种企业特性的微盟 SaaS 工具却屡次获得用户认可，这是怎么做到的？以下将带来微盟数据库负责人余成真先生的分享实录：微盟做为中国领军企业云端商业及营销解决方案 SaaS 提供商，现有员工超过 1 万人，入驻商户超过 300 多万家，在商业产品这块 SaaS 类云产品，能够为用户提供精准营销服务精准营销服务。SaaSSaaS

311、是一种全新的通过是一种全新的通过 InternetInternet 提供软件服务的模式，主要面向企业级客户提供软件服务的模式，主要面向企业级客户。微盟业务特色是营销数字化，通过多样营销插件，赋能企业实现数字化运营，让商业变得更智慧。业务多样及复杂性，也使得数据库面临诸多挑战，而微盟很多核心的接口都是毫秒级别的响应，落地到数据库可能就是几毫秒甚至纳秒级别。稳定、高可用也是稳定、高可用也是 DBADBA 提供数据库服务基本能力提供数据库服务基本能力，高可用依赖于云数据库能力，实现了异地多活、双活的架构，通过对高可用应用厂商调研，包括通过边缘业务实际演练，都证明这种高可用架构是非常成功的。其次是微盟

312、对数据安全追求，微盟对数据安全追求，数据安全是微盟极度重视的重点项目之一数据安全是微盟极度重视的重点项目之一，我们严格要求对于人员安全、数据库安全进行长期治理。比如说微盟数据库分类分级、线上数据查询精确授权、故障数据库备份场景演练、运维操作风险控制等等，都是属于微盟治理项目的内容。最后一块海量数据库运维带来的挑战海量数据库运维带来的挑战，因为微盟涉及到数据库实例数量多、类型多，业务线多，管理好这些原数据是 DBA 做好工作的先决条件，也是做好精细化运维的基础数据。有了这些数据，可以将一些数据库使用问题、巡检报告的风险分析，及时传导给业务域，去进行数据治理，降低故障，从而打磨出一个稳定、高可用产

313、品。腾讯大规模云原生技术实践案例集 比如说腾讯云腾讯云 MySQLMySQL 的优化，主要通过硬件选型、参数、服务器进行优化，以此达到选型优化目的。同时还有业务 SQL 优化，前面讲到微盟核心接口都是毫秒级别响应，所以对于业务 SQL 是要长期治理，微盟也形成了一套自己的 SQL 优化跟进机制。扩展：并不是说完成所有优化，业务就满足了，高 QPS 读也是需解决的实际问题，用云原生数据库云原生数据库 TDSQLTDSQL-C C来解决读能力扩展问题。众所周知，社区版 MySQL 对数据延迟不可控，而微盟现在用云原云原生数据库生数据库 TDSQLTDSQL-C C 解决了延迟不可控的问题。因为微盟

314、使用了扩展的只读能力，使业务应用只读的场景变得更多，同时提升了资源使用率，这也是一种降本的表现，云原生数据库云原生数据库 TDSQLTDSQL-C C 在极速扩缩容、海量存储应用上是非在极速扩缩容、海量存储应用上是非常便捷的。常便捷的。微盟还使用一款产品是 TDSQLTDSQL-H H，这种产品可以解决某些业务 AP 类查询资源使用高的痛点，通过数据传输工具 DTS 或 CDC，将 TP 与 AP 场景进行无缝结合，实现全场景使用闭环。数据库性能优化目标总结起来是三点：降本、增效、达标。通过不断 SQL 优化，不仅使数据库服务本身更加稳定，也降低资源使用率，能够精确资源配置，达到降配降本目的。

315、在增效这块，微盟对实例进行打标签，根据实例标签属性：重要实例、非重要实例、核心实例、高流量实例等等，为实例扩缩容提供一些依据，也为运维资源分配提供重要理论数据，实现重点资源重点运维，达到运维增效的目的。前面讲到优化，可能带来最直观效果就是告警数量的减少，告警数量减少意味数据库服务的达标。在优化过程中，微盟也衍生出很多治理方案及项目，比如说做慢 SQL 的治理，包括去定位 DBA 跟进人等。腾讯大规模云原生技术实践案例集 监控和告警治理方面，监控是依赖于腾讯云监控和告警治理方面，监控是依赖于腾讯云 APIAPI 接口做本地数据落地接口做本地数据落地，监控治理可对业务域监控数据输出，微盟基于需求监

316、控数据可以动态形成各种各样报表，比如说实例可以基于监控数据进行全资源风险巡检，可以动态多维度查看本地监控数据，去看 TOP 级 QPS、CPU 应用实例，达到掌控优化整个集群目的，同时对外我们也可以提供数据监控接口的能力，还能监测云监控本身服务的高可用。在告警治理这块，微盟将云上告警落到本地，这样可以对业务域进行定向维度告警，同时也可以做基于资源、时间维度、业务维度、告警指标维度的全方向实例分析，最终目的是为服务稳定做保障。这种告警也打通至内部监控系统，比如和 cat 去做耦合，形成了全链路业务告警联动，可以通过 DBA 视角去审视业务影响情况。SRE 运维解决方案是建立一套专业、可用的数据库

317、管理平台，这也是各大公司已经完成或者正在做的产品。而微盟这套平台解决的是实例全生命周期管理，还有工单自动化能力，也能提供运维人员对数据库的运营能力。高可用这一块，依赖于云数据库能力，云数据库消除了自建数据库高可用组件的运维压高可用这一块，依赖于云数据库能力，云数据库消除了自建数据库高可用组件的运维压力。力。在多可用区建设方面，微盟的 DBA 角色转换为需求提出者、方案验证者、可用产品的使用者。通过云数据库高可用架构原理推演及线上边缘业务真实故障演练，也证明了多可用区的故障转移能力，同时微盟也在计划进行周期性全实例多活可用性演练。数据安全是微盟重点关注方向数据安全是微盟重点关注方向，微盟解决方案

318、是通过定义规范化流程来保证安全，这里列举 4 个面来阐述微盟规范流程建设：操作 SOP 流程、应急预案流程、报告总结规范、权限收敛规范。主要是通过抽象 DBA 日常运维工作事项，来进行流程化、标准化定义。从而使得每种运维操作具有清晰操作步骤、验收流程、回滚方案，能够极大的降低运维人员操作风险、使各方能监控执行的各种状态、能预知操作的风险点，达到保证数据操作安全的目的。运维安全有两个点做阐述，一是系统风控，二是制度风控。比如说授权机制、权限分类级别、权限控制、账号权限回收、操作流程风控等等，微盟也有一套危机应急预案，在数据的恢复、还原方面；微盟在制度上面也做了很多工作，比如面试流程、人员离职流程

319、，包括在平时工作中也会跟进运维或者 DBA 人员工作状态，也定期向所有运维人员去做制度法律的宣讲。最后，聊一下对于云数据库使用的未来畅想。关于 TDSQL 产品前面介绍了很多，我这里也列了两点，第一点就是并行查询，据我所知，有厂商实现了并且部署在线上使用 ，并行查询理论可以提高百倍查询速度，这对用户来讲吸引力非常大，相信腾讯云厂商也是有能力把这块给到我们的企业用户。腾讯大规模云原生技术实践案例集 另外一块就是 HTAPHTAP 场景场景，因为 SaaS 行业的特殊性，对于 AP 类查询功能会越来越多，查询时效也会越来越高，而对于 AP 型数据库的要求，则是希望 TDSQL 这一系列产品最终实现一体化，让用户能够通过一个简单的配置或者一个简单的购买就能实现 HTAP 的能力。腾讯大规模云原生技术实践案例集