《騰訊云：騰訊大規模云原生技術實踐案例集（147頁）.pdf》由會員分享，可在線閱讀，更多相關《騰訊云：騰訊大規模云原生技術實踐案例集（147頁）.pdf（147頁珍藏版）》請在三個皮匠報告上搜索。

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、微信、騰訊視頻、王者榮耀等在內的騰訊內部業務騰訊內部業務，和騰訊云百萬級和騰訊云百萬級外部外部客戶一客戶一樣基于公有云的模式來樣基于公有云的模式來開發運營開發運營，騰訊全面開啟業務云端生長新時代?！斑@是騰訊自研上云戰略的一個里程碑?！彬v訊集團高級執行副總裁、云與智慧產業事業群CEO 湯道生表示：“把騰訊內部海量業務搬上云端，不僅幫助騰訊構建面向未來的技術架構和研發文化，推動科技成為公司業務發展和產品創新的動力與支撐，也全面錘煉了騰訊云的產品、技術和綜合服務能力，這些能力將加快推動產業的

8、數字化升級，助力實體經濟全面發展?！贝蟛糠謽I務都是在保持高速增長的過程中上云。比如，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 即可?？梢栽诟聵I務鏡像的同時也更新 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。只有限制能力，無法保障業務有足夠的資源可以使用?；谖覀儗τ跇I務產品的管理需求及期望，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，拉你進騰訊云容器技術交流群?？偨Y總結 本文總結了騰訊會議在 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 和切換功能。和切換功能?？傮w架構圖如下：業務上云后業務上云后 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 模式運行，然后灰度，再通過自適應限速、巡檢等實現大規?？s容，同時業務 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 業務場景。針對極小部分這類業務，我們需要能及時發現異常并進行熔斷和告警，并在畫像的基礎上增加一定的安全閾值，以確?？s容操作的安全性。騰訊大規模云原生技術實踐案例集 在整個變更過程中，KMetis 對外暴露了豐富的 metr

124、ics，如下圖所示，總縮容次數、縮容組件名、總擴容次數、擴容組件名、隊列長度、組件 OOM 次數、擴縮容延時、處于更新中的總組件數等。節點安全下線 通過大規?；叶冗M一步驗證系統穩定性和準確性后，通過按比例、自適應限速，我們對線上大規模集群實施了幾十萬次的縮容操作，那么在這過程中，如何將之前的不合適的老機型替換掉呢，并盡量提高節點的資源分配率呢？答案是定制調度策略定制調度策略。針對老節點下線問題，我們根據業務模塊畫像對應的資源，當老節點上的 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 上云，好比開著火車換引擎?，F在，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。低負載業務一般碎片化比較嚴重，而這些服務比較長尾，進而拉低了整體負載。時間不均時間不均 互聯網業務普通有明顯的波峰波谷，波峰和波谷的實際資源使用量至少有一個數量級差距，且真正的最高峰只有不到一個小時。企業不得不為這一個小時的用量而付出一天的成本?？臻g不均衡空間不均衡 一方面是在線集群波谷空閑了大量計算資源，另一方面是大數據離線計算需要大量計算資源。從整個公司視角來看，資源使用極不均衡。資源性能有待

199、提升資源性能有待提升 英特爾、英偉達每年都會有更強性能、更好性價比的硬件推出，云廠商也會有對 騰訊大規模云原生技術實踐案例集 應產品的發布。但是企業中業務線眾多，一個個去適配、驗證新機型，導致更換的周期往往要 1-2 年起。無法充分享受硬件帶來的成本優化紅利。解決方案解決方案 云原生給企業帶來一次技術重塑的機會。容器技術實現了資源和應用的解耦。業務研發和 SRE 關注 Pod 即可。底層計算資源由系統運維統一管理，對上層透明。Kubernetes 研發優化應用調度策略，實現計算利用率的最大化。大幅提升應用性能大幅提升應用性能 對公司主流的技術棧，深度優化所對應的框架。通過使用更高內核的運行態、

200、使用 Kubernetes 原生的注冊發現機制、保持各類網絡連接等等，實現 PHP 應用 43%的性能提升。通過使用 fluid，完成檢索服務計算和存儲的分離，極大提升了運維效率。過程中對內存基帶的使用進行了優化，帶來 30%性能提升，節省萬核級別計算資源。調度優化，整體提升計算利用率調度優化，整體提升計算利用率 容器服務使用統一的集群，常態在 40%左右，在保障業務穩定的情況下極限可達 60%。機器利用率大幅度提升。碎片化問題也得到徹底解決。但中間過程是曲折的，和騰訊云一起攻克了一系列業界難題。在 2020 年上半年我們完成了一塊核心業務的容器化之后，突然發現我們的運維成本居然增加了。原來在

201、虛機模式下，運維在晚高峰的時候，只需要去做一些穩定性的巡檢，其實并不需要有過多的一些運維動作。但容器化后，我們在晚高峰下需要不斷地對一些資源負載比較高的的去進行封鎖，然后把上面的一些比較重的 Pod 進行驅逐，為什么會這樣呢？就是我們分析了一下 Kubernetes 的原生調度器，還是以 request 進行調度?；ヂ摼W業務都會一個明顯的波峰波谷，在線教育的波峰波谷會更加劇烈，波峰波谷可能會有兩個數量級的一個差異。當研發在波谷的時候進行一次發布，這時候就會觸發容器的一次重新調度，比如像我這個服務有幾十個 Pod 的，可能會有十多個 pod 調度到一臺機器，因為這時候的機器的使用率很低，就是服務

202、怎么調度其實都可以，但是到了晚高峰的時候，我的每一個 pod 資源的使用率就上來的，CPU 使用高了，它的吞吐也高了，然后我這十個都在同一個機器上，我這臺機器就會出現一些資源的瓶頸?？梢钥闯鲈恼{度器只考慮了一些簡單的指標，同時也沒有考慮未來的一個變化。所以我們做了一個定義的調度器，將就是晚高峰的一些提前的情況進行了一些預測，以及融合了 CPU、內存、各種 io 的這些復雜指標都考慮進來做因子，同時就是我們也會定期的把歷史的數據進行大數據回歸更新策略。GPU 這塊它是一個比較相對貴的資源，我們調研了一些方案，主要推薦的方案是 GPU 虛擬化，但至少帶來 15%的性能損耗，這個是我們沒法接受的

203、。我們大多數的 GPU 服務是使用的各種資源是相對比較固定，所以我們基于算力和顯存去進行了一些策略的調度，其實也就是比較經典的背包問題，同時夜間的話我們也會進行一下預測再重新調度，如果中間出現一些卡的一些故障，我們也會執行轉移相關的策略。當 web 業務的完成容器化改造之后，我們也把一些定時任務遷移到容器的平臺。這時候新的問題又來了，很多任務會涉及到密集的計算，容器本身其實并不是一個隔離的機制，還是 騰訊大規模云原生技術實踐案例集 在做 CPU 時間片的一個分配。這些計算密集的任務多多少少還是會對 web 的任務造成一定的影響。同時它也會占用主機的 IP 資源，node 上的 IP 資源是有限

204、的，定時任務調度上來之后就會分配 IP，任務銷毀時 IP 資源也不會立刻銷毀，如果頻繁的把定時任務的 pod 的調度到主機群的節點上，就會導致主機群的 web 服務沒有足夠的 IP 資源。同時大規模的創建跟回收定時任務，也會觸發一些內核的問題，就比如有些定時任務的內存使用比較大，大規?；厥諘е孪萑雰群藨B，hang 住的時間比較長。這塊我們做的一些改造是這樣的，我們建立了三個池子，serverless、任務集群、主機群，我們優先會把定時任務去調度到 serverless 上，如果調入失敗的話，再依次到任務集群、主集群，serverless 并不是一種完全可靠的計算模式，對于他的使用我們這里引入

205、了一種資源預占的方式，比較類似于金融領域為保證事務的兩階段提交，我們預先去申請相關的資源，當完成預占之后，我們再把真正的把任務調度過去。在離線混部是工程界一個比較經典的課題。在線資源是有明顯的波峰波谷，波谷有大量的剩余計算資源。大數據離線使用了大量的一些資源，但多數的任務對計算的實時性并沒有那么強的要求，說必須在幾分鐘內得到結果，幾個小時跑出來也可以。如果我在在線集群波谷時來跑大數據離線計算，大數據離線的資源就可以節省出來，這樣就可以達到一個雙贏的效果。但是它會面臨很多挑戰，就是其實很難做到資源的完整隔離，在線資源的穩定性、延時都會受到影響。負責在線業務的同學也會有顧慮，就是我沒有得到很大的一

206、個收益，然后還影響了我的業務。在內核增加了新的一個調度器，在 cfs 和 idle 之間，把大數據的任務放到這種放到這類調度器上，然后就實現了 CPU 的避讓。在放量的過程中，我們也整體控制節奏，我們先在夜間在線服務沒什么量的時候來跑離線計算，然后跑相對比較穩定之后，我們再在白天的波谷時間來跑大數據離線。又經過一段時間穩定之后，我們現在其實在晚高峰的時候，也在跑離線任務，只不過是控制在 10%的 CPU 使用以內。使用新硬件，大幅提升單位計算的性價比使用新硬件，大幅提升單位計算的性價比 容器環境下集群底層計算資源使用有限數量的機型，做一些機型更換時減少了業務研發適配的成本，更換效率大幅度提升。

207、實踐價值實踐價值 在多重舉措的合力推動下，作業幫容器化的收益顯著，同樣業務遷移前后，使用了 HPA 和在離線混合部署后，成本下降成本下降 43%43%，穩定性提升到，穩定性提升到 99.995%99.995%，接口響應，接口響應提升提升 10%10%。由此，有效支持了作業幫業務業務的快速迭代，秒級急速擴縮容，服務運的快速迭代，秒級急速擴縮容，服務運行態規范落地和統一的運維環境，多云的環境統一，提升服務可用性行態規范落地和統一的運維環境，多云的環境統一，提升服務可用性。這也便于云間相互自由遷徙，實現單云故障的應急預案，通過優化資源碎片，在離線混合部署，自動擴縮容，整體成本進一步下降。騰訊大規模云

208、原生技術實踐案例集 案例十：案例十：作業幫云原生降本增效實踐之路作業幫云原生降本增效實踐之路 點此閱讀原文 為什么要進行降本增效為什么要進行降本增效 作業幫的技術現狀可以歸納為兩點，分別是規?；蛷碗s化。規?；阂幠；簲登€應用服務，對應數萬個服務實例，運行在數十萬計算核心之上；復雜化：復雜化：技術棧極為豐富，涵蓋多種主流語言。作業幫于 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?？偨Y總結 作業幫基于云原生進行了一系列改造，最終實現了降本增效，整體的降本服務度已達到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、降?？绯遣渴鹁W絡之間質量也較容易波動，導致服務質量抖動等。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 電商業務的本質是，對數據庫應用性能要求較高，必須抗住各種壓力?！庇喑烧嬲f道。在數字化轉型背景下，企業業務的核心是數據，數據驅動業務，數字即服務。而承載所有數據的數據庫，既有事務 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。更安全、更穩定、性能更強更安全、更穩定、性能更強 “數據庫全面上云后，不僅實現了當初規劃的目標，在數據安全性、應用的穩定性以及性能方面，也有更卓越表現?！庇喑烧鎸υ茢祿焐暇€后的效果，給與了高度評價?？偨Y而言，數據庫上云后，獲得了如下效果：全面確保數據安全。全面確保數

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、騰訊云數據庫雙方技術團隊無數次技術架構升級和性能優化，逐步形成高可用、高性能、高安全的計算分析平臺?！耙魳返臉I務場景較多，單一的數據庫架構不能完全滿足業務需求，所以針對不同的音樂的業務場景較多，單一的數據庫架構不能完全滿足業務需求，所以針對不同的業務場景，我們選擇了不同的數據庫架構業務場景，我們選擇了不同的數據庫架構”，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 的能力。騰訊大規模云原生技術實踐案例集