1、1騰訊云技術實踐精選集 20222騰訊云技術實踐精選集 2022【版權聲明】【參與編寫單位及人員】（按拼音首字母）本報告版權屬于騰訊云計算（北京）有限責任公司和 InfoQ 極客傳媒，并受法律保護。轉載、摘編或利用其它方式使用本報告文字或者觀點的，應注明“來源：騰訊云計算（北京）有限責任公司和 InfoQ 極客傳媒”。違反上述聲明者，將追究其相關法律責任。作者內容編輯蔡芳芳付秋偉陳煜東 董嶠術 郭志宏 胡錦前 韓碩江國龍 賈瓅園 林沐 李向輝 呂祥坤潘怡飛 孫勇福 陶松橋 童子龍 王魯俊王濤 王福維 許文強 于華麗 楊鵬程于善游 楊玨吉 楊亞洲 趙軍 張倩曾毅內容指導徐櫻丹內容策劃谷春雨 劉亞
2、瓊 李文芳 熊艷云 趙琪3騰訊云技術實踐精選集 2022卷首語2022 年，數字化轉型成為了全行業關注的焦點，數字經濟的價值進一步凸顯。云計算作為數字時代的關鍵要素之一，正從單一云向多云、混合云戰略過渡；分布式云服務也進入了高速發展的黃金期；隨著 Docker、K8s 等容器技術的流行，云原生正成為云計算的新賽場，也成為企業數字化轉型發展的“默認選項”、新底座；除此之外，人工智能、邊緣計算等技術的普及進一步加速了云計算技術的變革。無論是數字原生行業還是非數字原生行業，云計算在行業數字化解決方案、產業鏈數據流轉、資源動態配置、業務創新等方面正產生著難以估量的價值。對于騰訊的技術團隊來講，2022
3、 年也是一個重要的技術里程碑之年。歷經三年，包括 QQ、微信、王者榮耀、騰訊會議等億級用戶規模的騰訊自研業務已全面上云，集群規模突破 5000 萬核，累計節省成本超 30 億，這使得騰訊打造出國內最大規模的云原生實踐。如何把這些億級業務全部搬到云上并實現云原生改造？騰訊云做了大量的技術優化和革新：比如在容器調度領域，通過混部技術將資源利用率提升到 65%；在數據庫領域，通過存算分離技術，打造了國內第一款云原生 Serverless 數據庫；在安全領域，借助云原生技術本身的可觀測性手段，創新地與安全結合，打造了更貼合云原生技術的專業安全防護能力等等。為此也沉淀了一份 6 萬多字的騰訊大規模云原生
4、技術實踐案例集，包括 10 多個國民級應用的上云實踐，可掃描封底二維碼下載閱讀。除了賦能自研業務外，騰訊云還將上述諸多產品或服務以及配套的基礎軟件、底層技術等開放給百萬級的外部客戶，全部基于公有云模式開發運營，賦能千行百業，也造就了一大批金融、游戲、企業服務、智能制造、教育等場景下的最佳實踐。4騰訊云技術實踐精選集 2022此外，為了解決客戶上云、用云的成本之憂，騰訊云基于內外云原生成本管理最佳實踐，并結合行業優秀案例，提出了一套體系化的云原生上云成本優化方法論和最佳實踐路徑，發布了兩個業界“標準”：云原生最佳實踐路線圖和降本之源 云原生成本管理白皮書，旨在幫助企業改善用云成本，充分發揮云原生
5、的效能和價值。2022 年，是不平凡的一年，感恩來自行業、伙伴、團隊的力量推動著我們勇往直前。在今年，我們參與了 DIVE 2022 北京站、ArchSummit 2022 深圳站、QCon 2022 廣州站、ArchSummit 2022 北京站、ArchSummit 2022 杭州站等多場大會，與 1000+位技術人邂逅并分享心得。此外，這也是騰訊云連續兩年推出騰訊云技術實踐精選集，去年 2021 版精選集共 4 萬多字，全網帶來 7000 多次下載。2022 版的精選集總字數近 10 萬，尤其首次收錄了“騰訊自研業務大規模云原生實踐”系列內容，全面解密騰訊如何錘煉騰訊云。每一次相遇，都難
6、能可貴，每一場交流，都價值滿滿，遂整理成文，共享豐沃。展望 2023，愿與諸君攜手同行，共攀技術新峰！5騰訊云技術實踐精選集 2022目錄CONTENTS騰訊自研業務大規模云原生實踐大數據與云數據庫技術探索及實踐 01 02如何管理超千萬核資源的容器規模50W+小程序開發者背后的數據庫降本增效實踐擁抱云原生，數十萬規模 GPU 卡的利用率極致優化之路TDSQL-PG 數據庫在微信支付的應用實踐將云原生進行到底：騰訊百萬級別容器云平臺實踐揭秘云原生安全可觀測性探索與實踐大規模代碼中引入供應鏈漏洞的分析技術前瞻騰訊云大數據 TBDS 在私有化場景萬節點集群的實踐PB 級數據秒級分析，騰訊云原生湖倉
7、 DLC 架構揭秘CDW PG 大規模在線數倉技術構架分享云原生數據庫管控探索和實踐1.2.3.4.5.6.7.1.2.3.4.08172430384550566573806騰訊云技術實踐精選集 2022云成本優化與研發提效 03企業上云，云上資源整體成本優化管理如何做？企業如何利用云廠商能力構建自己的分布式云？從混部到 Serverless 化，騰訊自研業務的穩定性及云原生成本優化實踐Serverless 時代下，企業微服務的降本思考與實踐騰訊課堂面向協作的 DevOps 流程設計與實踐1.2.3.4.5.1341411491551598693101111126中間件與基礎設施 04Kafk
8、a Stream 的進化探索：流式 Serverless 計算JVMTI Agent 在中間件領域的應用區塊鏈如何支撐 Web 3.0騰訊操作系統的創新之路騰訊明眸媒體處理實踐1.2.3.4.5.166172184190201騰訊云原生數據庫 TDSQL-C 架構探索和實踐金融級分布式數據庫 TDSQL 升級版引擎架構和關鍵技術介紹國產金融級分布式數據庫在金融核心場景的探索實踐騰訊云 MongoDB 智能診斷及性能優化實踐騰訊云數據庫云上 SaaS 生態演進5.6.7.8.9.7騰訊云技術實踐精選集 2022騰訊自研業務大規模云原生實踐018騰訊云技術實踐精選集 2022僅用三年時間，基于騰訊
9、云 TKE 底座，騰訊自研業務容器化規模已達到千萬核級別的 CPU 資源規模。面對如此海量的異構資源和復雜多樣的業務場景，騰訊是如何做到資源利用率 65%的？在調度編排、彈性伸縮、應用管理、穩定性保障等方面，騰訊又有哪些秘籍？在 ArchSummit 2022 全球架構師峰會（深圳站）上，騰訊云自研上云容器平臺負責人王濤發表了題為如何管理超千萬核資源的容器規模的演講，為大家逐一揭秘。騰訊自研業務容器化上云歷程騰訊自研業務容器化上云的技術路線經歷了多個階段。最開始是一個虛擬機只調度一個容器的上云實驗階段，我們叫胖容器階段；再到富容器，一個節點多個 Pod，Pod 中有多進程的階段；然后是單 Po
10、d 單進程的微如何管理超千萬核資源的容器規模王濤 騰訊云自研上云容器平臺負責人騰訊云 TKEx 容器平臺負責人，8 年 K8s 生產經驗，從 0 到 1 建設 TKEx 平臺，全程支持騰訊海量自研業務容器化上云。9騰訊云技術實踐精選集 2022服務容器階段；現在在騰訊內部也有大規模的容器使用 TKE Serverless，再往后為業務提供 FaaS 的能力。整個階段都在夯實混部技術，包括離線混部、在線業務混部。Service Mesh 也得到了一定規模的實踐。上圖是自研上云涉及的相關產品的簡單架構。最底層是 IaaS 騰訊云計算網絡存儲，往上層的基礎服務主要是 Kubernetes、ETCD、
11、Helm，再往上是騰訊云的產品化服務，包括騰訊 TKE 產品、TKE Serverless、Edge、TKE-STACK。TKEx 容器平臺服務騰訊內部業務，內部入口可以直接是容器平臺或者研效平臺。經過三四年的大規模自研業務上云過程，我們已經在各個技術領域沉淀了很多最佳實踐和技術方案組件，諸如容器調度、彈性伸縮、有狀態服務、容器化、資源管理、穩定性提升、業務運維效率提升等都是我們沉淀或重點關注的技術。上云階段不止是把業務容器化上云，更重要的是怎樣衡量上云上得好不好。這里我們有騰訊云原生的成熟度規則來考核騰訊自研業務以及對應的容器平臺做得好不好，主要從四個維度考核，最大的權重維度是資源利用率，指
12、業務容器利用率、平臺資源利用率。還有彈性伸縮能力、容器可調度能力，以及申請的 Pod 資源是不是小核心的資源。從規模與成熟度曲線可以看出，最近兩年時間我們實現了非常大的規模增長，云原生成熟度得分也逼近 90 分。10騰訊云技術實踐精選集 2022各種混部場景下利用率提升方案在線離線混部集群在線離線混部集群是公司面臨的主要混部場景。之所以要做在離線混部，是因為在線業務都會面臨利用率較低、利用率有潮汐分布狀態的狀況。而離線作業很多是碎片型資源，可以容忍一定失敗率，執行時間較短。我們的在離線混部是面向 K8s，設計原則包括通用性，方便未來開放到社區和外部客戶；符合云原生方式；降低對應用依賴；兼容 K
13、8s 和 Hadoop 生態。而我們的目標包括保證在線業務的 SLO，離線作業要在負載利用率高峰期快速上下線，離線作業成功率也有一定保障，保證服務質量前提下盡可能提升資源利用率。騰訊內部在離線混部的技術方案名為 Caelus。它面向業務提供基于業務優先級的定義，接下來就當節點或集群出現負載或者干擾時，可以根據優先級來 驅逐 或抑制，對于不可壓縮資源只能驅逐到負載較低的集群。高優的離線作業不會直接 Kill，而是降低容器的配置。方案最核心的是節點上 Caelus 的組件，主要做干擾檢測數據的采集、分析，再決策做離線抑制還是調度。Caelus 的主要流程包括：數據指標的采集，包括來自于業務監控系統
14、的業務自定指標。采集到的指標統一存儲在對應的 Store 組件，再從 Store 拉取指標做在線資源的業務預測、離線業務的健康檢測。如果出現資源超發或高負載情況會做對應的抑制或者驅逐。11騰訊云技術實踐精選集 2022 這里提供本地預測和中心式預測兩種方式，中心預測主要通過 descheduler 的方式，先采集分析得到全維度的應用負載，做驅逐時考慮工作負載是不是做了多副本、對應的服務是否做了動態路由接入等，重調度時去衡量這些工作負載的配置，確保業務的服務質量。更重要的是本地干擾檢測和快速驅逐的能力，因為這里只關注節點本身的資源使用情況，能做出更快的離線業務的驅逐避讓。干擾檢測的指標一部分來自
15、于應用注冊的業務自定義指標，還有一部分來自平臺自身獲取的操作系統、節點提供的指標。處理的方式一種是直接把離線的 Kill 掉，一種是直接做限流操作。驅逐時一定要考慮業務的優先級以及業務有沒有做多副本、高可用，考慮是不是已做過容災措施。根據監控數據，我們的在離線混部的集群節點負載已經到了將近 70%的資源利用率。在線混部集群騰訊也有一些集群只能部署在線業務。這種集群要提升資源利用率會涉及不一樣的技術挑戰。全部是在線業務，意味著無法定義每個任務或者業務的優先級，每個業務的優先級都是一樣的。那么首先要做超賣、動態 Pod 的資源壓縮。在線業務混部意味著集群的負載、節點的負載可能出現分布不均勻的情況，
16、所以要解決集群節點負載均衡的問題。高負載時要及時、快速擴容資源，所以要提供極速的集群伸縮能力。12騰訊云技術實踐精選集 2022還有一個關鍵動作是，平臺或者容器的資源總是有限的，一定要有面向應用的業務配額動態管理。彈性伸縮這一層，我們自己做的方案叫做二級彈性資源池能力。第一層，平臺會把各地域閑置的 CVM 放在閑置緊急 Buffer 資源池里，可以秒級地從節點把 CVM 加入集群里，實現集群秒級擴容。這里的關鍵是節點所有初始化流程、標準化建設都已經準備就緒，可以輕松應對集群負載突發情況。第二層就是去騰訊云申請 CVM，CVM 要做初始化流程，這一層彈性能力是分鐘級的。當緊急 Buffer 池沒
17、有資源時才能找騰訊云接口創建對應的資源加到集群里。面向業務的彈性伸縮，我們把 K8s 的 HPA Controller 剝離出來，自己做了 HPAPlus Controller。因為我們的應用規模非常大，一個集群里可能有幾萬個 Workload，意味著幾萬個 HPA。我們自研的 HPAPlus-Controller 做了足夠的性能優化，以支持如此單集群的 HPA 性能。HPA 這里，我們還做了動態調整 HPA 最大副本數的特性。業務配的最大副本數通常是一個很主觀的不可信的值，當業務 HPA 達到 maxReplicas 后仍然有持續擴容的趨勢，HPAPlus 會提供 更大彈性 Buffer 能
18、力給業務，maxReplcas 能動態的自增長，還會發告警讓業務趕快判斷是否正常。這種 HPA 行為，我們會預留業務一定時間處理超出預期的業務流量，當然也有機制去限制 maxReplicas 的無限制自增長。我們還有 HPA 和 CronHPA 的聯動決策，支持業務計劃內的定時擴容，即便實際流量超過預估流量也能自動擴容。另外 VPAPlus-Controller 是用來支持有狀態服務無感知垂直擴縮容場景，而不需要重建 Pod。我們的動態調度器是解決節點負載不均衡的問題。它會根據負載給節點打分，讓節點關鍵資源在集群節點中均衡分布。我們還有自研的熱點動態補償算法，避免調度熱點問題，控制好節點的 單
19、位時間 Pod 裝箱數量。我們的在線業務混部利用率提升方案，讓集群 CPU 平均利用率提升到 30-40%的水平。在使用動態調度器之前節點負載是不均衡的，上線動態調度器后負載相對比較均勻。我們的在離線混部、在線混部方案最后都通過 Crane 對外開源了全套技術。13騰訊云技術實踐精選集 2022穩定性面臨的挑戰及其破解之法負載上升之后會面臨很多穩定性問題，我們主要關注平臺層、集群層、節點層以及業務層的穩定性。14騰訊云技術實踐精選集 2022平臺和集群穩定性層面有兩個實踐案例。第一是監控，要提升穩定性一定要有全面的監控體系。我們通過 Prometheus+Thanos+Kvass 方案，提供高
20、可用部署以及 Prometheus 的橫向擴縮容能力。我們集群規模往往很大，每個集群組件很多，意味著配置項非常多。為了對每個集群的所有組件配置做好統一，確保每個集群都是標準的，不能因為某個組件沒配對導致行為不一致，就需要做一些組件標準化的監控。我們研發了組件探測能力，可以看到每個組件版本是否統一，是否在做組件灰度發布，幾百個集群中哪些組件出現了異常，都可以通過監控實時獲取。節點穩定性是 K8s 生產環境遇到最多的問題，這里也舉幾個例子。第一個例子是針對一些節點上的核心組件、內核狀態做對應的指標監控、節點自愈。我們基于 NPD 組件擴展了指標，通過這個組件對節點穩定性做監控，用對應的決策樹做自愈
21、。這個組件也在騰訊云 TKE 組件里。節點規模大了之后會遇到各種各樣的內核問題，要升級內核或者打補丁時，必須要跟蹤好每個補丁是不是正常打好，對應的內核版本是不是我們當前的基線版本內核，這都需要監控、標準化和自動化。比如某些節點少打了一些補丁，我們需要自動把遺漏的補丁打上。業務穩定性方面，我們在內核層面做了很多工作，業務出現穩定性問題要看 Pod 對應內核指標是不是有異常，如果出現異常要快速調度。同一節點上的 Pods 共用內核、資源搶占的問題層出不窮，最終還是依靠演進到 Serverless K8s（TKE Serverless）這個容器產品，能夠給 Pod 做到虛擬機級別的隔離能力，最終徹底
22、解決這一類穩定性問題。從面向集群到面向應用的調度編排前兩三年大家更多關注的是怎樣面向用戶提供 K8s 的能力。接下來要重點解決的是從面向集群到面向應用的調度編排問題。這意味著用戶不用再關注集群，不用關注底層資源，只需關注應用本身。有一個例子，一個業務全網有一萬個工作負載，有五萬個 Pod，分布在全球十七個地域，八十多個集群。如果我要對這個業務做一次全網變更，按照以前面向集群的方式效率非常低。所以要抽象出面向應用的能力，首先是跨集群應用的統一變更，要有一個統一的看板跟蹤發布是否正常。業務部署后還要能從視圖看到部署15騰訊云技術實踐精選集 2022的容災是不是合理的，所以要有多地域的容災檢測。所有
23、這些能力我們都是基于騰訊云的 Clusternet 開源項目來建設。Clusternet 有 2 個極其重要的多集群能力，一個是動態拆分調度，主要根據集群容量、位置拓撲來做決策。比如用戶要求兩地三中心，接下來在兩地三中心選集群，每個集群容量不一致時要根據容量做評估。另一個是多集群協同彈性伸縮。多集群 HPA Coordinator Controller 做多集群 HPA 協同 的事情，可以根據集群容量、集群的可用性做 HPA 協同，保證業務擴容時不會因為某一個集群的資源不足擴不出來，自動調度到其他可用集群。騰訊在大規模資源上云過程中沉淀了這么多技術能力，服務了大量業務場景，包括音視頻、游戲、電
24、子商務、社交、辦公協同、出行等，我們正在做的是把這里積累的各種業務場景的最佳實踐，都輸出到云原生應用管理平臺這個公有云產品中，比如應用的標準化檢測、業務的 QoS 定義、應用多集群灰度發布、應用多集群自愈等等，最終將容器平臺上升到應用管理維度，同時服務騰訊內部和外部客戶。16騰訊云技術實踐精選集 2022掃碼獲取完整版演講 PPT17騰訊云技術實踐精選集 202250W+小程序開發者背后的數據庫降本增效實踐楊玨吉 騰訊云高級工程師 TDSQL-C Serverless 研發負責人擁有多年云數據庫研發經驗，負責設計和研發 TDSQL-C Serverless 產品形態。作為國內第一款云原生 Se
25、rverless 數據庫，TDSQL-C 目前僅在微信生態上就為超過 50W 小程序開發者提供數據庫底座，憑借按量計費、超強彈性、存算分離等特性，能有效降低用戶的數據庫使用成本。騰訊云 TDSQL-C 這款云原生數據庫相比于傳統數據庫有哪些技術突破？在場景實踐過程中遇到過哪些問題？又是如何解決的呢？在 ArchSummit 2022 全球架構師峰會（深圳站）上，騰訊云 TDSQL-C Serverless 研發負責人楊玨吉發表了50W+小程序開發者背后的數據庫降本增效實踐的主題分享，圍繞 TDSQL-C 在關鍵技術的多維突破、在實踐應用中遇到的挑戰及解決方案，以及在內外部用戶業務上云過程中的典
26、型應用場景及收益等問題給出了解答。18騰訊云技術實踐精選集 2022TDSQL-C Serverless的技術實現與自研業務實踐TDSQL-C Serverless 是騰訊自研的云原生數據庫。TDSQL-C Serverless 的特色是能夠讓企業像使用水、電、煤一樣使用云數據庫的服務。用戶不需要為閑置的數據庫而付費，用多少算多少。這項技術在很多業務場景下都能幫助企業極大的節省成本。TDSQL-C Serverless 的技術實現傳統云數據庫并沒有實現自動擴縮容、按使用量計費、無使用無費用。這就導致哪怕我只用了 10%的計算資源，另外 90%的閑置計算資源也無法分配給其他用戶，還需要為此而付費
27、。存儲資源也一樣，基于這種存儲跟計算綁定的架構，用戶需要提前購買好對應 CPU 和內存的數據庫，而且買完后就算沒用也需要因此而付費。而 TDSQL-C Serverless 做了計算、存儲分離。下面是存儲層，存儲層如果不夠，我們可以通過加機器、加存儲的方式實現水平擴展；上面是計算層，如果計算資源不夠，也可以按自己的需要去動態擴容，而且不用在意存儲層是不是滿了。計算和存儲分離后的每一部分資源都可以按照自己的需求去做分配。我舉個例子，現在我們面前有兩個房子，一個是兩房沒有客廳；另一個是兩房一廳，客廳里有個電視可以方便我們一起玩游戲，因此每個月要多花 2000 元。但問題在于我也不是每天打游戲，只有
28、周末才有時間打。這就是現實里經常碰到的兩難問題。如果這時候有個傳送門，我可以直接從房間里傳送到一個客廳里，一小時收費 10 塊，是不是這個問題就解決了？如果我兩房旁邊就有一個游戲廳呢？這個游戲廳是不是也能解決我的問題？這樣我就不用去解決傳送門的問題了。實際上很難，如果這個游戲廳只為你服務，它遲早倒閉。物理位置的限制，讓它沒辦法服務更多人。所以本質上，它要么服務人群足夠多，要么就是單價很貴。在現實里，如果游戲廳就在你房間旁邊，你房租的價格也會比其他地方的更貴。計算跟存儲分離，就是讓房子和客廳解耦。只要解決傳送問題（自動擴縮容）就可以讓這個房間的成本回歸到它本身的價值。雖然傳送門在物理上不存在，但
29、我們 TDSQL-C Serverless 做了一個傳送門，也就是計算存儲分離架構，讓所有的計算節點和所有的物理層，所有存儲層能夠相互進行訪問。TDSQL-C 在騰訊內部有比較多的應用場景，這里選取了兩個比較典型的例子跟他大家聊聊：19騰訊云技術實踐精選集 2022TDSQL-C 在微信小程序的應用開發微信小程序面臨的問題：云服務成本高。云服務器雖然方便，但價格并不便宜，目前常見的服務器有兩種按時付費和包年包月，按時付費價格有點高，包年包月不靈活；資源利用率低。根據數據來看，大部分小程序的用戶規模小，數據庫的資源使用率很低，而且大多數在活動期間會高一點，活動結束后，資源就用不上了；后端配置復雜
30、。云產品為了使用的通用性，配置會非常多，企業需要花很長時間去學習，去配置，運維成本很大?；谝陨系膯栴}，微信和騰訊云一起推出了微信云托管服務。簡化小程序開發運維的流程。開箱即用，按使用收費，不使用不收費。能極大減少開發者的成本。在實現整個架構的時候，騰訊云托管遇到了數據庫選擇的問題。原先選擇云托管后端自行分庫，所有的小程序都訪問同一個數據庫，通過不同庫來隔離。這種方案的隔離性很差，安全性也很差；后來選擇了 TDSQL-C 的方案來解決，每個小程序都有了自己獨立完整的 TDSQL-C 數據庫實例。TDSQL-C 在騰訊樂享的應用騰訊樂享是騰訊內部的論壇、文檔等，已經服務騰訊員工 10 多年了。下
31、圖是騰訊樂享的架構圖。20騰訊云技術實踐精選集 2022不同員工通過外部應用防火墻到 CLB，然后進入到騰訊樂享的業務邏輯層。這是一個典型的 SaaS 服務架構。因為要面對不同的企業用戶，所以在數據上要做隔離。同時，很多 ToB 企業用戶很少，所以并不會頻繁使用這個數據庫，導致它的整個負載比較低。經過幾次成本優化之后，騰訊樂享就會把很多負載低的客戶合并到一個數據庫實例里，也就變成了前面微信云托管那樣一個架構了。同樣，它也會面臨云服務器資源浪費的情況。最后，還是使用了 TDSQL-C 來代替原來的云上數據庫。TDSQL-C Serverless 數據庫最大的優勢是計費跟負載是強相關的，負載高計費
32、就高，負載低計費就低。替換后，騰訊樂享這邊測算數據庫的成本降低了 80%。TDSQL-C Serverless 數據庫特點及其他場景應用實踐TDSQL-C Serverless 數據庫的三大特點是：自動擴縮容、按使用量計費、無使用無費用。我們希望你想要請求的時候，這個水資源能像瀑布一樣傾瀉而下，不需要業務提前感知。希望云服務能像使用水資源一樣精準，你的賬單一定是來自你所使用的 CPU 和內存資源。如果你不使用，就像關上的水龍頭，不收費。常見的自動擴縮容業務場景1.慢查詢。我們大部分業務都有慢查詢，比如執行一個不帶索引的 SQL；或者你有一個多表查詢的場景；又或者前端有運營同學在做數據分析，慢查
33、詢會引發一個比較高的 CPU 負載，但如果我們買一個大的規格，21騰訊云技術實踐精選集 2022就需要承擔比較高的成本，如果買一個小的規格，那么可能會因為這些慢查詢而影響到在線服務。2.活動場景。在活動期間會有一個比較高的負載，但活動過去之后，負載就會降低。同樣如果我們買一個大的規格，就需要承擔比較高的成本，如果買一個小的規格，那么就支撐不了活動的使用了。當然你也可以選擇在活動前擴容，活動后縮容。但這總的也不方便，而且并不是所有的活動都有足夠的時間去規劃。所以這時候就需要一個自動擴縮容的能力。3.定時任務。很多業務都會有定時任務的需求。比如在夜間去計算一下當天業務數據的情況匯總為一個報表?；蛘?/p>
34、是用戶的一個賬單。那么在這個任務執行的時候會有一個比較高的負載。雖然你也可以根據計劃去手動擴縮容。但有些計劃使用的計算資源不可控，時間也不可控。少了速度慢，可能還會影響到線上業務，多了又會浪費。TDSQL-C Serverless 自動擴縮容技術業內常見擴容方案如下圖：第一步是低負載的情況，CPU 使用了 0.1 核，Buffer pool 使用了 1G，其他內存 100M。第二步，用戶來負載了，也就是高負載觸發擴容前，CPU 分配了 1 核其他內存 500M。然后第三步高負載觸發擴容后，CPU 使用 1.8 核，Buffer pool 2G，其他內存 500M。22騰訊云技術實踐精選集 20
35、22但這能滿足用戶的需求嗎？實際上并不能。因為從第二步到第三步得有個持續監控發現它高負載了，發現它超過了閾值，才會自動擴容。比如 5 分鐘高負載才擴容。而且它還是階梯式的，比如我規格最小 1 核，最大 16 核，如果是階梯式擴容，而我一開始就需要 16 核，你得反應 4 次才能擴容到 16 核，等擴容完成的時候，活動都已經結束了。再比如有些報表一兩分鐘就計算完了，擴容都來不及觸發。所以這個擴容根本就不能滿足業務的需求。我們之前也想過，想辦法把 5 分鐘擴容縮短成十秒甚至更低。但后來我們決定不這樣做。我們干脆直接把規格放到最大，也就是如果最大規格是 2 核 4G，我們就直接放大到 2 核 4G。
36、用戶可以一開始就使用 1.8 核，然后我們在持續監控這個 CPU 的高負載的情況下，對內存進行一個自動擴容。常見的業務場景計費模式1.近似計費。這種計費方式其實對用戶很不友好。比如說，我只有了 0.6 核，但是確要為 1 核付費。如果我控制不好，超出一點，用了 1.1 核就需要為 2 核付費。2.小規格實例?，F在其實有很多小數據服務，它的負載是低于 1 核的。但市面上大部分數據庫，提供的最小規格就是 1 核?，F在市面上有很對微服務，它對應的數據庫也是非常小的。TDSQL-C 的計費模式我們每 5 秒進行一次資源使用采樣，計算單位為：CCU（TDSQL-C Compute Unit）=max(C
37、PU,MEM/2,最小規格)。按實時的 CCU 進行計費。為了保證按使用計費，我們做了一個算法，能夠保證按照你使用的資源來進行計算，賬單也會體現你的資源每一時刻的使用。23騰訊云技術實踐精選集 2022常見的無使用不收費的場景1.歸檔數據庫。比如，在發論文的時候，有很多訓練數據需要存儲，這時候會需要去訪問這個數據庫，去取里面的訓練數據做實驗。這時候 CPU 會使用比較多，但我發完論文后，就基本不需要使用數據庫了，這就是歸檔數據庫的場景。2.低頻訪問的業務。像個人博客、垂直論壇、微信小程序等低頻訪問的場景。如果它每天的請求就十幾二十次，我們還按 0.25 核去進行收費是不太合適的。3.開發測試環
38、境。大多數只在工作日的白天才會用，周末和晚上基本不用。這種情況完全可以在不使用的時候把數據庫關掉。TDSQL-C 是如何實現不使用不收費的用戶通過接入層訪問我們的計算層，計算層通過存儲層取數據返回給用戶。管控平臺監控計算層和存儲層的資源消耗，包括 CPU、內存以及存儲量進行計費。如果持續十分鐘沒有任何請求，我們就會通過管控層進行計算層的資源回收。而當新的 SQL 來了后，我們接入層能夠感知并通知管控平臺進行恢復，又會開始資源的計算。這里面有一個很重要的指標就是從暫停到再一次啟動的時間。我們花了很多時間來優化這個冷啟動的時間。目前大概還需要 2 秒，我們未來計劃做到 1 秒內。未來展望我們希望把
39、數據庫服務做成一個跟水資源一樣的。讓初創企業用這個水資源去灌溉自己的農田。目前我們做到了一些，未來我們還有更多可以去做。如果說中小企業是一片片沿溪而耕的農田，那么我們 TDSQL-C Serverless 的愿景就是建一座大壩來管理好上游的水資源，用來灌溉下游企業。掃碼獲取完整版演講 PPT24騰訊云技術實踐精選集 2022擁抱云原生，數十萬規模 GPU 卡的利用率極致優化之路陳煜東 騰訊云異構計算、THPC 研發負責人騰訊云異構計算、THPC 研發負責人。2014 年加入騰訊，現負責騰訊云異構計算、裸金屬高性能集群等相關研發工作，具有多年的分布式資源調度、大規模集群調度理論與實踐經驗。在科技
40、和產業進入人工智能和全真互聯時代的大背景下，GPU 作為通用的算力加速引擎，業界最強的單加速器算力已經突破 1Pflops。如何配置高性價比的 GPU 彈性容器實例，并進行多任務共享 GPU，充分利用 GPU 算力資源，成為業界共同探索和努力的方向。在騰訊自研業務全面上云和云原生實踐的過程中，面對算力挑戰，騰訊除了配置極致性價比的 GPU 彈性容器實例外，也探索了在云原生架構下進行容器級別的 GPU 共享，從而在千萬級并發下對業務進行加速，幫助自研業務實現降本增效。在 ArchSummit 2022 全球架構師峰會（深圳站）上，騰訊云異構計算負責人陳煜東發表了題為擁抱云原生，數十萬規模 GPU
41、 卡的利用率極致優化之路的演講，為大家解密騰訊自研業務上云和云原生實踐背后的 GPU 優化技術及實踐。自研 GPU 業務上云歷程傳統業務上云時，業務部門總會有很多疑慮，主要擔憂集中在上云后業務的穩定性、靈活性、成本、監控完善度和部署難易度上。25騰訊云技術實踐精選集 2022騰訊內部自研 GPU 業務上云的歷程始于 2018 年。早期是一些小規模業務上云，2019 年開始云端達到數千張卡的規模，2020 年隨著云游戲業務的發展云端達到了數萬張卡規模。直到 2021 年，qGPU、Taco 訓練加速和容器實例混部成為上云需求主力，云端規模達到數十萬張卡級別。qGPU 共享技術：如何實現容器級細粒
42、度算力切分騰訊音樂和廣告業務都會用到在線推理能力，之前使用虛擬機的彈性容器實例，基于 vGPU 虛擬化技術實現。但 vGPU 技術切割不靈活，只能將整卡資源切分成一到四份，沒有辦法切成更小粒度，而一些業務的算力需求比較低，所以需要做整合，就有了顯存和算力強隔離的要求。多業務混合部署需求也是必須滿足的，才能讓業務有上云的動力。另外 vGPU 技術只有 Nvidia 的高端 GPU 才能支持，這也是一個不足。Nvidia 的 vGPU 是虛擬機固定比例資源切分，在容器場景沒有直接適配，粒度受限，且需要許可證管理，運維成本較高。業界對 GPU 共享方案的探索也有很多，一條路徑是按 GPU 核心做物理
43、切分，另一條是按時間切分。但前者需求底層硬件技術能力，所以只有原廠可以做，那么其他廠商的思路都專注在了時間切分。騰訊的 qGPU 方案也是時間片切分方式，針對的是 CUDA 和 Nvidia 專有 API 層。騰訊做的是算力隔離和共享方案。26騰訊云技術實踐精選集 2022騰訊 qGPU 的架構主要有兩個組件，首先是上圖中第二行綠色的 GPU manager，其次是中間內核 qGPU 模塊。從設備管理角度來看，從下往上看，最底層是一排 GPU 卡，紫色是 GPU 驅動。qGPU 要做的事情在于，如果有兩個 Pod，需要用 40%的時間片和 5G 顯存分配好，qGPU 就會打開 GPU 的設備，
44、再生成兩個設備，一個是/dev/qgpu0 及其配套的/dev/qgpuctl0，一個是/dev/qgpu1 及其配套的/dev/qgpuctl1。Pod 起來的時候會告訴底層 qGPU，這邊需要一個 GPU 設備，就把 qGPU 設備暴露在 Pod 里。底下 KMD 是 Nvidia 專有的一層，以為上層操作過來的是 UMB 的驅動，其實是 qGPU 模擬出來的設備。qGPU 在這當中做了一個通信中介，UMD 和 KMD 通過中介來交流，我們通過這個方法來做顯存隔離。對于算力隔離需求，只要上層有業務數據過來，就找到對應的硬件資源，準備好之后就走 Linux 的內核模塊直接對硬件設備做操作。C
45、UDA 需要申請資源的時候，我們要控制模塊幫它分配好內存資源，告訴底層設備把對應的控制信息提前分配好，再把內存之間的數據對好即可。qGPU 這一層可以通過攔截一些庫，幫助識別具體的任務，為此我們做了策略調度模型。qGPU 調度策略有兩個功能，一是 Spread，平均分配，保證負載穩定均衡；二是 Binpack，盡量填滿保證利用率。我們在單卡做的策略調度有三種模式，第一種是 Best Effort，有 N 個 Pod，每個 Pod 給 1/N 資源。第二種是 Fixed Share 固定配額，實現算力的精確隔離。第三種是突發型的 Burst Share，在基礎配額基礎之上把空閑資源拿出來動態配置
46、。對于第一種 Best Effort 模式，我們推薦負載較低的在線場景使用，即便多個業務高峰期來了，負載還沒辦法把整個 GPU 打滿。有些業務對處理時延敏感，最好使用第二、第三種，保證固定配額的調度模式。再看離線混部場景。離線混部場景下業務往往自己知道自己的優先級，會提前標注好。這時高優先級任務會平均分配保證負載均衡，低優先級任務會盡量填滿來保證資源利用率。這里還支持在線 100%搶占。算力平臺上有很多離線任務之前用單塔模式做訓練或推理，它們的業務沒有太多共享，所以上云之后把這種離線任務的 Pod 和在線任務的 Pod 做整合，填在一起。騰訊 qGPU 也是業內唯一的 GPU 在離線混部技術。
47、實測來看，qGPU 的效率損失非常小，QoS 效果比較穩定，延遲也沒有忽高忽低的情況。27騰訊云技術實踐精選集 2022基于 Taco 的異構計算加速實踐之前我們發現廣告場景做分布式訓練時出現了性能不升反降的情況。我們之前的業務都是用 A100 運行，但我們發現設備加了一倍之后性能反而下降。分析這里面的原因發現，整個 GPU 的數據通信過程被算法變成了一個環型結構，假設有 5 張卡，5 張卡首尾依次互連，然后每個卡都有對方卡的數據，算完還要再算四輪，做數據的交換處理。如果這些卡走跨機網絡通信就會受限于 PCIE 的帶寬甚至網卡帶寬。為了解決網絡通信問題，我們主要圍繞上圖中藍色的兩個層面來做優化
48、，分別推出 LightCC 算法方案和 HARP 協議方案。LightCC 改進了原有算法，先在單機的多卡之間用 NVLink 做數據通信，內部算完的結果再和其他機器做通信，盡量減少跨機之間通信的數據量。并且所有卡都在同時跨機收發數據，這樣能提升帶寬利用率。上云過程中需要復用云上的 GPU 資源，這些 GPU 資源有很多還是沒有對應配套 RDMA 網絡的，為此我們做了 HARP 協議。傳統數據通信走內核 Socket API，這里還有內存拷貝，效率比較低。我們 HARP 協議棧用 DPDK 做了一個框架，不走傳統內核協議棧，減少了內存拷貝。特別是每個 GPU 服務器會配套 8 個彈性網卡，GP
49、U 會跟彈性網卡去做一對一綁定，讓它獨享彈性網卡資源，避免大家都在共享網卡，出現 QoS 問題。28騰訊云技術實踐精選集 2022測試效果來看，A100 GPU，16 卡情況下，用開源方案性能會下降，用了 LightCC 和 HARP，性能還是得到了明顯提升。容器實例的 GPU 混部方案為了降低成本，業務端出現了兩個問題。第一是業務需要的 CPU 和內存資源無法按照 GPU 等比例切分，第二是業務后端無法定制多種規格的物理機。直接的應對思路就是將空閑資源與 CPU 彈性容器實例混部，但也帶來兩個問題，一個是頻繁的彈性伸縮，碎片資源不知如何高效利用；另一個是資源的遷入與遷出如何設定。上圖是我們的
50、遷移策略。遷移時會把待遷數據構建出來，也就是最右邊的橙色結構。目的端的宿主機也構建出來，構建成一個最小規格的數據結構。遷移的動作開始時，還是從容器實例最大規格來填，填充好后面就沒有產生多余的碎片，按這個排序找最小的規格可以滿足的宿主機去遷；小規格實例填充碎片即可。遷出策略和遷入相反，如果 GPU 的容器實例已被退出，我們去看對應的庫存 Buffer 量，是不是 GPU 資源已經不夠了，或者要補充庫存的，我們就會把 CPU 資源遷出來，保證一定的 Buffer 空間。外遷和遷入的動作一樣，不用考慮規格問題，因為遷移進來的實例已經被過濾一道了。29騰訊云技術實踐精選集 2022收益來看，混部方案可
51、以把空閑 CPU 利用起來，宿主機浪費成本縮減 70%，使用率提升 53%。這里沒有做到 100%，因為我們還要給 GPU 資源做預留，避免 GPU 實例過來發現沒有資源?？偨Y 通過在 GPU、UMD、KMD 之間增加一層，實現更靈活的算力、顯存切分調度；通過減少跨機數據通信與優化協議棧耗時，提升分布式訓練效率；彈性容器實例通過資源混部與動態遷移能力，提供能靈活的規格，降低成本。掃碼獲取完整版演講 PPT30騰訊云技術實踐精選集 2022TDSQL-PG 數據庫在微信支付的應用實踐胡錦前騰訊云數據庫資深架構師TDSQL-PG 系統架構設計師。主導過多個 TDSQL-PG 應用項目，包括騰訊內部
52、微信支付、AMS、互娛數倉、騰訊指數等業務，對外覆蓋了保險、稅務、公安、消防、政務在線、物聯網等行業，對于 TDSQL-PG 分布式數據庫應用系統設計、開發、性能調優及多中心多活應用實踐方面，擁有豐富的經驗。幾年前，微信數據量爆發式增長的同時，微信支付商戶服務、報表 BI、倉庫維表系統卻受制于存儲和性能無法擴展、業務拆分難度大等瓶頸。在這一背景下，TDSQL-PG 開始了在微信支付業務場景的應用落地探索。為了解決微信支付業務場景的痛點問題，TDSQL-PG 在實踐過程中也沉淀了一些技術創新方案。QCon 2022 廣州站上，騰訊云數據庫資深架構師胡錦前帶來題為TDSQL-PG 數據庫在微信支付
53、的應用實踐的演講，詳細講解 TDSQL-PG 在微信支付的應用實踐歷程，以及針對微信支付業務不同的痛點，TDSQL-PG 的解決思路與經驗總結。TDSQL-PG 在微信支付上的使用背景2016 年微信支付日均交易規模超過十億，數據量爆發式增長。彼時，微信支付的商戶平臺在數據存儲、查詢等方面無法滿足數據業務增長的需求，因此具備海量存儲和高查詢能力的 PGXZ 數據庫開始在微信支付31騰訊云技術實踐精選集 2022TDSQL-PG 在微信支付上的主要應用場景微信支付商戶平臺應用場景。微信支付商戶平臺是廣大微信商戶的查詢系統，提供賬單明細下載及賬單單據復雜條件的查詢等能力。在遷移到 TDSQL-PG
54、 之前，商戶平臺采用傳統 MySQL 分庫分表模式來提供服務，但遇到了分庫分表模式的單機存儲無法滿足業務增長需求、交易量大的商戶查詢性能不足、MySQL 無法提供存儲分離及自動搬遷能力、MySQL 難以滿足按時間分區剪枝的需求等問題。TDSQL-PG 解決上述問題的方法是：TDSQL-PG 能支持按照商戶號來拆分，將不同的商戶數據存儲到不同的節點，對外屏蔽內部的分布細節；對于數據大商戶的數據存儲采用雙 KEY 方式存儲，把數據均衡打散。TDSQL-PG 具備原生的索引調優等手段，有 Btree 索引、表達式索引等，同時也有 Index Only Scan 的算法，針對性調優可以滿足需求。TDS
55、QL-PG 集群支持 Node Group 概念，可以支持不同時數據按照不同 Group 存儲，支撐冷熱數據自動搬遷，大幅降低成本。TDSQL-PG 自研分區表，有效做到分區的隔離消除，通過分區+索引組合大幅提升查詢性能。報表系統微信支付 BI 報表是非常強大的系統，但之前的 MySQL 版本也遇到了空間存儲受限、擴容數據遷移成本高、批量寫和實時寫時延要求高、跨周期的數據統計分析性低、索引類型相對有限等問題。對此 TDSQL-PG 的解決方案如下：BI 通過 Spark 離線接入 MySQL 的寫入量可大可小，另一種是實時寫入，實時計算結果通過消息隊列寫到數據庫里。這兩種寫入需求都通過 TDS
56、QL-PG 的并行寫入、拷貝入庫的方式提供很好的支撐。讀取方面則通過模糊查詢、精確匹配、下推并行優化、讀寫分離等措施增強，使 BI 報表、數據開放服務的查詢能力有了較大提升。TDSQL-PG 已經全部接管 BI 報表的存儲查詢功能，大表打開時間在 3 秒以內。商戶平臺落地。2019 年，隨著 PGXZ 不斷自我完善，并行寫入及復雜條件查詢能力不斷突破，PGXZ 發展成 TDSQL-PG，微信支付的 BI 報表系統也全面從 MySQL 切換到 TDSQL-PG 數據庫。2021 年，在多年應用實踐的基礎上，騰訊發現 PGXZ 能夠打通數據倉庫與在線業務，于是把微信支付的倉庫維表系統全部都切換到
57、TDSQL-PG 上。32騰訊云技術實踐精選集 2022維表系統維表維度是觀察事物的角度。開發過程中的枚舉值也是維表，維表系統需要管理大量枚舉值。切換到 TDSQL-PG 前，維表上下游之間的處理缺乏一致性視圖，維表管理難以維護。而 TDSQL-PG 為 OLTP 與 OLAP 架設了橋梁，解決大數據瓶頸的維表管理問題。在線業務與大數據的報表平臺中，通過 TDSQL-PG 能夠關聯維表，并且支持實時更新、修改及刪除，還能實現上下游維表值的距離查看，不需要一層層傳遞。TDSQL-PG 在微信支付上的應用實踐雙 KEY 分布TDSQL-PG 對數據傾斜的處理采用雙 KEY 分布。我們有 Defau
58、lt Shard Group 和 Big Shard Group 兩個組，Default Shard Group 直接用商戶哈希來計算 Shardid ID，通過商戶直接下推到數據節點。大商戶用特殊分布邏輯，通過商戶 ID、Merchantid 加分片鍵的偏移量來做 Shardid ID 的路由計算。這種處理方式能實現大商戶在 Group 均勻存放，有效解決數據不均衡問題。下推查詢33騰訊云技術實踐精選集 2022這里計算節點能夠把排序下推到數據節點，數據節點通過 Merge Append 歸并各個子表的結果，子表上面的結果是有序的，走 lndex Scan 掃描出來，通過 Merge App
59、end 的子表的結果來做 DN 數據節點的高效掃描。數據推下來，所有 DN 并行運行。同樣計算節點也會對所有 DN 做歸并計算，從而保證有序性、正確性，并且保證數據計算下推并行執行。自研分區表34騰訊云技術實踐精選集 2022自研分區表的結構如圖所示，計算節點負責縱向分表，不感知分表邏輯，看到的數據節點上就是一張邏輯表。也就是說計算節點并不知道一張表有沒有做分區。數據節點具體實現橫向分表，根據分表將一張邏輯表劃分了物理表，這就是承載分區表的實現邏輯。自研分區表可以有效做到物理的掃描隔離、數據后續清理和治理的優化。并行優化我們現有的系統中，大 CPU、大內存是標配。為了有效利用這些資源提升查詢能
60、力，這里我們對于相關算子做了并行優化。35騰訊云技術實踐精選集 2022冷熱分離如圖所示，每一個 Group 的熱數據和冷數據都是不同的 Group 組。我們按天來分區，每一張表在冷數據跟熱數據都有一張物理表，數據寫入到熱數據部分，對應的冷數據這個時候是空的，冷熱數據轉化閾值是集群公共值，可以自定義。當冷數據達到閾值的時候，后臺會自動搬遷熱數據，這個過程對用戶來說完全無感知。因為冷數據存儲成本較低，因此總體成本大幅下降。讀寫分離TDSQL-PG 支持傳統的 Proxy 讀寫分離方案，可以對不同訪問轉發不同的讀寫平面來實現讀寫隔離。多個平面可以容災、實現均衡負載，降低組的負載壓力。但很多情況下開
61、發框架會帶來一些顯性失誤。在這種情況下，傳統的 Proxy 沒有辦法做到自動讀寫分離。而我們在 CN 的計算節點具備了自動讀寫分離功能，能夠實現一個賬號連通一個 IP，自動識別讀寫，將讀請求轉發到讀平面，寫請求轉發到寫平面。36騰訊云技術實踐精選集 2022TDSQL-PG 在微信支付上的使用效果特性總結 海量存儲，單表輕松突破 TB，快速擴容。數據治理能夠實現冷熱分離、靈活分區、數據訪問能力、數據多方位管理。事務支持，具備數據 upinsert 場景，全局多平面事務都有效保證事務一致性。高吞吐，可以在橫向擴容基礎上持續提升整體讀寫能力?？?AZ 容災，保證安全性，多副本跨 AZ 和低延遲。多
62、類型索引支持，支持全文檢索、模糊匹配、比較等值等條件。使用收益我們目前的收益包括存儲量 400 多 TB，全球流量每秒 24 萬，99.6%的響應時間在 10 毫秒以內。報表以及 BI 系統的用戶使用滿意度都比較好。新版本的特性介紹和總結我們的新版本特性包括：行列混合存儲高性價比。支持行式和列式存儲，支持高效行列混合計算，自研列存引擎，支持多種壓縮算法壓縮級別，提供自適應壓縮能力和高壓縮比。高安全高可用有保障。支持三權分立、數據透明加密、數據脫敏，強制訪問控制及全方位審計能力；支持多級容災高可用，完整的事務能力。支持完整的事務 ACID 能力，保證分布式事務的全局一致性，通過擁有自主專利的技術
63、來保證分布式架構下的一致性和高效性。全并行架構極致性能。無共享分布式架構，節點間、節點內、算子間全并行處理，高效向量化執行引擎，延遲物化技術，萬億級關聯查詢秒級返回。37騰訊云技術實踐精選集 2022 語法兼容度高遷移低成本。兼容 SQL 2011 標準，全面兼容 PostgreSQL，高度兼容 Oracle 語法，配套遷工具一鍵式遷移。強大數據治理能力。提供冷熱分離能力、Hash/List/Range 多種分區策略，靈活擴縮容能力，支持 FDW 外表能力與其他數據源快速互通能力?？偨Y來看，TDSQL-PG 解決了微信商戶平臺，包括 BI 報表和維表管理系統遇到的海量存儲、數據傾斜以及性能和成
64、本等問題與瓶頸。TDSQL-PG 在微信支付提供的在線擴容、雙 KEY 分布、冷熱遷移、下推查詢、并行優化、自研分區表、讀寫分離等技術特性取得比較好的實踐效果。TDSQL-PG 在微信支付各場景實踐將進一步優化，為微信支付報表等場景提供堅實的數據存儲技術支撐。38騰訊云技術實踐精選集 2022將云原生進行到底：騰訊百萬級別容器云平臺實踐揭秘林沐騰訊云高級工程師曾負責 QQ 運維平臺的開發工作，在海量服務產品的虛擬機部署形態、微服務架構和 Devops 流程方面積累了豐富經驗?，F階段負責騰訊內部業務上云過程中的容器化規范，以及百萬級別服務容器云平臺的設計與開發工作?；?K8s 的云原生容器化已
65、經在騰訊內部海量業務中大范圍落地實踐。業務從傳統的虛擬機部署形態無縫切換到容器部署形態，運行在 K8s 上的應用從無狀態服務擴展到有狀態服務，這個過程經歷了哪些改造？同時，K8s 如何經受住業務形態復雜多樣、模塊數量龐大的考驗，遇到哪些新的挑戰，如何優化，效果怎么樣？在 DIVE 2022 北京站上，騰訊云高級工程師在題為騰訊大規模自研業務容器化實踐的分享中解答了上述問題。在線業務資源容器化部署的問題與優化方案騰訊平臺的業務基本都屬于在線業務。這些業務以前在虛擬機部署時，是通過物理機操辦的方式生產出很多虛擬機，對于業務來說是不感知的。當業務發現虛擬機負載較低時，可將多個在線業務混部來提高資源利
66、用率。39騰訊云技術實踐精選集 2022這種資源管理方式到容器化部署時發生了一些變化，主要有四方面的內容。容器交付。每個 Pod 在交付的同時需要聲明規格大小，規格大小要改變時 Pod 必須銷毀重建，無法通過混部來新增業務。節點均衡。K8s 每個節點上部署多個 Pod，每個節點上的 Pod 類型、數量也都不相同，要保證節點均衡是一個挑戰。K8s 的云原生特性，也就是彈性，是否能夠符合在線業務在生產環境中的需求？集群池化。K8s 是按集群維度管理，而平臺有上萬個業務，這么多業務如何映射到不同的集群實現條帶化管理？針對上述問題，騰訊采取的優化手段是：1.資源利用率提升動態壓縮和超賣。我們面臨一個痛
67、點是用戶配置的容器規模不合理，普遍偏大，這樣節點裝箱率和負載比較低。所以第一個優化方式就是 Pod 資源動態壓縮，Pod 請求雙核處理器 4G 內存，在調度時壓縮成單核 4G 內存。因為 CPU 屬于可壓縮資源，內存屬于不可壓縮資源。這里修改的只是 Request 大小，并不修改 Limit，所以不影響容器實際能使用的上限值。這樣能提高節點的裝箱率。接下來是 Node 資源動態超賣，根據負載情況超賣更多 CPU 核心。40騰訊云技術實踐精選集 20222.節點負載均衡動態調度和重調度。資源壓縮超賣能提高節點的裝箱率和負載使用率，但 Pod 是共享 Node 的，壓縮和超賣會加劇它們之間的干擾。
68、于是我們開發了動態調度器，當每一個 Pod 調度時，能夠感知存量 Node 當前的實時負載情況，從而對增量 Pod 在 Node 當中均衡處理，掉到一個低負載的節點上。存量 Pod 在節點上也有可能發生高負載，這時我們在節點上部署 Pod-Problem-Detecor、Node-Problem-Detecor，檢測出哪個 Pod 會導致節點高負載，哪些 Pod 屬于敏感 Pod，通過事件上報告訴 API Server，讓調度器將異常 Pod、敏感 Pod 重新調度到空閑節點。3.K8s 業務彈性伸縮協同彈性。在線業務最關心業務穩定性。有時業務負載超出預期時，因為最大負載數配置過低，導致業務雪
69、崩。所以我們對 HPA 進行優化，加入 HPAPlus-Controller，除了支持彈性最大副本策略之外，還能夠支持業務自定義配置進行伸縮。第二個是 VPAPlus-Controller，可以 Pod 突發高負載進行快速擴容，對有狀態的服務也可以進行無感知擴縮容。4.集群資源管理動態配額和資源騰挪。從平臺的角度，K8s 集群也是一個重要的維護對象。平臺通過動態 Operator 的方式控制業務對集群的可見性以及配額大小，使得各個集群的業務是分布均勻的。集群本身也有規模大小，有節點伸縮，叫做 HNA。HNA 能夠根據集群負載情況自動補充資源或釋放資源。生產環境中一種情況是，有時候突發活動，在公
70、共資源池里沒有特定資源，需要從其他系統里騰挪資源。所以我們開發了彈性資源計劃 Operator，它會給每個節點、每個集群下發任務，要求每個集群釋放一些 Node 出來。這批節點的數量要盡可能符合業務的數量要求，同時要對存量業務的負載質量不產生影響。我們的方式是通過動態規劃的方式解決問題，從而在業務做活動，或者緊急情況下，能夠使集群之間的資源也能夠流轉。容器化對動態路由同步的挑戰與解決方案每一個 Pod 在銷毀重建的時候會動態添加或提取路由。一般來說，生產環節中的路由是第三方系統負責，當 Pod 正常的時候系統給它轉發流量，或者做名詞解析，當它摘除時就從名詞服務里剔除。41騰訊云技術實踐精選集
71、2022但我們的平臺在生產環節中會遇到一些特殊情況。第一個情況就是容器化之后容器的變更更加頻繁。第二個變化在于業務規模非常龐大，單個負載的 Pod 可能成千上萬。第三是業務層面的變化，云原生的方式是一個集群對一個路由入口，但在生產環節又是第三方路由系統，允許云上云下混合部署，跨集群多路由服務共享路由。動態路由是容器化的關鍵路徑，是要解決的核心問題。在微觀層面，業務對容器運行階段有特殊需求，包括容器分級、路由和進程的運行狀態一致、大批量探針失敗時要實現路由熔斷。生產環節中路由系統是非常多的，每個路由系統會對應一種控制組件。所以我們需要路由同步 Controller 的統一框架。這個框架理論上是一
72、個旁路 Controller，因此存在不可靠的問題。例如在 Pod 下線前，銷毀的時候不保證已經剔除路由；又比如在滾動更新時，可能上一批還沒有添加路由，下一批就開始銷毀重建。由于有些業務又比較敏感，必須要求絕對保證線下和滾動的時候路由的正確性，于是我們利用了 K8s 云原生的刪除保護、滾動更新機制來實現這一需求。當業務在銷毀之前先剔除路由，業務在滾動更新的時候先保證上一批添加。通過這種方式將路由融入到 Pod 生命周期里，來實現業務的可靠性。對于運行階段，例如容器異常自動重啟，或者 Pod 其中一個容器通過原地生成的方式啟動，這些場景就會繞過前面提到的滾動更新和刪除保護。所以還要在運行階段保證
73、業務之間的快速同步。業務大批量變更又會產生大量事件，導致 Controller 積壓問題。42騰訊云技術實踐精選集 2022對此我們第一個優化方式是使用 Service 粒度事件合并，將事件數量成數量級減少來提高速度。第二個是雙隊列模型。K8s 的 Controller 里有定時歷史對賬機制，會將所有的 Pod 對象全部入隊列。我們需要將實時和定時的事件分開，這樣既能夠解決定時對賬，又能解決實時處理需求。這里面有一個細節問題，兩個不同隊列可能在同一個時刻會有同一個事件要處理，這就需要相互感知的能力避免這種情況發生。下一個 Controller 框架的核心點在于支持共享路由。但云原生的 K8s
74、機制里是一個集群對應一個路由入口，所以我們在 Controller 框架里增加一個路由同步記錄，也是按照 Service 的粒度去記錄的。如果業務系統產生臟數據，例如觸發一個剔除操作，但是路由系統返回成功了，實際上沒有剔除，那么下一次它去同步處理這個事件的時候發現它沒有被剔除，那么還是會再重新剔除一遍。也就是說路由操作等于期望值去 Diff 當前值，而它的期望值就等于 Endpoint 和 Pod 生命周期的交集，當前值就是路由系統里面的情況加上路由記錄，二者再取差積就是要做的路由操作。旁路 Controller 作為一個組件會有異常的時候，雖然 K8s 提供 Leader 機制，但這個機制被
75、 Controller 拉起時需要預加載存量 service 數據，如果數據量非常大需要很久時間。我們的解決方式是，每一個 Controller 運行的時候屬于主備模式，這樣當主容器掛掉的時候，備容器獲得鎖，之間的間隔就是整個 Controller 同步中斷的最長時間，之后備容器就可以快速接管路由通路服務。中斷期間可能發生事件丟失問題，我們通過定時歷史對賬機制解決這個問題。我們還有特殊需求，是業務為了兼容虛擬機部署的一種管理方式，主要針對容器的運行階段以及特殊處理。這里的需求包括容器分級、流量平衡、路由熔斷。這些需求對傳統的 Endpoint Controller 而言是不感知的，原來只維護
76、Ready 和 Not Ready 的狀態，沒有感知更細分的狀態去維護容器的角色和狀態。如果這是由路由 Controller 來實現，那么對這些特殊場景來說是牽一發而動全身的，每一個組件都得同時開發，修改一遍，維護成本是很高的。所以我們提供了一種解決方案Endpoint-Plus Controller。它將維護容器角色和狀態的能力下沉到 Endpoint 來實現。它與 Endpoint 和路由同步 Controller 之間建立一種交互協議，就是 Endpoint Ready 時添加路由，Not Ready 時禁用路由，不在 Endpoint 里刪除路由。這樣所有組件都是統一的，而且每次業務的
77、新需求只要修改 Endpoint 就對全部生效，這樣實現了動態路由同步的橋梁作用。43騰訊云技術實踐精選集 2022一種全新的容器銷毀失敗自愈機制探索最后一個話題是關于容器銷毀失敗自愈的。前面提到了動態調度、彈性伸縮、容災遷移、流水線發布，這些操作都有一個前提，就是容器銷毀重建時老的容器要銷毀，新的容器能創建出來。但實際上在生產環境中這并不是 100%能保證的。因為容器是共享的，多個容器在同一個節點上，卡住的時候會涉及到很多原因：調用鏈很長，只要其中任何軟件出現 BUG 都會卡??；管理容器對業務容器有侵入，造成卡頓；業務容器之間互相干擾；共享內核、Cgroup、Namespace，并不保證所有
78、資源絕對完全隔離；共享節點資源，當 CPU、磁盤 IO 高負載時會影響整個節點上的所有 Pod。K8s 發展到現在已經有了一套很完善的自愈機制。對容器異常來說，云原生 K8s 提供一個暴力解決方案就是強刪機制。該機制只是刪除這個數據對象的數據，并不是銷毀這個容器。這樣導致一個問題，如果進行強制銷毀，可能老容器會殘留，新容器又起來了，這時老的容器會影響節點。所以容器銷毀階段卡住會影響容器銷毀重建這個基本需求，而且它的原因是復雜多樣的，在大規模系統環境中更容易出現，而已有的自愈機制是沒有涵蓋這種場景的，所以我們就需要提供一種全新的自愈機制。傳統的解決方案是通過腳本掃描到它，對于定位到的問題，沒有解
79、決方案的需要臨時隔離，已有解決方案的就要明確修復。但這并不是一個閉環方案，因為還有很多未知問題，對未知問題來說業務關心的是盡可能恢復，而對平臺來說為了保證穩定性，需要盡可能知道這些根因，去收斂這類問題。所以我們兼顧這兩個需求，要縮小定位范圍、縮短定位周期，提高定位效率。對定位到根因的我們要去評估它的影響面，防止增量發生。而已經有解決方案的，我們需要有全網修復能力，出現異常的時候要告警，從而實現閉環解決方案。我們想到了是智能運維的方法，它依靠大規模訓練樣本，關注相關性。而故障處理一般是小樣本量，強調專業和因果性，所以它并不很適合這種場景。但在智能運維的決策樹模型里有些概念可以拿來參考，譬如基尼系
80、數、信息熵、剪枝等。44騰訊云技術實踐精選集 2022最后簡單介紹一下決策樹模型的實現。第一步需要建立模型，是關于信息熵的權衡，要平衡自愈機制和定位效率。我們在選擇信息熵的時候是自頂向下的推導路徑，從節點異常再到容器調用鏈異常，再到具體系統日志。第二步是特征選取，基尼系數越小特征越明確，所以我們選擇共同特征作為一個特征值。同時選擇一些已知問題或者根因比較明確的作為葉子節點。最后一步是模型優化，例如剪枝優化，通過后剪枝的方式解決過擬合現象。同時簡化模型。通過這種方式，當容器發生銷毀失敗時，能夠觸發自愈路徑。同時，對于新增問題，我們可以縮短問題范圍，提高定位效率。通過以上三步，最終我們探索出了這樣
81、一種全新的容器銷毀失敗自愈機制。掃碼獲取完整版演講 PPT45騰訊云技術實踐精選集 2022云原生安全可觀測性探索與實踐江國龍騰訊云容器安全架構師、騰訊安全云鼎實驗室高級研究員騰訊云原生安全技術專家，主要負責云原生安全領域的技術研究、安全能力構建、騰訊云原生服務安全架構設計和落地實施等，有著豐富的云原生安全建設和實踐經驗。云原生架構下，可觀測性為云原生應用的故障分析、問題定位、性能提升等提供了重要的幫助，在云原生生態中起到了重要的作用。同樣，可觀測性對于云原生安全也有著重要的意義，如何利用可觀測性實現云原生安全？騰訊在這方面又有哪些積極探索和實踐干貨？在 ArchSummit 2022 全球架
82、構師峰會（深圳站）上，騰訊云容器安全架構師江國龍帶來題為云原生安全可觀測性探索與實踐的分享，解答了這些問題。云原生架構下，為什么安全需要可觀測性業務云原生化后往往會面臨一些運維和安全層面的問題：我的集群里有多少個 Pod 擁有高權限、我的應用應該被賦予哪些權限？如果發生提權操作，我怎么知道是哪個 Pod，我該怎么操作？我發現有 Pod 在訪問 API Server 執行操作，是被入侵了嗎？微服務之間的各種訪問通信，都是正常的業務操作嗎？46騰訊云技術實踐精選集 2022 鏡像掃出來一堆漏洞，我該怎么處理？安全產品告警了，我該怎么進行處置、怎么溯源分析？等等。云原生會給業務安全帶來這些挑戰，一個
83、重要原因是云原生架構顛覆了整個 IT 生命周期與治理模式。我們發現一半左右的容器的生命周期不足五分鐘，70%多的容器生命周期小于一小時，這意味著業務資產時時刻刻都在變化，安全檢測和防護更加困難。再從主機維度來看，云原生架構下主機行為更復雜，體現在工作負載密度更大、變化頻率更高、調用關系更復雜。還有，云原生架構下，現有安全能力無法識別全部風險，新技術、新架構、新模式對現有安全方案提出了重大挑戰。最后，云原生的合規標準也提出了更多可觀測性要求?；谏鲜霈F狀和問題，我們認為在云原生架構下，有必要通過可觀測性方式來加強安全性建設。什么是云原生安全可觀測性云原生可觀測性概念可以和傳統的監控對比。傳統監控
84、能告訴我們系統哪些部分不工作了，而可觀測性就能告訴你為什么那里不工作了，給你提供更多詳細的數據解決問題。到了安全層面，傳統的安全告警可以告訴我們系統哪里是不安全的，而安全可觀測性可以告訴我們那個地方為什么是不安全的，讓我們能夠基于安全可觀測性的數據去實現持續安全治理和運營。之所以強調云原生可觀測性，是因為云原生架構下安全治理和運營面臨更大的復雜度、更多挑戰。云原生架構面對的風險全景可分為兩部分，第一部分是風險可觀測，就是事前判斷系統都有哪些風險；第二部分是事中的威脅可觀測，一旦系統被入侵，我能夠快速發現整個入侵路徑、當前的威脅態勢。所謂云原生安全可觀測性，一方面是運用云原生的可觀測性來實現相應
85、的安全檢測，同時也是對整體安全態勢實現可觀測；另一方面，云原生架構的特性使得安全的可觀測成為可能。容器、微服務、DevOps 是云原生的基礎，它們催生了新的 IT 開發和治理模式，最終呈現為不可變基礎設施與聲明式的 API。從安全角度來講，不可變基礎設施讓安全措施更容易實現，催生了新的安全模式。要實現安全可觀測性，在實現層面可以總結為三大支柱：1.系統可觀測：風險/行為可觀測（監控/日志/追蹤）；逃逸檢測、越權檢測、WebShell 檢測、挖礦檢測等。2.網絡可觀測：網絡連接、網絡通信；挖礦檢測、端口探測、異常連接檢測等。3.應用可觀測：API 資產管理、API 調用異常、業務安全等。47騰訊
86、云技術實踐精選集 2022如何實現安全可觀測在上圖的安全可觀測實現路徑中，最關鍵的部分就是數據采集。在這一層面，我們會盡可能把安全能力同樣做到云原生化，同云更完美地結合。數據采集分為兩部分，首先是采集云端各類資產數據、可觀測性數據；其次就是采集安全探針數據。我們通過 DaemonSet/Agent 模式部署探針，采集相應進程數據、網絡數據。這里會基于 eBPF 實現安全數據可觀測，且騰訊云自身的網絡能力與操作系統對 eBPF 有著良好支持，這樣安全層面就有更多施展空間。例如對 K8s 審計日志做分析，一些操作對于傳統安全能力來說都是正常的，但從安全角度來說就是異常的，那么通過審計日志分析，根據
87、特定規則就能發現風險。又如容器權限的異常檢測，我們能夠通過探針發現正常業務應該有哪些權限，之后通過準入策略控制應用在啟動時獲得的權限。云原生安全可觀測性實踐騰訊云在做超大規模容器平臺的安全架構時，總體遵循四大原則：1.安全能力原生化，包括原生基礎設施安全性、安全能力云原生化；2.安全左移，指更早投入安全資源和能力、更有效收斂安全漏洞問題、更早確定安全性；48騰訊云技術實踐精選集 20223.安全防護生命周期，從開發到部署到運營全面融入 DevOps 體系，實現 DevSecOps；4.零信任安全架構，包括全面有效的身份權限管理與持續的檢測與響應。上圖是騰訊云的容器安全體系架構。底層是基礎安全能
88、力，這部分是不依賴云原生的能力；中間是云原生安全架構的基礎能力；最上層是應用安全，依賴于相應的可觀測安全管理的能力。這樣最終實現了 DevSecOps 全流程安全管控。整體來看，云原生安全性概念的范圍是很大的。具體的實現有幾個案例：容器鏡像的安全風險可觀測。我們從基礎鏡像的角度切入，通過可觀測性的方法實現對鏡像安全的治理。鏡像會有各類依賴關系，復雜業務會有很深的鏡像依賴樹，那么很多問題就很難找到具體的引入根源。對此我們會在鏡像掃描過程中把所有風險定位到相應的層級、相應的鏡像負責人。同時我們通過漏洞管理、風險管理等措施實現對容器鏡像的風險可觀測性。發起云原生安全測試平臺，全面覆蓋安全風險可觀測。
89、除了自身實踐之外，我們也聯合業界做了一些嘗試。我們聯合信通院和清華大學成立了云原生實驗室，推出了云原生安全測試平臺。我們基于這個平臺聯合業內安全廠商、云廠商、高校一起，共同進行相應的能力建設。我們最終的目標是通過能力共建來對云原生系統做相應的診斷、分析、評估，實現風險的可觀測。測試平臺目前覆蓋了整個云原生安全體系，可以對 400 多項可能存在風險，或者對安全能力有要求的位置做相應的安全有效性驗證。我們也希望能夠聯合整49騰訊云技術實踐精選集 2022個業界，把我們的積累分享給全行業。運行時的安全威脅可觀測。從運營角度來說，這里主要是發現威脅之后的取證、溯源、分析攻擊路徑等工作。針對單點威脅，我
90、們能夠把相應的問題、影響范圍、上下文、責任、資產、相應的責任人做到全方位關聯，讓運營能夠直接定位到具體的負責人，馬上做出相應的威脅處置。騰訊云容器服務 TKE 安全性也得到了行業認可，我們的安全成熟度模型拿到了最高的安全等級認證?？偨Y第一，云原生架構在安全防護和安全運營上存在挑戰；第二，云原生的可觀測性可以很好地賦能安全能力的構建；第三，云原生安全的可觀測性包含事前的風險可觀測和事中的威脅可觀測；最后，云原生安全的可觀測性可以很好地賦能安全治理和安全運營。掃碼獲取完整版演講 PPT50騰訊云技術實踐精選集 2022大規模代碼中引入供應鏈漏洞的分析技術前瞻王福維騰訊安全云鼎實驗室高級研究員騰訊云
91、安全高級研究員，專注基礎安全研究，在漏洞控掘分析自動化以及惡意代碼檢測領域，積累了前沿研究和一線攻防經驗?，F致力于在真實世界中挖掘暴露供應鏈安全的已知和未知威脅，并研究解決核心問題的技術方案。云原生之所以能提升開發效能，“代碼復用”功不可沒；獨立分析機構的調查報告指出，來自開源軟件供應鏈的代碼在線上應用中占比 85%+，這造成了代碼缺陷的廣泛傳播。據 Google Project Zero 團隊研究，今年在野利用的 0day 漏洞中有一半是歷史漏洞的變種；而開發者也總是在寫前人犯過錯誤的相似代碼。為了解決現有安全技術面對歷史漏洞傳播無能為力的問題，QCon 2022 廣州站上，騰訊安全云鼎實驗
92、室高級研究員王福維帶來了題為大規模代碼中引入供應鏈漏洞的分析技術前瞻的分享。本次分享將從一些典型案例切入，逐一進行問題分析，并首次揭秘騰訊安全當前正在發力研究的一項有別于 SAST、SCA 等的創造性技術，并介紹如何在 DevSecOps 實踐中使用該方案。51騰訊云技術實踐精選集 2022代碼復用所引入的軟件供應鏈安全威脅形式軟件可以理解為機密且功能復雜的機器，當中有大量復雜組件，不可避免會有一些核心、邊緣組件要從企業外部采購合成。這些組件的知識產權、質量、可靠性等要素經常缺乏足夠的保證。據業內權威報告，當今 90%98%的軟件包含開源代碼，所有軟件代碼中開源代碼所占比例超過 78%。這些開
93、源代碼中有 85%是嚴重過時的，81%的代碼至少包括一個漏洞。每個軟件依賴的代碼中平均有 49 個漏洞。代碼復用也不僅僅是“包依賴”一種形式。實踐中復用的形式多樣、粒度也有多個層次。目錄粒度上有軟件子模塊引用開源項目固定 Tag，開源項目代碼靜態引入和編譯；文件粒度上有單文件代碼引用，功能模塊克隆修改；代碼片段粒度上還有開源代碼函數級復用，示例代碼借用。特別是在云原生開發背景下，軟件開發迭代速度飛快，代碼的廣泛復用是不可避免的。谷歌的 Google Progect Zero 安全實驗室發表的漏洞利用根因分析研究指出，2022 上半年，被黑客在野利用的 0day 漏洞中有一半是歷史漏洞的“重現”
94、“翻版”。有時開發者會在項目重構時忽略以往的漏洞修復代碼，有時開發者會復制上游項目中已經存在的漏洞。還有一些廠商會自行維護上游項目的分支版本，但上游項目出現漏洞時分支版本要做修復會遇到因為版本差異導致的漏洞判斷困難、修復困難等問題。還有一些開發者在函數級別引用了帶有漏洞的代碼，又沒有申明依賴關系，以至于上游漏洞被發現甚至解決后都沒有意識到自己項目中有漏洞存在。還有一些漏洞共享的根因是不可修復的，需要對出現漏洞的各處代碼逐個修復，但下游開發者不一定都能意識到這一問題?，F有分析技術對規?；鉀Q相關問題的盲區行業面對開源代碼的安全威脅有兩種主流的代碼分析技術，分別是 SAST 源碼靜態安全掃描測試和
95、 SCA 軟件成分分析。52騰訊云技術實踐精選集 2022但這兩種技術解決不了上述問題，存在很多盲區：SAST 的規則類分析過于面向語言相關、通用基礎 Bug 模式，對真實、具體漏洞邏輯無感。大量漏洞所采用的都是規則覆蓋不到的模式。SCA 技術基于顯式依賴屬性或相似性度量，思想本身有制約。這種技術無法進行細粒度分析，無法發現邏輯同源漏洞。SCA 所定義的相似性指紋一般不具備可解釋性，自然也無法迭代演進。SAST 的規則需要高水平的安全人員編寫，需要對漏洞根因有深度理解才有較好的效果，在安全人員緊缺的行業中這是很難做到的。且相關規則很難修正，實踐中經?！罢毡拘啤?，為了減少誤報還有很多規則會被忽
96、略。規則的社區生態建設也缺乏基礎，大量規則的編寫工作仍由少數開發人員掌控?，F有方案執行效率低，系統龐雜，難于部署、遷移、使用、更新、擴展，DevSecOps 集成的形態和效果不如預期。一種面向代碼復用問題挖掘的技術速覽騰訊云針對上述安全問題，嘗試采用一種創新方法來突破現有挑戰。該方法的核心理念是語義和簽名的折中。一如“核酸檢測”對比“全基因測序”的關系，該方法僅以關鍵特征“基因”為探針，判斷符合性，而無需做長序列相似度匹配?！疤卣鞴こ獭睆恼Z法層面，比語義更有定向表示能力，比簽名更有泛化能力。53騰訊云技術實踐精選集 2022具體實現來看，該方法嘗試尋找有問題的代碼片段，這個代碼片段類似于病毒模
97、板，其特征通過代碼補丁的形式承載和體現。整個工程還是落到 SAST 靜態源代碼掃描平臺上，通過平臺尋找符合特征點位的代碼片段，從而解決當前 SCA 無法對細粒度代碼做分析的問題。該方法的框架分為三大部分。首先將打補丁前后同樣版本的代碼片段引入到平臺中，還原到語法層面來看前后語法之間有哪些差異，進一步找出有哪些語法結構是完全匹配的，有哪些語法結構不同，但實際上存在映射關系；定義差異后開始要素翻譯，將這些 AST 差異翻譯為 SAST 所能理解的代碼查詢條件，這里將差異節點翻譯為該層面的描述語言，描述節點存在哪些上下文，描述目標位置及特征，這樣就可以形成查詢條件，有機排列組合后得到大量查詢規則；最
98、后再用這些規則做回歸測試，確定哪些規則可以有效檢出目標代碼，哪些規則會引入誤報，從而更新規則。上圖是一個實戰案例，該案例涉及一個代碼補丁，其核心引入了一個新增的條件判斷，不符合特定數據規則就直接忽略。把它翻譯成為 AST 抽象語法數，在語法數層面進行語法要素的識別和映射，可以找到它的差異節點。再把它翻譯成為對應的查詢語句，拼出來很多查詢語句條件。接下來把它喂給回歸測試，得到一個能夠保證檢測出預期漏洞，并且盡量少誤報的最簡規則。我們使用生成的規則發現了 LibreSSL 項目存在同源異構漏洞，該漏洞是因為下游項目沒有跟進上游修復而造成的。54騰訊云技術實踐精選集 2022技術方案與 DevSec
99、Ops 集成實踐前瞻目前上述方案還在前期開發和攻堅階段，但我們希望未來它能集成到 DevSecOps 的實現中。集成 DevSevOps 的核心思想是兩個雙軌制：一是敏捷持續和持續測試并行，二是反哺開源社區與商業化輸出并行。在軟件的完整生命周期中，開發及預發布階段就要接入安全測試來修復安全問題，這就要求安全掃描能力可以在有限的時間內以最高的準確度給出結果。但同時還有很多安全分析的工具和方法致力于發現更深層次的漏洞，或者以更高的泛化能力去發現未知漏洞。這就是持續測試的理念，是在軟件開發生命周期之外，在軟件當前運行的所有版本中后臺運行測試。這種持續測試可以有一套稍微寬松的規則，這些規則由各個廠商的
100、安全研究員跟進，解決高隱藏高危害、有獨特性的問題，從而領先黑客來做前瞻性安全防護。我們的方案在理想情況下預計可以針對整個開源軟件生態中所有軟件和項目實現歷史漏洞的覆蓋，針對每一個歷史漏洞都實現對應的規則，形成非常龐大的規則庫。規則庫將向社區開放，開源維護者都是受益者。這樣開源軟件生態參與者可以及早發現代碼漏洞，避免這些漏洞對軟件造成危害。對于私有項目來說，該方案可以集成到騰訊自研的 DevSecOps 流程中，形成開源漏洞規則集，讓接入 DevSecOps 平臺的所有開發者能夠分析所有私有項目中包含的歷史 Bug，確保項目不會再引入開源項目中的已有漏洞?？偨Y首先，代碼復用形式多樣，各種形式均可
101、能構成 安全漏洞。靜態分析工具面對復雜的代碼復用場景，從機制和實踐中均無法滿足需求，難以解決問題。對此，騰訊云提出了一種基于“結構化比對”和“要素翻譯”的技術研究，增強 SAST、解決 SCA 盲區問題。未來，騰訊云會將這種能力集成到軟件生命周期，并向整個開源生態貢獻能力掃碼獲取完整版演講 PPT55騰訊云技術實踐精選集 2022大數據與云數據庫技術探索及實踐0256騰訊云技術實踐精選集 2022騰訊云大數據 TBDS 在私有化場景萬節點集群的實踐楊鵬程騰訊云 高級后臺開發工程師騰訊云 TBDS 大數據團隊存儲組件研發負責人。畢業于武漢理工大學計算機系，在大數據存儲、緩存加速以及實時計算等領域
102、有著豐富的落地經驗。在當前越來越強調云原生的環境下，存儲計算分離已經是大勢所趨。存算分離的存儲資源和計算資源的解耦，以及計算資源的彈性擴縮容能充分地提高系統整體資源的利用率和系統的健壯性。幾乎所有我們熟知的云數據庫都已經開始使用存算分離實現資源價值的最大化，不過在私有云場景下，國內的存算分離大規模實踐還比較少。這主要是由于私有化場景比較復雜，需要考慮私有化客戶的技術人員在大數據領域的固有技術棧、新老架構平滑升級、不同客戶的存儲計算引擎有一定的差異等一系列問題。在 DIVE 2022 北京站上，騰訊高級后臺開發工程師楊鵬程帶來了題為騰訊云大數據 TBDS 在私有化場景萬節點集群的實踐的分享，聚焦
103、騰訊 TBDS 大數據團隊通過 Alluxio+Ozone 進行存算分離架構優化，以及存算分離在私有云下大規模集群的實踐。57騰訊云技術實踐精選集 2022Hadoop 體系下存算一體存在的問題及解決思路大數據發展多年來，根據業務特點可分為四個階段：1.Hadoop 體系的存算一體階段。這種模式的計算層有一定的數據本地性，減少了一定的網絡 IO，有一定的加速作用。在規模集群較小且節點數較少時，每一個節點存儲分配到的總體文件相對較多，加速效果明顯。但隨著集群、數據規模和節點的增加，本地加速的優勢越來越小。相反，由于集群節點對存儲和計算的硬件配置要求較高，整體擴容成本也比較大。HDFS 的 Nam
104、enode 元數據擴展性也有瓶頸，導致集群整體的規模上限有瓶頸。為解決這個問題有了存算分離，也就是第二個階段。2.存算分離階段。由于存儲資源和計算資源對計算機硬件的配置要求不同，所以存儲機器的成本會便宜很多。但這個階段的存算分離最大的問題是：計算要通過網絡 IO 去遠端存儲獲取數據，計算速度和效率會比存算一體差很多。3.數據湖階段。數據湖主要是為了解決業務的多樣性以及業務之間數據共享難的挑戰而誕生的。數據湖里有一種統一的表格式來支持數倉和上層進行共享計算。4.云原生階段。云原生希望運用多個彈性計算資源，但計算層并不用關心整體調度細節，以及調度過程中的容錯、遷移、重建等操作。存算分離也是借助于云
105、原生和緩存加速才真正有了大規模生產實踐的落地。首先來看 Hadoop 體系下存算一體架構存在的問題。HDFS NN 的內存結構主要分為四個部分，一邊是 Namespace 和 BlockManager，另一邊是內存的網絡拓撲等結構。Namespace 維護了整個文件系統的目錄結構，是按照樹狀結構維護的。集群中的目錄和文件總量就是整個 Namespace 目錄樹中包含的節點總數，所以這塊的內存會隨著集群內文件一級目錄個數的增加而成比例增長。BlockManager 維護了整個文件系統與數據塊相關的信息，以及數據塊的狀態變化。這塊內存也是會隨著集群內的文件個數以及大小而成比例增長。網絡拓撲結構維護
106、著整個機架的拓撲以及 Datanode 的基本信息，即使擴容到上千節點規模的集群，這部分使用的內存也比較小且固定，不會隨著集群文件個數的增長而變化。其他一些小的結構所使用的內存都比較小，而且不會隨著集群文件個數的增長而變化。從內存結構可以看到，Namenode 文件系統元數據以及塊信息的位置基本全部存在內存中，隨著數據規模的持續增長，內存占用會逐漸增大。所以 HDFS 面臨的三大主要問題：NN 元數據擴展性挑戰、單機內存限制、JVM 要求高；塊上報風暴，重啟時間長；全局鎖，大量并發寫效率嚴重下降。所以 TBDS 在私有化客戶的經驗值是，Namenode 一旦超出了 150G 內存，或者整體集群
107、文件規模數量達到 5G 時就開始新建集群，但新建集群和舊集群的數據是不通的，集群之間也會形成數據孤島。58騰訊云技術實踐精選集 2022其實只需一個 HDFS Client 加不同孤島集群的配置文件就可以達到一個 Client 端訪問不同集群數據的目的，但每一次都要切換對應集群的配置文件。如果不同集群配置文件信息都匯總合并成一個配置文件，就可以用同一個 Client 和同一份配置文件訪問不同集群。但是這樣又導致了新的問題不同集群的 HDFS Schema、Namespace 名字不同，文件路徑還是割裂的。為解決這個問題，HDFS 社區提出的方案是在 Client 端用一個新的 ViewFS 掛
108、載表，統一管理多個 HDFS Namespace 路徑的映射關系，讓不同的集群文件路徑和 Schema 都統一成新的 ViewFS，這就是 HDFS Federation 聯邦。但 Client 端協議由 HDFS 變成了 ViewFS，另外子集群信息以掛載表的方式配置在 Client 端，一旦集群發生了機器遷移變更，所有的 Client 端配置都得改變。這種情況下，尤其是在私有化場景，引導客戶升級和維護的成本都非常大?；谶@種考慮，HDFS 社區在后來的 2.9 版本上又提出了 Router 聯邦。它引入 Router 服務去管理路由掛載表，對外由 Router 對 Client 端提供 H
109、DFS 協議的解析及訪問來代替 ViewFS 協議，達到了向下兼容的目的。TBDS 是基于 Router 聯邦的方式解決 HDFS 多集群數據孤島問題，讓集群之間的存儲能夠互通。在 Hadoop 集群之下絕大多數的業務都是通過 Hive 庫表的方式訪問 HDFS 存儲，雖然解決了數據存儲的孤島問題，但是無法讓業務跨集群聯通訪問。所以還得解決 Hive 庫表的跨集群聯通問題。TBDS 基于 HDFS Router 這個思路自研 HiveMeta Router Federation，實現了跨集群的 Hive 元數據的聯通與統一。HiveMeta Router Federation 實現了 Hive
110、Meta store 庫表大部分常見 Thrift 協議以及 SQL 語法解析，對計算引擎提供了 HiveMeta 服務。我們通過 Federation 解決了數據和庫表元數據的孤島問題，讓上層應用基本可以無感知底層變化而實現跨集群的數據互通。但 Federation 也有一些問題：第一是它增加了數據訪問調用鏈路，在大量 Shuffle 作業時增加作業整體耗時；第二是該架構只多了一層 Router 代理，沒有根本改變原來的存算一體架構，HDFS 和 YARN 在一起混部，在大規模集群對 JVM 要求很高的情況下又增加了相互影響的風險，加大了集群的不穩定性，也不能獨立分片擴展；第三是資源成本問題
111、，容易出現冷熱集群，需要動態均衡調整。存算一體集群成本高，尤其是大規模集群，同時滿足計算和存儲需要，硬件配置高，一方資源不夠就要整體擴容。不同時段對存儲和計算的需求不是相當的，計算和存儲對硬件資源要求不同，需求也是彈性變化的?；诤竺鎯牲c的考慮，我們開始了基于云原生的存算分離架構的演化。59騰訊云技術實踐精選集 2022TBDS 存算分離架構演進及三層優化我們的架構設計主要考慮三點，分別是核心擴展性、海量存儲計算速度以及云原生。核心擴展性主要是指存儲、元數據和調度計算獨立的物理擴展性，這種獨立擴展性能要達到上萬節點的規模能力；海量存儲計算速度主要是為了解決存算分離帶來的大量網絡 IO 的問題，
112、通過緩存加速等手段可以實現數據本地性能的能力；云原生主要是基于計算和調度依賴的云原生 K8s 能力，實現彈性計算以及自動容錯。以上是 TBDS 存算分離的架構圖。在存儲和計算層之間加了一個元數據層，計算層又分為計算資源層、計算加速層和計算引擎層三層。我們把可擴展性核心交給存儲層，因為存儲層的擴展難度是最大的，只要存儲層是可擴展的，上面的所有層理論上都可以擴展，其他上層內容可以通過分布式解決。存儲層主推騰訊自研并共享給阿帕奇社區的 Ozone 對象存儲。Ozone 在文件的元數據架構上通過拆分以及 Router 分布式方式，解決了 HDFS Namenode 元數據中央節點無法擴展的問題。因為
113、TBDS 面向私有化場景，考慮到客戶的現有情況，我們存儲層也支持亞馬遜的 S3、阿里的 OSS、華為的 OBS，支持標準對象存儲協議的對象存儲，也兼容老的 HDFS 文件系統存儲。針對不同的場景，我們會選擇不同的計算引擎，甚至會使用不同的元數據格式的數據。元數據層支持 Iceberg、Hudi 這種面向數據湖的表格式，也支持 Parquet、Orc 這種傳統的 Hive 數倉表格式。60騰訊云技術實踐精選集 2022我們也自研了“統一元數據”服務，解決元數據層的擴展性問題，它也同樣支持大部分 HiveMeta 的標準協議。計算資源層支持 Kubernetes 和 YARN 的計算調度。我們根據
114、不同的集群、不同物化的計算引擎去在 Kubernetes 和 YARN 中做選擇。計算加速層采用 Alluxio 作為計算引擎到存儲引擎大量網絡 IO 的緩沖紐帶，Alluxio 帶來的數據本地性讓我們上層應用享受更快的速度。接下來看我們目前做的設計和優化。對于存儲層，針對元數據擴展性問題，Ozone 把 Namespace 元數據服務和 BlockManager 拆分為兩個服務。OzoneManager 負責元數據服務，StorageContainerManager 負責數據塊管理、節點管理和副本冗余管理。針對塊上報風暴問題，StorageContainerManager 無需管理默認的 1
115、28 兆的 Block 信息，只需管理默認 5GB 的 Container 信息，可以極大減少對管理的數據量的依賴，從而提升了服務性能。OzoneManager 內部的鎖是 Bucket 級別，可以達到 Bucket 級別的寫并發。因為 Ozone 是對象存儲，所以對象存儲的語義不存在目錄和樹之間的關系，也不需要維護全局文件系統的系統樹，從而實現高吞吐。Ozone 同時支持 HDFS 和對象存儲的雙重語義，支持 CSI 協議給 K8s 協議掛載盤，也支持標準的 S3 協議。整體性能和 HDFS 差不多，但是穩定性尤其是千臺節點規模以上的穩定性比 HDFS 好很多。計算資源層，5000 個節點是
116、 K8s 集群的擴展性瓶頸。同時 K8s 的調度性能與 YARN 有數量級差別，K8s 在 1000 Pods 每秒的調度情況下性能已經嚴重下降，難以支持大規模數據調度場景；在超大規模集群高并發的場景下，APIserver、Etcd、監控、日志等都會存在明顯的瓶頸。我們針對原生的 K8s 節點擴展性以及調度能力瓶頸做了自研的統一 K8s 調度引擎，來優化解決這個問題：61騰訊云技術實踐精選集 2022用戶提交任務 Pod 之后，把它提交到租戶集群內，租戶集群的 Controller-Manager 給它創建 Pod，然后 Mongo-Scheduler 調度器會調度 Pod 到具體某一個底層物
117、理 K8s 集群的某個節點上。如果這個節點在租戶集群這邊還沒有創建出來，Syncer 模塊會將這個節點以虛擬節點的形式創建出來，并且定期同步物理集群的 Node 心跳信息到租戶集群。如果 Syncer 模塊發現底層物理集群還沒有創建 Namespace，它會創建一個租戶集群 Namespace。并且會統一給租戶 Namespace 在底層物理 K8s 集群映射的 Namespace 上加一個前綴，保證全局唯一，避免沖突。接著 Syncer 模塊會創建 Pod 依賴的 Secret、Configmap、Volume 等對象信息，同步到底層的物理 K8s 集群上。Syncer 創建底層同名的一個
118、Pod，修改 Pod 里面的屬性。物理 K8s 集群的 Kubelet 就會運行這個 Pod，最終 Syncer 感知到物理集群 Pod 的狀態發生變化，就會把 Pod 的狀態和 Event 事件同步到最后，Client 用戶就能收到這個 Pod 的狀態，這就是通過自研調度器提交 Pod 任務運行的流程。計算加速層優化，我們引入 Alluxio 做計算加速。Alluxio 提供了主動和被動兩種方式拉數據，我們可以提前在跑任務之前主動把 Hive 表里面的數據加載到 Alluxio 的 Cache 里，進行計算加速。利用 Alluxio 的 Prefix 前綴 Level 預熱能力，可以提前按照
119、表的分區級別設置成前綴，然后讓數據加載到 Alluxio 的 Cache 里，并且將數據和周期的調度時間成比例地設置 TTL 過期時間，保證分區的計算數據可以計算完后迅速過期，給 Alluxio 騰挪出更多的空間去緩存最重要的數據。當計算引擎需要的文件向 Alluxio 拿 Block 時，Alluxio 發現本地的 Cache 里沒有這個 Block，就會向后面底層的 UFS 去同步訪問相應的Block 內容，并且 Cache 到 Alluxio 的 Worker 節點中。這種被動方式第一次比較耗時，但是對于后面計算要重復使用的熱數據也有比較明顯的加速效果。Alluxio 也提供了元數據 C
120、ache 能力，減少 List 操作的高耗時，提升元數據訪問性能。62騰訊云技術實踐精選集 2022下圖是 Alluxio 部署在 K8s 計算層的一個典型的存算分離場景。云原生下的計算引擎優化和最佳實踐下面講實踐中計算引擎的優化，主要以 Spark 計算引擎為例。Spark 在物理集群中的常見的工作流：首先通過 Spark-Submit Client 提交運行一個 Submit Job 到 YARN 或者到 Mesos，接著 Mesos 或者 YARN 分配兩個 Worker 節點作為 Executor 給 Spark Client，然后 Spark Client 會向 Worker 啟動
121、Spark Executor，并且在 Executor 里啟動一個物理執行計劃。Spark Executor 的每一個 Task 要從遠端的 Ozone 或者 S3 的對象存儲訪問數據，然后計算。這種模式中的計算都是通過網絡 IO 從遠端訪問數據，網絡時延和 IO 都會影響計算速度。63騰訊云技術實踐精選集 2022上圖是在物理機上 Spark 經過 Alluxio 加速計算的流程。不過這種在物理機上經過 Alluxio 的加速模式放在 K8s 上部署后會有問題。首先 Alluxio Worker 的 Pod Host 是 K8s 集群里分配的，它和所在的宿主機的 Host 是不同的，導致我們
122、沒辦法通過 Pod 的 Host 去分配 Spark Executor 數據就近的 Pod。我們在實踐中配置 Pod 的 Host 的 Network 屬性，配置成 True 就可以讓這個 Pod 共享宿主機的 Host 來解決這個問題。這里又有兩個新的問題，第一個是 Spark Alluxio Pod 的 Host 和宿主機的 Host 不一樣，匹配不到。這里同樣讓 Spark Executor 這個 Pod 可以開啟 Host Network 這個屬性，它就可以以物理機的 Host 的方式去分配和 Alluxio Worker 同一個物理機的節點去進行本地計算；第二個問題是，即使能讓 Al
123、luxio Worker 和 Spark Executor 分配到同一個宿主機上去，但是因為 Alluxio 的 Client 只能通過短路讀，或者是 Local Domain Socket 的方式去訪問 Worker 開啟這個文件，但是 Pod 之間的文件系統又不互通。雖然我們可以通過 VolumeMount 方式共享宿主機的文件，但是具體要訪問的文件路徑和目錄也是動態變化的，而且這種存儲文件相對比較大，這種 Mount 的方式相對訪問來說是很不穩定的。我們實踐后的解決辦法是：讓 Alluxio Worker 通過掛載 HostPath Volume 方式共享 Domain Socket 到
124、宿主機。比如說掛載到 OPT Domain 這個路徑，然后由于每一個 Alluxio Worker 在 K8s 里都有一個唯一的 Pod 的 UUID，所以我們會把這個 Pod 的 UUID 掛載到這個路徑下面，具體的文件就變成了 OPT Domain UUIDA。Alluxio Client 會去 Alluxio 的 Master 詢問文件的 Block 所在的 Alluxio Worker 的 Pod，所以 64騰訊云技術實踐精選集 2022Alluxio Worker 會把自己這個 Local Socket Domain 通過 Master 發給 Client，然后 Alluxio Cl
125、ient 就可以在宿主機上通過匹配 UUID 的方式查找到 Worker 的 Domain Socket 的文件，也就是前面提到的 OPT/Domain/UUIDA，然后匹配到具體的宿主機，并且在這個宿主機上分配具體的 Socket Executor 啟動任務。Socket Executor 同樣也掛載和 Alluxio Worker 一樣的 HostPath Volume 路徑，Socket Executor 里面的 Alluxio Client 就可以通過 Domain Socket 的方式去訪問這個路徑的文件進行本地數據加速?？偨Y此次分享主要包含三部分內容，第一部分提到存算一體的擴展性問
126、題及原因，我們通過新增集群的方式解決了擴展性問題，隨后又帶來了數據孤島的問題，我們通過聯邦方式解決數據孤島問題，但聯邦的存算分離架構也依然存在一些問題，于是我們開始了基于云原生的存算分離架構演進；第二部分圍繞基于云原生存算分離架構的演進，重點講了存算分離三層架構以及擴展性問題、存儲層 Ozone 擴展性、K8s 層擴展性、Alluxio 加速效果；最后一部分是計算引擎的實踐優化，尤其是 Socket on K8s 模式下的實踐。掃碼獲取完整版演講 PPT65騰訊云技術實踐精選集 2022PB 級數據秒級分析，騰訊云原生湖倉 DLC 架構揭秘于華麗騰訊云大數據專家工程師騰訊云原生湖倉產品 DLC
127、 內核研發負責人，畢業于復旦大學數學系，近十年公有云大數據經驗，基于 AWS/阿里云/騰訊云打造業界領先的云原生湖倉數據平臺，在數據湖存儲、Severless 計算、統一元數據有豐富落地經驗。過去幾年，數據湖能力已經在騰訊內部包括微信視頻號、小程序等多個業務大規模落地，數據規模達到 PB 至 EB 級別，在此基礎上，騰訊自研業務也啟動了云原生湖倉能力建設。云原生湖倉架構最大的挑戰什么？騰訊云原生湖倉DLC從哪些方面著手解決問題？針對上述問題，在 QCon 2022 全球軟件開發大會（廣州站）上，騰訊云大數據專家工程師于華麗帶來了主題分享 PB 級數據秒級分析，騰訊云原生湖倉 DLC 架構揭秘。
128、云原生湖倉的誕生背景、價值、挑戰當前這個階段，相信大家對于數據湖，數據倉，湖倉一系列的名詞已經不算陌生了，我用最直白、最狹義方式去解釋“湖倉”的話，就是數據湖跟數倉存儲架構統一。數據湖最初的需求是，要存儲和分析海量的半結構化、非結構化的數據，以及數據倉備份和溫冷數據存儲。在公有云找到了對象存儲（海量、低價、高 SLA 和高可靠性）這樣一個全托管的存儲產品后，成本方面對66騰訊云技術實踐精選集 2022象存儲對比客戶 HDFS 自建大概為 1：10，非常有吸引力。這個存儲系統看起來這么好，有沒有可能把數倉一起解決，結構化數據是不是存在這里？伴隨著這個需求的升級，現代湖倉架構的基礎也隨之產生。云原
129、生湖倉又是什么呢？最狹義的理解就是容器計算+K8s。更加廣義的理解應該長在云上，更多的使用云上已有的全托管產品，比如利用對象存儲、本身服務云原生化等。在云原生湖倉架構下，會面臨很大的挑戰就是“性能”。為什么有“性能”的挑戰？第一：對象存儲有很好的成本優勢，但是引入對象存儲之后變成了存算分離的架構，損失了本地計算，整體性能損失 30%以上；其次彈性計算跟分析性能是矛盾的變量，ScaleUp 需要時間，甚至有可能彈不出來，沒有文件緩存，彈性會引起數據傾斜；最后是敏捷分析，海量明細數據直接分析也是很直接的需求。騰訊云原生湖倉產品 DLC 如何應對挑戰DLC 產品定位DLC 的第一個特點，簡單三個字概
130、況便是“全托管”，不同于 EMR，DLC 是開箱即用的，例如交互界面、元數據、安全、Spark DDL Server、Spark History 服務等都是全托管、免搭建的，甚至有很多是免費提供的。第二個特點，DLC 是騰訊云數據湖解決方案的粘合劑，不同產品能夠用一份湖倉數據，帶給用戶低成本，低維護成本的價值。DLC 架構理念接下來講 DLC 的架構理念，DLC 是騰訊大數據自研能力的上云，但是并不是簡單平移部署，產品形態便是最大的差異，DLC 是多租戶的全托管產品，我們秉持兩大原則：保持簡單 KISS、云原生。保持簡單上我們是非常執著的。67騰訊云技術實踐精選集 2022 對于服務引用非常保
131、守，服務能少則少，取而代之的是 SDK 的接入，例如上圖右側的 Presto 的 Local Cache 就不會引入 Alluxio Cluster，Spark 這兒不引入 RSS 服務而是輕量簡單的 Shuffle Manager 等等；降低使用復雜度，DLC 集成了騰訊自研 SuperSQL，去實現統一函數和語法來去兩個引擎無縫切換。上圖右側大部分服務都是托管的，如元數據、調度、權限、DDL 服務、Spark History 等這些服務都是用戶免搭建，開箱即用的，大部分是免費的，而且我們還給到了用戶一定的免費額度，只要配置得當，基本是能滿足客戶需求的。云原生原則：狹義的說，DLC 都是基于
132、容器的，包括計算引擎和各種服務容器化。廣義的說，云原生更應該“長在云上”，DLC 是直接使用云上的對象存儲、云數據庫、云 Kafka、TDSQL 等等全托管 SaaS 服務的。LC 實現 PB 級數據秒級分析回到最開始的問題“高性能”，PB 級數據秒級分析該怎么去做，從三個大維度展開。我們從三個層面出發講，第一從多維 Cache 的角度出發，包括文件緩存，中間結果緩存等；第二從彈性模型出發；第三從三維 Filter 的模型：分區、列、文件出發。68騰訊云技術實踐精選集 2022多維 cache多維 Cache 分了三個角度：1.文件緩存；2.Fragment 結果緩存，中間結果緩存；3.元數據
133、的緩存，重點說說前兩個。文件緩存。我們在 DLC 上線了 Alluxio Local Cache，優點是沒有單獨的 Alluxio 集群，也不占用計算資源，免運維。當然也會有需要優化的地方，比如文件/Split 級別、跨租戶 Cache 緩存數據安全、緩存一致性、彈性影響、監控、黑名單等，這些優化空間 DLC 都會幫客戶完成。在一些情況下，訪問 Cos 的性能有 310 倍的提升。Fragment 結果緩存。優點是不需要預計算，我們知道物化視圖也非常流行，但是物化視圖的利用率往往不好量化，事實上通常很低，而根據訪問行為緩存下來的是用戶行為肯定的；另外是用戶幾乎沒有什么成本，同時也很大程度上降低
134、底層存儲的壓力。當然，還會涉及到一些問題需要大家注意，例如緩存一致性、跨租戶的安全等。性能方面，從來自 Presto 社區的數據看，Raptorx 有接近 10X 的提升。虛擬集群彈性模型剛才講兩種緩存效果接近 10 倍的性能提升，對彈性模型就有了很高的要求，因為緩存的命中是很依賴集群拓撲的穩定性的。另外資源啟動要時間，新拉容器和鏡像最快也要 12 分鐘；最后 Client 預熱很重要，包括各種服務都是 Lazy 加載的 Module 等等，這也都是需要 30 秒甚至 1 分鐘的時間，這跟我們要求的秒級分析就差太遠了。那 DLC 是如何解決這個問題的呢？我們采用了虛擬集群架構，以子集群為最小單
135、位去橫向彈子集群，這樣子集群拓撲穩定，資源跟 Client 都有很好預熱。而且因為子集群的 Query 隔離，子集群也是很容易縮容的。69騰訊云技術實踐精選集 2022多維 Filter 過濾繼續說性能提升，還是 IO 優化，技術也是比較成熟的，只是還不怎么普及。先看第二個，列存 Parquet/ORC，結合引擎 Project 的下推，這樣只有關心的列才會被掃描。第三個分區/分桶也比較常規了，但是最新業界的新特性比如 Dynamic Partition Puning，可以很好地加速分區需要推斷的場景。下面仔細說說稀疏索引，Bloomfilter、Zordering 本質邏輯上是類似的，需要結
136、合引擎的謂詞下推減少 IO 掃描，加速分析。在大數據的海量低成本要求下，稀疏索引可以做到降低存儲成本并且加速分析性能，通過減少數據掃描量達到性能提升。具體分兩步：第一步數據要進行 Cluster，類似的數聚在一起，結合引擎謂詞下推，性能達到 10X 以上的提升。同時也能帶來存儲的下降，這個原理其實很容易理解，類似的數據在一起了，Encodin 壓縮能起到更好的效果。這也是大數據引擎，比如說像 CK、Doris 很重要的性能加速模型。穩定性也是大數據很重要的訴求，前面看到像索引的構建都需要進行大規模的數據 ETL。對于穩定性我們遇到了很多挑戰，包括虛擬集群彈性模型本身減少了彈性引擎的數據傾斜、I
137、ceberg 減少底層 List、Rename 導致任務失敗等等問題。這里我們主要分享下 DLC 的 Spark Shuffle Manager 架構。我們知道騰訊開源了 RSS 的服務 Filestorm，在全托管云原生的場景下我們做了簡化和改造，原理是：優70騰訊云技術實踐精選集 2022先使用本地磁盤，不足的時候 Spill 到 Cos，下面是業界幾種典型的思路，DLC 的做法秉持著減少服務引入、保持簡單、降低用戶成本、減少用戶/服務的運維。效果也很明顯，大部分任務/Task 都會以原有的性能完成，少量數據傾斜的任務/Task 會損失一定的性能，但是依然能穩定完成。DLC 作為全托管的產
138、品，還是要強調一下低成本和易用的特性。COS 湖存儲 VS 自建 HDFS 的成本優勢，其實 80%以上節省來至于 EC、HDFS 要預留資源以及 COS 有各種冷熱分層策略進一步降低成本等?；?EKS 或者 TKE 彈性資源，對比固定資源節省約 50%以上的成本，如果是交互式分析場景，周六周日兩天成本就是節省的，晚上也是節省的，離線是類似的。最后 DLC 是全托管的免運維的一個產品，統一的 SQL 在兩個引擎平滑遷移，SaaS 的元數據、DDL 服務、權限、調度、SaaS 級別的 Spark History 保障了用戶開箱即用，而且這些公共服務大部分免費，有的是有免費額度的，正確使用都完全
139、夠用。第三部分：湖倉背景下的建模新思路71騰訊云技術實踐精選集 2022接下來一起看下，在云原生湖倉架構下，建模有有哪些新思路：第一個，扁平湖倉架構，核心是不再維護復雜的數倉分層，而是把明細層的數據能夠直接高性能分析；第二個是離線增量；第三個，現在業界比較時髦的新方向實時增量湖倉。仔細講一下扁平湖倉的結構，要解釋為什么需要扁平湖倉建模，首先要看一下為什么要一層層去做分層建模，首先是在傳統的數倉架構下，明細數據的分析的性能不夠高，被迫去進行的預計算，同時因為多個結果可能會重復利用一部分公共數據，進行了 ETL 抽取。但是在 PB 級數據秒級分析的能力下，這些幾乎都是不必要的。層層建模的問題：第一
140、是模式是固定的，不夠敏捷。響應需求，從需求對接、歷史數據刷新、測試驗收，一兩個周就過去了；其次是計算利用率往往是低的，尤其 Cube。Cube 雖然命中很快，單 Cube 的利用率往往是個大大的問號，從我們的經驗來看其實非常低；另外分層離線更新是比較慢的，而現在特別火的實時增量更新并不是成熟和穩定，即使落地了對于存儲和計算硬件的需求往往也是很高的。結合前面講的云原生湖倉做性能提升的各種手段，在明細層直接分析的扁平湖倉架構的時代自然是大勢所趨了。當然最好能結合 BI 工具的時序結果緩存，這樣 BI 層都可以省去。72騰訊云技術實踐精選集 2022最后介紹下一個游戲客戶的案例：實時扁平湖倉秒級分析
141、邏輯架構非常簡單直接，數據都是在 Kafka，通過 DLC Spark 去做實時數據的接入，直接寫入幾百張 Iceberg 明細表，并且能夠保證冪等。值得注意的是一個 Kafka 里面有很多張表的數據，保證冪等也有一些比較有意思的邏輯。入到明細表之后，開啟明細表背后的一些優化，用 DLC SuperSQLSpark，進行清洗、合并小文件、以及稀疏索引構建等，最后達到的效果直接用 DCL SuperSQL-Presto 去做秒級分析，最后去對接 BI 的工具，達到一個非常好的分析性能，架構簡單明了，無需各種建模。掃碼獲取完整版演講 PPT73騰訊云技術實踐精選集 2022CDW PG 大規模在線
142、數倉技術構架分享張倩騰訊云數據庫專家工程師騰訊云數據庫專家工程師，中國人民大學博士，具備多年數據庫內核研發經驗，曾在 Teradata 天睿公司以及華為公司高斯實驗室工作多年。加入騰訊后，負責 CDW PG 數據倉庫內核優化器、執行器等多項核心功能研發。騰訊云數倉產品 CDW PG 是一款面向超大規模集群海量數據分析的在線數倉。通過創新的數據轉發平面、全自研列式存儲、分布式延遲物化技術，以及向量化執行引擎等核心技術為用戶帶來極致的數據分析體驗，可以真正將海量數據所蘊藏的價值釋放出來。ArchSummit 2022 北京站上，騰訊云數據庫專家工程師張倩帶來題為CDW PG 大規模在線數倉技術構架
143、分享的分享，主要聚焦 CDW PG 在構架設計以及核心優化上面的一些經驗和思路。CDW PG 發展歷程介紹CDW PG 是騰訊基于 PostgreSQL 自主研發的分布式在線關系型數據倉庫。PostgreSQL 是一個單機版數據庫，我們在這個基礎上開發了一個無共享 MPP 架構，支持行列混合存儲，同時支持超大規模集群，目前集群規?？梢灾蔚缴锨Ч濣c，同時可以支撐超高速的計算能力。74騰訊云技術實踐精選集 2022CDW PG 的整體架構如上圖所示。整體架構演進大規模集群面臨的一大挑戰是集群擴展性挑戰，分布式 JOIN 消耗大量網絡連接和對應資源。對于分布式 JOIN，數據是分布在不同節點上的，
144、數據的分布鍵和分布式 JOIN 的鍵并不是完全一致，這時數據需要重分布，重分布之后再進行 JOIN 連接才能得到最后結果。數據的重分布通過 DN 節點，把本 DN 自身的數據通過模塊連接發送到對應的其他 DN 上。如果 DN 節點非常多，每個 DN 都要和 JOIN 建連，則一個數據重分布就會有很多連接。假如有 200 個 DN 節點，有 100 個并發查詢，如果每個查詢 5 個重分布，這種情況下可以計算出 10 萬個連接。每個連接在每個節點上對應一個進程，對服務器的壓力非常大，也是限制分布式數據庫拓展性的問題之一。原來的集群架構顯然不適合大規模集群，所以我們在這個基礎上開發了異步執行框架，一
145、個新型的分布式架構。在這個架構里，我們會在查詢優化階段分析物理查詢計劃，統一創建 DN 上的各層執行進程，各層執行進程之間不需要建立直接連接，不同層級進程可以異步啟動執行。假設我們有 N 個節點，就會產生 N 個進程數，這是進程數上的優化。我們在連接數上會進一步引入 FN，FN 來負責節點間的數據交互。每臺物理機只需要布置一個 FN 節點，75騰訊云技術實踐精選集 2022FN 節點會負責本臺物理機和其他集群內其他物理機的數據交換。在本機節點上，這個 FN 與 CN 和 DN 之間是通過共享來進行數據交互的，本機和其他的物理機進行數據交互的時候是通過網絡進行。在這樣的分布式架構下，假設有 N
146、個節點，不管 JOIN 有多么復雜，查詢可以有十幾個 JOIN，它們只有 N*（N-1）個連接數。在優化器階段會查詢計劃分片。優化器是根據代價來審核的最優計劃。在單機上的代價是一些算子，每個算子有不同的代價；但在分布式的情況下，數據重分布也有自己的代價。優化器會生成代價最優的計劃，在分布式的計劃里可以看到，Remote Subplan 會有數據重分布節點，數據重分布節點會把下層執行的數據按照一定規則進行數據重分布，生成分布式的計劃之后會變成整個執行計劃，對這個計劃進行分片。分片的原理很簡單，我們對每個數據分布節點下面的 Log 節點作為一個組數，劃分成一個分片，把分片用 FID 編號。每個分片
147、除了 Remote Subplan 節點，下面的計算都可以在本地完成。本地完成之后再通過 Remote Subplan 節點把數據發送出去，串聯起整個分布式的計算。生成這樣一個分布式計劃之后，會下發這個計劃分片到對應的執行進程上，每個分片會在每個執行節點上創建一個進程來執行對應的計劃片段。在這個 JOIN 里會分成兩個 FN 片，會有 FID1 和 FID2，FID2 對數據重分布，然后再跟 FID1 做一個 JOIN，這樣兩個計劃分片在 DN 片會有 4 個進程。這 4 個進程，每個進程會負責執行自己收到的進程，然后把數據通過 Remote Subplan 節點，不會直接建連，而是把數據發送
148、給本機的 FN，FN 負責把數據轉發。不同層級之間的進程是異步啟動執行的，下面的分片和下面的分片是同時啟動執行的，通過 FN 進行數字交互。自研列式存儲我們自研的列式存儲支持按照行存儲和列存儲建表，列表和行表之間可以相互操作，行列表之間的混合查詢保證事務一致性。很多查詢都是點查詢或者是只會操作比較少量的數據，在這種情況下，我們點查每次只出一行數據，在這個行數里面可以獲取這一行數據進行處理。但是在 AP 場景中，對于寬表來說它的列會非常多，每次用戶操作的時候只操作其中幾列，比如說只查名字或者只查名字和部門，或者只查名字和年齡，后面的幾百上千列都不會管。如果還按行存儲就會浪費很多 IO。后面的列數
149、都是我們需要的，每一列單獨存儲，多個列邏輯上組成一行，一次的磁盤 IO 只包含一列數據。這種情況下，因為這一個數據文件只存儲單列的數據，它的數字類型都是固定的，很方便做數字壓縮，也能夠提供比較高的數字壓縮效果。在我們的數據庫里支持行列存儲，既可以在行存表和列存表，可以同時互相操作，也可以查詢復雜的操作，行列表之間的混合查詢能夠保證數據的一致性。76騰訊云技術實踐精選集 2022上圖介紹了我們自研的列式存儲，主要包含兩部分。第一部分是左邊的表，會有一些信息，有 C1 文件和 C2 文件，每個文件里面的數據是按照 Silo 來倉儲的，對應的 Silo 信息會存儲在這個表里，同時 Silo 的輸出上
150、，事務的信息也是通過這個表來保證的。在這樣的基礎上，可以看到這種數據結構比較適合大批量的數據導入，也就是說我們在做大批量數據插入的時候很快會填滿，再寫入下一個 Silo，內存的效率最高。但是在很多業務場景中，這個場景并不是很單一，也有可能除了大批量的數據插入之外，還有一些小數據量的操作。這種情況下如果我們還用 Silo 來存儲就會顯得效率比較低。為此我們開發了一個 Stash 表，它是一個行情表，主要目的是在用戶進行小數據量操作的時候，這些數據都會進入到 Stash 表里，提供一個像行存一樣的性能和訪問能力。在后臺我們會有一個 Stash Merge 操作，會定期 Merge。數據積累到一定程
151、度，我們有了整個 Silo 的數據，就會把它生成一個 Silo，從而獲得批量性能提升，這對用戶來說是完全無感知的。分布式集群里一個比較難的問題是保證分布式數字一致性。我們是基于 Timestamp 的分布式提交協議。我們會有一個 GTS 集群，GTS 集群包括 GTS 組和 GTS 位。GTS 集群是提供給數據控制節點，它是從內部開始，內部單向并且唯一由 GTS 維護，由硬件來保證使用源的穩定度。在這個情況下，加上數據庫內部的 MVCC 的存儲能力（MVCC 是整個并發控制的基礎），這兩個結合起來提供了分布式事務的一致性。GTM 單點可靠性是由 GTM 主備來支持的，也就是說主節點可以通過對外
152、提供服務來保證分布式事務的一致性，然后主備之間是通過日志簿時間戳的狀態來保證 GTS 的可靠性。對于單點可靠性，數據庫里面如果是非常繁忙的業務，TS85 服務器每秒能夠處理 1200 萬的 GTS，可以滿足絕大部分業務團隊的需求。77騰訊云技術實踐精選集 2022在列存的存儲格式中，我們進一步提供了延遲物化掃描優化。傳統的方式是把數據掃描上來做對應的計算，生成對應的結果。但在列存的數據格式下我們可以提供一個優化的方式，比如說有一個多列計算，可以先掃描其中一列，如果都不符合條件可以都不掃描，第二列直接跳過，或者我們掃描的這一列里面只有一個數據是符合條件的，在對第二列計算的時候，可以掃描對應的數據
153、位置來計算，相比傳統的方式需要掃描所有數據，這種方式可以減少很多 IO，提升掃描和查詢計算的性能。同樣這個列存也是支持索引的，我們現在支持的是兩種索引，一個是 B-Tree 索引，一個是 Hash 索引。列存的 Stash 表后臺的自動合并能力是為了小數據量插入和小數據量更新準備的。在這種情況下，數據會進入到 Stash Table 里，然后 Stash Table 會自動做一個 Stash Merge 到 Silo 表里。我們的列存表是支持創建配套的 Stash 緩存表，如果是批量的插入，中心會直接寫到 Silo 表，如果是小數據量插入，中心會寫入到 Stash 表，但這對于用戶是完全透明的
154、，是后臺自動判斷的。后臺也會有一個 Stash Merge 的進程，自動判斷這個 Stash 表里的數據大小，進行列存格式的整理。也就是說把 Stash 的表格數據 Merge 到 Silo 里，通過列式加 Silo 表能夠達到性能統一。執行引擎能力優化我們執行引擎的能力優化分為幾個部分，首先是多級并行能力的提升。我們是分布式集群，天然就提供節點級的并行。在每個 DN 內部，我們又提供了進程級的并行。某個 DN 會有計劃分片，計劃分片在傳統的數據里會啟動一個進程完成它。在我們的集群里面，對于同樣的一個計劃分片，我們會生成多進程并行。一個簡單的 Stash 操作，如果有兩個進程并行 Stash，
155、效率會提升 50%，每個進程只需要處理一半數據。上面做計算時也是兩個進程并行執行，最后得到的結果是兩個進程結果的疊加。在進程級的并行基礎上，我們還提供了 SIMD 指令級并行。在做計算時可以通過 SIMD 進行指令級并行。Silo 頭部會定義一些數據特征，包括 CRC 校驗、壓縮信息、Bitmap 信息、數據壓縮文件，最后有一些頁面對齊。我們提供了列存文件格式之后，由于每一列的數據格式是一定的，我們就可以提供一個比較高效的數據壓縮算法。在這里我們提供了三層壓縮級別，分別是 Low、Middle 和 High。選擇了對應的壓縮級別之后，數據庫內部是根據這個列具體的數據類型來選擇不同的壓縮算法，。
156、這個壓縮算法是內部選擇，用戶不用自己操心。我們寫入的時候會有一個輕量級壓縮，再一個是透明壓縮，然后是寫入 Silo 文件中，然后讀取到內存中計算，這個過程對用戶是完全透明的。High 的壓縮比會達到 5.5，Low 是 3.5 左右。78騰訊云技術實踐精選集 2022我們的向量化執行引擎也是基于自研的列式存儲上開發的執行引擎。傳統的執行引擎是采用火山模型，每次處理一個原子，邏輯比較簡單，但效率比較低。數據量非常大的時候，比如我們有非常多的源組庫的時候，函數調用和指令級調用都非常多，CPU 大部分時間中數據和指令的命中率都比較低，內存的命中率也很低，沒辦法利用 SIMD 能力。向量化產品執行引擎
157、每次不是處理一條數據，是處理一組數據。它會顯著減少函數調用的開銷，提高 CPU 的執行效率。我們這個列存天然可以將一組原子變成一組列存向量，從列存里面，我們可以讀取一個向量數據再發送給算子，算子就可以對這一組數據進行計算。這樣我們既可以減少函數的調用，又可以實現 SIMD 指令來加速算子執行。我們提供的另外一個能力是 Plan Hint 自動調優。很多場景都是非常復雜的查詢，會有非常多層。在這種情況下，我們的順序和對應的每個表選擇什么，都會影響 Plan 的執行效率。傳統的優化器是通過我們收集的表統計信息來決定查詢的執行計劃。但統計信息的收集是通過數據采樣大概模擬出這個數據到底是什么樣的，顯然
158、不太精確。而且由于統計信息收集不及時，會造成 Plan 的劣化，統計收集會有代價，在大數據量的情況下需要很長時間。在這種情況下，我們提供了 Plan Hint 的能力，會把這個計劃先執行一遍，收集一下計劃中執行的信息，生成 Row Set Hint：每個表里選擇了什么樣的方式，順序是什么樣的，數據存儲方式是什么樣的，并行執行的并行度選擇什么樣的，每一步算子執行實際的數據量是什么樣的。生成后還會把信息反饋到 Plan Hint 里面，根據這個信息生成一個新的執行計劃，再對比新的執行計劃和之前的執行計劃，然后把新的執行計劃再次通過 Plan Hint 執行，循環往復，最后能夠生成比較優的執行計劃。
159、這個生成過程是完全自動的，用戶可以在后臺比較空閑的時間來執行，或者用戶有一些調優需求的時候可以自動完成。第三是集群資源管理功能。在整個集群可能不會承載一個業務，有可能會有各種不同的各部門業務，都需要用這個集群的資源。在這種情況下，我們需要對集群資源進行管理和劃分。比如說我們做一些并發的控制、內存的控制、CPU 的控制，我們通過 Leader CN 節點統一規劃資源組使用情況。資源組里會有三個定義，一個是我們的并發，指我可以同時發起多少個查詢；內存控制，決定我可以使用多少內存；還有 CPU 控制，決定我可以使用的 CPU。這樣一個資源組是在 Limit 節點上進行統一規劃控制，優化器會根據 ME
160、MORY_LIMIT 設置 Query 中不同算子的 work_mem 內存占用。GPU 通過 cgroup 來配置占用百分比或者綁核，所有當前資源組啟動的后端進程會掛在對應的 cgroup 上。這是一個非常便利的操作。我們開發的 TDX 服務器負責外部數據源導入和導出的操作。CDW PG 引擎可以定義外部表與 TDX 服務器資源進行綁定。數據由 DN 節點并行導入與數據重分布，充分利用分布式系統資源。TDX 服務器支持并行多任務導入導出、管道、錯誤表等高級功能，提高用戶體驗，相比傳統 Copy 入庫出庫功能有數倍提升。我們還有多平面的能力，意思是說我們可以提供兩個平面，一個是讀寫平面，還有一
161、個是只讀平面。通過這樣兩個平面可以做到讀寫分離，也就是說讀寫請求可以進入到讀寫平面，大量讀請求可以通過只讀平面來完79騰訊云技術實踐精選集 2022成。內部是通過 DN 之間的內部復制來保證兩個平面之間的數據一致性。后續規劃上述內容已經在騰訊云上線，包括異步執行框架、FN 能力提升、自研列存儲，分布式延遲物化技術。我們后續在構架上會進一步優化，包括列存優化升級、向量化引擎深度優化、算子并行計算優化、SIMD 優化場景覆蓋。我們還會持續打造生態，持續融合 PG 社區能力，在兼容性上會有持續的功能提升，還有大數據生態對接和機器學習算法支持。掃碼獲取完整版演講 PPT80騰訊云技術實踐精選集 202
162、2云原生數據庫管控探索和實踐孫勇福騰訊云數據庫專家工程師云原生數據庫 DBPaaS 平臺“云巢”負責人，8 年工作經驗。從零設計騰訊云數據庫云原生 DBPaaS“云巢”平臺，并參與多款騰訊云數據庫產品從零到一落地。致力于提供易用/穩定/安全的數據庫庫產品服務，具備豐富的數據庫產品研發等技術經驗。云原生是未來發展的潮流，同時數據庫是用戶業務應用的核心存儲組件，如何利用云原生技術手段和數據庫結合，提供更好的數據庫產品易用性和穩定性是一大重要關鍵。ArchSummit 2022 北京站上，騰訊云數據庫專家工程師孫勇福帶來了題為云原生數據庫管控探索和實踐的分享，主要集中在 Kubernetes 上如何
163、構建有狀態管理服務方向進行深入探討，并在此基礎上提供一整套容器化管理數據庫的解決方案的新思路。PaaS 平臺背景70 年代 SQL 數據庫誕生后，數據庫技術變革日新月異，迭代非常迅速。從 SQL 發展到 NoSQL 和 NewSQL，數據庫也愈加復雜。與此同時，云計算形態也日新月異，從單體到單云再到混合云，多技術、多架構形態將成為未來常態。如何在數據庫日新月異及多技術平臺形態存在的背景下更好地服務客戶，對云數據庫廠商來說也是巨大的挑戰。針對這些挑戰，騰訊云數據庫中心有著自己的思考和應對。81騰訊云技術實踐精選集 2022騰訊云數據庫的產品矩陣有兩大模塊，PaaS 產品矩陣和 FaaS 產品矩陣
164、，有 200 多款數據庫產品。眾多數據庫產品技術架構不統一，大大增加管理難度。云廠商作為數據庫服務的提供者，需要給用戶提供全托管的企業級數據庫服務，并且也要提供一致性的產品體驗、統一的用戶界面來提升資源使用效率，給云廠商帶來了巨大的困難和挑戰。數據庫演化的核心是如何把云廠商多年數據庫管理的經驗輸出到用戶使用。但煙囪式的發展會帶來一種問題，無法對新興技術的數據庫產品快速提供復用和知識，導致新的數據庫產品形態往往比舊數據庫形態落后較多。除此之外，各個產品之間煙囪式的發展、團隊之間技術棧不統一，會導致研發效率的低下。這些單獨的產品作為一體化解決方案時，打包、輸出起來是非常復雜的。云廠商也在考慮資源成
165、本，煙囪式的發展會存在資源利用不充分的問題。帶著這些思考，我們主導和設計了數據庫 PaaS 平臺。我們對 PaaS 平臺提了四個規范要求：1.這個平臺必須有規范標準。整個平臺要統一標準，減少硬件設施的適配工作，減少影響上層的服務邏輯。2.我們也把安全穩定性作為比較高的目標。數據庫是用戶使用場景中很重的資產和財產。我們作為數據庫服務廠商，一定要保證用戶財產的安全。保證數據庫的高可用以及數據安全性也是我們平臺一項重要的指標。3.我們平臺化的思路是實現數據庫公共能力的沉淀和經驗能力的沉淀，形成蓮花效益的相互復用。這樣可以降低數據庫產品的成本，也能給外部客戶實現規?；当?。4.有了通用的 PaaS 平
166、臺，可以通過標準的 PaaS 平臺構建我們的 PaaS 護城河。傳統的煙囪式發展很難做到這一點，因為不同的 PaaS 平臺的模型和能力都是不統一的。有了標準平臺后，可以站在標準上再圍繞客戶的某些場景或者行業屬性去提供 SaaS 的增強能力，提高用戶黏性，拓寬數據庫的護城河?；谶@樣的設計理念，我們有了以下分層設計：82騰訊云技術實踐精選集 2022整體架構演進我們選擇了 Kubernetes 作為基礎底座。但 Kubernetes 的優勢是在無狀態服務領域，我們在狀態服務領域更標準化、更成熟。我們就要圍繞 Kubernetes 去解決有狀態服務的困難，這些也是我們的云數據庫“云巢”設計的核心。
167、云巢是按照平臺化的思路演進的。如果只是使用社區的 Operator，只是簡單把我們之前通過物理機的方案、煙囪式的發展，變成了以 Kubernetes 底座為平臺去做煙囪式的演進和發展，完全沒有解決煙囪式發展的問題。所以在我們研發初期直接放棄了 Operator 的設計方案。云巢架構設計分了四個層面。資源管理部分可以理解為通過云原生的 Kubernetes 設計實現一整套的資源調度輕量級管理系統，滿足資源高可用、資源生命周期入口、配置管理、面源管理等需求。集群管理和流程管理提供業務作業平臺，實現業務的復用性。運維模塊提供發現、告警和預測機制。在底層的云巢設計之上，我們再通過業務產品的接入實現業務
168、場景界面產品化適配。同時我們整體的 IS 層是構建于整個騰訊云的 IS 層之上，可以形成復用，有了新的技術紅利的演進時可以很快觸達云巢，再通過云巢觸達各個 PaaS 產品。做整體架構設計面臨的第一個問題，是對這種數據庫領域資源模型的抽象。因為數據庫領域涉及到的產品形態非常多，比如說主從關系、多層樹狀類型、網狀結構等。這些產品之間的數據模型如果不統一，就很難統一抽象資源管理系統，所以第一步要收歸數據模型。首先要根據模型的分類分為主從類型、樹狀類型和網83騰訊云技術實踐精選集 2022狀類型，模擬一個分布。每款產品都是由組件組成的，只是組件的個數有差異而已?；谶@一點，我們通過 Cluster 保
169、持實例元數據的概念，通過 Set 標識組件的屬性集合，通過 Pod 承接數據節點的角色。有了這樣一個標準設計后，我們很容易構建自己的資源管理系統，比如統一發貨、升級、銷毀或降級等。我們還可以圍繞這樣一個標準模型去抽象自己的系統，包括統一的監控體系、管理體系、流程細化等。這是云巢設計的基礎和核心。接下來我們要處理節點和節點之間的關系，把這種關系叫做資源模型的屬性，所以我們會繼續往下沉淀和思考我們的屬性模型，通過關系和資源模型的配合，滿足數據庫產品形態所依賴的所有要素。因為屬性是領域知識，不同產品所需要的領域模型、領域知識不一樣，變化的部分是領域知識。我們對變化的部分分析和抽象，定義每一類模型的標
170、準定義。比如說調度策略，我們會定義一個標準策略的模型是什么樣的，這個模型就會當作領域模型的輸入和輸出，控制器可以按照領域模型的輸入和輸出構造設計。我通過領域模型的標準輸入和輸出以及控制器的組合關系，就可以很快、很靈活地拼接出每款產品個性化的訴求。在發布過程以及實例運行過程中，需要實時對數據庫的進程和實例進行靈活控制，怎樣管理這樣的業務容器呢？設計方向有兩個，分別是 Client 模型和擴容器模式。為什么我們沒有選擇擴容器？因為擴容器存在以下問題，它整體架構比較臃腫，還有業務容器和其他屬性進程存在更新不同步，會影響整體的 SLA，這對 PaaS 服務來講是完全不能忍受的。所以最終我們選擇了可以集
171、中管理，靈活控制的點。同時基于這個設計，我們會把一些命令和編排進行中心化設計，放到中心化的控制器中。比如說對配置文件的修改、腳本命令的下發、執行以及服務發現等都會放到中心化控制器操作，用戶通過控制單元管理 Pod 節點。有了控制，我們的第一個實際目標是發貨，發貨過來才能給用戶使用。我們發的是有狀態服務的實例。每個節點都按照數據啟動就好，但是這個方案沒辦法滿足發貨效率，因為我們數據庫都是節點化的，節點數比較多，隨著節點數的增加，發貨效率會線性下降。針對發貨效率的要求，我們分析整個 Pod 的生命周期，一個是 Init-Container 階段，一個是 Pre-Slop 階段。通過啟動策略去選擇
172、ZK 優先啟動，然后下發 CK 去實現啟動。這樣不管任意節點，只要資源足夠，就可以并行發貨，效率快速提升。還有一個問題，我們實際的節點啟動不是單純啟動，還依賴于一些復雜的配置。比如說啟動需要 IP，但是只有在節點發貨完成之后才能夠獲取到，所以要求我們實現一套動態的數據獲取機制來滿足 Pod 節點下發的要求。我們有一個中心化的實例設計，不管是靜態還是動態的源數據都是 Pod 的縮影。同時 Translate 層不能有84騰訊云技術實踐精選集 2022侵入性。我們通過配置模版渲染出最終想要的配置文件，再把配置下發到用戶所需要的目錄，在運行過程中下發和更新，用戶不管是發貨過程中，還是運行過程中都可以
173、修改配置。通過這樣的方案設計，我們實現了云巢配置介入和平臺編碼的解耦。用戶在接入云巢的過程中，只需要把自己的算力模型適配好，把自己的模板寫清楚，就可以很快速接入云盤。除此之外，實例運行過程中會遇到各種各樣的問題，如 Pod 故障，驅逐/刪除等。針對各種各樣的異常，怎么實時保證服務高可用、數據高安全性，我們也有一些對策。我們設計了云巢的探針服務，還有多維度的數據采集指標。通過多維度的采集，再通過 HA 的決策大腦，根據決策樹模型選擇合適的 HA 的落地路徑來滿足 HA 的要求。為了保證實例安全性，云巢主要涉及到幾個方向。首先是基于 NetworkPolicy 限制最小化網絡訪問權限。為避免某一個
174、用戶的安全漏洞影響其他節點的使用，我們通過 Kubernetes NetworkPolicy 的手段實現網絡的隔離。對于用戶數據鏈路層面，我們會通過整個騰訊云的安全組機制接續。無論是數據鏈路層還是容器層面，我們都做了安全保護。還有一個瓶頸是，Kubernetes 的資源非常有限，一個 Kubernetes 只能支持 15 w 個 Pod，但云廠商會有上百萬個 Pod。我們有一個合理的思路，通過水平擴容 Kubernetes 去滿足資源的無限增長，我們抽象了集群管理，通過集群的源數據的維護以及集群控制器的合理設計去屏蔽業務對多集群管理的細節感知。通過這個解決方案可以快速擴展資源模型，最終達到幾百
175、萬個節點的管理規模。解決了規模之后，隨著產品越來越多會遇到另外一個問題，就是完全不能避免性能的損耗，尤其是網絡的損耗。于是我們提出了一個新的網絡解決方案，也是利用我們云原生的能力，給每個 Pod 插一張網卡。在數據流量使用過程中，數據流量是直接打到容器網卡上。這樣的設計可以把性能提高 10%以上。下一個問題，上了云巢之后，我如何量化感知到一款 PaaS 產品的性能指標、高可用指標？我們可以利用云原生的紅利，借用一個平臺去模擬機器故障、網絡故障或者節點故障等，同時通過可編排的流程引擎、主動觸發測試來獲得量化指標。這樣會給所有上云巢的產品提供一個門檻，只有達到一定的指標值之后才能在上面售賣，這樣外
176、部用戶的體驗感更好，口碑有了保證。在整個 PaaS 模型之上，我們還在發力 SaaS 產品。隨著云廠商發展，PaaS 層面的同質化相當嚴重，這時候需要 SaaS 提高護城河和用戶黏性，通過 SaaS 打入用戶的個性化應用場景或者一些行業屬性，綁定這些行業，或者給這些行業的客戶提供一些更具應用性的解決方案，讓用戶的體驗更順暢。85騰訊云技術實踐精選集 2022未來展望數據庫可能會出現壓力過大、負載過高等問題，響應比較慢。傳統上會安排人工分析，再 Kill 會話，重啟數據庫，HA 主備切換。未來云巢的自治場景可以 7*24 小時做異常診斷，通過合理的智能分析，自動做流量阻斷或者 SQL 調優，給云
177、廠商提供更好的服務體驗。隨著云廠商在公有云的不斷沉淀和實踐，未來我們也會回歸社區。通過回饋社區生態能讓大家獲取這些福利，同時通過社區的生態點來補足用戶個性化場景，能夠形成行業規范，反哺騰訊云上 PaaS 產品。掃碼獲取完整版演講 PPT86騰訊云技術實踐精選集 2022騰訊云原生數據庫 TDSQL-C 架構探索和實踐王魯俊騰訊數據庫內核開發工程師曾就職于螞蟻金服、阿里云等，在數據庫內核領域有多年開發經歷，對分布式系統、數據庫存儲引擎等方面有豐富經驗。TDSQL-C 是騰訊打造的云原生數據庫產品，其高可用、高可靠、高性能的特性已經被越來越多的用戶認可。在 DIVE 2022 全球基礎軟件創新大會
178、（北京站）上，騰訊數據庫內核開發工程師王魯俊帶來了主題為騰訊云原生數據庫 TDSQL-C 架構探索和實踐的分享，為大家介紹 TDSQL-C 總體架構和核心能力的持續演進現狀，并重點介紹 TDSQL-C 在可用性、可靠性和性能方面的工作，同時結合用戶場景分享 TDSQL-C 在實際應用中的實踐經驗。產品架構介紹騰訊云原生數據庫早期也曾采用傳統架構實現，但實踐中存在很多問題：傳統架構的實例存儲上限完全受限于本地磁盤容量，擴展成本高昂且操作復雜。用戶數據較多時需要分庫分表，帶來很多分布式事務問題。而用戶希望一個實例有 100T 以上的容量，且存儲容量可以快速透明擴展。傳統架構基于 Block 復制，
179、普通的異步或半同步復制方式可能丟失數據，同步復制方式的性能損失較大。87騰訊云技術實踐精選集 2022用戶要求數據不丟失（RPO=0），且數據有多副本容災，可靠性滿足要求。傳統架構可用性不足，HA 或宕機重啟后一段時間（分鐘級）不可用，且主備副本延遲較高，有些達到小時級。用戶期望能夠快速切換 HA，實現秒級恢復、回檔，且副本時延在毫秒級。傳統架構水平擴展時需要復制一份原有數據庫實例數據，再建立同步關系。才能真正水平擴展；創建只讀副本時要把原始數據復制過來，然后搭建主備同步，只讀副本才能開始工作，過程可達小時級別。用戶則希望實現秒級副本擴展。騰訊云針對這四方面的用戶需求采用了存儲計算分離的架構，
180、就是 TDSQL-C 的核心架構。它的存儲是云存儲，可以水平擴展，理論容量無限，對每一份數據都有多副本來保證可靠性。數據現在分散在云存儲的各個節點上，可以做持續備份、運營回檔等功能。在可用性方面，數據的分片可以并行恢復、并行回檔，時延更低?？蓴U展性方面，新建只讀副本時數據不需要復制，只需要對數據做共享操作，再構建增量的數據復制即可。TDSQL-C 架構整體分為上面的計算層和下面的存儲層。計算層有一個讀寫節點可以提供讀寫請求，還有多個只讀節點可以提供讀請求，也就是上圖中的 Master 和 Slave 節點。讀寫請求進入后，Master 節點產生數據修改，然后把修改產生的 InnoDB 的 Re
181、do Log 下傳到存儲層，同時會把 Redo Log 分發到自己 RO 節點上。88騰訊云技術實踐精選集 2022用戶場景實踐TDSQL-C 的典型客戶場景如下：1.Serverless有時業務端預測未來的需求持續上漲，所以會提前準備數據庫實例，但實際需求卻偏小，最終會造成浪費。但如果突發情況下實際需求暴漲，實例資源無法立刻跟上，又會對業務造成嚴重影響。理想情況下，資源容量應該與真實業務需求同步變化，隨時保持在比真實需求略高的水平。TDSQL-C 實現了智能化的極致彈性，可以根據負載來快速啟停實例。TDSQL-C 還實現了按需計費，可以按秒計量、按小時結算，避免浪費。2.彈性擴容有些業務每天
182、都能產生大量數據，且對單庫容量要求很高；有些業務如開發測試場景，某一次測試后數據庫實例直接刪除，生命周期非常短；有些歷史庫場景中歷史數據只存儲最近一段時間，老數據直接刪除來節省成本。針對上述場景，TDSQL-C 支持按需擴容，不需要預先進行存儲規劃；還支持自動回收，按實際使用容量計費等。存儲層負責管理所有數據，包括數據頁面、InnoDB 層的 Segment。當 Redo 日志發送到存儲層之后，Segment 負責 Redo 日志的回放。整個存儲層架構在 COS 存儲服務上。TDSQL-C 的存儲可以自動擴容，最大提供超過 1PB 的容量，最大支持 96 CPU、768G 內存，只讀性能超過
183、100 萬 QPS，讀寫超過 45 萬 QPS。該架構實現了秒級故障切換、秒級快照備份和回檔，且存儲和計算層有足夠彈性，可以實現一定程度的 Serverless。需要擴展只讀性能時，該架構很容易增加只讀節點。TDSQL-C 現在最多可以掛 15 個只讀節點，且在讀寫節點和只讀節點之間只有毫秒級延遲。整個工程是基于 MySQL 代碼庫演化來的，所以 100%兼容 MySQL。89騰訊云技術實踐精選集 2022系統關鍵優化以下是 TDSQL-C 支撐相關場景的關鍵優化：可以看到 TDSQL-C 對比傳統 RDS 數據庫，在停機時間、啟動時間、事務恢復時間和性能恢復時間上都有巨大優勢。2.二級緩存二
184、級緩存是 TDSQL-C 在存儲計算分離架構下所做的創新優化，也是對這種架構的重要補充。例如存儲層水平擴展后數據量膨脹上百倍，但計算節點的 Buffer Pool 容量沒有太大變化，意味著相同大小的 Buffer Pool 要服務更多數據。由于 InnoDB 的 Buffer Pool 一定程度上承擔了讀緩存的作用，意味著讀緩存的效率可能會下降，對性能影響較大。1.極速啟停3.備份回檔很多場景對備份回檔要求較高，如金融行業對備份速度和備份時效性都有很高要求，涉及到頻繁回檔的游戲業務對備份回檔速度要求較高。TDSQL-C 支持持續備份，存儲分片可以根據備份點獨立備份，同時可以設定全局一致的備份點
185、來備份。TDSQL-C 還支持每一個分片并行回檔，各自的數據全量、增量備份，并且可以并行回放自己的日志。另外，TDSQL-C 還支持 PITR，可以快速恢復到數據庫任意一個時間點的狀態。90騰訊云技術實踐精選集 2022其次，傳統 RDS 的 Buffer Pool 和本地的磁盤空間存儲中間沒有其他層次的硬件存儲設備，但在存儲計算分離架構下數據存在遠端機器上，需要通過網絡訪問其他機器的 SSD。這之間有至少兩個層次的硬件存儲設備，一個是 SSD（本機硬盤），另一個是持久化內存。我們將這一類的存儲用作二級緩存，能夠有效減緩 IO bound 場景下命中率較低的問題。這種方式的運維成本也不高，因為
186、 SSD 的成本遠低于內存。3.極致伸縮存儲功能下放到存儲層后，存儲層有了存儲池的概念。這樣可以把存儲空間擴展到整個存儲層，所有存儲空間都池化。這樣頁面回收之后可以在物理上真正刪除，而不是只標記為刪除，這樣能降低客戶的存儲成本，實現按需計費。4.極速備份回檔現在數據分散到了分布式存儲上，分布式存儲包含很多存儲節點，本身還有一定計算能力。所以每個實例、存儲節點都可以獨自備份，也就是自治備份。有時候我們還需要全局一致的備份點，這時有計算節點負責協調，做統一備份?；貦n也是并行的，每個計算節點都可以獨立做自己的回放。根據測試數據來看，1TB 數據的備份時間用 RDS 實例需要 61 分鐘，用 TDSQ
187、L-C 只需 21 分鐘；1TB 的回檔恢復時間，RDS 需要 168 分鐘，TDSQL-C 也只需 22 分鐘。5.Instant DDL 和并行構建索引Instant DDL 是 MySQL 8.0 的新增功能，是指用戶在新增列、修改列類型、刪除列時，實際上僅僅修改元數據就可以直接返回，這樣注冊時間非常短。原來重建表索引時都是單線程構建，先掃描所有主表數據，再根據每一行數據生成對應的索引行信息，生成臨時文件。之后對這個臨時文件按照索引行的索引鍵排序，再將數據導入，完成構建。我們針對這里做了并行優化，包括并行掃描、并行采樣和并行導入，很多場景提升到 2 倍以上的性能。91騰訊云技術實踐精選集
188、 2022產品未來演進我們探索的第一個演進叫 Global Database：上圖左邊有一個 Primary 實例，現在新增了一個 Log Store 模塊。它負責接收日志、分發日志，可以提升日志的響應速度和整體的 IO 吞吐量，進一步提升寫性能。另外 Primary 實例與圖右的 Standby 實例可以通過各自的 Log Store 來建立數據復制鏈路，這樣數據就擴展出來一個只讀節點，從而可以讀擴展，而且是跨 Region 讀。另外我們通過這種方式實現了跨 Region 容災，這對很多金融業務來講是剛需。第二個演進是計算下推。我們的存儲實際上擁有一定的計算能力，所謂下推就是利用它的計算能力
189、。例如讀下推（頁面內計算下推），不用將索引的葉子節點讀入 Buffer Pool，而是直接將下推條件發給存儲，返回符合條件的 Record。又如讀下推（undo 頁面間的計算），對于數據的歷史版本掃描下推到存儲層完成，內存不讀取頁面，僅獲取最終結果。還有寫下推，特定頁面的修改直接在存儲層進行。92騰訊云技術實踐精選集 2022總結騰訊云原生數據庫 TDSQL-C 繼承了傳統架構下的云數據庫 1.0 的優勢和競爭力。我們面向云上用戶場景分析其業務特性，持續提升產品的可用性、可靠性、可擴展性和性能，進一步提升了 TDSQL-C 產品的競爭力。未來我們還會繼續面向客戶需求，跟進新硬件的發展，再去探索
190、表現更好的新型架構。掃碼獲取完整版演講 PPT93騰訊云技術實踐精選集 2022金融級分布式數據庫 TDSQL 升級版引擎架構和關鍵技術介紹韓碩騰訊云數據庫高級工程師北京大學博士，研究方向包括分布式數據庫、圖數據庫、存儲引擎優化等，在 SIGMOD 等數據庫領域頂級會議上發表多篇論文。2019 年博士畢業后加入騰訊計費，主要負責 TDSQL 存儲相關的研發。TDSQL 是騰訊云發布的一款全新自研的分布式數據庫產品，具有完全兼容 MySQL、分布式事務全局一致性、彈性擴縮容、智能調度管控、在線表結構變更等關鍵特性。金融級分布式數據庫 TDSQL 升級版引擎聚焦于適配金融級敏態業務，在頻繁進行模式
191、變更，數據流量陡增等敏態場景下，實現彈性伸縮變更對業務透明無感知。ArchSummit 2022 北京站上，騰訊云數據庫高級工程師韓碩帶來分享金融級分布式數據庫 TDSQL 升級版引擎架構和關鍵技術介紹，介紹 TDSQL 升級版引擎的架構設計，以及彈性伸縮特性的實現原理。TDSQL 升級版引擎架構TDSQL 是騰訊自研的，面向企業金融級應用場景的分布式數據庫產品，它最早誕生于騰訊百億級賬戶規模的金融平臺。目前，TDSQL 產品已經在金融、政務、電商、社交等客戶得到廣泛應用，奠定了金融級高可用、強一致、高性能的產品特性和口碑。全國前 20 的銀行里有將近半數都在使用 TDSQL，有力推動了國產數
192、94騰訊云技術實踐精選集 2022據庫的技術創新與發展。隨著我們業務場景的不斷增長和復雜化，業務形態、業務量會超過預期地增長，業務的敏態發展對于我們數據庫的底層技術也提出了具有敏態能力的要求。我們已經投產的 TDSQL 版本應對這些業務的敏態變更時，有以下痛點需要改善：兼容性：建表需要手動指定 ShardKey。運維：存儲層擴容需要 DBA 發起，部分事務會中斷。模式變更：Online DDL 依賴 Pt 等工具。去年騰訊云發布了 TDSQL 升級版引擎架構，針對我們不斷變化的敏態業務和以前的痛點做了改善。新架構實現了模式變更，可以大幅度提高數據吞吐量，有效應對業務變化，還具有數據形態的自動感
193、知特點，使得數據能夠根據業務的負載情況進行動態遷移，降低分布式事務的比例，從而獲得比較好的擴展性能。上圖是升級版的架構圖，分為計算層、元數據管理層和分布式存儲層。升級版引擎技術亮點可以總結為四部分：MySQL 兼容、分布式、低成本，非常適合大規模業務量的業務。高可擴展性，計算/存儲資源彈性擴縮容。95騰訊云技術實踐精選集 2022 事務模型具有全局讀一致性，圍繞管理層 TDMetaCluster 統一分配全局唯一遞增事務時間戳，來做數據的一致性判斷。計算節點是在線模式變更，目前已支持在線操作、索引操作。升級版有三大模塊，首先是計算模塊 SQLEngine，內核完全兼容 MySQL8.0。計算層
194、為多主架構，每個 SQLEngine 節點均可讀寫，SQLEngine 之間通過一定方式刷新表結構變更等信息。新版改造為無狀態化設計，移除各種有狀態化數據，多線程替換為協程框架。交互層 SQLEngine 從 MC 獲取全局事務時間戳和路由信息，然后返回。存儲模塊 TDstore。架構是基于 LSM-Tree 和 Multi-Raft 的分布式 KV 存儲引擎。數據方面，Region 是基于 Raft 同步的多副本存儲管理單元，數據根據 Key 范圍分布在不同 Region 上；Region TDMC 調度下可發生分裂、合并、遷移、切主等操作；交互層面：TDStore 接收來自 SQLEngi
195、ne 的事務請求，充當分布式事務的協調者角色，處理后返回結果；每個 Region 的主副本負責接收和處理讀寫請求；管控模塊 TDMetaCluster。主要工作是高效生成和下發全局唯一的事務時間戳，管理模塊的元數據（比如 TDStore 和 SQLEngine 元數據），管理 Region 數據路由信息，以 Region 為基本單位進行負載均衡和存儲的均衡調度。負載均衡調度要考慮負載熱點，管控模塊會把熱點 Region 打散到不同的存儲節點上，也需要兼顧性能影響，還要對 Region 進程做一些合理的劃分。對于兩階段提交的模型，我們會把進程通過合理的 Region 調度和劃分，把兩個階段的事務
196、變成一階段的事務，從而提升效率。關鍵技術介紹分布式事務TDSQL 升級版分布式事務模型遵從了分布式事務的原則性。對于涉及到多個 Region 的事務，所有的參與者要么提交成功，要么全部回滾，通過兩階段提交模型杜絕半提交事務情況的發生。與經典的 percolator 模型相比，我們把協調者下沉到了存儲層 TDStore，選取其中一個作為協調者。我們會把未提交事務的緩存到 TDStore，下沉之后做一個落盤。因為我們的存儲層會有過期版本的清理，并且我們作為時間戳的分界點早于全局時間戳，所以只需要保留一個最新的版本，不再依賴于額外的垃圾回收機制。96騰訊云技術實踐精選集 2022上圖是簡單分布式事務
197、的執行過程。無感知擴縮容這是我們非常重要的特性。我們擴縮容的過程中對業務是透明和無感知的，也就是說擴容期間，對業務的請求能夠做到觀察不到性能抖動的現象。下面以擴容場景為例，展示我們是如何做到水平擴展和負載均衡的。首先水平擴容涉及到 Region 的調度：分裂、遷移、切主。分裂時，我們的管控模塊發現某個 Region 的設計規模超過了 Region 的閾值，MC 就會下發一個分類任務。分裂過程中也遵循了兩階段提交的原則，但是以 MC 作為協調者，Region 一主兩備的副本作為參與者，來保證全員成功或者全員失敗，避免分裂過程中不一致的現象。分裂結束之后，我們會發現分裂只能讓 Region 數量增
198、加，但是數據本身的分母不變，只是每個 Region 所管理的數據規模變得更均勻了，但是要想真正達到水平擴展的效果，還需要遷移。遷移是由 MC 下發，遷移的流程是通過 Raft 協議增減副本完成的。遷移過程中，除了原數據要遷移過去，數據本身也會遷移。增加了一個副本后接下來要移除一個老副本，Region 置換數據的遷移是通過 Raft 協議中的流程來實現的。遷移完之后會發現，Region 在幾個 TDStore 之間變得更加均勻。但這不意味著 TDStore 之間的讀寫負載也是均衡的，所以下一個操作是切主，讓不同的 TDStore 副本之間達到負載均衡。比如說我們通過 Raft 的操作，把 Lea
199、der 盡量分配均勻。97騰訊云技術實踐精選集 2022以上幾點操作是無感知，對事務沒有影響的，所有過程中是不插事務的。2PC 階段提交由新主繼續推進；未進入 2PC 階段的事務，切主前需要將事務數據傳輸到新主上，從而保證事務執行的生命周期會跨過切主的流程，分裂也是類似的。遷移是通過 Raft 增減副本的方式執行的，就是增加了一個 Follower 節點，它與提供服務的 Leader 節點并沒有直接聯系。Raft 副本的機制保證了遷移過程中對事務沒有影響。分裂和切主不可能存在并發，我們希望事務的生命周期必須要跨過分裂和切主的操作，這在工程實踐來講是個挑戰。以分裂為例，剛開始只有一個 Regio
200、n1，上面有個事務 T，寫入了兩條，A 等于 1，H 等于 5，反映到 Region1 上。Region 的區間是 A 到 Z，分解成 Region1 和 Region2，Region 中的部分數據需要分到 Region2 上，這時候會做數據的切分，把事務緩沖中的信息做切分和傳輸。如果這個事務想讀 H，H 跑到 Region2 上去了，在分裂之前可以從 Region1 讀，在分裂執行的一霎那之后，就可以到 Region2 讀，把活躍事務的私有數據遷移過來。另一個方面來講，我們在 Region1 除了把事務分裂搬遷出去，另外涉及到兩階段提交。單節點的 1PC 的事務變成了 2PC 的事務，這時候
201、我們就要保證事務參與列表能夠實時更新，從而在事務的提交階段能夠保證98騰訊云技術實踐精選集 2022數據項順利落盤。在兩階段提交階段我們也會做一個檢測，會檢測 Region 列表是不是包含了分裂過程中新增的 Region，如果不包含會返回上層，但不會造成事務的回滾。協調者會更新協調者列表，本地保存的 Region List 更新一下，發現所有的數據都可以提交成功。這個例子可以說明基本的邏輯。數據存儲與遷移上圖展示了 TDStore 數據的持久化流程，分為兩部分，一部分是 Raft 信息，另一部分是數據，分別存放在 Raft Log DB 和 Data DB。事務寫入的數據首先會以 Raft L
202、og 的形式同步到 Region 的副本上，當 Raft Log 形成了多數派后，這時候會認為這個 Raft Log 就提交成功了。成功后，主備都會做 Raft Log 回放，會把其中事務相關的信息回放到內存結構WriteBatch 中，寫入到 MemTable 的事務中。如果收到回滾請求，就直接把 WriteBatch 中的暫存信息丟棄。對于已提交事務的信息，MemTable 會不斷增長，寫到閾值之后就會轉成不可變的 MemTable，然后做落盤操作，也就是 Flush。數據是以 SST 文件組織的。我們通過 Compaction 做過期數據的清理和數據壓縮。這涉及到數據的清理，無論是 Ra
203、ft Log DB 還是 Data DB，都要做清理，我們會以快照的形式進行清理，保存具體的數據。更老的數據根據全局一致性原則肯定不會讀到，所以可以及時清理。99騰訊云技術實踐精選集 2022上圖展示了數據遷移 Install Snapshot 的流程。對于 Raft 協議會發送一條請求，接受到這個請求之后就會開啟一個流程，首先向 Leader 或者其他副本請求數據，要在 SST 中撈取對應的 Data，相當于是實時生成的。源端就會以 Region 區間為單位，與這個 Region 重疊的 SST 生成一個迭代器，把迭代器做合并，把數據按照新老版本合并，邊合并邊傳輸，傳到目的端。傳輸過程中只會
204、把你所需要的數據版本存過來。傳過來之后不能直接往里 LSM-tree 中寫，而是形成外部的 External SSTs 文件，寫滿閾值會生成一個或多個外部 SST，然后插入到 LSM-tree 中一個合適的位置。數據傳過來放到合適的位置之后，也不能影響新舊版本數據的一致性或者正確性的原則。100騰訊云技術實踐精選集 2022掃碼獲取完整版演講 PPT總結與未來規劃我們希望用戶能夠像使用單機數據庫一樣使用我們的分布式數據庫，同時又會具備無限擴展性。未來我們會有三個比較重大的特性升級：一是數據位置感知，允許運維人員具體根據不同的分析表做具體的 Region 分布的數據對齊和感知，這個特性可以讓更多
205、分布式降低到事務，從而大范圍提升性能；二是對等架構，使得在線上的小規模集群環境下，資源利用率能夠得到進一步提升；三是管控這邊會做粒度更細、更智能的負載均衡和調度策略，使得擴縮容、變更的性能曲線更平滑。101騰訊云技術實踐精選集 2022國內行業 IT 系統中，數據庫領域長期被國外產品壟斷，國內云計算廠商基于云計算帶來的架構升級，以及產業互聯網數字化實踐，引領了新一代分布式云數據庫技術與實踐突破。從金融級場景到傳統金融核心系統場景，在云化的技術浪潮下，國產分布式數據庫得以在對數據庫最高要求的金融行業實現應用，并逐步拓展至政務、運營商、工業制造等，逐步支撐國民經濟對數據庫的國產化與數字化轉型升級需
206、求。騰訊云數據庫 TDSQL 正是走過了這樣的歷程，在技術突破，到支持客戶轉型實踐過程中，積累了豐富的解決方案與實踐經驗。在 DIVE 2022 全球基礎軟件創新大會（北京站）上，騰訊云數據庫資深解決方案架構師賈瓅園帶來了國產金融級分布式數據庫在金融核心場景的探索實踐的主題分享。國產金融級分布式數據庫在金融核心場景的探索實踐賈瓅園 騰訊云/數據庫資深解決方案架構師15 年金融銀行 IT 工作經驗，先后經歷和主導國內多家銀行核心系統架構設計與建設，長期從事核心業務系統、分布式技術架構、云原生、信創相關技術工作，現為騰訊云數據庫團隊行業架構專家，從事金融領域數據庫賦能、行業架構設計相關工作。102
207、騰訊云技術實踐精選集 2022回歸本源，是什么驅動力促進金融核心場景分布式數據庫發展？一方面是國家機構、監管機構給出的政策及指引，2021 年末，中國人民銀行基于“十四五”規劃發布了金融科技的發展規劃，2022 年初銀保監會發布了銀行業、保險業的數字化轉型指導意見，個人總結為三個詞：安全、發展、創新。第二方面是金融業務的發展對于技術架構的要求，銀行業務與需求發展背景下，技術要求、技術多樣性、功能細化性、架構復雜度、管理等維度的要求也逐級提高。第三方面，金融業系統技術與架構的趨勢之下所衍生的數據庫要求、自主可控的軟硬件要求等。我們當下處在分布式數據庫的快速發展過程當中，既要契合金融場景專業特性，
208、技術上也要適配外部環境與生態以及通用性，面臨著從技術角度、從公司實力角度、從數據庫研發角度的多維度挑戰。分布式數據庫在金融領域的挑戰與痛點金融架構里面的挑戰維度有哪些？第一是設計、規劃、解決方案能力，相對于新事物，需要行業多方面的接受過程，這個時期國產分布式數據庫不能像傳統數據庫，而是需要更貼合于業務場景和行業特性并抽象和分析使用特點，衍生變化為數據庫通用特性和功能，更方便地讓金融客戶以及開發廠商使用。第二方面是擴展能力，包括橫向和縱向的擴展能力。第三方面是穩定性和性能，圍繞這個維度又衍生了廣播表、單表、事務等功能與解決方案。103騰訊云技術實踐精選集 2022第四方面是高可用性，滿足監管要求
209、和行業特點，支持多中心多活、故障切換等方式。第五方面是軟硬件兼容性要求，我們正在使用的領域有自主可控軟硬件、虛擬化、云化等基礎底座。分布式數據庫在金融業務領域又面臨哪些難點呢？第一是保證業務系統兼容性，降低改造和引發的風險，比如關鍵字、函數、語法，甚至常規業務系統使用的軟件驅動。第二是遷移同步的方案與功能，這個往往在金融場景下容易被忽略掉，需要考慮異構遷移工具、方案，考慮如何處理業務場景數據同步、高可用要求下的數據同步。第三是運維體系，分布式體系下特性帶來的管控維度較多，因此可視化、智能化的管理平臺和工具尤為重要，同時也要覆蓋黑屏命令工具、監控工具等，匹配 DBA 使用習慣。第四是服務與交付，
210、分布式數據庫還處在一個發展和高速迭代過程中，那么如何來契合金融場景設計特點與復雜度，都對人員能力、交付提供了更新的要求，當下走的路線應該既與金融行業系統開發廠商不同，又與傳統數據庫廠商不同。第五是生態建設，這涉及到共享知識庫如何建立、檢索、查閱，社區如何運營、認證培訓如何開展更有助于生態合作?？偨Y來說，分布式數據金融領域落地不僅僅是技術與產品力的考驗，也是考驗著金融場景理解能力、金融運轉體系理解能力與設計能力等。金融級架構探索、思考與實踐架構體系如何支撐金融核心業務發展和合規?我們一直在探索和積累，來支撐金融級分布式的架構體系，以滿足監管合規的要求，完整的實現自主可控，并契合金融核心的特點。我
211、們滿足了金融級的“四高兩低”的要求，包括未來都是以此為原則基礎。并且實現了多內核。為什么要多內核？在金融銀行業中，不同的金融業務場景，不同的分布式業務架構需求，以及每家銀行的建設因素不同、104騰訊云技術實踐精選集 2022系統歷史遺留問題原因不同、系統的 AP/TP 屬性等綜合多方面和實踐經驗，因此必須要有多內核的兼容性來保障新舊數據庫轉換能力，保證業務系統能夠平滑下移。另外，貼近開發，解決“開發不規范，調優困難”的問題。契合金融業運維模式，解決“診斷難、維護難、時效長”的問題。同時也要考慮不單一綁定某一技術形態，采用兼容通用協議的技術形態，降低從業者的學習難度。業務系統兼容性探索在做業務系
212、統兼容性探索時，要注意系統背景、特點、場景的不同，不能“通吃”，應按不同類型、不同緯度進行兼容適配，并考慮系統業務與當前的架構現狀。例如：我們按照金融銀行業系統傳統分類標準做了梳理和歸納，它們都有各自的特點以及兼容思路和技術訴求。在語法與開發兼容性方面，我們通常關注：數據結構梳理:訪問頻度、數據量、關聯關系、分片依據、水平垂直分庫設計規則 基礎數據類型:字段數據類型歸納，不兼容類型采用工具化配置轉換 對象使用:存儲過程、視圖、非標準函數使用分析，與業務系統配合調整 SQL 執行對象:索引、函數、鎖、大查詢、大事務分析與調整 數據庫基礎集成層面:會話保持、鏈接池參數、探活機制、驅動設置105騰訊
213、云技術實踐精選集 2022數據遷移與同步的兼容和實踐業務場景數據遷移與異構數據庫遷移項結合，數據庫須具備異構庫數據遷移能力，不同的數據遷移同步場景有著各自的關注點：異構業務系統遷移場景：業務邏輯復雜、數據業務關聯度高 適用定制化的業務數據遷移程序與方案并配合數據庫工具，進行數據遷移異構對抽遷移場景：業務邏輯關聯少，數據量大,增量/全量數據遷移 適用數據庫提供異構庫遷移工具進行數據的遷移 業務遷移與異構庫結合場景：兼具兩種場景特點 采用組合遷移方案，滿足異構業務系統+異構數據庫數據遷移 在貼源數據同步實踐中，各場景的關注點如下：106騰訊云技術實踐精選集 2022運維架構探索與實踐從運維角度來看
214、，架構特性從最早的字符界面端到圖形化、智能化運維發展迭代，字符界面操作上手速度快，但具有高度依賴人工、管理流程復雜、成本高、容錯低、風險高等特點。圖形化運維實現了工具化，降低了容錯風險和管理成本，而智能化運維更進一步實現了風險預警、主動探測和提前預知，讓運維從被動變主動。探索實踐新的實施與服務模式大多數的開發人員、技術人員都具備一定程度的傳統數據庫的知識、開發經驗和體系，基于系統的成熟穩定，技術的共識性實施角度不存在什么太多的問題。因此傳統成熟的數據庫廠商在經歷了眾多行業的積累后不斷打磨，已走出了一條成熟的實施道路，即關鍵節點保障型。面向客戶時技術團隊基本上是以 DBA/架構師1v1，或 1v
215、 多的模式，不需要完整周期跟進實施全流程。107騰訊云技術實踐精選集 2022生態建設高校、合作機構、金融 IT 同業、金融客戶等，對當前分布式數據庫都有一定的深入了解，但認知程度暫時達不到傳統數據庫所積累的程度，因此需要我們在數據庫層面不停深入建設共享知識體系，包含社區、生態合作、培訓等體系。一、這個生態里面不只我們自己，包括分布式數據庫領域的眾多廠商、金融IT開發廠商，實踐方案、調優指南、使用指南、技巧經驗、系統兼容經驗、金融系統運維等豐富到整個金融實踐體系中。金融軟件的開發廠商聚焦業務系統，這類型廠商為什么走的是需求差異化的路線，原因是業務通用性的同時每家銀行的需求不同，業務復雜度不同，
216、涉及每家銀行技術架構、廠商特點也不同，導致了整體相關的工作，都需要在銀行整體組織下進行大規模的完整周期實施和調整。所以團隊有技術架構、DBA、業務專家、項目管理以及開發，基本上團隊是一個 1v1 的模式，全周期保證?；谖覀兌嗄甑难邪l、實施經驗來講，當下兼容和融合以上兩種相對比較好，既保障了數據庫的交付與落地，同時兼顧成本和投入，以及經驗回歸和產品打磨。具體的方法論而言，總結大致為：第一，幫助金融行業的客戶將數據庫融入到行業架構規劃中，既然能夠協助更好地理解知識體系，也能夠為金融客戶未來的數據庫使用奠定基礎。第二，跟進常規的 IT 系統建設，總結系統使用數據庫的特點特性。第三，在設計交付之初，
217、我們就考慮到兼容對應的業務性特點來進行分片、運營模式、數據吞吐量設計、數據節點等統籌安排。第四，有別于傳統的數據庫廠商，我們配備了行業架構師、數據庫架構師以及 DBA 等角色來共同完成項目。這樣兼顧了數據庫以往的交付與服務模式，同時也兼顧了行業的特點，也包含成本管控以及訴求。108騰訊云技術實踐精選集 2022二、增強社區廣度和深度，聚集于碎片化問題解決、學習筆記、金融場景特點優化，開辦技術論壇，讓眾多的行業以及未來有潛力從事這個行業的人才能夠加入到其中。三、深入生態合作，與學術研究機構、信創基礎軟硬件廠商、金融軟件同業、金融客戶合作，推進一些相關的標準甚至研發體系，進行產能體系的升級。四、認
218、證培訓添加，聯合第三方進行金融客戶服務中知識轉移、技術認證模式，通過認證培訓普及常規知識，為未來金融 IT 領域人才儲備夯實基礎。建設模式探索與實踐聚焦到建設模式共分為兩類，一是關鍵系統/模塊下移模式，二是業務系統升級/建設模式。關鍵系統/模塊下移模式實際是把整體分了 N 個階段來做，并不是一次完成。這種模式具有很多優點，包括低成本、風險比較低，并且是循序漸進的。但對于系統的規劃、建設周期布局以及管控能力要求較高。分布式數據庫要滿足“四高兩低”的要求，即高可用、高一致性、高擴展、高性能、低成本、低風險。從產品109騰訊云技術實踐精選集 2022選型到適配業務，原則上必須要保證數據庫兼容業務系統
219、，相對來說業務結構要清晰，數據結構容易梳理、系統維護技術能力要強。在基礎適配壓測階段，重點是語義語法、業務使用場景和問題的篩選。在業務系統適配驗證階段，重點是聯機業務，批量業務，供數、同步類業務，驗證“四高兩低”。業務系統升級/建設模式其實相對來說容易一些。因為系統升級自然面臨新系統的變化改造，通過開發設計過程，匹配數據庫特性，沒有歷史包袱。此類模式對于管控能力的要求相對會低?？傮w而言，從投入成本、核心能力、服務能力來講，對廠商、銀行也會有一定挑戰。這些挑戰主要集中在升級與適配、系統的架構設計、UAT 測試與基礎底座驗證、工具化與數據移植、切換投產演練等方面。未來挑戰與探索思考將來，我們認為金
220、融領域分布數據庫仍然需要不斷地面對挑戰和打磨。110騰訊云技術實踐精選集 2022第一個是分布式事務的業務場景，當下我們能夠保證分布式數據庫的事務處理能力，能保證全金融業務場景，但我們也在不斷地努力，探索將來按照分類去做一些實踐研發工作，探索如何通過數據庫解決事務場景，降低應用的復雜度。第二是隨著外部環境的發展，數據庫不斷提升兼容生態能力。第三是全打包的金融級解決方案，符合金融級監管要求的同時，滿足客戶的個性化特點，最終走向多對一的、統一的數據庫產品。未來數據庫時代，云原生數據庫發展也在不斷進行當中。云時代的特點是 IT 設施從零散走向集中化、規?；?，交付方式從軟件交付走向服務標準交付，開發方
221、式從底層(laaS+PaaS)走向上層(SaaS)，數據形式及應用場景從單一化走向多樣化。在這樣的云時代的背景下，數據庫將來要做到單一引擎極致化、多引擎統一智能管控融合、以及 DBaaS 形態在行業應用的探索。掃碼獲取完整版演講 PPT111騰訊云技術實踐精選集 2022騰訊云 MongoDB 智能診斷及性能優化實踐楊亞洲騰訊云數據庫專家工程師當前就職于騰訊 NoSQL 團隊，多年軟件研發經驗，致力于高性能中間件、數據庫研發。騰訊云 MongoDB 當前已服務于各行業頭部用戶，致力于為用戶提供高性能、低成本、高可用的存儲服務。在 DIVE 2022 全球基礎軟件創新大會（北京站）上，來自騰訊云
222、的數據庫專家工程師楊亞洲帶來了主題為 騰訊云 MongoDB 智能診斷及性能優化實踐的演講。為大家分享了 DBbrain for MongoDB 智能診斷、數據庫自治等功能實現，包括異常診斷、智能索引推薦、SQL 限流等核心功能實現。此外，結合真實典型案例，給大家分享千億級高并發 MongoDB 集群踩坑及性能優化實踐。MongoDB 核心優勢分布式MongoDB 是開源的分布式數據庫，可以解決傳統數據庫在性能和存儲容量上的瓶頸問題，得益于此，用戶不必再提前考慮分庫分表等操作。同時 MongoDB 也是一個天然高可用的數據庫，比如說在一主兩從的工作模式下，當主節點意外宕機，從節點就會接替主節點
223、的工作，整個過程無須依賴任何第三方組件。112騰訊云技術實踐精選集 2022schema-freeMongoDB 的表結構相對自由，添加字段方便快捷，相比于傳統數據庫在一張大表里添加字段，運維成本大大降低。高性能MongoDB 早期使用 MMAPv1 存儲引擎，后來替換為 WiredTiger 存儲引擎，它支持行級粒度鎖、熱點數據緩存等特性，這給 MongoDB 帶來了高性能、低延遲、高吞吐等能力。高壓縮比在默認配置下，MongoDB 使用 snappy 壓縮算法，可達到平均 2 到 4 倍的文本數據壓縮能力，如果使用 Zlib 壓縮算法則可以提升到 3 至 7 倍，但是對性能影響較大，因此線
224、上通常使用默認配置即可。經測試，在默認配置的情況下，同樣一份數據寫入 MongoDB、MySQL、ES 的真實磁盤消耗比約為 1:3:6。完善的客戶端訪問策略MongoDB 支持五種均衡訪問策略：Primary：讀主節點，當主節點異常時，可能造成短期內的業務異常。PrimaryPreferred：主節點優先，當主節點異常時可以讀從節點。Secondary：讀從節點，把流量平均分配給多個從節點，實現負載均衡。SecondaryPreferred：從節點優先，如果從節點異常，則讀取主節點。Nearest：就近訪問，在多機房場景下，就近訪問可以避免出現跨機房訪問的情況。113騰訊云技術實踐精選集 2
225、022騰訊云 MongoDB 的核心優勢騰訊云 MongoDB 可有效減少運維成本，通過 DBbrain 提供一站式監控的診斷分析，并且能給出相應的優化建議，同時也集成了官方的常用工具，讓用戶使用更方便。騰訊云 MongoDB 在內核里做了一些定制化的開發，比如解決表數量達到百萬級別時的性能問題、提供 SQL 限流功能減少流量過大導致的集群不可用問題。安全方面，騰訊云 MongoDB 可以將數據恢復到 7 天內的任意時間點，并且提供 24 小時的專業支持服務。除此之外，也天然集成了云上高可用、高性能等通用能力。DBbrain for MongoDB 介紹DBbrain for MongoDB
226、是騰訊云開發的數據庫智能管家，是為用戶提供數據庫性能、安全、管理等功能的數據庫自治云服務，它不僅支持 MongoDB 數據庫，同時也接入了 MySQL 等其它數據庫。DBbrain for MongoDB 擁有的核心能力如下：豐富的監控指標：除了最初控制臺暴露給用戶的主要監控指標以外，所有實例維度和節點維度的核心指標同時也被暴露到 DBbrain 上。豐富的工具集成：一鍵集成 MongoDB 常用分析工具，如 Mongostate、Mongotop 等。如果需要查看某個實例或者某個節點的流量、庫表分布等信息，直接在控制臺界面點擊就可以實時輸出，無需額外通過客戶端登錄查看。114騰訊云技術實踐精
227、選集 2022 實時異常事件診斷與優化建議：很多異常事件可以被 DBbrain 提前發現，并且給出一系列優化建議，除了常規的異常診斷，還包括一些特殊的異常診斷項。實時 Kill 會話：有些查詢沒有使用到索引，有時需要手動 Kill 這些會話，現在這些操作可以直接在 DBbrain 上完成，甚至可以設置一些定時任務來周期性的執行，這樣開發或運維人員就不需要自己編寫腳本來進行操作。庫表分析：對數據庫和表進行詳細分析。慢日志分類匯總：將慢日志進行分類匯總，更清晰直觀的展示給用戶。健康報告：每日生成健康報告，數據庫狀況一目了然。索引推薦：很多用戶自己并不清楚如何創建索引，這時就可以采用 DBbrain
228、 推薦的最優索引。SQL 限流：在大流量、不同業務使用同一數據庫等情況下，可以使用 SQL 限流來保障核心業務的可用性。MongoDB 異常診斷異常診斷當前已經覆蓋了 MongoDB 常見的核心指標，實時對云上所有實例進行異常分析，發現異常后會第一時間觸發診斷告警并提出優化建議。通常把異常診斷項分成兩種，一種是基礎診斷，比如內存、CPU、磁盤、連接數，慢查詢、節點連通性、主從延遲、Oplog 保存時間等，這些是最常用的數據庫診斷指標，還有一些高級的指標，比如 Session 會話數（Session 會話數較高的時候，可能會引起集群抖動）、讀寫活躍隊列、前臺加索引、讀寫等待隊列、死鎖檢查（例如索
229、引還沒加完，又去刪除索引就會造成死鎖）、全表掃描，還有純粹的引擎相關的一些參數，如引擎 Cache 使用百分比、引擎臟數據百分比等。騰訊云 MongoDB 團隊后續規劃把 MongoDB 的診斷數據，也就是經常在數據庫里面看到的 diaglog 數據進行處理，用來分析內核的一些深層次問題。MongoDB 智能索引推薦實現智能索引推薦主要是基于索引規則和代價估算來實現的，整體的架構如下：115騰訊云技術實踐精選集 2022智能索引推薦分為四個模塊：Agent 模塊 Kafka 模塊 日志分類模塊 代價估算模塊系統整體的工作流程是：每個 MongoDB 節點上布署一個 Agent 節點，它會實時采
230、集所有有用的日志并存儲到 Kafka 里，日志分類處理模塊會從 Kafka 里把需要的日志提取出來進行分類，然后把分類好的日志交給索引代價計算模塊進行計算，最終得到最優索引。Agent 模塊和 Kafka 模塊的邏輯相對簡單，這里重點介紹日志分類模塊和代價估算模塊。116騰訊云技術實踐精選集 2022日志預處理分類第一步：提取有效的慢日志并不是所有的慢查詢日志都需要處理，由索引問題導致的慢查詢，諸如索引不對或者索引不優引起的問題就需要提取，由于沒加索引造成的全表掃描，這類日志也應該提取。如果加了索引，如何判斷添加的索引是不是最優？答案是對比索引數據掃描的行數與實際數據的行數，如果差值較大，就判
231、斷這個索引不是最優的，需要進一步優化。第二步：根據 filter 對 SQL 分類同一個庫表中會有很多查詢，查詢條件不盡相同，屬于同一類的 SQL 需要滿足幾個條件，即庫、表、命令、查詢條件完全相同，前三個條件容易區分，比如同庫同表情況下，Find 操作算一類，Update 操作算一類，而查詢條件相同的前提是查詢關鍵字要相同且操作符屬于同一類。日志聚合處理定期從 DB 中獲取分類好的 SQL 信息交給代價估算模塊進行處理。索引代價計算模塊處理流程抽象語法樹生成及分解：從日志分類處理模塊中獲取對應 SQL，抽象語法樹，同時進行分解。根據索引規則生成候選索引：根據最優候選索引規則生成侯選索引的流程
232、，可以參考騰訊云數據庫公眾號發布的文章：云上 MongoDB 常見索引問題及候選索引規則大全一文。對候選索引進行代價估算：從源集群隨機抽樣數據，對候選索引進行代價估算，得出最優索引。AST 裁剪及候選索引生成，詳見下圖：117騰訊云技術實踐精選集 2022假設有一個查詢，查找位于四川成都，年齡在 20 到 30 歲，身高大于 1 米 7 的人，或者位于四川成都并且在騰訊工作的人，這個查詢如何推薦最優索引？第一步要生成抽象語法樹，可借助 MongoDB 內核的 Explain 來實現，可以看到生成的抽象語法樹中涉及了 OR 操作，需要進行拆解并把 OR 操作“去掉”，將原 AST 分解成 2 個
233、子樹，可以看到拆解后的兩個子樹中已經沒有 OR 操作了，然后分別獲取子樹 1 和子樹 2 的候選索引，生成整個 OR 類查詢的候選索引?？梢钥吹阶訕?1 包含三個查詢，省、市、工作地點，都是等值查詢，所以可以把三個字段隨機組合在一起成為一個候選索引即可，因為等值查詢無論怎樣組合，代價都是一樣的，通常在等值查詢的情況下有一個不成文的規定，即把區分度最高的字段放到最左邊，什么是區分度？假設一個字段的取值有 100 種，區分度可以理解成就是 100。假設 Work 的區分度大于 City，City 的區分度又大于 Provice，把區分度最高的字段放在最左邊，子樹 1 的候選索引就可以求得了。再看一
234、下子樹 2 的候選索引可以發現，省份和城市都是等值的，但是年齡和身高是非等值的，所以需要根據等值和非等值組合索引規則，通過查詢前面提到的候選索引規則表，可以知道子樹 2 的候選索引需要先把等值字段組合在一起，然后再加上一個非等值字段，因為有兩個非等值字段，所以等值字段加第一個非等值字段構成第一個候選索引，第二個等值字段再加第二個非等值字段，就構成了第二個候選索引，所以子樹 1 就有一個候選索引，子樹 2 就有兩個候選索引，因為子樹 1 和子樹 2 是 OR 的關系，所以整個 OR 查詢的候選索引就是把子樹 1 的候選索引和子樹 2 的第一個候選索引組成一個候選索引，再把子樹 1 的候選索118
235、騰訊云技術實踐精選集 2022引和子樹 2 的第二個候選索引組成一個候選索引，最終整個 OR 查詢就有兩個候選索引。至此就得出了整個 OR 類查詢，這是通用于絕大部分場景的候選索引生成過程。騰訊云上有些用戶的數據分布比較特殊，所以騰訊云 MongoDB 后續還會增加幾種候選索引，主要用于應對一些特殊的場景，對于一般用戶來講，通常只要滿足上述候選索引規則，再總結出來，就能夠滿足絕大部分場景的候選索引需求。候選索引代價計算現在就有兩個候選索引可供選擇，那么哪個是最優的？這就需要進行代價計算，舉例說明，對于一個 OR 類查詢，上面得出的兩個索引對應的執行計劃流程是：首先第一個索引進入 index s
236、can stage，然后進入 OR stage，OR stage 執行完成后就會開始做 Fetch 操作，最后就會得出整個流程掃描了多少行數據、得到了多少行數據，以及整個流程的執行時間，第二個索引也需要執行同樣的流程，代價估算就根據這三個值進行對比，最終選擇執行時間少，掃描行數少的候選索引，這就是代價計算的主要流程。騰訊云的代價估算是由一個旁路模塊實現的，實現難度較大，需要對整個內核執行計劃有透徹的理解，所以對于自研用戶，建議在采樣數據過后，寫入一個新的 MongoDB 集群，然后讓執行計劃執行候選索引，得出執行這個索引掃描了多少行、執行多少行、執行了多長時間，最終也可以得到最優索引。云上因為
237、要保證用119騰訊云技術實踐精選集 2022戶的信息安全，所以一般直接抽樣到內存里并進行計算，而不是抽樣到一個新的實例上，但實際這兩種方式原理是一樣的。智能索引推薦當前已經服務化，逐步會開放給用戶使用，如果大家有興趣可以去體驗。索引推薦基本上能在半小時內發現實例上存在的索引問題，除了推薦最優索引外，還可以把實例上的無用索引和重復索引也找出來，這樣能用最少的索引滿足用戶需求，性能等方面也會更好。MongoDB 內核 SQL 限流實現另外一個要分享的是 SQL 限流。為什么要做 SQL 限流呢？當流量過大、負載過高，數據庫抖動可能造成雪崩時，就可以限制一下流量，保證一些請求能正常返回。另一方面，有
238、些用戶為了節約成本，將多個用戶的數據寫到了同一個實例上，某一時刻可能出現用戶編寫的接口不對或其它異常情況，導致流量非常高，就會影響這個實例上的其他核心業務，這時就可以通過限流把異常的和不太重要的表做限流，保證核心的業務流量能正常訪問，還有一些突發掃表，高危掃表操作都可以通過限流進行限制。我們在內核哪個地方做了 SQL 限流功能呢？先捋一下 MongoDB 的整體架構，它是分層的，第一層是網絡收發模塊，網絡收發過后，交由命令處理模塊把這些 SQL 解析出來，然后這些 SQL 會進入查詢引擎模塊、讀寫模塊以及并發控制模塊。我們整個 SQL 限流模塊是加在命令處理模塊之后的，加在這里有什么好處呢？首
239、先到這里的時候，已經拿到了詳細的 SQL，再者就是在并發控制之前做到 SQL 限流，避免 SQL 限流里120騰訊云技術實踐精選集 2022面的操作會影響并發控制和數據庫讀寫訪問，防止與下層的并發控制模塊產生沖突。內核 SQL 限流的整體流程是：首先在 DBbrain 界面上可以配置策略規則，比如 SQL 類型、并發數，可以配置定時關閉還是手動關閉，定時關閉是指最多執多少時間，手動關閉就是打開后永遠執行，除非手動關閉。然后是搜索關鍵字，配置完規則，就可以對指定庫、表或者指定的 SQL 語句做限流。整個流程是首先在 DBbrain 的控制臺下發規則，以分片集群為例，就下發給分片集群的 Confi
240、g Server，Config Server 接收到后把這個規則寫到 Config Server 的一個表里，分片集群的每個 mongod 定期從 Config Server 獲取這些規則并加載到自己內存里，基本上幾十秒就獲取一次，所有的 mongod 節點內存里就會有完整的規則數據存在，當發起一個請求，通過客戶端到代理，再到 Mongod 節點的時候，進行限流規則匹配，觸發限流操作。為什么選擇在 Mongod 上做限流？而不是在 Mongos 上？首先 Mongos 上面的流量控制是由客戶端基于 IP 做哈希的，可能導致流量不均勻，其次線上有副本集的集群，也有分片的副本集群，在 Mongod
241、 上做可以實現代碼統一，再者如果在 Mongos 上做的話，因為 Mongos 之間是無狀態的，無法保證相互的控制達到一定的級別，還有一個原因是瓶頸一般都在 Mongod 節點上，所以就在 Mongod 上面做。121騰訊云技術實踐精選集 2022關于 SQL 限流規則，一個是 SQL 類型，比如說增刪改查，另外一個是限流時間，再者就是并發數，并發數可以限制某類請求同時訪問我們 DB 的并發量，另外就是關鍵字，可以匹配庫，也可以匹配表，甚至可以匹配詳細的 SQL，這樣就可以實現指定的庫、表和某一類型的 SQL 限流。收到一個請求的處理流程是怎樣的？一個請求到達 MongoDB 后，首先看這個實
242、例是否啟用了 SQL 限流功能，如果已啟用，則提取用戶請求中的庫、表和 SQL 關鍵字信息，下一步和配置的限流規則做匹配，判斷這類 SQL 是否有可用的 Ticket,Ticket 代表并發控制中的并發數，如果沒有可用的 Ticket，比如 Ticket 值為 0，說明當前已經有很多訪問，就直接限制這個請求，返回客戶端異常。如果有可用的 ticket，就把 Ticket 值減 1，同時訪問 DB，訪問到 DB 后就將數據返回給客戶端，同時釋放當前 ticket，后面的請求就可以繼續復用，這就是整個限流工作流程。典型案例：千億級高并發 MongoDB 踩坑及性能優化實踐給大家舉一個典型案例，我們
243、有一個千億級的高并發 MongoDB 集群，維護過程中踩了一些坑，我們對它做了一些性能優化，在此給大家講一下。122騰訊云技術實踐精選集 2022這個集群存儲了一個金融行業頭部客戶大概 1000 多億條訂單信息數據，整體采用私有云的解決方案，MongoDB 集群采用分片模式，由于需要長時間高并發讀寫，寫入的數據需要馬上可讀，所以讀寫都在主節點完成。高峰期的讀寫流量可達幾十萬每秒，在極端情況下甚至能超過百萬每秒。從上圖可以看到僅一個分片的流量即可達到 16 萬每秒。我們其中一個踩坑點是主從切換。業務上曾出現過幾次主從切換，切換完成后，從節點變為新的主節點時，整個集群出現了幾分鐘到幾十分鐘的不可用
244、，而且這個時間是不固定的。還有一個踩坑點是集群經常會出現數十秒的抖動，產生慢查詢。123騰訊云技術實踐精選集 2022下面就具體看這幾個問題，比如說主從切換，為什么會發生主從切換？主從切換只發生在主分片，因為主分片壓力最大，流量較高，有十幾萬的寫入，可以看到的現象是數據百分比正常，不到 20%，但內存使用率在持續增加，可以達到 95%，讀寫隊列和流量也比較高，流量高是由 于用戶運行批量任務造成的，批量任務會持續運行數個小時，產生大量的寫入和更新。短期來看集群是正常的，但長時間的壓力導致整體內存持續升高，產生大量排隊現象，最終主節點不堪重負，?；顧z測超時，進行了主從切換。針對這個問題短期的解決方
245、案是讓業務進行改造，在批量任務并發寫入的時候減少并發量，拉長寫入時間，控制在業務可以接受的范圍內，但長時間的批處理作業依然會產生一定的積壓現象，所以對于長期的優化方案來說，我們看到的物理現象是主分片壓力很大，但是其它分片壓力不大，集群的 Chunks 數又比較均衡，這說明集群中存在熱點 Chunks，終極的優化方案是找出熱點 Chunks，通過手動的方式把一部分熱點 Chunks 遷移到其它分片。124騰訊云技術實踐精選集 2022主從切換后存在一個非常嚴重的問題，集群會出現幾分鐘到幾十分鐘的不可用，這是不可接受的。通過日志進行分析可以看到，新的主節點會去獲取路由的元數據（Chunks 信息等
246、），而獲取 Chunks 信息的原理是：業務通過 Mongos 訪問數據時，會帶上最新的版本路由信息，當主節點接到請求后會將此信息與本地路由信息進行對比，如果發現路由信息不是最新的，則從 Config Server 獲取路由增量信息并寫入本地 Config 庫的 Cache.chunks 表中，但這個操作的前提是 Oplog 需要同步到多數節點中，但此時主從延遲較高，導致 Oplog 同步緩慢，這就間接導致獲取路由信息的操作也被卡住。當路由信息寫表完成后，還需要從表中加載到內存，因為有 500 萬個 Chunks 路由信息，所以加載過程很慢，大概需要 45 秒，這也造成了時間的消耗。優化方法是
247、讓從節點定期從 Config 庫的 Cache.chunks 表中把路由版本信息加載到內存，這樣當從庫切換為主庫被業務訪問時，就不會觸發獲取增量或全量路由信息的流程，新的主節點就可以快速變為可用狀態。由于路由版本信息是定期加載的，極端情況下還有可能因為 chunks 數據不一致而觸發重新獲取 chunks 數據的操作，當出現這個問題時，可以及時把延遲高的節點從集群中踢掉來規避這個問題。125騰訊云技術實踐精選集 2022FTDC 是 MongoDB 的內核診斷模塊，通常會寫數據到 MongoDB 數據目錄的 Diagnose.data 目錄中，這些數據會記錄 MongoDB 內核各個流程的核心
248、診斷數據，比如時間消耗等信息，但它是加密的，導致只有原廠工程師才可以對其進行分析。騰訊云 MongoDB 團隊結合 MongoDB 內核源碼對 FTDC 生成的數據進行了反解析，包括全量的和增量的。有一些疑難問題通過日志是看不出來的，比如可以看到慢，但為什么慢不知道，這時候就需要解析診斷數據，舉個例子，一個集群在低峰期的時候沒有什么流量，卻發生了主從切換并產生了大量慢查詢，這明顯是有問題的。日志里只能看出數據庫慢，做了主從切換，但不知道原因。這時把診斷數據解析出來，可以分析出數據庫內核模塊每個流程的執行時間消耗，可以看到時間都消耗在 TCMalloc 這個模塊上，用了 17 秒，這樣就能明確問
249、題出現在 TCMalloc 模塊，進一步分析，將 Diagnose.data 中的增量數據解析出來，可以看到 TCMalloc 在某個時間點一次性釋放了幾十個 G 的內存，一次性釋放大量內存就會引起業務卡頓，解決方案是在平峰期實時的釋放 TCMalloc 的內存，不要積壓在一起統一釋放。未來騰訊云 MongoDB 團隊計劃將 DBbrain 與 Diagnose.data 診斷數據結合，去分析深層次的內核疑難問題。126騰訊云技術實踐精選集 2022騰訊云數據庫云上 SaaS 生態演進潘怡飛騰訊云數據庫高級工程師騰訊云數據庫解決方案架構師，擁有多年的數據庫服務應用優化實踐經驗。近年來，騰訊云數
250、據庫產品在 SaaS 生態方向上積極探索與布局，在數據庫服務平臺化、自動化、智能化領域推出一系列優秀的 SaaS 產品和完善解決方案，助力互聯網、金融、傳統企業等客戶架構升級，數字化轉型，構建新一代的數據庫服務平臺。ArchSummit 2022 北京站上，騰訊云數據庫高級工程師潘怡飛發表題為騰訊云數據庫云上 SaaS 生態演進的演講，介紹騰訊云 SaaS 產品矩陣、能力、生態和演進方向。騰訊云數據庫 SaaS 生態矩陣騰訊云數據庫 SaaS 生態分為基礎能力 SaaS 化、易用性 SaaS 化、智能化運維和模塊化 SaaS 產品四個方向?？傮w來說，SaaS 產品的生態演進是基于 PaaS 產
251、品的基礎能力和衍生能力，提煉出更靠近業務屬性的 SaaS 能力，幫助用戶和客戶更好更方便地使用數據庫，創造業務價值。騰訊云 SaaS 生態矩陣的幾個主要產品包括：127騰訊云技術實踐精選集 2022 數據傳輸服務 DTS，定位為數據遷移與數據流打通的服務，包含在線遷移同步、低時延和高可靠的特性，主要包含遷移、同步和訂閱模塊。數據智能管家 DBbrain，是定位于自動化、智能化運維統一管理平臺，從前期的數據庫巡檢、故障發現、故障定位到后期的故障解決與系統優化，形成一套數據庫全生命周期管理運維的工具。數據庫安全審計，是一個內核級別的安全審計平臺。區別于一些需要旁路管控部署的方式，它對性能和收集完整
252、度都支持得比較好。同時它跟 DBbrain 聯動，對收集到的審批日志進行匯總、分析，這樣可以看到具體的問題根因，發展出在運維或者臺賬過程中也可以使用審計日志的能力。騰訊云圖，是一個定位于定制化大屏 BI 展示的平臺。它可以快速通過可視化的圖標管理來降低建立專業大屏的門檻。它內置預設了多個行業模版，可以用自由拖拉拽的方式快速形成一套炫酷大屏，包括前端數據展示。騰訊云數據傳輸服務 DTS數據傳輸服務 DTS 包括以下幾個部分：數據遷移功能面向單次的數據庫遷移，支持多種網絡鏈路，全量增量不停機遷移，最小化遷移過程中停機對業務造成的影響，全程自動化減少風險點，支持一致性校驗能力。適用于一次性遷移數據庫
253、遷移，數據庫遷移上云或遷移下云場景。數據同步功能指兩個數據源之間的數據長期實時同步，具有多種高級特性，庫表重映射、DML/DDL 過濾，Where 條件過濾，雙向同步，豐富沖突策略。適用于云上云下多活、異地多活、跨境數據同步、實時數據倉庫場景。數據訂閱是指實時按需獲取數據庫中關鍵業務的數據變化信息，將這些信息包裝為消息對象推送到內置 Kafka 中，方便下游實時消費。適用于異構數據更新、業務異步解耦 緩存更新，ETL 實時同步等場景。128騰訊云技術實踐精選集 2022上圖是數據傳輸服務整體架構，主要有兩個關鍵措施。第一個是基于原生解耦，采用統一的數據中間格式，導出和導入完全流程化。第二是插件
254、式設計，方便數據庫快速接入，解決歷史遺留問題。數據傳輸服務應用的場景有：云數據庫遷移，提供靈活的上云下云場景支持，同時支持下云到自建 IDC，有數據正確性保證。雙向數據同步，支持異地多活、異地災備，支持雙向、環形數據同步，解決了同步數據重復寫沖突問題，具備高性能、低延遲。多到一數據同步，包括多源數據聚合、匯總分析場景。支持多到一數據匯總、同步，支持分表聚合、一拆多、跨云賬號。異構數據同步，包括同源異構同步與非同源異構同步。數據傳輸服務中，數據訂閱適用于很多沒有固定下游的場景，例如數據倉庫、自定義函數、云函數等。數據訂閱的架構和同步類似，基于 Binlog 解析，將這些 Binlog 解析為正確
255、的消息對象，基于客戶配置的不同的表或庫，再推送到內置的 Kafka 里。用戶可以很方便地通過各種 Kafka 來消費不同的異構下游，實現了異構數據庫之間或者復雜鏈路之間的同構。同時 Kafka 也支持多分區，可以設置不同的策略來優化大數據量同時傳輸效率。129騰訊云技術實踐精選集 2022Binlog 本身是無法自解析的，解析出來的日志只有數值，沒有對應的表結構字段。如果按這種方式推送到下游，其實數據是不可用的。所以我們需要自研的 Schema Tracker 組件來實時、無鎖，動態獲取維護表結構的變更，這樣就完成了整個鏈路的打通。另外考慮到數據訂閱也支持到了更多數據格式，降低了用戶切換和使用
256、的成本，可以無損替換使用，方便打通不同鏈路。通過遷移、同步和訂閱三種模塊，可以充分打通數據鏈路之間的流轉管理，構建雙向、環形、異構、多合一等場景。用戶不用自己開發工具或定時任務解決這些需求，可以更專注于業務。數據庫智能管家 DBbain數據庫中統一管理時有許多難點和痛點，DBbain 是應用于這個場景的一款 SaaS 工具。它有三大功能：智能優化。針對獲取信息、分析信息、優化手段痛點，利用完善的云平臺監控、智能算法與案例庫沉 淀，針對問題根因形成優化手段。數據庫安全。DBbrain 內置深度學習算法、海量樣本，提供的功能包括安全預警、敏感數據發現、數據脫敏、治理建議等。數據庫管理。DBbrai
257、n 的功能包括云上云下混合云管理、無侵入安全鏈路、掌上運維?；谏鲜鋈蠊δ?，DBbrain 適用于數據庫日常運維、安全威脅識別、混合云管理數據庫、掌上數據庫運維等場景。130騰訊云技術實踐精選集 2022上圖是 DBbrain 的整體架構圖與核心優勢展示?；?DBbrain，運維人員可以針對突發復雜告警問題做快速處理或提前規避。DBbrain 的全生命周期管理分為幾個模塊，一是監控、預防、分析、告警，主要用于事前分析。包括 70 余項監控項，監控大屏、秒級定期巡檢，做到全程問題把控，把問題扼殺在搖籃中。這一部分還可以進行性能預測、容量預測，避免因為存儲問題影響性能。事中模塊包括快速定位和應
258、急管理，如果不幸發生問題可以快速止損。比如一鍵分析異常能力會給出具體分析，應急處理里的靈活限流可以避免問題擴散，一鍵 Kill 提供兜底能力。事后需要復盤，復盤后需要一鍵優化能力，DBbrain 會給出全盤報告對之前的問題復盤，包括自動調優、專家級建議，還有優化效果對比。DBbrain 的一個性能優化場景是慢 SQL 分析。它會基于多維度統計，包括用戶和賬號等信息，根據耗時區間來統一匯總 SQL 模版并自動排序，這樣我們可以靈活判斷出是哪個 SQL 導致的問題。下一步是性能優化，我們可以進行編譯器、優化器的改寫，比如計算代價和成本，同時可以判斷 SQL 是不是優質，是不是需要添加索引，可以針對
259、性做優化，也減少了 DB 和研發的各種對接。甚至一些不必要麻煩可以在 DB 層面處理掉。它甚至可以做 API 的拉取，再通過開源組件進行存儲分析。這樣可以基于 DBbrain 的 SaaS 能力構建自己的運維平臺，免費滿足收集、分析、優化需求。131騰訊云技術實踐精選集 2022第二個性能優化場景是異常診斷。日常診斷是根據秒級監控，對十幾個維度的信息做匯總展示。診斷提示展示診斷事件的概要信息，包括等級、開始時間、診斷項、持續時長。DBbrain 會定期進行健康巡檢。診斷事件詳情可查看事件概要、現象描述，給出智能分析以及專家建議。騰訊云 BI 云圖騰訊云圖可以零門檻構建 2D 和 3D 的前端大
260、屏，預設有多個模版，不需要有代碼門檻，可以快速構建出一個炫酷大屏，同時投屏到不同終端，后端數據源也支持多種。構建大屏只需要四步，首先創建一個大屏項目，再基于預設的模板形成及時預覽和所見即所得的頁面。第三步是配置數據源，然后預覽發布。不管是運維大屏還是業務大屏都可以快速交付。云圖的一些案例包括現在常見的疫情監控大屏，包括 3D 版的智慧校園、騰訊內部用的騰訊云大屏，還包括智慧城市、智慧零售等等。這些案例都可以用幾步很簡單地制作出來，大幅降低研發成本。132騰訊云技術實踐精選集 2022總結和展望SaaS 產品價值總結下來就一句話：可以降低用戶在工具或者不必要的研發上的投入，更專注聚焦于自己的業務
261、，不需要再去建數據庫和前端，直接依賴 SaaS 就好，幫助業務更好地創造自己的價值，不需要分散精力。DTS 后續會在場景化和復雜拓撲場景深耕，可以一鍵創建用戶需要的復雜拓撲鏈路，比如環形、雙向等場景，而且不需要逐條配置沖突策略。DBbrian 后續會向智能化、AI 化方向發展，可以直接基于慢 SQL 自動創建索引，甚至數據庫負載自動擴縮容，同時可以利用云原生數據庫的快速縮擴容能力，充分結合更多產品進行場景聯動，幫助客戶創造業務價值。掃碼獲取完整版演講 PPT133騰訊云技術實踐精選集 2022云成本優化與研發提效03134騰訊云技術實踐精選集 2022企業上云，云上資源整體成本優化管理如何做？
262、郭志宏騰訊云資深容器解決方案架構師容器解決架構師團隊負責人，具備多年容器，Kubernetes 從業經驗和豐富實踐經驗，主導了騰訊云多個大客戶向騰訊云 TKE 遷移及容器化落地工作。Kubernetes 在生產系統中部署率快速上升，然而業務上云的過程中，針對資源的有效利用有待提升。在 ArchSummit 2022 北京站，騰訊云資深容器解決方案架構師郭志宏發表題為企業上云，云上資源整體成本優化管理如何做？的演講，分享騰訊內部廣泛使用的云成熟度模型。該模型將基于云原生技術高效利用云資源手段作為成熟度重要考核指標。郭志宏還在演講中發布了基于 FinOps 理論指導的 Kubernetes 開源項
263、目 Crane。135騰訊云技術實踐精選集 2022云原生資源利用現狀CNCF 在 2021 年的報告中指出，目前 96%的企業已經開始使用云原生技術。但另一方面，Flexera 發布的2021 云計算市場發展狀態報告提到，云原生領域的資源利用率非常低，大概有 35%的資源被浪費掉了。我們也對騰訊云上客戶真實的資源利用率從三個維度做了抽樣調查，包括物理機、虛擬機和容器。其中物理機的利用率只有 10%左右，因為物理機沒有虛擬化技術，也沒有很好的混部方法，所以這個數字可以理解。虛擬機時代，我們通過 VM 在操作系統層面的隔離做了虛擬化，讓利用率提升到了 12%，也不高。Kubernetes 和容器
264、具有更細粒度的資源管理和調度能力，它應該可以最大程度提升資源利用率，但其實利用率也只有 14%左右。我們分析了一下云原生時代資源利用率不高的核心原因。在之前沒有云原生的時候，企業一般有一個統一的 IT 架構或者財務團隊，統一對半年以后的資源需求做規劃，然后采購。這是一個中心化的管理模式。邁入云原生時代，更多企業把這種權限下放給了其他業務團隊，上云后資源分配更頻繁，靈活度更高，所以沒法通過中心化手段統一管理，而是用類似分布式的手段下放給其他組織。雖然靈活了，但是管理難度更大。也就是說雖然技術或者手段有了迭代，但管理維度上對 Kubernetes 的理解程度不夠，導致了利用率還是無法顯著提升。深入
265、理解 Kubernetes 的資源管理首先我們來看 Kubernetes 是如何管理資源的。Kubernetes 是聲明式的 API，對每一種管理資源都抽象了一個對象。為了給系統或者底層組件做預留會有預留資源，分配后會有剩余，比如說一些碎片資源沒法分配。Kubernetes 還有兩個核心概念，Request 和 Limit。Request 指的是申請的資源數量，Kubernetes 是根據申請做調度的。Limit 指的是使用過程中最大可以使用的資源數量，這兩個參數對應 Kubernetes 底層的容器和技術。Request 對應 CPU Share，指 CPU 內核調度權重；Limit 對應
266、Quota，限制最大用量。這兩個參數可以提升部署密度，Request 小于 Limit 時就可以申請比較低的資源，但它可以在利用率高的時候用更多資源。136騰訊云技術實踐精選集 2022上圖是典型的資源利用率較低的情況。資源總量很多，但實際使用并不多，中間有很大浪費，包含很多未分配以及過多分配的資源。在線業務還有波峰波谷，這些波谷也是被浪費了。所以提升資源利用率的核心思路就是從這三部分入手來解決問題。Kubernetes 也提供了彈性能力，幫助我們進一步提升資源利用率。雖然 Kubernetes 提供了提升資源利用率的手段，也可以細粒度管理資源，但實踐中用戶往往并不能充分利用這些手段。核心原因
267、是我們向容器化遷移后往往會帶著之前的經驗，延續過去的用法，導致水土不服。業務人員如果通過壓測來規劃業務增長規模，往往規劃也是偏多的。如果通過彈性能力來擴容，遇到業務高峰又可能出現擴容不及時導致業務崩潰的情況。還有一些業務優先級較高，用戶也不敢縮小資源配比?？偨Y來說就是不會配、不敢配、不能配的問題?；谠圃夹g的成本管理最佳實踐基于上面的這些問題，我們有了對應的思考、方案和實踐落地。首先，我們提供了全鏈路降本方案，從三個維度出發：137騰訊云技術實踐精選集 2022上圖概括了我們的三大方案，也就是解題思路。有了解題思路后還需要理論指導，這里就要提到 FinOps Framework，它定義了一
268、套最佳實踐和原則。它提倡團隊協作，提倡團隊內部每個人都有成本管理意識；它也有一些自上而下的角色，由 FinOps 從業者或管理人員驅動整個團隊做成本優化；它也有一些階段，例如成本展示、費率優化、持續迭代運維等；要做到成功優化，我們還需要一些核心能力，包括理解用量、理解成本，理解浪費；還要做績效和綜合展示，驅動業務團隊向前走；還有實時決策、運營日報、費率優化、用量優化等。我們提供的技術手段是 Crane 開源項目。Crane 是 Cloud Resource Analytics and Economics 的縮寫，就是云資源分析和優化。Crane 框架的核心能力完全對標 FinOps 能力模型，
269、包括理解成本、快速決策、性能優化、費率優化等。Crane 核心由兩部分組成，第一部分是 Craned，第二部分是 Crane Agent。Craned 的核心是資源的預測，正常的在線業務都有類似波形的周期曲線，所以我們可以根據波形算法和歷史利用率預測未來一段時間可能需要的資源數量，推薦合理的 Request。有了預測還可以做提前彈性，解決擴縮容延遲問題。還可以預測空閑時間，讓空閑資源被其他業務重復使用。提升利用率的同時必須保障業務穩定性。Crane Agent 就是做穩定性相關的工作，它擴展了 kubernetes 的PriorityClass，提供了更多業務優先級定義。我們還提供了一些全功能
270、的 QoS 隔離，包括 CPU、內存、網絡、GPU 的 Kubernetes 隔離能力，保證高優業務不被干擾，低優業務可以避讓。138騰訊云技術實踐精選集 2022上圖是我們內部基于 Crane 做的降本產品框架?；谶@樣的降本產品，騰訊內部按照 FinOps 的能力模型指導了實踐落地過程。首先我們做了成本分析，發現業務資源利用率不高，彈性也不好，只有 10%左右的 HPA 在一年中彈出過。第二步我們做了目標設定，目標是自上而下設定，績效則是自下而上匯總：1.為優化騰訊內部業務云資源，騰訊定義了云成熟度模型；2.該模型從平臺側以及業務側考核各個 BG 的云資源使用情況；3.總成熟度得分=業務側
271、得分*50%+平臺側得分*50%；4.得分情況從作業、產品、部門維度層層匯總，并以該結果作為考核參考指標。通過這樣的模型，我們推動業務部分提升得分，取得了很好的效果。我們還有一個獎金池來獎勵表現較好的團隊。FinOps 還需要持續的優化迭代過程。這里分為業務側和平臺側兩個維度。業務側提供了成本可視化，業務人員可以看到自己的業務資源使用率情況、浪費情況、本月費用、下月費用預測。我們還根據不同部門、不同業務、不同標簽做業務匯總。使用過程中業務會提出各種各樣的需求，我們也支持了原地升降配能力、提升 VPA 時不需要重啟的能力等。139騰訊云技術實踐精選集 2022我們在平臺側也提供了一些能力，比如說
272、集群大盤的可視化，可以看到大盤集群資源利用率，哪些節點是熱點，哪些節點的資源利用率不高，等等。為了提升部署密度，在業務側可以降低 Request，在平臺側可以放大節點的可調度能力。我們在平臺側可以給節點容量做縮放，為了保證節點穩定性還提供了節點的控制。比如說某節點預估最大的 CPU 和內存達到了 80%，新的業務就向它調度，保證節點不被打掉。我們還提供了緊縮優先策略，一些空閑的資源利用率不高，我們就不往這個節點上調度，后續可以把這個節點回收掉。這些都是 Kubernetes 原生調度沒有的能力。平臺側還有一大優化能力是業務定級與混部。我們可以大范圍提升資源利用率，核心有兩點，一是提供了 Pri
273、orityClass 的優先級定義，讓業務定義它的優先級，高優任務可以定成 1 和 0，其他業務可以定到 2、3，離線任務可以定義較低水平。這樣通過 Crane Agent 或底層內核提供的 QoS 隔離技術保證高優任務可以在業務高峰時搶占低優業務資源。騰訊內部目前有上百萬核的混部集群，利用率一直維持到 50%-60%左右。降本產品混部推廣后在數百個集群、上百萬核資源做了實踐。結果資源的申請量通過預測技術降低了 25%左右，效果非常明顯。GPU 資源成本優化兩年前谷歌在一份調研報告中提到，GCP 的 GPU 利用率只有 40%左右。騰訊云上用戶的 GPU 利用率也不高。我們認為核心原因在于 G
274、PU 推理任務較多，很多資源被浪費。目前 Kubernetes 提供的 GPU 管理技術也沒法共享資源，英偉達提供的 vGPU 技術也沒法細粒度到進程層面的調度，所以 Kubernetes 場景使用起來不太方便。業界方案也有很多問題?；谶@些困境，騰訊虛擬化團隊做了 qGPU 產品。它可以讓多個容器共享一張卡，并且可以細粒度保證算力和顯存精細隔離，同時支持業界唯一的在離線混部能力，從而在精細切分 GPU 資源的基礎上，在最大程度保證業務穩定的前提下，將 GPU 利用率壓榨到極致，最終幫助客戶大幅節約 GPU 資源成本。qGPU 使用起來非常簡單，我們繼承了 Kubernetes，還提供了三種隔
275、離策略和調度模式，分別是默認的 Best-Effort，可以互相搶占；Fixed-Share 固定配額；Burst-Share，保證配額加彈性能力。140騰訊云技術實踐精選集 2022掃碼獲取完整版演講 PPT我們測試了 qGPU 方案的性能，發現精度、準確度、吞吐和原生方案相比基本沒有損失，隔離性非常好。qGPU 與業界方案對比，兼容性、抖動性、算力隔離、靈活度、切分粒度等層面都有優勢。Crane 項目在 2021 年底開源，希望業界可以一起參與共建，也歡迎大家試用和落地實踐。希望我們提供的技術可以幫助更多企業享受到云原生技術的紅利。141騰訊云技術實踐精選集 2022企業如何利用云廠商能力
276、構建自己的分布式云？李向輝騰訊云容器技術專家騰訊云容器技術專家，騰訊云分布式云產品副總監，主要負責騰訊分布式云產品，致力于基于容器技術構建分布式云，構建分布式云操作系統，向下屏蔽混合異構的基礎，向上支撐業務系統上云，同時支撐更多的應用和行業。具有多年分布式系統高可用，可并發和在線服務治理經驗，曾負責過十億 pv 應用的在線業務架構和應用遷移云原生經驗，以及混合云操作系統經驗，在穩定性提升，成本優化，效率和業務體驗提升上有較深的積累和思考。2021 Flexera 云狀態報告顯示，92%的企業選擇多云戰略，企業平均使用 2.6 個公有云+2.7 個私有云。Gartner 2020/2021 連續
277、兩年將分布式云作為十大頂級戰略趨勢之一，同時預測，2025 年超過 50%的組織將使用分布式云實現業務轉型。信通院“2021 云計算十大關鍵詞”之三：云原生、混合云、邊緣計算。企業在構建分布式云的過程中，面臨復雜的網絡互通與管理，統一控制面和操作體驗和業務單元化部署等眾多挑戰。ArchSummit 2022 北京站上，騰訊云容器技術專家李向輝發表演講企業如何利用云廠商能力構建自己的分布式云？介紹騰訊云在分布式云領域的實踐和思考，介紹企業如何利用企業既有的 IT 投資構建自己的分布式云，實現降本增效。142騰訊云技術實踐精選集 2022企業上云困境與行業趨勢我們首先來看企業上云面臨的核心問題。第
278、一個問題是 IDC 利舊場景。在企業上云時往往有大量 IDC 物理機或私有云，希望能充分利用這些 IDC 資源。其次，這些 IDC 資源和公有云連接后，發現整體資源利用率只有 10%左右。企業面臨的問題是如何通過部署密度提升、綜合調度編排能力、離在線混部來提升資源利用率。第三，由于用戶在 IDC 環境中構建了自己的私有云，同時又使用了云廠商能力構建了公有云，在滿足數據主權和安全能力需求的前提下，如何構建體驗一致的一朵云也是一大問題。最后，混合多云成為目前企業上云的主流架構，企業要同時面對 IDC 資源和多家公有云資源，如何屏蔽底層的異構基礎設施，實現上層應用的統一管理，也是一大課題。目前業內有
279、三大技術趨勢值得關注：一是容器采納率在不斷提升，2022 年 Forrester 報告指出行業容器采納率達到 50%左右，CNCF 云原生用戶調查報告也顯示，目前計劃和正在使用容器 K8s 的用戶達到 96%；其次，由于新冠疫情和地緣政治的影響，降本增效成為企業的主要趨勢；最后，我們還看到托管容器服務的平均年增長率達到了 140%，同時容器的滲透率達到 50%+。我們認為云原生能夠很好地屏蔽底層異構基礎設施的差異，同時有效提升部署密度和彈性。分布式云能夠有效平衡資源和應用架構，是企業漸進式上云的最佳方案。Gartner 在分布式云的定義中指出，將公有云服務分布到不同的物理位置，而服務的所有權、
280、運營、治理、更新和發展仍然由原始公有云提供商負責。騰訊云在 2022 年七月份聯合信通院發布業內首個“分布式云發展白皮書”。我們認為分布式云是將云服務按需部署到不同地理位置，提升統一管理能力的云計算模型。騰訊云在原生分布式云的實踐騰訊云原生分布式云的載體是云原生操作系統遨弛 Orca，我們希望統一管控用戶跨數據中心、多云和邊緣的基礎設施，給用戶提供一致的體驗，使用戶可以隨時隨地構建云原生的應用能力，最終將一致、延伸的云服務提供到用戶的生產現場 IDC。我們希望通過騰訊的云原生操作系統實現分布式云的戰略，最終達到開源創新、全域治理、無限算力和觸手可及的目標。騰訊云原生分布式云是構建在遨弛操作系統
281、之上的，是一個面向多云和多集群的應用管理平臺，主要包括三個部分：143騰訊云技術實踐精選集 2022TKE Anywhere，希望能夠在任意位置創建 Kubernetes 集群，納管任意的 Kubernetes 集群；TKE DataService。我們在用戶落地實踐的過程中發現用戶需要有云端監控、日志、運維、審計以及安全等能力。當我們向用戶交付本地化容器環境時，用戶需要 PaaS 數據庫和中間件能力。這一部分可以將公有云 PaaS 能力延伸至多云、混合云或邊云環境；TKE AppEngine，分布式云應用管理平臺。云原生分布式云的應用場景包括：資源利舊，打通 IDC 資源和云上資源，實現云上
282、云下的一致體驗；云邊一體場景，將公有云能力交付至云下，通過分布式管控進行弱網自治，實現云邊一體管理；混合多云，構建一個多云混合云底座，實現業務的跨云遷移和多活。騰訊云原生分布式云的主要解決場景我們在落地過程中面臨的核心問題如下：144騰訊云技術實踐精選集 2022如何管理異構的基礎設施差異我們的解決方案是 TKE Anywhere。TKE Anywhere 是將 TKE 延伸到任意環境，無時無地無差異地獲得騰訊云原生能力。對于云下節點，TKE Anywhere 可以通過云聯網技術實現云下節點和云上VPC 的互通。其次，TKE Anywhere 使用了騰訊開源的 Clusternet 方案，可以
283、通過反向注冊通道為 Agent 反向連接到云上時構建安全通道，實現云上可以安全管控云下集群，最終實現云上和云下集群和節點的統一管理。在邊緣等網絡條件較差場景下，采用 SuperEdge 方案保證網絡斷開情況下用戶也能保持邊緣自治能力。通過構建安全的連接通道和云聯網連接，TKE Anywhere 可以將云上監控、日志、審計、事件、安全認證、權限授權等一系列能力延伸到云下。我們還可以通過應用市場分發云上應用，同時進行業務的治理、一鍵擴縮容、PaaS 組件的交付。如何解決多場景網絡互通我們還提出了新一代容器網絡解決方案，適用于四種場景。用戶在云上可以使用我們的網絡方案，但用戶在 IDC 場景下不具備
284、 SDN 網絡能力，需要采用 BGP、Overlay 等多種網絡模式。我們支持在一個集群、一個節點上運行多種網絡模式，實現混合網絡的網絡互通。給用戶提供云上 LB 方案時我們采用 LB 直通的零損耗網絡方案，可以使整體性能提升 50%-70%。同時我們還支持網絡限流能力和在離線混部，在混合網絡場景下支持業務動態優先級的絕對搶占及多優先級任務的搶占。我們還有精細化 IP 管理機制，包括指定 IP、固定 IP 和多集群共享子網能力。整套網絡方案支持萬級 TKE 集群、30 萬節點和 600 萬容器穩定運行。如何實現輕量應用交付傳統本地化交付方案采用云下交付，需要派遣駐場運維人員，成本較高、毛利較低
285、。且私有化交付導致版本管理復雜，問題的發現和解決依賴駐場人員。我們的輕量交付方案依托開源 Clusternet 方案，通過 Clusternet-Agent 和云上分布式云集群 TDCC 連接后，構建了一個完整的交付通道。當用戶沒有完整的 TKE 集群時，我們將云上 TKE 的發行版交付到云下，而用戶只需要在云上簡單操作就可以完成部署，后續的運維和升級由騰訊公有云來負責。如果用戶已經有了 Kubernetes 集群，我們通過注冊集群能力安裝好 Clusternet-Agent，完成云下集群和云上集群的連接，構建一個交付通道。接下來可以通過云上應用市場能145騰訊云技術實踐精選集 2022力將云
286、上應用分發至 TKE Anywhere 或者注冊集群。之后通過正向代理構建 LB，將云下日志、監控等數據推送到云上，然后依靠公有云監控和日志來做報警，可以先于用戶發現問題。由于云上集群和云下集群是一致的 TKE 發行版，也就提供了一致的用戶體驗。由于云下數據會實時推送到云上，我們可以運用公有云的大量運維經驗先于客戶發現問題，發現問題后又能通過交付通道來及時修復，降低集群運維成本。用戶還可以通過這個交付通道連接自己的應用，實現自己應用的備份和升級能力。如何解決數據庫中間件依賴問題完成用戶集群交付后，用戶在多云環境下會有一些數據庫和中間件的依賴。這里通過 TKE for DataService 的
287、能力，使用上述交付通道來交付云上 PaaS。TKE for DataService 的能力有遠程投遞、離線時云下自治，以及在公有云管控云下服務，提供多云 IDC 和邊緣場景下一致的數據庫引擎及管理能力。用戶在構建 PaaS 體系時會存在 PaaS 版本不一致，多云 PaaS 不統一，PaaS 彈性擴容能力不足三個問題。用戶 PaaS 版本的能力不足時，我們可以通過云上遠程投遞能力逐漸滿足用戶需求。用戶多云的 PaaS 不統一時，因為我們在底層構建了 TKE Anywhere，就可以將一致的 PaaS 應用在這個環境下，實現 TKE PaaS 能力的統一。因為原有的 PaaS 能力擴容依賴于底層
288、資源擴容，由于我們的 PaaS 是在容器環境下，環境適配后可以提供快速彈性。目前我們已經支持了 6 款 PaaS 組件的分發。如何解決應用統一管理問題用戶在多集群環境中需要統一發布管理多個云上的應用和服務，還要解決應用的跨域容災、故障遷移、備份場景需求，與多集群間的彈性伸縮調度需求。為此我們提供了 TKE AppEngine 一站式應用管理平臺。該平臺可以構建分發資源，稱為 CRD，再由用戶制定分發策略，進行多個集群的統一分發。多個集群配置存在不一致時，可以通過配置的差異化管理來滿足多個集群之間分發的差異性要求。在此之上，我們構建了一個云原生網關，能夠基于流量進行智能調度和親和性調度。同時我們
289、提供了一套統一的權限和認證機制，滿足業務的安全、合規和審計需求。平臺整體對用戶是零侵入的，用戶可以方便地管理自己的集群，而不需要對原有的基礎設施進行統一改造。146騰訊云技術實踐精選集 2022如何進行成本優化如何將云上成本優化經驗輸出到云下？我們給出的解決方案是成本大師。我們認為成本優化分為幾個方面：首先是可擴展的資源優化推薦，通過實時監控數據發現業務級別的浪費情況，同時給出業務的平臺得分和業務得分，為用戶提供整體的最佳資源推薦。這里分為 Request 推薦和副本數推薦，能夠推薦出一個應用應該申請的內存、CPU 的資源大小、以及它應該有多少個副本；針對突發流量，我們實時監控用戶過往 14
290、天的數據，結合用戶應用特征繪制用戶的業務畫像，我們能夠提前預測整個業務的副本數和推薦資源，通過容器原地升降配以及副本數擴充去解決 VPA 和 HPA 擴容和彈性不一致問題；我們還提供了節點增強調度能力，支持節點打散和緊縮調度，提升節點利用率并實現應用均衡調度。在業務混部場景，我們通過多優先級管理和容器動態調度機制來解決調度時容器資源分布不均的問題?；隍v訊開源方案，我們提供了 CPU、內存、磁盤、網絡以及 GPU 等多種資源的精細隔離能力，實現資源的最大化利用，降低應用的交付成本。企業構建分布式云案例分享企業該如何構建自己的分布式云原生云？我們提出了三種模式：第一是節點連接模式，也就是注冊節點
291、模式；第二是集群部署模式，也就是輕量交付模式；第三是集群注冊模式，也就是集群連接。注冊節點是云上運行托管的 TKE 服務，允許用戶將非騰訊云的主機添加到騰訊的容器服務。此時 Kubernetes 集群的控制面在云上，而用戶自己的節點通過專線和云聯網技術和云上打通，這樣就可以利用 IDC 資源來進行整體部署。同時由于云下只有一個簡單節點，云上節點就可以免運維。由于云上 TKE 的控制面對接到了云上監控、日志、審計和安全服務，就可以無差異實現云下和云上節點的能力一致性。同時我們也支持云上和云下節點混合部署，實現云上和云下一致的彈性。實踐中，某客戶在 IDC 購買了大量物理機需要利舊，但在上云時這些
292、機器又不能退庫。用戶還想嘗試云原生技術方案來提升部署密度和降本增效，希望利用這些 IDC 資源實現快速云原生。我們給用戶推薦了云原生分布式云方案，將 IDC 節點以云聯網方式加入公有云，實現 IDC 節點和云上 VPC 之間的互通。接下來，我們在云上節點運行云上插件，在云下運行 Overlay 網絡模式，使用集群的混合網絡。IDC 集群導入公有云后，整個云集群的運維由云團隊負責，同時 IDC 資源又能夠利舊和重復投入，實現降本增效目標。147騰訊云技術實踐精選集 2022有些客戶有大量 IDC 資源，需要在 IDC 里部署一個集群，同時需要完整的控制面。這時用戶往往會自建一個 Kubernet
293、es 集群，但 Kubernetes 集群的學習曲線是非常陡峭的。這時可以用 TKE Anywhere 集群來統一云上和云下能力。還有客戶的數據機器是邊緣節點或設備，分散在相距幾十公里遠的工廠內，網絡又是弱網絡。這時可以使用 TKE edge 方案，TKE 控制面在云上，云下節點只需裝一個插件就可以實現云下弱網環境的統一管理。隨后，用戶可以通過云上應用市場，將日志監控和 PaaS 能力下發到云下，運維一側又有公有云的運維團隊負責，這樣極大提升了應用的交付效率，降低了業務的交付成本。這種模式稱為輕量交付模式。某光通信企業有若干工廠和分廠，工廠間距離很遠?？蛻粝Ｍ诩瘓F統一管理各個分廠，又希望有統
294、一的云廠商維護集團公有云的基礎設施。我們提供了云原生分布式云的分級管控方案。首先我們在云上通過云原生分布式云中心，為用戶集團工廠交付若干個 TKE Anywhere 集群。在集團工廠上，我們通過 TKE Anywhere 搭載的邊緣一體機部署在用戶的企業工廠。邊緣一體機注冊到 TKE Anywhere 上，實現數字工廠的三級管控能力。同時用戶可以用邊緣設備打通自己的 IT 和 OT 通道，獲得大數據運算及邊緣 AI 檢測能力。由于我們打通了云邊端通道，用戶出現故障后我們可以及時解決。集群注冊是將用戶本地數據中心的 K8s 集群或其他云廠商的集群接入到云平臺實現統一管理。云原生分布式云中心可以對
295、多個集群進行統一管理，對分布式應用進行統一分發，同時管理多個集群的流量來實現業務流量的動態調度。云上的可觀測能力還可以滿足監控和審計要求。某韓國游戲注冊用戶 1500 萬，業務主要部署在東京、首爾和新加坡的 TKE 集群，以及北美和歐洲的 AWS 集群。由于我們的云原生分布式云是支持國際站的，我們通過國際站能力將分布在 TKE、AWS 和 Kubernetes 的集群進行統一管理，同時將日志監控統一接入騰訊云國際站，給用戶提供開箱即用的高運維效率和系統高穩定性。同時我們通過應用的分發策略、多集群的批量發布和灰度發布能力，最終實現業務的快速遷移，提升了業務發布效率，降低出錯率。148騰訊云技術實
296、踐精選集 2022總結總體來說我們解決了兩個核心問題，一是管理異構資源，二是承接上層應用。我們主要通過五層能力來構建方案，最底層是騰訊云遨弛云原生操作系統，之上構建了 TKE Anywhere 實現任意位置集群的統一管理。在此之上通過 TKE for DataService 實現云上能力一比一延伸至 IDC 和用戶現場。在 PaaS 組件和應用交付后，我們提供了一站式的應用管理中心來多維度管理用戶在多云上的應用。最后，我們希望云原生分布式云能夠給用戶賦能，讓用戶可以利用云廠商能力在任意基礎設施上享受騰訊云帶來的云原生生態，構建一朵自己的分布式云。掃碼獲取完整版演講 PPT149騰訊云技術實踐精
297、選集 2022從混部到 Serverless 化，騰訊自研業務的穩定性及云原生成本優化實踐呂祥坤騰訊云容器高級工程師負責騰訊內部超大規模云原生應用平臺 TKEx 的研發設計工作，已支持包括騰訊會議、QQ、騰訊文檔在內的海量自研業務實現云原生架構改造。隨著云原生技術的逐步推廣，騰訊公司內部也在大力推動業務使用云原生容器化的方式去構建自己的應用。Kubernetes 作為云原生應用管理平臺，成為大家的一致選擇。雖然 Kubernetes 有著眾多優勢，但是去建設并運營一個云原生應用平臺，依然存在很多的痛點與挑戰。特別是在業務規?？焖僭鲩L后，平臺資源運營成本居高不下。為此平臺希望通過混部提升資源利用
298、率，以此節省成本，卻導致服務穩定性受損。ArchSummit 2022 北京站，騰訊云容器高級工程師呂祥坤帶來分享從混部到 Serverless 化，騰訊自研業務的穩定性及云原生成本優化實踐，介紹騰訊內部云原生應用平臺在面臨規?？焖僭鲩L遇到的痛點問題時給出的解決方案。150騰訊云技術實踐精選集 2022騰訊自研業務容器化上云歷程及主要問題上圖是騰訊內部業務上云的簡略架構。最下層是我們騰訊云基礎設施層，包括計算、存儲、網絡，上面提供基礎服務。再對服務做產品化包裝，就有了公有云的 TKE、EKS、TKE-Edge、TKE-STACK 等，有了這些產品化服務，我們在公司的 OA 這邊給用戶提供了容器
299、控制臺，用戶可以在這里查看他們自己創建的服務和相關數據。并且我們會把原生的 Kubernetes API 提供給用戶和研效平臺，用戶可以在研效平臺實現從代碼開發到應用構建再到應用發布的完整流程。我們的平臺早期是獨立集群架構，給每個業務在每個用戶需要的地域創建一個獨立集群。獨立集群有幾個缺點，一是節點裝箱率較低，二是資源利用率偏低，因為很多業務每天都會有很長時間是空閑的。三是運營成本高，四是海量節點運維成本高，沒法利用彈性優勢。于是我們把獨立集群改成了公共集群，所有的業務都使用同一個集群。151騰訊云技術實踐精選集 2022在線混部集群的資源利用率提升方案上圖是該方案的整體架構。我們會依賴監控平
300、臺所存儲的業務節點負載相關數據，再使用一些算法對用戶資源進行預測，描繪業務畫像。有了這些數據后我們做了二層資源超賣、節點負載均衡調度、彈性伸縮、業務配額動態管理。動態調度器。Kubernetes 原生調度器屬于靜態調度，當大量業務混部在一個集群時，必然出現節點負載不均衡，Pod 調度時仍可能往高負載節點調度，造成業務服務質量下降。為此我們自研了動態調度器，讓節點的關鍵資源在集群節點中均衡分布。調度器會定期拉取每個節點的負載情況，調度時讀取候選節點指標來過濾節點，對過濾出來的節點打分并選取合適節點來調度。具體流程中，如果一個集群在某一小段時間內有一大批 Pod 同時創建，很可能這一批 Pod 都
301、被調度到相同節點上，因此我們又自研了熱點動態補償算法來解決問題。我們加了一個評測指標，用它評測節點被調度的頻繁程度，用來和剛才計算出來的負載分數對沖。二層動態資源超賣?；觳康暮诵脑V求是提升整個集群的資源利用率。為此一定要把超賣比控制好，盡量不影響業務的穩定運行。其次，節點資源超賣后不能對 Kubernetes 驅逐機制和資源預留機制產生影響，超賣比變化需要動態調整 Kubelet 的對應配置。超賣比需要根據節點實時負載數據動態調整，防止節點負載過高。如果確實出現高負載情況，我們會對節點進行驅逐。如果出現大面積節點高負載，會通過集群彈性伸縮方案盡快向集群添加節點。這個方案有兩個核心組件，分別是
302、Compressor，用于動態調整 Pod 資源壓縮比；還有 Oversaler，用于動態調整 Node 資源超賣比。152騰訊云技術實踐精選集 2022集群彈性伸縮。我們平臺已經運行了上百個集群，核心目標是統籌全局，讓整個平臺所有節點能夠在各個集群之間高效流轉、管理，提升資源利用率。我們還要做不同集群的節點上下線自動化和標準化，同時針對緊急擴容和普通的常規擴容需求準備兩個資源池。該方案中，De Scheduler 組件會先送一個節點，把 Pod 驅逐掉。Node Score 組件負責給節點打分，將低分節點下線對整個集群影響最小。HNA Controller 組件在集群高負載時添加節點，集群空
303、閑時下線節點。ERP Controller 對接我們自己維護的資源池和公司免審批資源池，做節點擴縮容。集群縮容策略。集群要驅逐節點時，要選擇對業務影響最小的節點。Node Score 組件會對所有節點打分，閾值以下的節點是可以縮容的。這里先拉出整個節點下所有 Pod 的情況，看 Pod 所屬的負載是否開啟副本數，是否是無狀態負載類型，是否創建在了測試空間。知道 Pod 所屬的負載得分后，看實際 Pod 的負載情況。經過計算得到節點上每一個 Pod 的得分，最后將所有 Pod 得分求和，再計算和查看節點的實際負載情況，根據實際 Pod 數量得到最終分數。業務彈性伸縮。集群混部方案中業務也要配合彈
304、性伸縮策略。我們基于社區原創的 HPAPlus-Controller 研發了增強版的 CronHPA-Controller 來支持業務常規場景。它支持用戶給每個 HPA 對象定制擴縮容策略、HPA 計算周期和容忍度，還支持彈性最大副本數的配置策略。我們還針對整個集群所有對象都創建一個 Workload，需要計算 Workloads 調整副本數時，我們支持幾千個對象并行策略，能夠最快響應業務流量擴容訴求。HPA 和 VPA 也有聯動策略，我們優先會使用固定副本數，但 HPA 也會生效，會計算當前確定的固定副本數是否能滿足業務需求；如果不能，會繼續擴容到 HPA 最大副本數的 2 倍。在線混部利用
305、率提升方案取得了很好的效果，通過在線業務混部超賣方案，集群 CPU 平均利用率提升到 30%40%。使用動態調度器后，幾乎所有節點的資源利用率都比較均衡，方差不會特別大。穩定性提升方案?；觳繜o論如何都會對業務運行造成一定影響。因為原生的基于虛擬機創建的集群上，一個虛擬機會創建多個業務 Pod，這些 Pod 之間并沒有完全隔離。當某一個 Pod 出現問題時會導致這個節點上所有 Pod 異常，甚至節點自己出現問題。為此，我們做了節點層面和容器層面的優化。在節點層面，我們所有的集群都裝了 APD 組件。它會讀取節點狀態，分析異常日志，展示穩定性指標等。騰訊內部團隊專門定制了一個團隊內核，我們能讀到內
306、核級別的穩定性問題。出現異常時我們會按照預定策略執行動作，比如重啟節點。153騰訊云技術實踐精選集 2022擁抱騰訊云彈性容器服務 EKS 的價值所在集群擴展到超大規模后，混部帶來的穩定性影響是不可避免的。于是我們逐漸把架構從混部遷移到了 Serverless，就是騰訊云彈性容器服務 EKS。EKS 采用 Serverless 架構，以 Pod 為交付資源，無須在集群添置節點即可部署負載。容器彈性不受固定資源池限制，理論上可以無限擴容。它采用 Pod 間虛擬化隔離技術，每個 Pod 獨享虛擬機，不會被集群其他異常 Pod 干擾。EKS 通過 Pod 而非節點計費，根據 Pod 的資源配置及運行
307、時間計費，容器運行結束自動停止計費，無須為 Buffer 資源付費，可以降低運營成本。EKS 的產品優勢包括：支持 K8s 編排，完全兼容社區 K8s API。內核的計算、網絡性能非常好。高可用，可自動/指定跨 Zone 部署應用，容器支持熱遷移。支持異構算力，包括多種主流 CPU 型號、虛擬化 GPU。彈性效率，支持敏感擴容、定時擴容。安全性強大，有租戶間隔離等。154騰訊云技術實踐精選集 2022掃碼獲取完整版演講 PPT未來規劃 引入 EHPA，預測傳入的峰值流量并提前擴展其副本數，提升用戶使用 HPA 的信心。通過服務負載歷史數據，給用戶進行資源配置推薦，以此提升資源利用率。針對需要固
308、定副本數的工作負載，進行副本數推薦；針對可以開啟 HPA 的工作負載，進行上下限副本數推薦。155騰訊云技術實踐精選集 2022Serverless 時代下，企業微服務的降本思考與實踐于善游騰訊云微服務高級工程師騰訊云高級工程師，負責騰訊云 TEM 產品的設計與開發，專注于微服務和 Serverless 云原生領域，在微服務方向具有豐富經驗。自 2014 年 AWS 推出 Lambda 服務開始，Serverless 的概念遍借著云原生的東風吹向企業應用開發的各個角落。Serverless 快速交付，免運維，極致彈性擴容等諸多特點，為企業應用開發的降本增效提供了簡潔有效的最佳實踐路徑。與此同時
309、，在如今大多數企業應用架構都已經轉型為微服務架構的今天，如何讓微服務在 Serverless 平臺產生價值最大化，讓 Serverless 平臺成為支撐微服務架構實現的最佳方式，便成為了一個值得探討的話題。ArchSummit 2022 北京站上，騰訊云微服務高級工程師于善游帶來題為Serverless 時代下，企業微服務的降本思考與實踐的演講，從騰訊云微服務產品矩陣出發，結合眾多企業在上云過程中的實踐，為大家提供企業微服務架構在 Serverless 平臺上實現降本增效的新思路和最佳實踐方式。Serverless 場景帶來的新機遇在前云原生時代，IDC 基礎設施時期的問題是波峰波谷相差很大，
310、用戶成本和體驗很難平衡。虛擬機時期的問題則是虛擬化技術重復輪子很多，很難保證質量，且一致性較差。156騰訊云技術實踐精選集 2022進入云原生時代，主流的 Kubernetes 最大的問題是學習曲線陡峭，且生態龐雜、難以取舍。傳統應用改造遷移成本非常高昂。2016 年谷歌 Cloud 誕生，FaaS 形態的 Serverless 產品開始百花齊放。2019 年，基于 Kubernetes 的 Knative 誕生，以應用為中心的 Serverless 產品進入新形態。Serverless 有兩種形式，一種是面向應用的，另外一種是 FaaS。很多用戶認為 FaaS 并非最佳選擇，因為企業需要對應
311、用做大規模改造來對接 FaaS 平臺，且 FaaS 依舊需要冷啟動時間。為此騰訊關注的是面向應用的 Serverless，希望讓用戶的應用無需改造也能享受 Serverless 的優勢。Serverless 平臺如何成為微服務架構的最佳底座在企業架構演進過程中，資源層和應用層是相輔相成的發展過程。應用層從單體發展到微服務架構，資源層則從 IDC 到 Kubernetes 再到 Serverless。微服務體系的特性包括日日可發布、實時可擴縮、故障可回滾、平滑過渡，隨之而來的是發布挑戰，流量彈性挑戰，可監測性挑戰。騰訊致力于幫助用戶解決這些問題，通過極致的彈性方式幫助用戶提升可用性，幫助用戶平滑
312、升級應用，保證業務不中斷服務，同時也節省用戶的資源成本，解決服務質量下降和運維成本高的問題。第一代微服務技術是侵入式的框架，其優點是去中心化，引入注冊中心，服務間的通訊及容錯機制模塊化，非功能性能力下沉。而它的缺點有框架適用范圍、語言有限，對業務存在侵入性，框架維護成本高、升級困難，框架提供的治理能力有限。第二代微服務技術是 Sidecar Proxy 模式的服務網格。優點是屏蔽分布式系統通信的復雜性（負載均衡、服務發現、認證授權、監控追蹤、流量控制等），服務只用關注業務邏輯；異構語言，統一服務治理體系，標準化；對應用透明，Service Mesh 組件可單獨升級。缺點是存在一定程度上的性能損
313、耗，引入 Service Mesh 服務實例還有運維和管理問題。第三代微服務技術是內核態的服務網格，優點是不需要 Sidecar，直接在套接字和網絡接口處攔截數據包，請求路徑縮短，性能更優。缺點是實現復雜，技術較新，未經過大規模生產驗證。157騰訊云技術實踐精選集 2022上圖是企業微服務在云上部署的一種形態。騰訊云 TEM 針對企業應用降本增效的優化首先是 DevOps 層面。DevOps 是部署到各個環境上的構建模式，是比較流行的構建方式。TEM 通過兩種方式實現 DevOps，一是通過騰訊云 Coding 平臺。我們在 Coding 上有插件，可以部署到騰訊云的 TEM 上，可以選擇各種
314、發布方式，自動分批或者手動分批發布，接入 Coding 上云。第二是 IDEA 方式，主要面對開發者。我們開發了一個 IDEA 插件，開發人員可以直接通過 IDEA 部署到騰訊云上。其次是針對鏡像構建加速做的優化。傳統的 Docker Build 有很多問題：只改變 Dockerfile 中的一行，就會使之后所有行的緩存失效；無法提供編譯歷史緩存，多階段并行的構建效率不佳；鏡像 Push 和 Pull 的過程中存在壓縮和解壓的固有耗時。因此騰訊云 TEM 針對傳統的 DockerFile 做了改變。我們用了最新的 Docker 開源數據，Buildkit 組件做了構建。該組件的穩定性、兼容性、
315、構建效率、Push 效率和可維護性都很好。經過優化后，用戶原本拉取鏡像所需的時間被節省下來，鏡像構建和 Push 速度也提升了。TEM 針對應用加速也做了優化。這里主要是指 Java 的應用加速。Java 提供了一種冷啟動加速方式 AppCDS，先使用 ClassList，然后把源數據存儲到 JSA 文件中，再指定文件進行應用加速過程。它的缺點是使用比較繁瑣，且 Spring Boot 應用需要使用 Maven Shade 插件改造。而 TEM 對任何應用都可以直接158騰訊云技術實踐精選集 2022加速，無需任何改造。RCK 會自動解析 JAR 包，對 Spring Boot 嵌套 JAR
316、包結構進行解析和改造。TEM 還能自動將 AppCDS 的歸檔文件構建成一個 Image Layer。TEM 還使用 AppClassLoader 加載歸檔文件，實現加速。在發布管理層面，我們引入了開源社區的 OpenKruise CloneSet。但它不支持多個批次，只支持兩批；它還不支持自定義刪除策略，原地升級是先縮后擴的語義，需要支持多種批次確認策略。第一版的問題主要是過多消耗用戶資源，平臺側成本也較大。為了解決問題，我們引入了多集群管理方案。這是平臺納管的 Kubernetes，可以做應用下發、協同管理。在極致彈性層面，TEM 針對傳統的 HPA 做了一些改造。我們可以通過一些指標做彈
317、性處理，還支持從 0 到 1 的彈性過程。我們對接了 TEM 上的各類 HPA，如網絡帶寬、網絡流量、磁盤流量等指標都可以對接上去?？捎^測性層面包含三部分，分別是 Logging、Tracing、Metrics。TEM 可以通過各種各樣的協議進行指標上報。騰訊云 TSE 針對大規模微服務的落地實踐騰訊內部的注冊中心孵化出了北極星（PolarisMesh）。之前，我們在服務注冊上遇到的最大問題是公司的服務注冊是不統一的。我們為了統一服務注冊開發了北極星，目前整體注冊服務數已達 160 萬，服務企業數 340 萬，接口日調用量 20 萬。北極星解決了分布式和微服務架構中的服務發現和治理問題，提供了
318、服務注冊、健康檢查、服務發現、服務路由、負載均衡、服務降級、服務熔斷、服務限流等功能。其中，TSE 解決的是微服務的傳統問題，提供服務注冊、健康檢查、服務發現、服務路由、負載均衡、服務降級、服務熔斷、服務限流等功能，還可以提供跨地域的數據就近接入能力。北極星除了支持多語言 SDK 外，還有 Mesh、HTTP、DNS 接入，解決了多個集群之間的通信問題，同時還提供 HTTP 協議和 DNS 的注冊過程。TSE 還為央視頻提供了統一的注冊方案。TSE 的全局服務注冊中心解決了服務發現問題；多種路由策略，解決集群隔離以及互訪問題。TSE 還兼容多種接入模式，解決新增與存量互訪問題等。掃碼獲取完整版
319、演講 PPT159騰訊云技術實踐精選集 2022騰訊課堂面向協作的 DevOps 流程設計與實踐董嶠術騰訊課堂研發效能負責人先后參與過 QQ 群、吃喝玩樂、NOW 直播、騰訊課堂等產品的研發，在云原生、研發效能和分布式架構方向深耕多年，目前是騰訊課堂后臺 Leader 和研發效能負責人。關注云原生、CICD、可觀測、自動化測試、性能和成本優化等方向的最新理念與實踐。今天的互聯網行業面臨了越來越多的不確定因素，如何降本增效成為熱議話題。在 ArchSummit 2022 全球架構師峰會（深圳站）上，騰訊課堂研發效能負責人董嶠術帶來了題為騰訊課堂面向協作的 DevOps 流程設計與實踐 的演講。董
320、嶠術從研發流程和開發節奏入手，分享騰訊課堂在 DevOps 流程中，如何通過統一化、標準化、透明化、主干開發、APIOps、GitOps、測試左移、領域驅動等方法，逐漸降低研發人員理解和交流成本，提高工作拆分的合理性和提升項目落地執行效率，從而提高業務整體研發效能。背景騰訊課堂平臺是 B2B2C 的直接教育平臺，業務非常復雜。首先它是一個電商平臺，有商品系統、機構中心、營銷系統和支付結算系統；其次它也是一個教學平臺，有直播房間業務、考勤簽到業務、考試批改業務；另外它也是一個開放協作平臺，有開放平臺、ToG/ToB 業務、私有化能力。騰訊課堂平臺有多年歷史，現在微服務有上千個，三種語言實現，五種
321、 RPC 框架，歷史債務很多，提升研發效能比較困難。160騰訊云技術實踐精選集 2022外部因素來看，近兩年在線教育經歷了高峰到低谷，又出現了職業教育風口，我們也在順應大潮發展職業教育。面對這些內外部因素，業務快速迭代的能力就成為通向成功的非常關鍵的因素。談到快速迭代，理想的研發節奏是按部就班的，按照產品節奏慢慢迭代，但現實情況不是這樣。因為市場、用戶習慣、政策都在變化，面對突如其來的問題我們可能會發起一場戰役，打完后會修整一下進入下一場戰役。為了打好團戰，我們有很多角度可以提升效率，例如建設公共中臺來提高復用度、通過云原生實踐降低業務的運營成本、實現快速自動擴縮容、提高開發人員研發和交付的能
322、力，或者技術主管提前預測產品動向，做技術預研或布局，等等。從 DevOps 的角度來看，我們要提高協作效率，從而提升團戰能力。從 DevOps 流程來看，隨著參與人員不斷增多，研發耗時成本一開始會逐漸下降，但繼續增加就會逐漸趨于平緩，甚至可能會開始回升。因為人員之間的理解成本、交流成本和資源浪費不斷增加，對人員溝通協作能力、對需求的拆解能力、方案的細化能力等要求也在不斷增加。為了應對這一挑戰，我們可以將需求的生命周期分為需求評審、技術方案、開發、聯調、測試、發布、運營等過程。這些過程中有四大關鍵點貫穿始終：1.理解，指團隊對需求、技術棧等有一致的認知和操作；2.分工，指對工作合理細致的拆解；3
323、.交流，指研發過程中團隊內部和部門之間的順暢有效的溝通交流；4.落地，指上述措施切實有力的落地執行接下來我們從實踐出發，來看如何提升這四大要點的效率。理解以一個業務痛點為例，研發人員經常抱怨工具太多，頻繁切換帶來很大心智負擔。我們的優化策略是在 DevOps 選型時盡可能選擇可以閉環整個研發工作流的平臺，來提升研發效率。平臺的工具鏈有著聯動和組合效應，CI、CD、聯調、自動化測試、CO 等工具都統一到云原生 DevOps 平臺上。云原生 DevOps 的架構，底層基于騰訊云上一站式 DevOps 平臺，上層有開發域、構建域、測試域、部署域、運營域，完善了業務的 DevOps 流程，從而提升研發
324、效能和資源效能。161騰訊云技術實踐精選集 2022第二個痛點是缺乏研發全流程的標準化。我們在 CI 環節有標準化過程，但在測試、部署和運營過程中缺失標準。在服務數量較多時，這種情況非常不利于跨團隊協作。對此我們通過研效平臺做了研發全流程約束。比如新建一個服務，錄入服務基本信息，就可以通過平臺對整個自動化測試、資源、部署、編排、監控、日志都進行標準初始化。第三個痛點是黑盒問題，就是配置不透明，且分散在各個角落。比如說構建和編譯過程在 CI 平臺上，而部署的配置是在發布系統上，監控告警是在可觀測系統上配置，等等。這里我們是使用了“XAC+同源”的理念，以一個微服務的代碼為中心，通過 Makefi
325、le 或 Dockerfile 描述其 DI、編譯構建等過程。CI 則呈現成.ci.yml 放入庫中，CD 配置放在.cd.yml，等等。這樣開發人員都可以通過代碼來看清整個 DevOps 過程?？傮w而言，我們通過統一化、標準化、透明化機制來降低了團隊的理解成本，讓研發人員和產品人員能夠更好地對齊對需求的理解。分工我們希望需求盡可能細致，方便小步快跑、快速迭代試錯。如何拆分需求？我們的做法首先是根據領域來劃分，其次是根據業務流程拆解。接下來是根據緊急程度、實現難度、所屬客戶端和平臺、用戶價值、用戶角色、團隊當前情況等因素來拆分。拆分過程需要架構師或者主管對業務和商業模式有深入理解，才能和產品人
326、員很好地溝通和交流。162騰訊云技術實踐精選集 2022第二個方法是領域驅動設計。有些需求可能非常大且復雜，很難拆解。領域驅動設計可以分層抽象、降低需求的耦合度、復雜度。以某政務系統為例，首先由業務人員對整體業務架構進行歸納和總結，生成業務架構圖。接下來將業務架構轉變成系統架構，最后切分成代碼實現。這樣的架構能夠讓每一位研發人員清晰認知自己在系統中處于哪個模塊，以及模塊之間的聯動方式。領域拆分的代碼實現方面，我們針對小型需求有一個小型的代碼目錄，沒有非常復雜的代碼設計。對于比較大型或者復雜的業務流程，我們有一個詳細的 DDD 代碼目錄結構設計，這樣可以讓團隊有規范可循，不論是簡單架構還是復雜架
327、構都可以參考設計?？傮w來看，我們主要采用需求拆解和領域驅動這兩個方式提高需求拆分、工作拆分的細致程度。交流分工協作是研發流程中非常容易產生浪費的環節。為了幫助大家順暢和有效地溝通，我們主要有以下幾個實踐。主干開發，直接通過代碼方式幫助研發人員對齊需求。我們主要圍繞 Master 分支進行版本迭代，個人則通過特性分支持續開發，然后回到主干上。CR 過程也盡可能左移，避免很大的 CR。通過小規模的提交、主干開發和 CR 左移的實踐，可以幫助我們把控代碼質量，對齊對需求的理解。自動化測試也是不可或缺的，測試代碼本身也需要 CR。如果有一些對不齊的問題，就通過當面交流或者會議及時對齊。163騰訊云技術
328、實踐精選集 2022 APIOps，也就是通過 API 驅動后端和前端的代碼設計和開發協作。APIOps 平臺可以沉淀代碼或接口協議的規范，并具備 Mock、抓包等能力，方便前后端聯調和驗證。這是前后端溝通過程中必不可少的工具。測試左移可以降低開發和測試人員的溝通成本。我們通過測試代碼對齊測試和開發人員對功能的理解，并將 UT 和 IT 沉淀在代碼庫中。開發和測試人員可以通過代碼協作對齊測試過程，提交代碼后可以輸出自動化測試報告，及時反饋給開發人員。GitOps 理念能夠降低開發人員與工具的人機交互成本。我們通過 GitOps 管理研發流程，沉淀信息，通過 Git 回溯開發過程的變更，對變更進
329、行 CICD 和自動化測試。開發人員提交代碼后，后續的過程都是自動的，并且整個過程產生的信息都是在 Git 上沉淀的?？窗骞芾眄椖窟M展和風險。我們將每個需求的研發過程、進度、風險都在敏捷看板上同步，這樣可以幫助我們和項目側更好地對齊進度和風險。落地最后，如何切實有效地保障這些實踐的落地？我們第一個理念是度量，要對整個研發過程有較好的度量指標。管理者可以通過度量指標掌握團隊的單元測試情況、CI 延時等信息。我們盡量選取比較客觀、明確、公正，不易作弊的指標，數量不宜過多。如果盲目選取指標，會對團隊造成較大傷害。164騰訊云技術實踐精選集 2022第二個實踐是 ChatOps。以告警流程為例，告警出
330、來后會自動對服務拉一個群，在小群里同步告警的詳細情況，在大群中公示每個告警的處理和解決的過程，在組長群度量每個組對告警的響應率、響應時間和解決情況，并且通過單據沉淀。其他領域也可以通過 ChatOps 方式推進研效工作落地。在企微群或發這些消息可以更方便團隊接收，也起到了公示作用?？偨Y總結來看，我們在理解層面有幾種方式降低理解成本，在分工層面通過需求拆解、領域驅動設計進行科學分工，在交流層面通過幾個實踐降低交流成本，在落地層面通過度量和 ChatOps 幫助我們更好地落地。當然，研效提升的方法并不唯一，我們也會加強交流和探索，尋找更多有效的手段提升我們的研發效率。掃碼獲取完整版演講 PPT16
331、5騰訊云技術實踐精選集 2022中間件與基礎設施04166騰訊云技術實踐精選集 2022Kafka Stream 的進化探索：流式 Serverless 計算許文強騰訊高級工程師騰訊高級工程師，Apache Kafka Contributor。擁有多年分布式系統研發經驗，主要負責騰訊云 Kafka 和 Datahub 的研發 和管理工作。專注于消息隊列及其周邊技術生態在公有云場景下的技術建設、分析、優化。隨著 Kappa 架構流批一體在大數據領域興起，萬物互聯引發數據源爆發，基于數據流的實時處理計算成為趨勢，傳統的分布式數據計算引擎如 Spark、Flink 也面臨著數據量級和業務復雜度的雙重
332、考驗。業界的流批一體，也逐漸轉變為統一到流。近年來，新的流計算形態不斷涌現。在 Apache Kafka 的生態中，通常是通過原生的 Connector 來實現集群間的容災、同步以及簡單的數據轉換處理能力。如果需要實現流式計算處理，則需借助 Flink、Spark 或者原生的 Kafka Stream 來編程實現。這在實際的使用運營過程中面臨學習成本、運維投入、擴縮容等問題。新興起的無服務器架構具有事件觸發，多語言編程，彈性擴縮容，函數態運行等能力，為消息在容災、同步、轉換處理、流式計算等場景提供了一種新的技術選擇。在 DIVE 2022 北京站上，騰訊高級工程師許文強帶來了主題為Kafka
333、Stream 的進化探索：流式 Serverless 計算 的演講，主要分享基于 Serverless 架構的消息的處理、流轉的探索和實踐經驗。167騰訊云技術實踐精選集 2022Kafka Stream 的機遇和挑戰在大數據架構中，Kafka 是一個消息隊列，扮演緩沖層的角色，起到削峰平谷緩沖的作用。Kafka 上下游分為數據接入和流出兩部分，Kafka Stream 就是數據流出部分的技術方案之一。Kafka Stream 的主流方案分為計算、集成、處理和容災四類，每一類都有一些主流方案和適用場景。Kafka 自帶的流計算庫 Kafka Stream 是社區推出一個庫，功能和 Spark/Flink 類似，架構分為消費、處理、寫入三部分。它的優點是部署、管理比較簡單，和 Kafka 強綁定，但功能不夠強大，應用不多?？偨Y來看，當前方案面臨的痛點主要包括使用成本和擴縮容能力兩方面。使用成
0731-84720580
sgpjbg002
工作日 9:30 - 18:00
研報
新質生產力
DeepSeek?
低空經濟
大模型
AI Agent
AI Infra
具身智能
自動駕駛
寵物
銀發經濟
人形機器人
企業出海
算力
微短劇
薪酬
白皮書
創新藥
人工智能
AI產業
信息科技
互聯網
消費經濟
汽車交通
電商零售
傳媒娛樂
醫藥健康
投資金融
能源環境
地產建筑
傳統產業
英文報告
其它
最新報告
中英對照
全文搜索
報告精選
PDF上傳翻譯
多格式文檔互轉
入駐&報告售賣
會員權益
機構報告
券商研報
財報庫
專題合集
英文報告
數據圖表
會議報告
其他資源
行業聚焦
芯片產業
熱點概念
全球咨詢智庫
人工智能
500強
新質生產力
會議峰會
新能源汽車
企業年報
互聯網
公司研究
行業綜觀
消費教育
科技通信
醫藥健康
人力資源
投資金融
汽車產業
物流地產
電子商務
傳統產業
傳媒營銷
其它
2025低空經濟/低空產業報告合集（共49套打包）
2025年智算中心/AIDC/AI數據中心研究報告合集（共37套打包）
AI、科技與通信
廣告、傳媒與營銷
消費、零售與支付
HR、文化與旅游
金融、保險與投資
能源、環境與工業
醫療制藥與大健康
物流、地產與建筑
其他行業
AI ? 科技 ? 通信
數字化
金融財經
智能制造
電商傳媒
地產建筑
醫療醫學
能源化工
其他行業
收藏
下載
2025-05-20
AI查數
行業數據
政策法規
商業模式
產業鏈
競爭格局
市場規模
產業概述
其它
2025年
AI讀財報
年報
一季報
半年報
三季報
IPO招股書
社會責任報告
A股
IPO申報
港股
美股&全球
新三板
掃碼登錄
手機快捷登錄
賬號登錄
