《騰訊云：騰訊云技術實踐精選集2021（204頁）.pdf》由會員分享，可在線閱讀，更多相關《騰訊云：騰訊云技術實踐精選集2021（204頁）.pdf（204頁珍藏版）》請在三個皮匠報告上搜索。

1、1騰訊云技術實踐精選集2騰訊云技術實踐精選集卷首語近年來，云計算、5G、人工智能、大數據等新一代信息技術發展勢頭迅猛，加速了各行各業的數字化轉型，數字經濟儼然成了產業發展的新風口。身處技術革新的浪潮下的企業，更應順勢而為，抓住時代機遇。一直以來，騰訊云堅持以卓越的科技能力打造豐富的行業解決方案，構建開放共贏的云端生態，推動產業互聯網建設，助力各行各業實現數字化升級以及產業的降本增效。與此同時，騰訊云不僅在技術領域不斷創新突破，取得了沉甸甸的收獲，還將積累的成功經驗向外部技術同仁賦能輸出?；赝?2021，來自騰訊云的技術專家分別在 QCon 全球軟件開發大會、ArchSummit 全球架構師峰會

2、、GMTC 全球大前端技術大會中，圍繞“云原生技術應用”“數據庫與存儲技術”“前端業務架構”以及“架構設計”四個方面，分享了獨到的技術見解與成功經驗。騰訊云技術實踐精選集 2021第一期將二十余位騰訊云講師的演講內容進行了收錄，以期幫助更多中國互聯網行業的同仁們學習騰訊云在技術演進、能力落地以及行業探索等方面的經驗。展望 2022，騰訊云將持續輸出更多的技術能力、沉淀更優質的技術內容，也期待與更多業界同仁一道推動產業升級，促進業務創新。3騰訊云技術實踐精選集推薦序數據庫行業迄今已有數十載，而歷久彌新。隨著互聯網行業及云計算、5G、人工智能等技術發展，多種類型的數據呈爆發式增長，各種創新業務場景

3、層出不窮，沖擊著這塊古老而全新的軟件領域，也促進了技術和產品架構的創新，使得中國數據庫市場進入了百花齊放的階段。從我的從業經歷來看，越來越復雜的業務場景對數據容量、并發量、實時性、數據分析、安全性、容錯性、可信賴等方面提出了更高的要求。硬件發展和軟硬件一體化優化技術，給數據庫設計者和開發者提供了更多解決問題的思路。騰訊云數據庫構建了企業級分布式事務能力、云原生能力、超融合能力以及全球部署能力，在提供強大存儲和計算能力的同時，簡化了業務開發模型，在金融、游戲、物聯網等眾多關鍵領域中，都取得了亮眼的成績。本冊電子書收錄了與數據庫相關文章，結合了騰訊云數據庫的實踐經驗，向外界傳遞我們的前沿探索/技術

4、實踐，讓更多業界同行從中獲得有價值的見解。騰訊云副總裁 林曉斌“生于云，長于云”，短短幾年時間，云原生技術便從出現走向成熟，在企業的數字化轉型中發揮著重要作用。與此同時，云原生技術所涵蓋的范圍也越來越廣，從容器、微服務、DevOps 到 Serverless、大數據、AI，只要符合云原生理念的，我們都可以稱為云原生技術。那么這些云原生技術演進背后的邏輯是什么？究竟能夠給企業帶來什么價值呢？我認為用“降本增效”四個字可以涵蓋。本冊電子書的“云原生技術應用”部分將主要介紹如何利用云原生技術幫助企業實現“降本增效”。騰訊云容器產品中心總經理 鄒輝4騰訊云技術實踐精選集目錄云原生技術應用數據庫與存儲技

5、術PART 01PART 02Service Mesh 在游戲行業大規模落地實踐解決萬千節點可觀測性數據壓力騰訊內部實踐正本清源，你真的了解 Serverless 嗎？百萬級大規模容器平臺的設計與實踐騰訊云 Serverless 在音視頻處理的探索與實踐騰訊 Kubernetes 大規模離在線混部與內核隔離實踐騰訊百萬級容器規模的云原生平臺設計與實踐1000+企業云原生改造成本優化總結破解 Kubernetes 應用開發低效之困:一鍵調試，實時熱加載騰訊大規模云原生平臺穩定性實踐Kubernetes 環境下極致開發體驗-實時熱加載和一鍵調試云原生 Serverless 數據庫的設計與實踐企業級

6、分布式數據庫 TDSQL 元數據管控與集群調度TDSQL-C PostgreSQL 在云原生架構下的新活力“緩存+存儲”架構下 Redis 持久化的探索與實踐云原生數據庫的“能與不能”騰訊云存儲數據湖三層加速1.2.3.4.5.6.7.8.9.1.2.3.4.5.6.071723303843526370779098106122128133138CONTENTS10.11.5騰訊云技術實踐精選集前端業務架構架構設計PART 03PART 04TRTC Web SDK 新架構設計解析云剪輯實時渲染引擎設計音視頻跨平臺應用與元宇宙未來暢想Serverless 時代的低代碼實踐十億級 Node.js

7、網關的架構設計與工程實踐云原生微服務治理架構深度解讀和實踐騰訊云億級 QPS 彈性負載均衡系統演進1.2.3.4.1.2.3.1461551641701791891976騰訊云技術實踐精選集云原生技術應用PART 017騰訊云技術實踐精選集近幾年，云原生工具和技術應用持續增長，容器的使用和編排愈加流行，Serverless（無服務器）、Service Mesh（服務網格）等技術興起。在大規模服務網格性能提升的需求面前，其過程中的探索價值凸顯。在游戲行業的上云過程中，騰訊積累了深厚的經驗，也探索出了自己的路。在 2021 年 Qcon 全球軟件開發大會【北京站】中，騰訊云高級工程師鐘華帶來了主題

8、為Service Mesh 在游戲行業大規模落地實踐的演講，分享了騰訊云在這一領域的成功案例與最佳實踐。Service Mesh 在游戲行業大規模落地實踐鐘華 騰訊云高級工程師Istio contributor，Dapr contributor,Tencent Cloud Mesh 技術負責人。專注于容器和服務網格，騰訊服務網格 Oteam PMC，在容器化和服務網格生產落地和性能調優方面具有豐富經驗。發展趨勢與挑戰據 CNCF 發布的 2020 年服務網格發展趨勢報告顯示，在 1300 多家 IT 企業中，生產環境里使用 Mesh 技術的比例為 27%，較上一年（2019 年）提升了 50%

9、，預計未來還會持續增長；而所有的 Mesh 技術棧中，Istio 的使用比率最高。8騰訊云技術實踐精選集數據面的統計數據中，2020 年在生產環境中使用了 sevice porxy 的比例大概是 37%，其中前兩名是 Nginx 和 Envoy，分別是 62%和 37%，值得關注的是，Envoy 的增長率達到了 116%：為了獲得更強的七層流量管控能力，一部分用戶會從老牌的 proxy 遷移到 Envoy，比如 Nginx 和 HAProxy。這份報告中體現了兩個主要的信息：一，服務網格生產落地持續增長；二，在技術選型方面，Istio 和 Envoy 還是主流的選擇。但這份報告沒有體現規?；w

10、驗方面的內容，比如，使用這些 Mesh 的用戶規模如何？實際上，在我們接觸的 Istio 用戶中，中小規模占了很大比重，這并不表明 Istio 大規模落地沒有需求，而是其需求更復雜、要求更嚴苛。我們在大規模落地過程中遇到的問題，包括性能開銷、場景限制、復雜度。其中最難的是性能開銷，在給騰訊大規模的游戲客戶做服務網格支持的時候，體會更深。大規模服務網格性能優化游戲服務本質上是互聯網的產物或者互聯網的組成部分，所以它有互聯網服務的一些共性。比如，它們都是分布式環境，要求高可用，強調分離基礎能力，有很多微服務等等。同時也有行業自身的特點，比如會產生更多有狀態的服務。由于游戲體驗強調實時性和強交互，所

11、以對延遲更敏感，穩定性要求更高。比如，Web 程序通常是讀多寫少，CPU 通常還好，但 IO 很密集；而游戲的讀寫都很頻繁，CPU 和 IO 都非常密集。此外，游戲中的大量差異化玩法，在微服務方面則體現為更多的版本。1.利用 BPF 技術優化數據面轉發鏈路優化為了提高性能，我們做的第一個優化是利用 BPF 技術優化數據面轉發鏈路優化。首先，相比于服務直接通信，Istio 數據面的通信模型在引入 Sidecar 模型后，通信路徑明顯增加，具體來說，每個被劫持的報文會多經過 2 次協議棧，多 2 次數據拷貝。根據測試，這個架構在內核態的開銷，大概占總開銷的 30%左右。9騰訊云技術實踐精選集BPF

12、 的全稱是伯克利包過濾器，它在內核中已經存在很多年，是一個高效的虛擬機，它能以安全的方式在很多 hook 點執行我們提供的字節碼。這里的核心工作是在 Socket ops 掛載我們的 eBPF 程序，攔截應用程序和 Envoy 之間的流量，直接發給對端的 Socket，這樣就跳過了后續的內核協議棧處理。業界對這個問題的一些探索：業務進程和 proxy 之間使用 UDS 通信，數據包不會經過協議棧。但是 UDS 的缺點是對代碼有入侵，需要用戶顯示面向 UDS 編程，這種做法常見于一些私有的 Mesh 方案，不適合公有云的場景。我們的方案是利用 BPF 來跳過協議棧的處理。10騰訊云技術實踐精選集

13、在具體流程中，我們要關注連接創建和數據發送。當監聽到連接創建事件后，程序把兩端的 Socket 信息存到 Socket hash 中，這是一個高效的 KV 存儲，Key 包括源和目的的四元組，Value 是 Socket 對象。當監聽到消息發送的事件時，可以從當前的 Socket 信息中，分析出目的端的緩存 Key，利用這個緩存 Key，再去 Socket hash 取到對端的 Socket 對象。這樣就實現了源和目的兩端都跳過了后續協議棧的目的。這樣操作的優化效果也比較明顯：吞吐量提升了約 7.4%，延遲 p90 降低 15.6%，延遲 p99 降低 27%，基本符合我們的優化預期。2.xD

14、S Lazy Loading第二個主要是優化 Istiod 設計的缺陷 xDS 全量下發，帶來的性能瓶頸。目前，Istiod 下發 xDS 的機制是全量下發，以左圖為例，Workload1 雖然只依賴 Service2，但它的內存里會始終加載 Service2、Service3、Service4，因為 Istiod 會把所有數據都發給 Workload1。這會導致 Workload1 中的內存急劇膨脹，同時還要花大量的 CPU 去解析這些 xDS。另外，HPA 也會受到影響，Kubernetes HPA 通常是 Pod 維度，如果 Sidecar 里內存已經很高了，業務容器的內存可能就無足輕重

15、了，HPA 基本就失效了，這會導致系統穩定性比較差。當 Mesh 的規模增長以后，內存開銷上升地非常明顯。11騰訊云技術實踐精選集具體流程是，一開始限制所有服務的可見性，Workload1 不加載任何服務，有任何請求都會攔截到 Lazy Egress（類似網絡里的默認網關）去，Lazy xDS Egress 會分析流量的特征，然后把流量轉發到下一跳中，緊接著在 Egress 會把這次訪問關系，以 Access Log Service 形式上報到 Lazy-xDS-Controller 中，由 Controller 分析服務依賴關系，并將其以 CRD 的形式寫到 Mesh。Istiod 更新了這

16、些服務依賴以后，后續就會把 Service 2 的信息下發給 Workload 1，后續 Workload 1 再次訪問 Service 2 就是直連的。對此，我們也做了對比測試：在一個 Kubernetes 運行兩個 BookInfo，左邊開啟 xDS 懶加載，右邊不開啟，頻繁下發一些它不需要訪問的服務。最終的優化結果是 900 Pods 規模 Mesh，單個 Envoy 減少 14M 內存；10 萬 Pods 規模 Mesh，單個 Envoy 內存降低約 1.5G，優化效果比較明顯。以上兩個重要的優化，能夠幫助我們支撐一些比較大規模的服務網格場景落地。面對這種情況，社區中有一個解決方案：用

17、 Istio Sidecar 這個 CRD 來做優化，在 CRD 里可以去配置服務的可見性或者服務依賴。但在大規模場景下，由于服務依賴關系頻繁變化，很難梳理清楚，因此 Istio Sidecar 在大規模場景下比較難落地。我們的方案是實現 xDS 的動態懶加載，在網格里增加兩個組件：一個是 Lazy-xDS-Egress，另外一個是 Lazy-xDS-Controller。12騰訊云技術實踐精選集騰訊云服務網格在游戲行業生產實踐TCM 是基于目前主流的 Mesh 技術棧：Istio 加 Envoy，所以 TCM 是完全兼容開源 Istio API。TCM 提供對 Mesh 全生命周期的管理，包

18、括 2 種部署模式，獨立部署版和全托管版本，其中全托管版本中的 Istio 相關控制面組件全部由云平臺來管控，對用戶不可見，極大地降低了用戶的運維成本。另外還有很多擴展能力，包括全托管遙測系統、深度的性能優化、協議擴展能力等等。典型落地案例歡樂游戲是騰訊老牌的游戲，主要的游戲品類已經運營了很多年，其核心的技術架構已經比較穩定，但在業務上云的大背景下，大家認為擁抱云原生技術，能提高大家的研發效率，降低運維成本并提升資源利用率。另外系統引入 Service Mesh，主要是為了實現精細化的流量管控，并提升系統的可觀測性。這是目前歡樂游戲的整體架構，是公有云和 IDC 服務混合部署的架構。在上云之前

19、，歡樂游戲使用的是私有的 RPC 協議，上云后，云上使用的是 gRPC，云上和存量 IDC 服務間，通過自研的 Mesh Gate 做協議轉換。同時這還是一個多集群服務網格，使用了 TCM 多集群單控制面，每個具體的游戲獨占一個Kubernetes 集群，13騰訊云技術實踐精選集還有一個存放公共服務的集群，所有服務網格相關的控制面組件都由 TCM 托管。歡樂游戲絕大部分都是有狀態服務，大家知道 Kubernetes 有狀態服務通常用 Stateful Set 來管理，Stateful Set 的特點是可以給每個 Pod 分配唯一的網絡標識，能有序地部署和擴縮。但 Stateful Set 不是

20、很能滿足歡樂游戲的調度場景?？s容時，Stateful Set 會從最后一個開始縮，比如這里有 1 2 3 三個 Pod，有可能最后一個 Pod 還有賽事在進行，而第二個 Pod 的賽事已經結束了。所以現在縮容時，不能刪掉第三個，而是應該刪掉第二個。歡樂游戲自研了一個工作負載控制器 game server set，可以把它看作是加強版的 Stateful Set，或者更能理解棋牌業務的一個有狀態控制器?？刂破鲿鶕?Pod 里正在進行的游戲場次信息、當前容量等等業務數據，去實現擴縮容，而不僅僅是 CPU 和內存，這樣實現了更智能化，或者和業務場景聯動的有狀態 Pod 調度。定向流量調度是什么意思

21、呢？大家知道游戲通常都有匹配系統，比如每個 Pod 上開啟了不同的賽事，容量和資源也在實時地變化，簡單來說，匹配系統需要根據這些輸入信息，結合當前用戶請求的特征，把用戶請求路由到一個最合適的 Pod 里去。具體的匹配算法是游戲業務的核心邏輯，這里不展開。假設這個最優的目標 Pod 已經確定了，用戶流量是怎么精確地到這個 Pod 中，這就是定向流量調度需求。簡單來說，就是要把一個用戶的流量，精確地路由到一個指定的 Pod 去，這是原生 Kubernetes 不具備的，這正是使用了 Istio 強大的流控能力。最后，歡樂游戲還用到 TCM 的一個高級特性CRD 中心化托管。每個業務集群都有自己的

22、Game server 控制器，每個控制器都要讀寫 Istio 流控規則，也就是各種 CRD，VirtualService，DestinationRule 等，熟悉 Istio 多集群架構的同學可能知道，在多集群 Mesh 中，CRD 是存在于主集群上的，只有主集群才能讀寫 CRD。TCM 在這里做了擴展，TCM 不但托管了 Istiod 相關服務，還把 Istio 相關 CRD 對象也做了托管，也就是把 CRD 存儲也做了托管，這樣 Mesh 內任何一個成員集群，都可以直接讀寫這些 CRD 資源。第二個案例是游戲電競直播，這是一款海外直播平臺，主要給歐美市場提供海外游戲直播服務。核心的技術訴

23、求是：電競業務范圍包括歐洲和北美多個地區，各地區服務需要具備就近訪問和自動容災切換的能力。首先，團隊把開發語言切換到 Golang，RPC 切換到了 gRPC，這樣可以更好地和云原生技術接軌。對于跨國流量穿梭，Istio Mesh 本身有多集群互通的能力，TCM 在此基礎上提供了云上跨國際地域服務網格。14騰訊云技術實踐精選集企鵝電競在硅谷和歐洲等地部署業務集群，集群之間通過騰訊云云聯網打通，這些集群的服務發現數據會接入統一的 TCM 網格控制面。這是典型的單控制面多集群服務網格。硅谷或歐洲用戶的流量都會優先訪問本地域集群服務。當本地域服務出現異常，會觸發服務斷路器，并將流量自動降級到另外一個

24、就近地域。整個就近訪問、失效轉移都是自動化的，開發運維同學不需要過多的配置和介入。企鵝電競在整個系統中使用了大量的 Istio 流控策略，除了常見的灰度發布、流量鏡像以外，另一個高級的流控場景是對有狀態消息的定向路由。舉個例子，在直播場景里有一個消息聚合服務，邏輯上需要 300ms下發一次，從性能上考慮會把一個直播間的消息都收集在一起，確保同一個直播間的消息都發到一個實例上，由一個實例來處理會更高效。為實現帶狀態路由，我們需要把相同特征的請求路由到一組相同特征的 Pod 上。在使用服務網格技術之前，需要我們在業務 SDK 中實現。在使用 TCM 后，這就變得很簡單了，Istio mesh 對

25、gRPC 提供了一致性哈希負載均衡策略。比如，我們可以配置使用直播間 id 來做一致性哈希，通過使用這種方案，業務代碼層無需做任何變更，由網格層來接管并實現帶狀態的消息路由?？刂泼姘寤叶壬壟c負載平衡的最佳實踐對于大規模的 Mesh 落地，僅僅關注性能優化是不夠的，還要重點關注控制面板的健康程度，這里分享兩個最佳實踐：第一，控制面板灰度升級，Isito 目前三個月發一個版本，版本更新比較頻繁，而且經常有比較大的改動。所以大家總是覺得升級 Istio 是一個大工程，又容易出錯。其實我們經常利用 Istio 的能力，對數據面業務做灰度升級，這是一種發布的最佳實踐。對于 TCM mesh 的控制面，

26、它里面也是一些服務，所以灰度發布策略用于控制面也是很有價值的。所以在 TCM 上，我們對控制面灰度升級做了產品化支持，首先我們把新的控制面部署好，然后再對 namespace 逐個地注入新的 proxy，指向新的控制面，在這個過程中，可以隨時去驗證業務是否正常，異常情況可以隨時回滾，升級完，老的控制面還可以保留一段時間，以備回滾之需。使用 TCM 控制面灰度升級，極大地降低了升級過程中的風險。15騰訊云技術實踐精選集第二個控制面最佳實踐是確?？刂泼尕撦d平衡。先看看控制面負載不均問題：在 Istio Mesh 中，sidecar 和 Istiod 之間的 xDS 是一個 gRPC 長連接，當數據

27、面規模增長到一定程度，會觸發 HPA 策略，Istiod 副本會進行擴容，但因為 Kubernetes 默認的隨機負載均衡，老的 Istiod 還是會接到新 proxy 的連接。這會導致老的 Istiod 的連接和負載仍然會持續上升，進而影響其穩定性，在大規模的 Istio Mesh 中比較明顯。目前社區提供了一個姑息的方案：周期性地斷開 sever 和 client 之間的長連接，讓 client 重連實現負載平衡。斷連的周期由 Max Server Connection Age 參數控制。但這個方案比較雞肋，如果時間設長了，控制面需要較長的時間來實現負載平衡，在實現平衡之前，控制面可能已經

28、出現了負載不均異常。如果設短了，數據面和控制面之間會有太多的斷開和重連，會導致 xDS 數據流的低效，影響網格的穩定性。開源 Istio 難以解決以上問題的主要原因是，社區只能圍繞 Istio 來做解決方案，而在云上，可以聯合其它基礎設施做解決方案，會有更多的選擇。在騰訊云上，CLB 支持最小連接數算法，理論上可以滿足我們的需求。但在實現過程中，還要解決一些鏈路轉發問題。默認情況下，LB 綁定的后端 rs，是 Kubernetes service 在節點上的 node port，而當流量進入 node port，又會被 kube-proxy 的 iptables 攔截，所以最后結果又是隨機的。

29、在 TKE 上還有一個高級的能力，CLB 直通 Pod，這種模式會給 Kubernetes 里的 Pod 增加彈性網卡，然16騰訊云技術實踐精選集后 CLB 的后端直接指向 Pod 彈性網卡，就跳過了中間的 node port 和 kube-porxy。通過一個簡單的例子就能夠說明優化的效果：先啟動 2 個 Istiod，數據面有 60 個 Pod，大概每個 Istiod 有 30 個 xDS 連接，中途再啟動一個 Istiod，模擬 HPA 擴容的效果，同時把數據面擴容到 90，也就是增加 30 個數據面 Envoy?？梢钥吹?，在沒有優化的情況下，新的 Istiod 接收到的連接大概是 10

30、 個，也就是新連接數的三分之一；優化以后，新的 Istiod 接收到了 26 個連接，用標準差來衡量負載均衡的效果，可以看到默認情況下的值是 18，優化后的值是 4，優化效果非常明顯。17騰訊云技術實踐精選集兵法有云：“知己知彼，百戰不殆”。在企業 IT 系統運維層面，“知己知彼”用技術術語來講就是系統要具備充分的可觀測性，良好的可觀測性能夠讓企業及時診斷故障、發現根因，有效降低運維成本、提升系統運行效率。Apache Pulsar 消息流平臺，是云原生時代可觀測性領域備受矚目的一項創新技術，解決了海量數據聚合層面的很多問題和挑戰。如何在企業內部集成并有效運用 Pulsar 平臺是很多技術團隊

31、關注的一大主題。在 2021 年 Qcon 全球軟件開發大會【北京站】中，來自騰訊云微服務團隊的趙善從發表了主題為解決萬千節點可觀測性數據壓力騰訊內部實踐的演講，分享了騰訊解決萬千節點可觀測性數據壓力的實踐經驗。解決萬千節點可觀測性數據壓力的騰訊內部實踐趙善從 騰訊云高級架構師曾歷任 IBM 研發 Leader，AIOps 產品負責人，先后為國內外眾多金融客戶提供產品側技術支持和解決方案。在云原生、大數據領域均有豐富的研發和落地經驗。18騰訊云技術實踐精選集云原生概述在騰訊看來，云原生本質上是一種行為方式和設計理念，凡能夠提高云上資源利用率和應用交付效率的行為或方式都是云原生的。云原生的目標包

32、括控制成本、增加彈性、提升開發與部署速度、縮短迭代周期等。云原生的幾大代表性模塊包括：微服務：高內聚，低耦合，便于擴展；服務網格：控制應用的不同部分之間共享數據的方式；容器：應用實例容器化，跨平臺屏蔽開發和底層差異，實現彈性擴縮容以節省成本；聲明式 API：關注應用自身，而非系統執行細節。如 K8s 提供了服務編排能力；不可變基礎設施：對于底層設施采用版本控制和可溯源的變更，避免產生沖突和事故。云原生應用的實現形式多種多樣，并沒有嚴格的規范和路徑約束，在云原生領域也存在很多認知誤區：第一個誤區是云原生的使用誤區，一些企業只是對應用做容器化改造，打包成鏡像托管到 K8s 上；或者只是頻繁 CI，

33、頻繁使用 Jenkins，做很多 Pipeline，但不敢把應用發布到生產環境，不敢在生產環境中快速迭代，這樣的系統很難稱之為云原生系統。第二個誤區是認為分布式、微服務可以解決一切問題。美國火星氣候探測者號的失敗就是個很好的例子。該案例失敗的根因是地面與飛船的傳感器分別使用了英制與公制單位，導致同步失敗，沒有對接成功。從微服務視角來看，這是兩個微服務通信出現了問題，但追根溯源是微服務交互層面的設計出現了問題。微服務場景中，上下界切分與交互 API 是重要環節，也是保障微服務健壯性的關鍵。另一方面，探測器這樣的場景屬于典型的分布式系統，這個案例說明分布式并非解決問題的靈丹妙藥，其本身有時會成為最

34、大的問題根源。那么，要如何處理好這樣的生產問題？這里涉及到事件的可觀測性。所謂可觀測性，就是圍繞著數據的生成、收集、捕獲以及過濾的過程，對數據流進行處理來繪制數據流向，將復雜場景簡單化，將問題抽象化，通過大數據處理等方式尋找根因的一整套體系。19騰訊云技術實踐精選集可觀測性的現狀與展望可觀測性最早起源于電氣工程領域。隨著系統復雜度提升，工程師需要一套機制來監控系統內部運行狀態，通過一些方法和手段輔助解決問題。例如汽車生產廠商會在車身內安裝各類傳感器，來監控采集汽車的運行狀態信息，以便發現和定位問題。在 IT 領域的云原生轉型過程中，用戶將業務上云后，需要一整套基于新架構的配套設施來助力企業轉型

35、。新的架構效率要求更高、系統更加復雜、環境更加動態化、上下游依賴更多，這些因素都對可觀測性提出了更大的挑戰，針對每一項挑戰也誕生了對應的解法：應用數量龐大、接口繁多、數據體量巨大：這一現狀給后端帶來了海量數據的上報+計算+存儲困境，在 UI 層面則出現了頁面信息不夠直觀，影響排障效率的困境。針對這兩項困境，騰訊在后端引入大數據計算+存儲+ETL 解決數據壓力，在前端則提供豐富的篩選+排序工具，展現數據的立體視圖，提供定制化的頁面信息。應用關系復雜：由于應用層級眾多、節點較多，應用關系邏輯圖也很容易變得混亂無序。對此，騰訊的解法是錨定應用、定向過濾，定時高亮某個節點，或根據業務復雜度情況選擇數據

36、流向圖、力導圖來展現信息。數據高效準確的需求與低成本的矛盾：需求越多，成本一定越高。海量數據和高效準確，精準實時計算和低成本之間都是一對矛盾點。為此，騰訊做了很多嘗試，通過大數據后端計算和存儲架構、通用計算平臺來提升平臺的整體利用率。20騰訊云技術實踐精選集在可觀測性架構落地實踐中，可以在容器與中間件之間，部署一些埋點或無侵入式配置來生成下半部分的鏈路圖。鏈路圖從左至右，從上至下描述了當前的可觀測情況，包括各個節點、鏈路、到達的中間件、時延等觀測數據?？捎^測性架構也會收集一些基礎資源的監控指標和日志。監控指標、調用鏈和日志共同形成了可觀測性的三駕馬車，三者良好結合就能輸出很好的可觀測性結果。當

37、前的可觀測性架構也存在一些問題，如涉及的系統較多，運維成本較高；監控、日志和調用鏈并未打通，需要自行接通；相關工具容易被云廠商綁定等等。面對這樣的混亂局面，行業也在向標準化、統一化的方向演進。騰訊正在設法更進一步，在不同協議之間做好適配工作，協調 OpenTracing 和 OpenSensors之間的不同點、三駕馬車之間的不同點，最終形成可觀測性領域的大一統框架。OpenTelemetry 是未來可觀測性所遵循的統一框架。OpenTelemetry 統一了可觀測性涉及的協議與采集端 Agent，同時支持云原生，提供良好的向下兼容能力：騰訊正在設法更進一步，在不同協議之間做好適配工作，協調 O

38、penTracing 和 OpenSensors之間的不同點、三駕馬車之間的不同點，最終形成可觀測性領域的大一統框架。OpenTelemetry 是未來可觀測性所遵循的統一框架。OpenTelemetry 統一了可觀測性涉及的協議與采集端 Agent，同時支持云原生，提供良好的向下兼容能力：統一協議：將調用鏈、日志、監控三者在源數據層面拉通，相當于采集到的數據是同樣的對象，存儲單元大致相同，從而方便互相傳遞和使用。統一 Agent：在采集層面拉通，所有語言遵循相同協議，各類數據按照同樣的采集方式上報。云原生友好：支持容器與 Serverless，具備優秀的擴展性。兼容性：向下兼容谷歌、微軟等國

39、內外廠商的各類標準、協議。目前 OpenTelemetry 也存在一些不足。首先是與各個廠商的溝通協調存在很大門檻；其次，由于后端架構種類繁多，如何協調統一的采集端也是一大挑戰。接下來，三駕馬車的數據如何有效關聯和整合，產生聯動效果同樣是一個問題。OpenTelemetry 面對的最大挑戰是海量觀測數據與豐富的展現形式，給后臺的存儲和展現帶來了沉重壓力。為處理海量數據投入的資源成本也不可忽視，監控成本必須控制在合理水平，避免影響核心業務投入。21騰訊云技術實踐精選集Pulsar x 可觀測性云原生可觀測性的降本增效針對上述問題，騰訊決定引入消息中間件 Pulsar，它具備很多競品 Kafka

40、不支持的能力，例如計算存儲分離設計、方便進行底層擴展等等。其中 Pulsar Function 提供了 ETL、數據實時聚合、分析、過濾和 Enhancement 等能力。通過騰訊的云原生可觀測性實踐，用戶可以節省自建可觀測性平臺的成本，云廠商可以減少使用過多組件的成本，而 Pulsar 能夠對云原生資源進行深度分解，實現高彈性伸縮，做更好的系列分析。在上述架構中，采集端 Agent 采集到監控數據后進行初步壓縮，走 APM Gateway 做協議轉換，拿到Span、Trance、Reference，通過 Pulsar Function 做 Splitter 或聚合操作，再到下一層的 Inde

41、x 做入庫處理，或用 Flink 做更高維度、更復雜的大數據場景，最終放到時序數據庫里就可以在前端直接展示。其中，Pulsar Function 具備一些區別于 Kafka 的能力。例如前者支持流式計算、無狀態；開發人員可以自己編寫代碼擴展 Pulsar 的能力，例如做簡單的數據驅蟲或過濾時，直接在 Pulsar 上延伸就可以實現。在云原生支持方面，Pulsar Function 使 Broker 可以基于容器做橫向擴展，提供很好的彈性能力。22騰訊云技術實踐精選集總結而言，騰訊在可觀測性領域希望達到“突破最后一公里”的效果，實現以下幾大目標：更簡單的追蹤埋點，降低監控接入成本；更輕量的大數據

42、支持，降低大數據分析成本；更友好的用戶界面，降低用戶使用成本；追求應用可靠、穩定，實現性能與成本的平衡。23騰訊云技術實踐精選集最近兩年，業內關于 Serverless 的討論主要圍繞云廠商平臺能夠提供哪些能力，如擴縮容的效率、冷啟動的時間、支持的語言運行時等，較少從應用角度思考，如何將傳統的單體應用改造成 Serverless 架構？微服務是否是單體到 Serverless 的必經之路？對于這些問題并沒有一個明確的答案，那我們究竟應該怎樣去設計 Serverless 應用？在 2021 年QCon全球軟件開發大會【北京站】中，來自騰訊云Serverless部門專家架構師楊政權帶來了主題為正本

43、清源，你真的了解 Serverless 嗎？的演講。正本清源，你真的了解 Serverless 嗎？楊政權騰訊云 Serverless 部門專家架構師曾任 ThoughtWorks 中國北美事業部技術總監，在過去的幾年中，楊政權先后為電信、金融、稅務、CPG、能源等行業客戶提供提供定制化的軟件開發和咨詢服務。先后承擔大型團隊的研發組長、技術總監和企業架構師角色，作為客戶主要的技術接口人，主導并參與客戶的技術戰略制定、技術戰略實施和企業架構治理的過程中。他主要關注于企業架構、遺留系統改造、云原生架構以及企業數字化轉型等方向。24騰訊云技術實踐精選集云彈性之下，Serverless 價值幾何？從物

44、理機、虛擬機到容器，隨著抽象級別的提升，底層細節的關注度在弱化，比如關注虛擬機不再需要關注硬件，關注容器不再需要關注操作系統的一些細節。類比到 Serverless，可以減少開發者對服務器細節的關注。如果開發者要寫一個 Serverless 應用，理論上只需要關注應用級別的一些屬性，比如應用語言、內存占用、平均超出時間等。我們在提 Serverless 的時候，經常會提到 FaaS 和 BaaS 兩個概念，FaaS 和傳統的方式相比，具有更高的抽象級別，而抽象級別的提升也將促進社會化分工，比如，很多企業開始把和自己核心競爭力無關的工作交給云廠商處理，如虛擬機的運維、安全等。另一個相關的概念 B

45、aaS（Backendasa Service），云上大量開箱即用的服務可以直接使用，對于大部分企業來說，并不需要維護一個龐大的視頻算法研發團隊，也不需要招聘專門的人去做 OCR 模型訓練等等，只需要調用現有的 API，直接復用現有的云上能力。Serverless 和傳統的 PaaS 平臺到底有什么區別？如果平臺能做到以下幾點，都可以叫 Serverless。第一，函數實例如 ScaleDowntoZero、容器等能否縮減到零，還是要一直運行；第二，能否快速啟動。不考慮應用級別，平臺級別的冷啟動時間是否可以縮減到 100-200 毫秒左右；第三，能否快速擴展 FastScale。如今，業界各家

46、FaaS 產品的擴容能力基線是每分鐘可以擴容 300 500 個函數實例；第四，能否快速回收。Serverless 作為平臺提供方，仍然需要掙錢，需要考慮資源利用率的問題，在盡量避免冷啟動的情況下，需要快速回收資源，降低成本，提升利潤率。25騰訊云技術實踐精選集目前，業界對于 Serverless 的認知還有一些誤區，大家會認為 Serverless 可能更適合一些邊緣場景，不太適合核心業務。我今天想分享一個樂凱撒披薩的案例，它是一家知名連鎖餐廳，在全國大概有一百四十多家門店，從 2018 年就開始使用騰訊云的 Serverless 產品，截止目前已經有 90%的業務跑在騰訊云的 Server

47、less 產品之上?？梢哉f，騰訊云的 Serverless 產品在和這家企業一起成長。對于一家企業而言，為什么要去采用 Serverless？除了本身 Serverless 按照用量計費能節約成本之外，我認為更大的價值在于能夠支撐業務增長。就樂凱撒披薩的業務模式而言，它需要不斷復制現有門店，跨地區、跨區域地開新店，基礎設施變更周期至少需要 2-3 周的時間。在使用了 Serverless 之后，企業可以只用一個簡單的命令，就能快速復制一套系統，支撐業務的飛速發展。從這個角度來說，Serverless 不僅可以降低開發周期、研發難度以及基礎設施成本，還可以提升業務的響應力，支撐業務的快速增長。還

48、有另外一個音視頻處理的例子，一家企業用了 Serverless 之后，可以做到 10 分鐘之內瞬間拉起 5000-6000 個實例去做視頻轉碼，把之前的一個小時轉碼時間縮短到 10 分鐘。從本質上講，雖然成本只降了 20%，但是對于企業，這意味著可以在 10 分鐘之內拿到所有的合成結果。從業務人員角度來看，這就是用戶體驗和產品競爭力的提升。事實上，基礎設施成本不僅僅是服務器消耗，也包括服務器的運維成本。據TheSateofServerless2020調查報告顯示，將近 75%的受訪企業已經采用了 Serverless 技術，關注的價值點依次是快速伸縮、研發效率和降低運維成本。26騰訊云技術實踐

49、精選集Serverless 應用在極致彈性方面有哪些設計方法？Serverless 應用極致彈性的設計方法是什么？領域驅動設計幾乎是業內默認的微服務設計方法。如果只把這樣的方法適配 Serverless，在戰略設計階段其實并沒有太大的差異，但是在戰術設計階段，首先會遇到限界上下文邊界沖突問題。限界上下文其實更多的是邏輯邊界，從業務的視角去拆分，在一個邊界內，可以提升整個團隊的溝通效率和彈性邊界，而彈性邊界是什么？當業務在增長，系統出現瓶頸的時候，模塊復制的單元并不是一一對應的關系，于是會出現彈性邊界和邏輯邊界阻抗不匹配問題：舉一個例子，音視頻處理的限界上下文，如視頻合成，它非常依賴專業知識，需

50、要團隊成員在音視頻方面有專業的技術積累，對類似音視頻編解碼中的采樣率、分辨率、H264、H265 等的術語有統一認知（Ubiquitous Language），溝通無障礙。而在不同場景下，限界上下文內，不同場景的內存消耗不一樣，實時性的要求也不一樣，例如對于基本的視頻拼接只需要 128M，但是 QPS（每秒查詢率）很高，處理時間也只需要 60 70 毫秒；對于單錄視頻和27騰訊云技術實踐精選集多錄視頻，處理時間比較長，對于 CPU 資源消耗也很多，而內存和 CPU 是綁定關系，需要通過提升內存來提升可分配的 CPU 資源。如果我們在進行 Serverless 應用設計的時候，不進行場景的細分會

51、導致成本過高、內存并發超限等問題。對于這兩種場景，如果我們合并為一個 FaaS，會導致高昂的運行成本，因為在云函數產品的計費方式中，內存規格對于最終成本的影響非常大：512M 需要 1 萬左右，如果內存規格是 2048M，成本將近增加了三到四倍。所以這也給了我們啟示：在討論彈性伸縮時，一定要在固定的成本下，考慮如何最大化彈性伸縮效率。企業的 IT 預算有限，決策者考慮的是如何實現投資產出的最大化。根據剛剛的例子可以看到，細粒度的 Serverless 應用設計可以降低企業的成本，那么，Serverless 的彈性設計邊界之內，應用是否被拆分得越細越好？應該怎么度量軟件的復雜度？JohnOust

52、erhout 提出了這樣一個公式，子模塊的復雜度 Cp 乘以該模塊對應的開發時間權重值 tp，累加后得到系統的整體復雜度 C。系統整體的復雜度并不簡單等于所有子模塊復雜度的累加，還要考慮開發維護該模塊所花費的時間在整體時間中的占比（對應權重值 tp）。這里隱含著一個修改擴散的問題，當完成一個功能的時候，修改時是否有連鎖反應？有多少個模塊需要被修改？每一個模塊的開發時間占比是多少？在微服務設計里面，有一個概念叫 DistributedMonolith（分布式單體），指物理上分離，邏輯上耦合，這種情況需要極力避免。在 Serverless 領域，早在 2019 年 Thoughtworks 技術雷

53、達已經提到了 LambdaPinball 的概念，這種過度的模塊拆分會增加系統模塊之間的耦合度，從而增加整體的軟件復雜度，可維護性會降低。目前業界有兩個比較流行的 Serverless 應用設計方法，第一個方法是面向對象設計，沿著領域驅動設計的思路，分解彈性需求。28騰訊云技術實踐精選集第二種方法叫函數式流派或者業務流程、業務流程圖驅動設計，通過強類型約束 API 的輸入輸出，以狀態剝離的方式，剝離業務邏輯中無狀態操作，作為純函數和有副作用的函數。這種設計方法最大的好處就是強類型約束，讓開發者不必在代碼里去做各種各樣的邊界檢查，僅通過類型就可以做質量控制；此外開發者拆分出的函數，可以更加平滑地

54、遷移到 FaaS 平臺。除此之外，這種設計流派還可以促進組織內部再分工。比如，讓新員工去負責較為簡單的純函數，讓資深或者有經驗的同學負責有狀態的函數。如何優化 Serverless 應用的冷啟動？除了方法設計之外，企業如何持續優化 Serverless 應用？Serverless 應用不會一直駐留，需要被事件觸發的時候才會啟動，這就涉及函數的冷啟動問題，不同語言的運行時和冷啟動時間是不一樣的，比如 Python、Go 的冷啟動時間比較快，相對來說 Java 會慢一些：如果企業業務對于冷啟動時間非常敏感，比如某些面向最終 C 端的產品，對于首屏加載時間非常敏感，那么就可以用類似預置并發的方式，來

55、降低冷啟動帶來的影響。在 Java 方向我們看到社區也在針對 GraalVM 進行持續探索，通過 Native Image 的形式用更小的內存、更快的冷啟動速度來運行 FaaS 類型的 Java 業務邏輯，大家可以保持持續關注。此外，冷啟動問題和應用設計也有很大的關系，在初始化階段，需要避免去運行過于復雜的業務邏輯，導致冷啟動時間過長，影響彈性擴容的效率。Serverless 走向何方？最后，楊政權談了談個人對于 Serverless 趨勢的一些展望：29騰訊云技術實踐精選集他認為，首先，Serverless+X 這種按量付費、托管的可擴展性應用的產品形態會誕生，比如中間件、數據庫等等。其次，

56、ServerlessasEngine，對于最終 SaaS 產品的使用者來說，并不需要關心業務運行在虛擬機、K8s 還是 Serverless 之上，但 SaaS 廠商可以把 Serverless 作為應用的執行引擎，讓企業無需維護底層的基礎設施，即可獲得 Serverless 的按量計費、彈性伸縮的價值，而這些價值會為 SaaS 產品帶來更高性價比、更好性能的優勢。此外，目前在 Serverless 社區開發者體驗方面，ServerlessDX（Developer Experience）還不是很成熟，還有很長的路要走，我們需要一個更成熟的的開發者工具，來提升 Serverless 開發者的效率

57、。30騰訊云技術實踐精選集云原生轉型是當今企業數字化浪潮中的熱點主題，容器平臺是業務向云端遷移過程中非常關鍵的基礎設施，但對于業務達到一定規模，現有 IT 系統比較復雜的企業而言，如何設計一套高性能、高可用性，且有著良好兼容性和穩定性的容器平臺是擺在 IT 團隊面前的一大挑戰。具體而言，容器平臺可能會面臨集群規模差異巨大、數量眾多，業務混合分布、類型眾多，Workload 規模巨大，業務需求復雜等諸多難題，需要從基礎架構開始打造一系列平臺能力來應對這些挑戰。騰訊在云原生轉型的道路上積累了比較豐富的經驗，內部開發了一套能夠滿足企業復雜需求的大規模容器平臺。在 2021 年 QCon 全球軟件開發

58、大會【北京站】中，騰訊云高級開發工程師嚴申就帶來了主題為百萬級大規模容器平臺的設計與實踐的演講，分享了騰訊云在這一領域的成果與見解。百萬級大規模容器平臺的設計與實踐嚴申 騰訊云高級開發工程師負責騰訊內部業務自研上云平臺的開發設計工作，超大規模集群的調度優化、監控、自愈系統、網絡等能力；內部業務（騰訊會議、QQ 等）上容器的業務改造、穩定性優化等技術支持。31騰訊云技術實踐精選集大規模容器平臺的現狀和問題大規模容器平臺的一些最佳實踐騰訊作為頭部企業，在設計大規模容器平臺時需要考慮很多現實因素：集群規模差異：平臺需要管理多個 K8s 集群，節點數量從數十到數千不等；集群數量眾多：業務地域分布廣泛，

59、每個地域都有雙活甚至多活，總數在 100+；業務混布：業務數量極多（10000+）、類型各異，包括游戲、會議、AI、直播、爬蟲等；業務需求復雜：有狀態、長鏈接、本地升級、快切升級等；Workload 巨大：單個 Statefulset 可能有數千 Pod；單一業務可能同時包含上述所有問題和需求。針對這樣的復雜現狀，騰訊云將業務需求的所有功能與能力實現為平臺的基礎能力。1.StatefulsetPlusStatefulsetPlus 是騰訊自定義的 K8s 負載類型，可理解為 Statefulset 的升級版本，該負載類型包含以下能力：1.自動灰度分批發布，升級時可以定義 Workload 的百

60、分比（Num%），大多數版本的發布與更新都需要這一能力的支持；2.暫停/自動回滾；3.自定義發布時間間隔；4.原地升級；5.批量配置更新；6.maxUnavailable（最大失效副本數量）。32騰訊云技術實踐精選集與原生類型相比，StatefulsetPlus 更適合大量 Workload、復雜升級需求和較多參數依賴的業務場景。例如，一個理想的 Workload 升級場景，定義自動升級分為 30%和 70%兩個批次：在實際生產業務中可能面臨較復雜的情況，例如，升級批次較多，每一個批次占用比較少時，當升級到中途發現問題，原生自動回滾會一次性退回失敗時間點之前的全部批次，而 Statefulse

61、tPlus 可以按照之前升級的批次按序回退，并可以調整回退的時間間隔。另一種情況是升級與 HPA 的配合問題。例如，前 30%的批次升級完成后，后 70%的批次升級之前，HPA 對副本進行擴容，導致新版本 Pod 所占比例增大，與原定升級比例值不符。為此需要引入最大失效副本數等參數來確保業務無損。StatefulsetPlus 還針對 UDP 類型業務定制了名為“快切升級”的功能：33騰訊云技術實踐精選集部分 UDP 流媒體業務在執行完整升級流程時，需要刪除原 Pod，拉起新 Pod，為此要先剔除流量再加回流量，對高敏感度流媒體業務不夠友好。以騰訊會議為例，這一場景會導致業務 Pod 重啟時間

62、長達十幾秒甚至一分鐘?？烨猩夁壿媱t在原始狀態下，標準業務容器之外增加一個業務容器與 EmptyDir Volume。該 Volume 中寫入一個文件充當鎖，在正常情況下，是由上圖中間的業務容器來提供服務，業務容器輪詢，詢問文件是否拿到鎖，如果拿到鎖就對外提供服務。升級時，可以在業務容器提供服務的同時，將下面的 Backup 容器鏡像拉下來，只需將業務流量切換到新容器即可在瞬間完成快切升級，實現幾乎無感知的升級過程。該功能還支持共享內存，有狀態的服務可以用共享內存的方式，保持兩個容器的業務狀態信息不丟失。2.Descheduler 與 NPDDescheduler&NPD 主要包含以下四個能力

63、：1.高負載自動遷移；2.基于事件的 Pod 驅逐；3.分布式 Ping 檢測；4.節點自愈策略。由于騰訊業務平臺的海量節點數量及繁多的節點類型，Descheduler 與 NPD 就此誕生，這兩項組件能夠以代碼的方式實現較為智能的節點重啟操作，顯著提升了運維效率，節省人力成本。此外，由于各種類型節點的重啟策略不同，自動化操作可以避免人工操作時出現的誤判風險。34騰訊云技術實踐精選集Serf-agent 獲取整個集群里所有節點的 IP，并隨機挑選幾個節點做 Ping 檢測，Ping 檢測失敗后，Serf-agent 會通知多個 agent 重復檢測，全部失敗后生成聚合信息發送到 API Ser

64、ver，告知某節點已下線。集群外的 NPD Server 組件獲取 NPD 相關事件后，根據 Recover Policy 執行一系列重啟（自愈）操作，使節點恢復到正常狀態。如下圖所示，該功能還包含一些其它插件：以 PIDPressure 插件為例，當某些業務容器因為一些原因發起了過量進程后，檢測插件會檢測到出問題的 Pod，并將 Pod 信息放入一個 PIDPressure 事件中，再傳給 API Server，NPD Server 會獲取該事件，驅逐該 Pod 或發送告警信息。對于 RuntimeProblem 插件來說，當 Runtime 出現問題時，該插件能夠自定義策略，優先排空 Po

65、d 重啟運行時，恢復業務并保留現場后再排查問題。根據實踐經驗，常用的自愈行為分為以下步驟，具體策略也可以根據實際情況做調整：重啟運行時，解決 Pod 持續 pending/creating 的問題；驅逐業務 Pod，節點有問題時對外提供服務為最高優先級；重啟 Node 節點，快速解決節點問題；刪除節點，適合節點數量較大的情況。自愈特性方面的經驗：跳過 Cordon 掉的節點，避免節點重啟以便排查問題；節點可通過 labels 指定不生效的行為；35騰訊云技術實踐精選集 強制重啟；具備可觀測性，所有自愈操作在 Prometheus 上可見。節點負載較高時根據負載情況進行 Pod 遷移，降低高負載

66、節點比例。Descheduler 根據 CPU、內存、PID等指標判斷負載情況，并根據 Pvc 掛載情況、Pod 刪除保護、label/annotation 標識等信息判斷業務 Pod 能否被 Deschedule。分片的云原生監控在監控方面，騰訊容器平臺提供了云原生標準監控方案、分片支持海量數據、全局查詢、定制化精細監控指標等能力，這些能力能夠更好地支持平臺超 3 億 Series、300+Prometheus 實例和大小不一的海量集群。在整體架構中，每個集群內有一個 Slipset，其中三個容器分別是 Prometheus、thanos sidecar 和 kvass sidecar：這里

67、的 kvass sidecar 負責解析 kvass 協調器下發的配置文件，并動態生成配置文件發送給 Prometheus 實例，讓 Prometheus 收集相關監控指標。而 kvass 協調器負責讀取常規的 Prometheus 配置文件，然后收集所有 Series，計算 Series 總量，并按照設置比例動態分配到多個不同 Prometheus 實例中，再分配給 kvass Sidecar。當集群中 Series 數量非常大時，無論讓 Prometheus 收集還是人工拆分都很困難，而動態分片就可以根據 Series 數量的變化動態計算分片情況。Kvass 是 Prometheus 橫向

68、擴展解決方案，分為 Sidecar 和協調器兩個組件；Thanos 負責數據匯總和全局查詢；Discovery 進行跨集群 Prometheus 實例發現，每一個集群里有一個 Discovery，負責匯總集群中所有 Prometheus 實例，上報到 Thanos Global Query 組件的配置文件，確保 Thanos Query 在集群擴容時識別所有實例；Container-exporter 是容器內監控實例。根據分片云原生監控實踐，我們也總結了以下幾方面經驗：36騰訊云技術實踐精選集1.單實例 Prometheus 一般設置為 200 萬 Series，可以實現較穩定的狀態和合理的內

69、存使用比例；2.200 萬 Series 配合 24GB 到 32GB 內存+800GB 磁盤；3.Series 數量占比最大的是 Cadvisor 和 Kube-state-metrics。單集群里的 Kube-state-metrics 會暴露集群里所有對象的原數據信息，實踐經驗中一個集群可能有超過一百五十萬條數據。類似地，Cadvisor 的 Metrics 數量可能占整個監控體系里面 60%；4.針對第 3 條可以有兩個優化措施，首先，裁剪一下 Cadvisor Metrics。Cadvisor Metrics 有一些可以后續聚合計算，例如一個 Pod 的 CPU 使用情況，可根據 P

70、od 里三個容器各自的使用情況聚合計算得來；5.當集群太大時，Kube-state-metrics 的單個 Target 的 Series 會超量；且 Series 數量太多時，每一次采集在指定時間內無法全部讀完。為此，可以做 Kube-state-metrics 分片，這是 Kube-state-metrics 組件原生支持的。但分片數量不能太多，因為 Kube-state-metrics 會頻繁 List 所有 K8s 對象；6.Container_exporter 可以在容器業務較關鍵時，收集容器的進程、線程、CPU、內存等數據。該方案提供一個二進制基礎鏡像給業務使用，業務將鏡像放入自身

71、容器，鏡像將對應數據推到 Pod 所在節點部署的 pushgateway 上，之后再由 Prometheus 發現 pushgateway，收集數據做聚合計算。該方案的優勢是高精度和高頻率，其 Exporter 可定制，并且可以做到非常輕量化。之所以做容器內監控，是因為常規情況下很多業務沒有原生暴露的 Metric，只能通過容器內監控進行數據收集。而 Node_exporter 不夠輕量化，一些計算方式不兼容器類。而使用 Daemonset 的方式部署 Pushgateway，則是為了避免所有容器內監控數據推送到 Pushgateway 形成單點故障。37騰訊云技術實踐精選集其他實踐 IP 規

72、劃與配額動態分配：當集群規模較大時，IP 數量可能不夠用，為此要提前做好 IP 規劃和動態分配，有些集群的 IP 空余時要設法回收。固定 IP 的優勢：方便添加黑白名單，針對一些有狀態業務的 IP 保持不變。HNA：集群節點可以橫向擴縮容，從而提高集群資源利用率，降低集群故障率。HNA 還支持計劃擴容，能夠提前一段時間寫好擴容規劃。容器平臺技術演進方向實現 EKS（彈性集群）的一些能力：通過無節點概念降低運維成本，同時完全兼容 K8s API；支持多個可用區；實現業務畫像能力，通過中心調度決策系統從 Prometheus 讀取數據，為不同的業務繪制畫像，計算擴容等決策。服務網格：跨多個集群的服

73、務網格將逐漸淡化整個平臺的集群概念，讓所有業務流量通過服務網格的方式跨集群、跨地域進行優雅地切換和備份。每一個可用區有一個服務網格控制平面，整個平臺上所有 K8s 集群內的 Pod 接入完整的數據平面，控制平面和數據平面的交互是用戶不可見的。這樣用戶無需考慮服務部署在哪個集群，且服務部署時可以直接部署在多個可用區，通過服務網格的形式進行流量轉發和備份。38騰訊云技術實踐精選集Serverless 服務是騰訊云近年來發展的重點。在音視頻處理領域，騰訊云也在積極探索將 Serverless 架構與音視頻處理技術相結合，為用戶帶來更加低成本、高性能、高擴展能力的音視頻處理底層服務能力。在 2021

74、年GMTC 全球大前端技術大會【深圳站】中，來自騰訊云的高級工程師，Serverless 應用后臺模塊負責人田夢敏，重點分享了音視頻領域在 Serverless 場景下的落地實踐。騰訊云 Serverless在音視頻處理的探索與實踐田夢敏 騰訊云高級工程師&Serverless 應用后臺模塊負責人2017 年加入騰訊，先后負責 CVM 候鳥遷移、域名解析、apigateway、云函數自動擴縮容等業務，目前主要負責 Serverless 應用的研發工作。39騰訊云技術實踐精選集音視頻市場背景音視頻內容生產和消費的痛點據 UserTracker 2020 年的互聯網網民數據顯示，85 后已經成為互

75、聯網主流的用戶群。與此同時，互聯網主流娛樂形式與過去相比發生了巨大變化，短視頻成為了新的舞臺焦點，這意味著音視頻的市場需求大幅增長，UGC 創作場景常態化與視頻消費形式的多樣化，對視頻底層技術也提出了更高的要求。例如，超高清回傳、實時共享、自由視角、自由縮放、云端制作渲染和強交互等需求，均需要音視頻底層基礎設施具備更強的能力。市場需求落地到底層技術一側后，可以提煉出音視頻技術所面臨的主要挑戰。整體而言，當下行業面臨的挑戰可以用四組數字來總結：1.40：由于用戶使用的設備多種多樣，創作視頻時使用的編碼格式各不相同，生成的視頻封裝格式非常多樣。平臺需要應對的視頻格式有 40 多種，要做到統一管理、

76、形成標準輸出是一大挑戰；2.320p/4k：主流視頻清晰度的跨度非常大，從 320p 一直到 4k 不等。不同的清晰度需要對應不同的算力進行支持，如何做到靈活調度算力也是一大挑戰；3.10：一般來說，視頻生產者制作一到兩小時時長的視頻，轉碼、渲染到最終輸出結果的過程需要在 10 分鐘內完成，才能提供比較好的體驗。這對后臺的處理效率提出了很高的要求；4.1000w：考慮到上述復雜的需求，當平臺用戶量達到千萬規模時，音視頻提供商需要具備相當高水平的資源儲備才能有效應對流量波峰。這樣勢必會造成底層資源的浪費，同時大幅提升資源成本。上述挑戰進一步總結可以歸納為：1.帶寬成本高昂：當視頻數量或者用戶量增

77、長的時候，迫切需要進一步減少碼率，降低企業運營成本；2.服務器成本高：自建轉碼服務器開銷和運維成本較高，需要考慮可用性、擴展性、監控、升級、容災等情況;3.內容質量參差不齊：內容生產流程不規范，環節間剝離，沉浸感差，非常依賴于各個環節人員的經驗；4.定制化不足：轉碼算法靈活度、定制化能力不足，無法滿足用戶或者企業對于個性化、定制化的使用需求。40騰訊云技術實踐精選集基于 Serverless 的海量音視頻處理方案為了讓大家更好地理解 Serverless，這里舉個小例子：日常出行的方式一般有網約車、汽車租賃和私家車三種選項。其中網約車是按需付費、隨叫隨到；汽車租賃需要付出租金、保險、油費等成本

78、；私家車則需要車主一次性投入一筆不小的資金，后續還有一系列的維護保養的投入。將駕車出行的情況類比到 IT 行業，就相當于 Serverless 對比虛擬機和物理機。像網約車對比私家車和租賃車一樣，Serverless 的運維成本是有顯著降低的。Serverless 更大的優勢是彈性快速擴縮容，傳統的音視頻提供商如果沒能準確預測業務的流量高峰，就可能遇到流量高峰時流量溢出的故障。但如果將 IT 資源準備得足夠豐富，就會造成資源的巨大浪費。相比之下，Serverless 的核心優勢就是基礎資源設施具備極高利用率，其按需付費、彈性伸縮的特性能有效降低運維成本?；谏鲜鎏匦?，騰訊云探索了一系列 Ser

79、verless 解決方案來應對音視頻領域的幾大挑戰。第一個場景是音視頻轉碼方案。該方案有以下優點：1.中間轉碼層采用了騰訊云多媒體實驗室的轉碼算法。該轉碼算法在多媒體領域深耕多年，是騰訊內部 QQ、騰訊視頻等應用的基礎支撐組件；2.方案靈活可定制?？蛻艨梢噪S意擴展云函數功能、修改入參，或者使用自定義算法完成視頻的拼接、補幀等等；3.成本更低，支持高并發。充分利用 Serverless 天然的按需付費、快速彈性擴縮容特性；4.效率更高。云函數是按需付費的，一個大的視頻文件拆分后，并行觸發多個云函數轉碼，在大幅提升轉碼速度的同時，不產生額外費用。第二個場景是音視頻的單流、混流錄制后處理方案。該方案

80、是與 TRTC 深度合作的成果，利用 TRTC 團隊的 SDK 進行了深度優化。例如，用戶在互動直播的過程中，想要拉取 TRTC 房間里的某一路或者多路流做后處理工作，經過云函數優化后這一目的能夠得以實現。該方案具備定制化優勢，可以滿足很多個性化場景。用戶基于云函數的開發模式可以做到敏捷高效開發。同時該方案特性均以應用的形式深度集成了云上產品的 SDK，方便用戶直接使用。41騰訊云技術實踐精選集第三個場景是音視頻全景錄制方案，該方案也結合了 TRTC 的 SDK、云上白板，即時通訊的 SDK 等技術。該方案將整個 SDK 融合到一個客戶端頁面，云函數模擬一個客戶端，接收客戶傳給方案的數據。相當

81、于一個虛擬的瀏覽器，把用戶的所有數據通過實時截屏的手段錄制下來，后續轉碼為用戶想要的視頻格式。該方案的優點有：1.具備一鍵觸發能力，可以實時彈性啟動，由服務端執行瀏覽器全景景象錄制；2.實時截屏可以將多方視頻源混流，大幅降低算法開銷；3.多路直播流、白板、信令等同步集成，避免了時間不一致情況；4.錄制過程中可以靈活調整布局，可以錄制彈幕等內容。全景錄制架構圖包含多個函數，多個函數組成一個工作流，每一個功能對應的原子函數經過工作流編排，形成全景錄制整體應用。發起任務時，向應用輸入視頻地址、錄制時間、錄制碼率、輸出格式等參數就可以開始錄制。dispatch 功能負責增刪查改，如發起錄制、停止錄制、

82、暫停錄制、查詢錄制任務狀態等。錄制的文件是分段的，每一個小文件逐個上傳到 COS 觸發實時轉碼，錄制完的文件可以上傳到 COS、ARD 等，上傳的原子函數完成之后，應用可以報告用戶錄制已完成，由用戶決定下一步操作。該錄制方案為了保障錄制的可靠性，每一個環節都有專門的函數監控，確保足夠高的 SLA，滿足金融等高可靠性場景的嚴苛要求。目前，該方案的可靠性已經得到了重點行業客戶的實踐驗證。在線輸入媒體流方案主要針對定時發送視頻的場景。例如，教師可以把上午錄制好的講課視頻，上傳到 COS 后建立一個定時任務，在指定時間將視頻推送到指定房間。該方案具備很好的通用性，并利用 Serverless 的特性做

83、到了高性能與極低延遲。Serverless 視頻智能化編排處理方案，使用戶能夠輕松通過可視化編排的方式，構建定制化視頻處理流程。Serverless 應用將所有視頻處理功能做成了原子化云函數，每一項原子能力都以 demo 的形式存在于云函數之上。用戶可以自行更改 demo，之后，可以將各個云函數在可視化界面中組合起來。不同能力可以直接復用，整個流程也實現了標準化操作。42騰訊云技術實踐精選集從上述解決方案可以看出，Serverless 音視頻方案相比傳統技術有三大優勢：1.靈活性優勢。云函數具備很多規格的算力資源配置，能夠通過彈性伸縮能力自由處理各類任務。云函數的參數可以靈活修改，自由定制。云

84、組件支持自定義編排處理流程定制化，標準化；2.算法優勢。騰訊云 Serverless 音視頻方案標配騰訊多媒體實驗室自研的高效編解碼算法，其得到了騰訊多個業務及大量用戶的實踐驗證，具備行業一流水平；3.成本優勢。Serverless 支持按需付費、彈性伸縮，不需要運維或者運維需求極低，能夠靈活應對流量高峰低谷，及時擴縮容，相比傳統平臺有明顯成本優勢。目前 Serverless 音視頻解決方案主要有四大類應用場景：教育錄播課、媒資管理審核、短視頻編輯分發和直播與視頻拆條回放。憑借 Serverless 方案的幾大優勢，這些場景的音視頻應用可以獲得性能、功能、開發速度、可用性、成本效益等多方面的顯

85、著提升。43騰訊云技術實踐精選集在線與離線業務混合部署的背景下，在線負載與離線負載之間的隔離變得尤為重要。在實踐中，傳統的資源隔離方式暴露出了隔離力度不夠、無法保證強隔離等諸多缺點。在 2021 年 QCon 全球軟件開發大會【北京站】中，騰訊云專家工程師徐蓓、專家工程師蔣彪兩位老師分享了騰訊 Kubernetes 大規模離在線混部與內核隔離實踐的主題，介紹騰訊 Kubernetes 利用自研內核 QoS 技術，實現主要資源強隔離，在內核層面保證在線離線資源服務質量，并在保證業務穩定的前提，將工作節點利用率提升到極致。騰訊 Kubernetes 大規模離在線混部與內核隔離實踐蔣彪 騰訊云專家工

86、程師徐蓓 騰訊云專家工程師12 年專注于操作系統技術，在操作系統內核、虛擬化和性能優化相關領域有豐富的研發經驗，負載騰訊云底層性能優化和相關研發，Linux Kernel 社區貢獻者。11 年軟件架構與研發經驗，其中 7 年云計算經驗，在 IaaS、PaaS、離在線混部和云原生大數據領域有豐富的研發與落地經驗，Kubernetes Contributor，開源愛好者。44騰訊云技術實踐精選集騰訊 Kubernetes 混部實踐騰訊混部背景在生產環境中，觀察資源申請或負載層面的資源消耗會發現，在線業務申請資源時往往按照峰值申請，峰值和真實利用率之間會很大 Gap。在線資源在 CPU 層面的整體利

87、用率均值小于 15%，這部分 Gap 資源稱之為閑置資源，往往是被浪費掉的。反觀離線資源會發現它是 Best Effort 屬性。給它的資源供給越多，業務的運行質量會越好，運行時間也會越短。離線任務集群均值，按照實際經驗，大概率會大于 40%。離線計算業務密度非常高的環境里面甚至可以達到 70%、80%左右。在資源管控或者調度層面，一般在線和離線業務分屬于不同的資源管控和調度系統。如在線業務通過 Kubernetes 集群做資源調度和管控，離線業務使用專門的管控調度系統，比如 Yarn、Spark 和 Flink 等。在線和離線資源管控端的分離對業務方、資源運營方都會帶來巨大的管理成本。在這兩

88、個大的背景下，騰訊云希望通過 Kubernetes 層面在調度層面做到統一，提升研發效率。第二核心目標是將在線和離線通過 Kubernetes 部署在一個大的共享集群里，提升整體資源效率，大幅下降整體資源成本，大幅下降整體資源開銷的 30%左右。騰訊混部發展騰訊很早就開始實踐混部了，2009 年主要使用 LXC 容器做隔離，底層通過 cgroups v1 實現，但整體的隔離效果不是特別好。2014 年開始，隨著 Docker 技術的日趨成熟，騰訊云把底層容器技術完全切到了 Docker 容器平臺上。45騰訊云技術實踐精選集2017 年開始，隨著云原生領域以 Kubernetes 為代表的容器平

89、臺的完全成熟，上層的管控端完全切到了 Kubernetes 上。彼時在線資源用 Kubernetes 做整體的資源管控和調度，在隔離層面更多依賴 v1。騰訊云內部還做了一個 Linux 發行版，加入非常多的面向容器的隔離實現，保證整體混部后在線不會受離線任務的影響。2019年開始，騰訊云逐漸把離線計算完全切到 K8s 上，最終做到了在線和離線統一，通過 K8s 統一管控調度，底層完全做混部。資源隔離層面完全切到了 v2。內部的 Tencent Linux 發行版升級成了 Tencent OS 完全面向云原生和容器的實現，在資源隔離層面做到了非常好的效果。Tencent Kubernetes 離

90、在線混部架構任務級別方面，根據任務負載的特點分為在線和離線。下面又會根據不同業務對 QoS 要求的不同進一步劃分。比如在線這邊劃分成在線高敏和在線低敏，對應底層不同的資源隔離的實現。離線這邊一般會設置成最低優的任務資源。調度層面，在線和離線分走不同的調度器，用原有的 K8s Schedule 做在線層面調度。除了性能層面做了一些大優化以外，在策略層面主要實現了節點層附帶感知，從而在業務調度決策時動態感知整個集群節點層面的真實負載，維持較好的負載均衡。離線層面自研了 tke-scheduler 調度器，batch 性能對比 kube-batch 有約 10 倍提升。調度策略上實現了 gang-s

91、chedulling 等策略，完全滿足大數據、機器學習等計算任務的調度需求。46騰訊云技術實踐精選集資源層面，在線業務會把所有集群層面的賬面資源用滿。一個資源預測器模塊會實時根據節點上在線資源的負載預測閑置資源，給離線調度器使用。通過這種方式做到了整體，尤其是離線資源層面的超賣。整個集群層面離線計算能大概超賣 60%左右。做混部之后，在線業務不能受離線業務影響。所以架構中一個非常重要的模塊是 Resource QoS manager 插件式框架，內部實現了 4 個主要資源的隔離實現，包括 CPU、內存、磁盤和網絡。Kubernetes 1.19 開始默認支持 cgroup v2，支持 v1 到

92、 v2 無縫轉換，除了開源內核支持外，我們跟 Tencent OS 內部發行版的內核做了深度集成，在資源隔離層面做了非常緊密的結合。通過上述架構部署，集群達到千萬級以上規模。集群整體 CPU 均值達到 46.5%左右，在有些離線計算密度非常高的集群里可以做到均值 65%。資源隔離：CPU 隔離CPU 隔離層面，因為 Tencent OS 內核是完全面向云原生容器領域，所以內核層面就提供了優先級的概念。騰訊云在 Kubernetes 層面做了三個優先級對應，Guaranteed 對應 p0 優先級，Burstable 對應 p4，BestEffort 對應 p7。OS 本身還提供一個非常重要的功

93、能，可以做到對低優先級任務的 100%搶占。內核在 CPU 調度上，一般采用 CFS 調度，有三種分配策略：第一種是 cpuset，是物理核綁定；第二種是 cpu quota/period，是 CPU 時間片分配；第三種是 cpu share，做權重分配。CFS 是基于 CPU 時間片的完全公平調度，但它實際上不能保證 CPU 100%搶占，底層資源節點 CPU 緊張的時候，高優資源并不能 100%保證在下個時間片區被分到。如果是一些 CPU 敏感型的業務，在資源緊張的時候可能會受損。在這樣的前提下，Tencent OS 的 CPU 層面能在整體 CPU 緊張的時候被 p7 以上高優任務做搶占

94、，這樣保證高優任務不會受到低優任務的影響。在整體核分配上，在線進一步劃分成在線高敏和在線低敏。高敏業務一般做單獨 cpuset 綁定，但是量不會特別多，目前預估整個集群 5%的業務會做單獨綁定核操作，剩下 95%的 CPU 核會和整體的離線計算混部在一起。觀察生產集群，干擾率能小于 5%，甚至離線計算壓滿的情況下干擾率也在 5%以下。這一套 CPU 隔離的47騰訊云技術實踐精選集方案整體的效果非常好，完全達到生產級別的預期。資源隔離：內存隔離內存本身不可壓縮，極端情況下可能高優或者中優的任務就直接被殺死，業務是不能接受的。在這樣的背景下，我們更多采用對任務內存做抑制的方法，保證不會進入到任務殺

95、掉的粗暴路徑。內存回收層面實現了優先級感知功能，可以根據優先級做排序的殺死。在整體內存回收的水位線做了分級實現，比如會把低優 wmark 的水位線上移，這樣有些低優的資源密集型的任務在大量申請節點資源的時候會觸及水位線，從而做到抑制的效果，使整個節點層面有一個緩沖的機會，保障整個節點的內存水位線處在比較健康的狀態。資源隔離：內存 QoS這里利用了 cgroups v2 Memory Controller 提供的兩個參數，一個是 memory.min，主要做 requests 級別的保留。在 pod、Container 或節點層面做內存申請時，會在 memory cgroup 里針對這部分內存做

96、預留，保證進程肯定能拿到這部分資源。第二個參數是 memory.high，做超分配內存的 throttling。比如有些 pod 創建的時候，requests 是小于 limits 的，limits 到 requests 之間是超分配的內存。如果默認是 80%限制，memory.high 就設置成 limits 乘以 80%，設置這樣一個水位線。觸及水位線以上的內存申請都會被 throttling。這樣從超賣內存層面保證整個節點層面的內存不至于迅速被超賣的 pod 消耗完。Tencent OS 在騰訊內部已經演進了超過 10 年時間，是騰訊云獨立維護的一個發行版，后續的目標是做成一個面對云原生

97、場景完全定制的操作系統。Tencent OS 在底層的資源隔離技術方面提供一個完整的解決方案叫 RUE。Tencent OS 面向容器場景的實踐48騰訊云技術實踐精選集以上是 RUE 的架構，最底層是 cgroup priority，在內核當中引入了 cgroup 優先級的概念。優先級是所有資源共用的基礎，所有資源都基于優先級做 QoS。中間層是資源 QoS 的 4 個模塊，分別是 CPU、內存、網絡和 IO。最上層做了一個 Resource Quality Monitor，可以實時監控不同優先級的 pod 服務質量。服務質量方面主要包括幾點內容。首先會對不同優先級容器的服務質量打分，當發現關

98、鍵的 SOI 不能滿足要求的時候，會自動記錄關鍵信息到 Monitor Buffer 里面，可以在出現干擾的時候實時抓到干擾的現場。RUE：cgroup prioritycgroup 優先級是所有資源共用的核心基礎設施，統一優先級的概念剛好跟 cgroup v2 理念完美結合。目前 RUE 支持 8 個優先級，可以整體覆蓋 K8s 云原生的三個 QoS 級別。這里最大的特點是不同優先級之間可以實現絕對搶占，高優先級需要資源的時候可以立刻絕對搶占低優先級的資源。同優先級的容器之間是按照權重分配資源。49騰訊云技術實踐精選集RUE：CPU QoS騰訊云對于調度器做了非常徹底的改造。在資源隔離層面整

99、體的解決方案叫 TCNS，Tencent 云原生調度器。這個調度器整體上由三個調度類組成，可以覆蓋所有場景的混部。第一個調度類叫 BT，離線調度類，主要針對容器的混部；第二個是 VMF 調度類，叫 VM First，專門針對虛擬機的混部，也可以針對安全容器的混部；第三個是對面對通用的場景，跟社區結合更緊，這個調度類是 ECFS。面向容器的場景主要用 BT 調度類。它的三個特點，第一個是絕對搶占。因為社區里面的 CFS 基于公平原則，要考慮通用性，要覆蓋所有場景，所以很多決策都做得比較保守，沒有辦法達到極致的需求。比如說在高低優的優先級的進程之間，它始終是有時間片的分配，就是最低優先級也能分配到

100、一定的時間片。所以這種情況下，它的混部的 CPU 隔離效果就沒有辦法做到極致。但是如果按照社區的機制、思路去改造 CFS，對于社區來說是完全不能接受的。因為如果改造成絕對搶占的方式，離線有可能會出現餓死，有可能出現優先級反轉的問題。社區在考慮這樣的問題的時候，是不可能接受去做這樣的深度改造的。騰訊云在很早之前就自己寫了一個離線調度類，是在 CFS 后面加了一個調度類 BT，它的優先級比 CFS 更低，當有 CFS 進程運行的時候，其實離線任務是沒有辦法運行的；當 CFS 不跑的時候離線才能跑。BT 里面實現了 CFS 最基礎的功能，比如 cgroup，還有其它的一些單核調度負載均衡功能。另外它

101、可以做到是絕對隔離。因為 BT 的調度類優先級比 CFS 低，所以可以達到絕對搶占的效果。然后是超線程干擾隔離，同一個 CPU 的超線程之間要共享一些核心計算資源。這種情況下，當在線和離線同時運行在一堆超線程上的時候，干擾是絕無法避免的。針對這個問題，社區其實沒有一個完整的解決方案。這里在調度的一些關鍵節點，比如說在調入、調出的時候會做一些檢查，可以避免離線和敏感的在線業務同時運行在一堆超線程上面，實現完美的隔離。最后一個特點是由于騰訊云對調度器做了完整、全面的改造，所以核心競爭力是具備完全的定制能力。因為混部場景非常復雜，不同場景下的需求可能是不一樣的。所以騰訊云可以根據業務的場景去適配、改

102、造調度器，滿足業務要求。一個實例是微信的一個業務上面的混合效果。因為微信業務對延遲非常敏感，整體的 CPU 利用率從原來的15%做到 60%均值。在一些對延遲不敏感的場景里面可以做到 90%。50騰訊云技術實踐精選集RUE：內存 QoS在混部實踐進入深水區的時候，內存的復用是最大瓶頸。這里面的關鍵痛點是沒有辦法保證在線業務分配內存的延遲。分配內存有很多條件，達到某個水線以后會進入不同的流程。其中最頭疼的是一旦進入慢速度路徑，它的延遲是完全不可控的，有可能是秒級的。這種情況下，對于高優的容器是完全沒有 QoS 保障的。內存回收方面也有一個天然的問題。內存回收的時候時間也是不可控的，尤其是在標準的

103、 OOM 場景，OOM 要給進程發信號，發了信號以后依賴于接收信號進程的調度的上下文。它得到調度以后才自己去回收自己的內存。但是在混部的場景當中，離線的優先級比較低，當 CPU 壓力比較大的時候要去回收它的內存，它根本得不到調度，這個時間是完全沒辦法控制的。在分配的路徑上，現有內核里也是不感知優先級的，沒有為高優容器做特別保障。RUE 在這提出一些關鍵的解決方案。第一個是優先級，第二個是不同的優先級可以對應不同的水線。在分配的路徑上可以保障高優容器的水線更低，更少進入直接回收流程；低優水線更高，達到水線的時候更早做抑制。在回收流程上，RUE 也是完整感知優先級?；厥樟鞒讨饕?OOM、Rec

104、laim 和異步回收，在所有的回收路徑里面都能感受到優先級。另外一個特性是加速內存回收的功能，意思是離線任務需要回收它的內存的時候，在給離線發信號的時候會做它的調度類判斷，去加速。從調度層面，讓內存回收的流程和調度模塊緊密結合，在回收的時候去提升進程的優先級，保證在指定的時間內一定能得到調度。得到調度以后，它回收內存的時間其實是跟分配內存的時間一樣的，就可以預期它什么時候能夠回收回來。第四個特性是內存分配限速，RUE 做了一個通用功能，可以限制指定 pod 的內存分配速度，從而讓回收的時間能夠更可控。第五個特性是做了 Latency QoS 功能，可以設置指定 pod 的內存分配延遲，如果超過

105、指定的閾值，會啟動快速回收的流程，通過回收低優容器的內存來保障高優容器的 QoS 質量。最終達到的效果是通過犧牲離線業務的內存的可用性來保障高優容器的內存分配的延遲。效果來看，第一個是加速內存回收，可以保證在毫秒級的延時情況下就能回收回來。第二個是內存分配的延遲，可以保證在線高優業務的內存分配延遲始終保持在一個非常穩定的水準。51騰訊云技術實踐精選集從騰訊內部的混部規模來看，已經覆蓋了超過千萬級別的 CPU 核，提供了百萬級別的離線算力。樣板集群可以做到 65%的 CPU 均值。Tencent OS 內核是經過多年演進，整體針對于云原生場景重新設計的內核。未來演進 全面擁抱 cgroups v

106、2。在內核層面做更強的、更全方位的隔離。Kubernetes offload Kernel，希望將 K8s 需要的一些云原生能力下沉到內核當中實現，讓內核提供最完 整最強大的云原生能力，再結合騰訊上層的 K8s，整體上最大程度釋放云原生的潛力。Quality Monitor，可以基于更精細化的指標做更精細化的運營。52騰訊云技術實踐精選集云原生業務改造是云原生普及道路上的一大難關。很多傳統業務遷移上云時都會遇到很多陷阱，如何應對這些坑和挑戰是研發人員非常關心的問題。在 2021 年 ArchSummit 全球架構師峰會【上海站】，騰訊云高級工程師宋翔做了主題為騰訊百萬級容器規模的云原生平臺設計

107、與實踐的分享，講述了騰訊云團隊幫助很多業務進行云原生改造過程中遇到的難題與解決經驗。騰訊百萬級容器規模的云原生平臺設計與實踐宋翔 騰訊云高級工程師負責騰訊超大規模自研業務上云的容器平臺 TKEx 研發設計。將 Docker、Kubernetes、Istio 等云原生技術內部落地；支持騰訊 QQ、在線教育、騰訊會議等海量業務的云原生容器化改造。實踐53騰訊云技術實踐精選集今天，云原生容器化領域的現狀有幾方面的特征：首先，隨著產品規模逐漸增大，單個集群節點可能達到上千甚至上萬個，造成了單個集群的管理難度；第二是集群的數量特別多，而同一個業務可能分散在上百個不同的集群里，這些集群如何協同管理是一個非

108、常大的挑戰；第三點，業務部署是一個混布場景，既有在線業務也有離線業務，有些業務有波峰、波谷特征，有些則長期平穩，或者存在機器學習、訓練任務。平臺上跑著各種各樣的程序，負載和穩定性都會有一定制約。無狀態的服務處理起來比較簡單，業務改造成本較低，但有狀態服務在發布上就會面臨很多挑戰。例如疫情期間，線上會議、視頻、直播業務的發展非常迅速，它們的云原生改造過程中就發現了很多問題，類似的還有一些中間件服務如 DB、還有一些定制化的需求，都是一種有狀態的服務。RUE：內存 QoS騰訊云從幾個方面來改善有狀態服務的管理：升級方式、升級效率、升級穩定性、灰度配置和異常節點處理?？梢詺w納出一個有狀態服務發布平臺

109、需要具備的基礎能力：自動分批更新能力，不一定按照固定數量分批升級，也可能按照遞增的百分比數量升級；升級的過程一定要可以隨時暫停，是可控的。如果遇到失敗率大到一定程度的情況，要有自動觸發回滾的機制；在有狀態升級的過程中要有時間間隔，不能像傳統的升級過程只能滾動升級，上一個升級完再去發布下一個；固定 IP 能力。容器化現狀有狀態服務管理54騰訊云技術實踐精選集有了基礎能力，就要有一些高級能力進一步提高效率。原地升級能力：例如，分批發布只能在 Pod 升級層面做性能優化，但如果有固定原地升級能力，只需每次重啟對應的 Pod 里的 Container 就可以實現它的升級，這在一定程度上又會減少升級的發

110、布時間。ConfigMaps 也要支持灰度升級。K8s 1.12 版本之后允許魔改 Api-server 和 Kubelet 的參數，實現原地升級的能力。騰訊云內部的一個有狀態服務的發現，叫做 StatefulsetPlus，通過一個 Operator 實現了原地升級的能力。55騰訊云技術實踐精選集在原地升級過程中是有一定缺陷的。Pod 里的鏡像版本升級之后，升級的過程外部是無感知的，但實際上鏡像容器的停止啟動過程是有損的，所以騰訊云利用了叫做 readiness gate 的能力做了無損發布。每次替換里面的鏡像版本時，都會先對它的 Condition 打上一個叫做 False 的標簽，讓外部

111、感知到這個容器的 Pod 處在再升級的階段。此時系統剔除掉對應的后端服務的 IP，在升級成功之后再加回，這時 readiness gate 的 Condition 就會設置為 True，完成優雅的升級過程。56騰訊云技術實踐精選集關于灰度配置：騰訊云把 ConfigMap 的升級抽象成了一個工作負載的升級。實際上每一個版本都是一個新的 ConfigMap，所以對 ConfigMap 的升級抽象成了一個工作負載，它掛載了 ConfigMap 名稱的變化。最后是一些進階功能的支持：第一，允許升級的過程失敗。有狀態服務在創建的過程中不一定百分之百會成功，比如預熱一些資源的時候可能就會失敗。最好允許這

112、種場景的發生，比如失敗在一定的百分比內可以允許繼續升級；第二，maxSurge/maxUnavailble。這是 deployment 概念，但在一些場景下有必要提供支持，例如業務的工作負載使用的 CPU 或者內存已經到了 70-80%，這個時候去做銷毀重建的操作會讓底層的后端服務更加異常，甚至有可能出現一些中斷場景。所以可以通過 maxSurge，在升級的過程中預加載新擴容一批的 Pod 去做流量分發；第三，要刪除指定序號的 Pod。有狀態的服務是遞增序列，但使用的過程中，有些場景下某一個 Pod 關聯的有狀態服務是異常的，重啟也無法解決問題。這樣就只能把這個序號刪除掉，等待人為把相關的有狀

113、態的關聯服務啟動成功之后再加回 Pod。下一個問題是升級過程中有可能出現中斷。升級過程中中斷會出現視頻卡頓現象，所以騰訊云對最底層的 Endpoint 做了一定變更，實現了優雅剔除的能力。57騰訊云技術實踐精選集在 Pod 的升級過程中，首先 Pod 到 Terminating 狀態，再啟動一個新的 Pod，把它變成一個新的版本，這個時候是在 Pending 狀態，最后達到 Running 狀態。但在 Pod Terminating 的時候，原生的 Kubernetes Endpoint 里會把這個節點剔除掉。剔除掉之后，上層的四層負載或者 Ingress 就無法探測到剛才升級的那個 Pod，

114、會做一個解綁操作。做解綁操作就會導致流量直接中斷。所以騰訊云在升級的過程中，會判斷 Pod 是否由于升級而發生 Terminating。如果是由于升級發生 Terminating，會把它的一些信息保存在 Endpoint Not ready address 列表里。這個時候上層的負載均衡器監聽到了它的一些變化，會直接把它的流量權重降為零。這樣新的流量不能再進來，但是已建立的鏈接還可以實時處理。等會議或直播結束之后再去做最終的 Pod 刪除操作。即使是這樣的情況下，也不能百分之百保證 Pod 刪除是正常的，一般情況下需要有一個第三方來判斷，實現了刪除保護。比如，請求一個中臺系統確認這個 Pod

115、是不是要刪除、重建的操作，這里會有一個 Delete Validating 的 Webhook，支持一些協議，探測第三方的 Webserver，確定后端的服務是真正可以銷毀掉、可以重建的，這種場景下才會進行重啟操作。上述邏輯能夠一定程度上保證優雅升級，但效率較低，在此基礎上又做了平滑升級的支持。比如會議要開58騰訊云技術實踐精選集24 個小時，Pod 只能在 24 個小時之內刪除、重建，變成最新。常見的一些視頻流是基于 UDP 協議，允許短時間的流量暫停。比如重啟一下，做一個幾毫秒的斷線操作，對于用戶來說就是突然有一點點小卡頓，通過一些方式可以在這個卡頓期間就完成升級。具體來說是有一個 Pod

116、，里面有三個基礎元素。第一個叫做 sidecar，用來監聽這個 Pod 現在是否處于要升級的階段，以及這個階段是否正常。后面還有兩個 container，第一個 container 是 Pod 實際運行的時候要對外服務的 container，里面是真實的鏡像版本，還有一個空的鏡像做短暫的占位作用。當觸發一個真正的升級過程時，Statefulset Operator 會對空的鏡像 Patch 一個最新版本，例如 V2，之后空的鏡像會做一些有狀態的預熱操作，等到它自身認為預熱已經完成，要啟動的時候，會在下方的 EmptyDir 目錄里寫一個文件，聲明自己現在是一個最新版本，要準備啟動了。這個時候

117、sidecar 會監聽到，知道當前是有兩個版本，一個是 V1，一個是 V2版本，且 V2版本已經準備好發布。它就會把自己的容器狀態置為 False，讓上層的 StatefulsetPlus Operator 感知到。在毫秒級升級過程中，第一個版本會被變成空鏡像。這個時候 V2版本知道自己是最新的，且現在沒有在運行的其它服務跟自己沖突，它就會立刻啟動。通過這種方式可以實現毫秒級切換，用戶側感知不到掉幀，是一個平滑的升級。59騰訊云技術實踐精選集產品配額調度下一個話題是產品配額調度。業務在每個季度或者每年都會有一定的預算配額。一個兩個集群無法滿足預算要求時，就會出現多集群、多地域、多產品之間配額和

118、實際集群容量做調度的問題。集群規模很大的情況下，產品可以動態分布在各個集群里面。這樣可以根據業務情況和產品情況做配額調度。在上圖的動態調度架構中有一個中間層，是一個 TKE，基于開源的 TKE Stack 實現。它其實是一個多集群管理工具，有點像聯邦集群概念。在這個聯邦集群的層面上做了聯邦級的一些 API 和聯邦級的動態調度器，負責各個集群里面的產品調配。每個集群里也有一個動態調度器，負責在這個小集群里的各個產品細分的調度，以及動態數據的上報和匯總。它還有一個 Validating Webhook，禁止異常情況下超過負荷的動態擴容。60騰訊云技術實踐精選集負載與穩定性底層運維層更關注的問題是集

119、群的負載和穩定性。為了滿足集群的拓展和伸縮需求，人們傾向于把集群做得非常大，但集群做大之后存在一些問題，就是業務對自己的容量評估是不合理的。比如，產品可能要消耗 10核心的資源，但申請的時候會申請 15 核心的資源，這樣會存在資源浪費的情況。這種場景下，騰訊云有一系列的手段應對，比如 Pod 資源壓縮、Node 超賣，HPA 動態擴縮容。HPA 上還集成了一些第三方的監控系統數據，基于這些數據去做擴縮容。還有 HNA 節點擴縮容，整個集群的負載達到非常接近上限水平的時候，會橫向做節點的擴縮容。下一個手段是 VPA。它在實踐中操作難度比較大，因為程序運行的過程中資源不足可以擴充，但很難縮資源，尤

120、其是內存資源。所以這里需要人工介入，在產品側觀察是否適合降配操作。最后，騰訊云還會根據一些業務的特點做預測和畫像。上述手段本質上是壓縮，它會導致集群不夠健壯穩定。為提升集群穩定性，主要依賴三個手段。第一個叫做 DeSchduler，重調度器。第二個是動態調度器，負責優化資源的調度。第三個是 NPD。重調度的概念很簡單，就是動態發現節點上的資源是否分配合理。負載很高的節點可以觸發調度策略，把它調度到其它的節點上。61騰訊云技術實踐精選集動態調度器可以幫助 K8s 實現更細化的調度。它會基于一些加權指標，判斷服務 Pod 是不是真正可以調度到這個節點上。這里還有一個問題是 K8s 原生是基于 Re

121、quest 做調度，可能比實際使用量高很多。所以這里會根據計算好的真實利用率去做動態調度。NPD 節點探測有幾十條各種各樣的檢測指標。對于常見的一些指標會做自動修復和自愈工作，還有一些指標會做人工審核。另一種指標用作審計用途，會統計出來交給專門團隊分析。這里還可以自定義插件，針對不同平臺自定義探測和恢復策略。62騰訊云技術實踐精選集展望騰訊云的集群原來是基于 Kubernetes，現在慢慢切到 EKS 集群。EKS 是無服務節點集群，運維層面看不到底層的 Node 節點，實際上底層是一個無限大的資源池，這樣就沒有了管理 Node 節點的概念。底層運行時，原來使用 dockerd，后來換用 co

122、ntainerd，還嘗試用 Kata 運行時做更好的隔離。最后騰訊云還是結合了輕量級虛擬機 CXM，使用 EKS 產品，解決 containerd 中遇到的問題。它的隔離性、穩定性會比 dockerd 更強。而且自研優化讓啟動時間非常短。騰訊云后端的集群非常多，但希望業務層面做到無感知。所以騰訊云在通過 EKS with VK 的形式把一些傳統的 Kubernetes 集群以 VK 節點的形式加入到 EKS 集群里，而對于運維層面、上一層接口調用層面來看，它就是一個很大的集群。騰訊云在 Operator 層面做了一些集群間的調度，對用戶做到了無感知。騰訊云還在探索服務網格，做了一個全托管的服務

123、網格，獨立于 K8s 集群。它可以從外部連接到各個 Kubernetes 集群，去做流量控制、自愈、故障注入等操作。但這個網格的舊服務遷移成本較高，性能也存在不足，所以騰訊云也在努力改進。63騰訊云技術實踐精選集不同企業上云后，其成本節省程度是不一的。從 IT 資源成本節省量來看，低的企業不到 10%，高的企業可達 60%-70%。究竟為何會造成這么大的差異？又有什么組織管理手段和產品技術手段可以降低企業上云成本？在 2021 年 QCon 全球軟件開發大會【北京站】中，騰訊云專家工程師于廣游發表了1000+企業云原生改造成本優化總結的主題演講，介紹了騰訊云云原生團隊，通過大范圍的客戶調研和訪

124、談，解答了企業如何借助云原生進行更深層次的成本優化，以及騰訊內部和騰訊容器服務客戶在容器化過程中進行成本優化的最佳實踐。1000+企業云原生改造成本優化總結于廣游 騰訊云專家工程師，騰訊云容器技術總監主導了騰訊云容器產品從 0 開始的設計、研發和運營工作，并在騰訊云海量 Kubernetes 集群的治理和落地過程中積累了大量的經驗。騰訊自研業務全面云原生上云的主要參與者之一，在云原生領域有豐富的實踐和思考。目前致力于 Kubernetes 在成本節省、Serverless、混合云等場景的探索。64騰訊云技術實踐精選集企業 IT 資源成本優化的理想與現狀“從我加入騰訊以來，主要做了兩件事情：第一

125、件事情是主導了騰訊云容器產品從 0 開始的設計、研發和運營工作，第二件事情是把騰訊內部的全部自研業務上云?！痹?2017 年時，我們經常跟客戶講容器和云原生的優勢，客戶會問它到底有什么好處，能降低多少成本？為此，我們與騰訊內外部的客戶進行了多次訪談，最后通過數據分析，得出了云原生、容器跟資源利用率之間的關系。大家應該知道，把 IDC 中的設備和業務搬到云上，在架構不變的情況下，資源利用率肯定不會提升。事實上，我們的調研數據跟預期是一致的，將業務從 IDC 搬到公共云，它的資源利用率平均值一般還是低于 10%。在 TKE 中，70%客戶的平均資源利用率低于 20%；40%客戶的資源利用率只有不到

126、 10%。也就是說，把業務從 IDC 搬到云上，資源利用率沒有提升；接著，把業務容器化以后，資源利用率竟然還是沒有提升多少，這是一件非常奇怪的事情。因此，我們針對以下三類客戶，進行了一次更深層次的分析：第一類：業務有波峰、波谷，但是波峰其實不高，波谷更低；第二類：全天的資源利用率都非常低，一直不到 10%；第三類：晚上會跑一些離線的計算業務，這類客戶資源利用率稍微高一點，但平常也不高。65騰訊云技術實踐精選集我們總結了資源利用率低的兩大類原因：沒有進行業務容器化的企業，這類型企業的業務沒有應用的編排調度管理工具，資源以整機的形式交付，使得業務間無法進行有效隔離，只能被迫把設備交給業務。不同業務

127、獨占資源池，資源碎片的現象會比較嚴重；企業已經將業務容器化了，但資源利用率依舊較低，這類企業本質原因是并沒有云原生化，展開講就是業務微服務改造不徹底，沒有用云原生的方式運行業務；還有云原生的彈性伸縮能力本身不夠成熟，導致業務架構無法彈性伸縮、擴容不及時，且云上資源存在售罄的可能性，因此業務需要提前冗余地占用較多資源量。舉個例子，假設一家公司在云上共有 1 萬核，資源利用率每提高 10%，每年就能省 100 萬，如果能從 10%提升到 40%左右，企業一年其實能省幾百萬，想必沒有企業會拒絕如此大的成本優化吧？為此，我們又進行了一個調研，總結出了企業資源利用率優化失敗的典型模式，我們稱它為四步失敗

128、法。在第一階段中，公司業務高速發展，老板告訴 IT 團隊要全力保障業務發展，要多少機器給多少機器，業務就能夠隨便用，但是資源利用率非常低。第二階段是公司業務發展沒那么快，老板一聲令下讓 IT 團隊優化成本，但由于業務下降，團隊都在尋求新的增長點，所以依舊沒有精力進行成本優化。在這種情況下，無論是業務還是平臺，大家都開始在百忙之中建設資源運營平臺、彈性平臺，推動業務團隊改造。到了第三階段，某天業務突發了線上故障，企業內部就會組織一場復盤大會，業務團隊復盤認為是 IT 團隊推動成本優化，架構冗余減少，擠占研發人力造成的；而 IT 團隊則認為是業務技術能力差，提出不合理接入需求、團隊人力少所導致的。

129、最終在一次次的博弈中，成本優化就無疾而終了，進而走向了第四個階段，業務與 IT 團隊關系極度惡化，所有團隊都覺得成本優化是件吃力不討好的事情。企業 IT 資源成本優化關鍵路徑根據上述提到的企業成本優化的失敗路徑，我們發現成本優化其實是由三對本質矛盾組成的，且這三對矛盾不可調和。1266騰訊云技術實踐精選集第一對是業務穩定性跟資源利用率間的矛盾，很多業務沒有人維護，其穩定性全靠冗余來支撐，而冗余天然跟資源利用率就是一個互斥的話題，沒有冗余，業務的穩定性就會降低；第二對是業務投入與技術投入的矛盾，假設部門只有一個 hire count，到底應該去做業務，還是去把架構搞得可彈性，這其實也是一個不可調

130、和的矛盾；第三對是企業內不同角色/組織的矛盾，不同團隊由于各自目標，最終演化成了業務團隊與資源團隊之間的矛盾。雖然這些矛盾是本質性的，無法完全解決，但企業可以通過技術手段和組織手段減少這些矛盾。組織手段可以分為兩個方面：一方面可以通過獎勵進行驅動，拿騰訊舉例，只要能夠觀測到每個業務真實的成本和資源利用率，接下來也不需要強制做什么，只需要掛一個紅黑榜，給資源利用率前十名的團隊獎勵，請排名后三位的團隊回復郵件，解釋說明資源利用率低的原因。另一方面，企業還可以設置一些增強手段建立成本文化，這是剛剛興起的一個名詞叫 FinOps，意思是代碼設計之初就需要考慮冗余和架構，企業要監控性能、穩定性等數據的指

131、標。它讓每個團隊都可以像監控業務可用性一樣監控業務成本，像優化業務可用性一樣去持續優化成本。此外，組織手段雖然可以使不同團隊目標對齊、促進協作，但關鍵難點還在于技術復雜度的處理，沒有技術投入和技術實力，成本優化就是無休止的扯皮和甩鍋。實際上，資源利用率提升的本質是消除浪費，一種方式是推動業務按需使用，即為彈性伸縮，用多少申請多少，不用就把它縮下去；第二種是業務不用動，平臺方進行資源騰挪復用，即為在離線混部。這兩種方式分別有不同適用的場景：1.彈性伸縮彈性伸縮是根據實際負載，對業務和資源進行橫向和縱向的動態調整，它的核心是業務資源的按需使用，一般資源池大小是動態的。所以它有兩個限制條件，一是純

132、IDC 環境效果有限，縮容的資源依舊空閑；另外是業務方需要進行微服務化改造，無法無痛接入。目前，騰訊云已經在這方面做了一系列工作，并且主要圍繞及時性、靈活性、可用性做了優化。其中，及時性支持基于預測的提前擴縮容，基于 Buff 的節點預擴容，基于配置擴容等等；靈活性是從業務層載體的擴縮容算法、支持多種指標擴縮容；可用性則能夠動態感知資源售罄，智能調整擴容策略，提高擴容成功率；在大數據方面，騰訊云基于 Yarn Operator 和存算分離實現了大數據等業務的彈性擴縮容。67騰訊云技術實踐精選集那彈性該怎么落地呢？騰訊內部推出了一個云原生彈性成熟度模型，用來監控業務組件在過去一周中是否發生過伸縮

133、。如果監測到從來沒有發生過伸縮業務，就讓它能夠伸縮，有這個能力之后，再去推動彈性改造，最終，通過這種方式資源利用率提升了 30%-40%。2.在離線混部在離線混部的本質是將分配給應用，但應用實際未使用的資源，再動態分配給其他應用，其核心是資源的騰挪、再利用，一般資源池大小是固定的。它的優勢非常明顯，業務幾乎不需要做過多的改造，且平臺可后臺對資源進行靈活騰挪和復用。但是它同樣也是有限制的，首先，總資源池大小固定，無法應對流量突發的場景；其次，需要有離線業務能夠填補在線低峰。在騰訊云的在離線混部實踐中，提出了如意 RUE 的解決方案，它能夠讓機器分別部署高優業務和低優業務，當高優業務起來的一瞬間，

134、能夠對低優業務進行絕對的壓制，并且對在線業務零干擾。最終，能夠使資源利用率提升 60%-70%。前面提到的兩種方案都有各自的優缺點，所以最好的方式就是互補，在離線混部+彈性伸縮才是提升 IT 資源利用率的絕佳組合。68騰訊云技術實踐精選集騰訊云原生內外客戶成本優化實踐在 2020 年時，有一個騰訊云的外部客戶對整個在線業務進行了容器化改造，他們也是非常驚訝地發現，容器化改造之后，資源利用率的提升是有限的，所以就希望在 2021 年進一步提升。顯而易見，這家公司內部已經將全部業務進行彈性化改造了，另外，他們業務的波峰、波谷非常明顯，而且離線業務非常大，以至于離線業務跑起來的時候，在線業務的池子是

135、不夠用的，所以騰訊云為他提供了混部+彈性的方案?？蛻舻募罕旧聿渴鹆嗽陔x線混部的特性，同時騰訊云又給他們提供了一個大數據的容器化方案，使其現有的大數據系統不用做任何改造，只需部署一個組件，就能夠把大數據系統的 Job 任務運行在 K8s 集群中?？蛻暨M行了非常穩健的內部推廣，前期只在業界把離線業務往在線業務平臺上發布，但整個實施過程其實非常簡單，因為絕對壓制的 OS 內核能力，使其并沒有用太多的調度能力。此外，TKE 可以在一個集群中插入虛擬的 Node，正常情況下插入一個真實的節點，用戶需要創建一個容器。當創建虛擬動作時，最終會到騰訊云的資源大池中創建一個輕量的虛擬化 Pod。在這種情況下，

136、就完成了在線和離線的統一。最終，通過優化資源碎片、在離線混合部署、自動擴縮容，這家企業的整體計算成本下降了43%。69騰訊云技術實踐精選集總結演講最后，于廣游對成本優化的關鍵點進行了總結，他提到，僅把設備搬到云上，資源利用率是無法提升的，企業會驚訝地發現他們把業務容器化以后，資源利用率的提升竟然也是有限的。當企業去實施成本優化方案時，對其自身企業的技術實力和管理能力，又是一個真正的大考核，但這個大考也是有答案的，那就是 TKE，云原生能夠把握效率和成本的平衡點。最后再介紹下騰訊內部自研上云混部的實踐，游戲、金融、社交等 6 個騰訊 BG，每一個業務的技術棧都是不一樣的，所以進行混部優化的過程非

137、常艱難，但騰訊公司內部還是通過自上而下的支持，進行了全面云原生的改造，把全部的增量業務全部放在 TKE 進行，存量業務逐漸往 TKE 遷移，共用 TKE 這樣的調度系統進行混部。最終，平均資源利用率達到了 46.5%，樣板集群資源利用率達 65%。70騰訊云技術實踐精選集K8s（Kubernetes）應用對運維所關注的彈性、穩定性和性能等方面都起到了很大的作用，對運維人員來說，它達到了降本增效的作用；但對 Node、Java 等后端開發人員來說，K8s 應用卻給他們帶來了諸多困擾。這個矛盾看似不可調和，但開發工作還是要做，代碼也還是要寫，能不能找到一套云原生的組合拳來解決開發人員所面臨的困擾呢

138、？在2021年 QCon 全球軟件開發大會【北京站】中，來自騰訊云 CODING 的研發總監王振威帶來了主題為 破解 Kubernetes 應用開發低效之困：一鍵調試，實時熱加載的演講，分享了騰訊云在解決這一問題的思考和實踐。破解 Kubernetes 應用開發低效之困：一鍵調試，實時熱加載王振威 騰訊云 CODING 研發總監深耕開發者工具領域，CODING 代碼托管、CI/CD 等產品的從 0 到1 的牽頭人。云原生開發環境 Nocalhost 產品負責人。71騰訊云技術實踐精選集K8s，運維之糖，開發之傷在演講中，王振威總結了這樣一句話：K8s，運維之糖，開發之傷。為什么這樣說？在 CN

139、CF 2020 年的畢業項目以及進入孵化的項目中，沒有一個是與開發效率、開發體驗直接相關的，幾乎全部是站在運維角度，從業務穩定性、資源調度、架構性能、流程規則等方面的；在 CNCF Sandbox 的眾多項目中，也僅僅只有四款與開發過程有關。為了解決 K8s 給開發人員帶來的困擾，首先要了解開發效率為什么會降低？這要從以前寫代碼與現在寫 K8s 應用代碼的對比來看。以前寫代碼非常簡單，寫完代碼編譯成一個程序，程序啟動后變成一個進程，之后對這個進程進行一些輸入操作，再看它的輸出。這是最簡單也是最原始的一個做法。72騰訊云技術實踐精選集隨著容器化浪潮的席卷，我們一步步地把這一過程進行封裝、進行解耦

140、化、用松耦合系統做成封裝套娃。第一層，為了解決運行時一致性問題和交付問題，在進程外，套了一些基礎運行時（Runtime），變成了容器。比如，原來是個 jar 包，現在把 JVM 套進來之后就叫容器，但是容器也會掛掉，而且容器與容器之間有協作，所以又要把多個容器套到一個 Pod 里，再配上基礎網絡和存儲。作為 K8s 的最小調度單元，光 Pod 還不夠，多個 Pod 可以形成工作負載（Workload），可以用 HPA 來控制這些負載的橫向擴縮容。但工作負載還是不夠，工作負載之間的調用關系我們希望與業務容器解耦，因此又需要在工作負載內部的 Pod 里加入 Sidecar，嘗試用 Sidecar

141、來解耦服務與服務之間的注冊、發現流量調度等問題，這也是 Mesh 的一個核心能力。再往上，因為不同的服務可能有不同的版本、不同的作用域、不同的優先級，于是又把服務套成了 Service，最后多個 Service 套成了一個應用，形成了云原生的終極封裝套娃。這一過程對開發人員來說是非常復雜的，因為開發人員關注的只有最核心的，容器最里面的Process（進程）。開發人員之困當然，封裝套娃帶來的優勢是顯而易見的，例如松耦合、容錯性以及易于管理等等，但對開發人員的困擾也很大，主要體現在以下幾個方面：首先是要學習的東西變多了，其次是根本沒辦法搭建出一套環境，像 CODING 團隊中規模較大的應用有 20

142、0 個微服務，幾乎沒有人能夠把這個環境搭建起來。如果要老手搭建起來，至少也需要兩周的時間；173騰訊云技術實踐精選集以前的代碼是實時熱加載的，只需要在 IDE 里點一下 Debug 或點一下 Rerun，就可以刷新頁面了。但現在，整個寫代碼的過程就變成了：修改代碼 推到倉庫 觸發 CI 編譯 打包成鏡像 鏡像倉庫 由 CD 系統或運維人員把它更新到集群中，當集群中的容器探針檢查通過服務上線之后，再發一個請求調用看看，才知道結果。這時候如果發現少改了一個字母，這時就要再重來一遍，整個人都崩潰了。大多數團隊整個過程至少要 10 分鐘，有些團隊自動化程度好一些，也要 5 分鐘。即使能夠把所有的配置和

143、鏡像都準備好，本地電腦或者辦公室的測試機也沒有足夠的資源把它運行起來，這也是需要面對的一個現實問題。因為我們知道，云的天然特性是它的資源可彈性提供，所以最好的解決方案就是把環境搬到云上，由云來提供最終的支持；即使能夠把 200 個微服務的環境搭建起來，也有足夠的資源來運行它，但如果要寫一段代碼并要看其運行的結果，你會發現這一過程慢得令人發指。因為不得不進行如下圖所示的一套流程。23在代碼和 Kubernetes 之間搭建一座橋梁要怎么做才能真正地提升開發過程中的編程效率呢？CODING 團隊提出了這樣的觀點：在代碼和 K8s 集群之間搭建一座橋梁，讓代碼直達 K8s 核心，而不經過一系列流程和

144、工具。首先，第一步必須要解決環境問題，因為很多團隊對環境沒有彈性的理解，都是由公司內部的不同團隊來維護幾套固定的環境。比如，測試環境一、測試環境二。但事實上，這些環境都是需要獨占的，環境數量有限，當別人用的時候你就不能用。74騰訊云技術實踐精選集而理想效果是不需要人去維護環境，只用代碼把環境定義好。比如 K8s 的應用，用 Helm 或 Kustomize 把環境定義好，需要用的時候去部署一套，做成按需的。與在云上買一臺虛擬機的道理一樣，需要的時候買一臺就可以了。開發環境和測試環境也一樣，需要的時候直接云上部署出來即可。除此之外，如果開發環境、測試環境與正式環境使用了一致性的定義手段，在云上運

145、行時，就可以最大程度地減少在開發和測試階段中，因環境問題帶來的不可預期的影響。其次，我們能不能利用一種手段，把最核心的進程直接暴露給開發人員？在生產容器中，只有進程本身的 Binary 和進程的基礎運行時。以 Java 為例，這個進程可能是一個 jar 包啟動起來的，基礎運行時就是一個 JVM 的解釋器，但在這樣的環境里開發其實不太容易，于是便有了一個這樣的設想：在開發或調試階段，就把生產容器變成開發模式。變成開發模式之后，容器里全套 SDK 的工具鏈，可以直接使用源碼啟動進程。以 Java 為例，可以在開發容器里裝 Maven、JDK 以及各種抓包工具、curl 調試工具，甚至還可以將源代碼

146、傳輸到這個容器里，就可以隨時控制主進程的啟停，最終實現與本地開發一樣的效果。75騰訊云技術實踐精選集通過這種方式，云原生的低效開發模式變成了一個極簡的開發模式，改完代碼之后，啟動刷新頁面看效果，不對再修改，對了就提交，這是開發人員非常想要的一種體驗。想要達到這種效果，首先是環境必須到位，環境應該由云來提供，這樣可以最大程度地減少開發人員和基礎架構部門的負擔。想象在一個場景中，測試人員測出了一個問題，但開發人員在他的環境里卻很難重現。如果環境是按需的，測試人員測完之后直接可以把環境交給開發人員去調試，開發人員調查完畢，再把這個環境銷毀掉。以前，我們僅僅用到了云的基礎計算能力，如彈性能力、計算控制

147、、權限控制等等，那么能不能讓云更進一步，把基礎的監控、CI/CD、制品管理、源碼管理、服務網格、日志管理、分布式追蹤等能力都交給云？事實上，現在騰訊云的容器團隊已經提供了比較完善的基礎能力，包括日志管理、追蹤等等，所以對騰訊內部的業務團隊來講，不需要太關注這些點，直接使用即可得到一個按需、規范的環境。CODING 團隊開源的一款軟件 Nocalhost，可以方便地調試遠端進程中的代碼，直接與本地打通。通過 Kubernetes、HELM、Nocalhost、Istio、Prometheus 等八個組件，讓不同的人用不同的環境來做自己對應的工作，是開發人員就做開發，是測試人員就做測試，由云來提供

148、基礎的監控、日志、跟蹤等等。76騰訊云技術實踐精選集CODING 團隊的實踐CODING 團隊在云上用了一個巨大的集群來支持開發和測試的環境。在這個集群里，我們實現了所有人都可以擁有具備 200 個微服務的開發環境，而它又非常節省資源，并不是所有開發都在同時運行程序，所以有相當大的“騰挪空間”。同時，這個集群的資源利用率也有了很大的提升。對于企業內部來說，利用云的資源其實變相節省了公司內部的開發電腦，或是內部的服務器、IDC 機房等等，同時還解決了開發效率的問題，最終得到了一個降本增效的綜合結果。目前，CODING 團隊在云上穩定運行著大概 120 個不同類型的環境，并且這個環境是按需的，CO

149、DING 團隊的理念和實踐是測試人員可以在 CI 流程里隨時構筑一個新環境，跑完自動化的測試后，再把環境銷毀掉，開發人員可以為一個新需求快速構筑一個新環境，開發自測驗證完畢后銷毀掉?？偨Y要解決 K8s 應用帶給開發的困擾，需要做到以下幾點：必須要用代碼來定義環境，實現自動化部署，不是維護環境，而是要定義它；環境跟環境之間應該形成隔離，能夠讓不同的測試場景、開發不會相互干擾，他們可以沉浸式地在一個環境中去體驗、去觀察自己代碼的運行效果；要合理地利用云提供的各種各樣的基礎設施，進而為團隊賦能；環境準備好以后，必須能夠支持所有人可進行便利化的調試和開發。123477騰訊云技術實踐精選集隨著云原生技術

150、的逐步推廣，越來越多業務開始使用云原生容器化的方式構建自己的應用。Kubernetes 作為云原生容器調度平臺成為了行業的一致選擇，基于 Kubernetes 還衍生出了 Serverless、邊緣計算、Mesh 平臺等一系列云原生平臺解決方案。在 2021 年 ArchSummit 全球架構師峰會【深圳站】上，騰訊云 TKE 穩定性負責人唐聰發表了題為騰訊大規模云原生平臺穩定性實踐的演講，介紹騰訊在構建大規模云原生平臺過程中提升 Kubernetes 集群穩定性的實踐經驗。騰訊大規模云原生平臺穩定性實踐唐聰 騰訊云 TKE 穩定性負責人騰訊云 TKE 穩定性負責人，騰訊云技術專家，極客時間專

151、欄etcd 實戰課作者，業界首個 etcd 一站式治理平臺開源項目 kstone 創始人及維護者，etcd 活躍貢獻者，KubeCon、ArchSummit、Gopher 講師，主要負責騰訊云大規模 etcd 平臺、大規模kubernetes 集群的成本和可用性優化、有狀態服務容器化等產品研發設計工作。78騰訊云技術實踐精選集kubernetes 故障案例分析與最佳實踐首先從典型故障案例說起，為什么 Kubernetes 穩定性不可忽視呢？下圖給大家列舉了三個典型場景的 Kubernetes 故障：master 核心組件組件，Kube-apiserver/etcd 組件因大量 List 等 e

152、xpensive request 導致集群雪崩，這類故障輕則無法發布，重則影響業務數據面；集群 addon 組件故障，如核心的 HPA 組件等。當面對突發流量時，如果 HPA 服務遭遇故障，無法及時擴容則也會導致嚴重的服務可用性故障；業務自行開發的 operator 引起的故障。各業務在云原生過程中，會結合業務領域知識、編寫 operator 來適配自己的業務場景，而 operator 核心工作機制是根據實際狀態與期望狀態進行比較，并采取一致性協調動作使它們趨于一致。然而某業務 operator 依賴方變更，返回數據異常，operator 在快速進行一致性協調過程中，刪除了某類 Kuberne

153、tes 資源，導致業務異常。79騰訊云技術實踐精選集了解了 Kubernetes 穩定性的重要性之后，那我們又該如何保障 Kubernetes 的穩定性呢？從 Kubernetes 架構我們知道，master核心是 Kube-apiserver 和 etcd,因此可以從 Kube-apiserver 出發，結合 Kube-apiserver 原理和大規模實踐，我將典型的故障場景總結下圖中的六大類。針對這六大故障場景，我又從八大方面總結一系列故障預防和最佳實踐手段，如下圖所示，因時間有限，無法深入每條實踐細講，這里重點分享下為什么需要避免大量指定 label get 或 List 操作查詢等。8

154、0騰訊云技術實踐精選集Kube-apiserver 如何執行查詢 get/list 等資源的請求Kube-apiserver在啟動的時候會加載一系列處理鏈，收到請求之后，會通過鑒權模塊判斷用戶身份是否合法，審計模塊會記錄用戶的詳細行為，限速模塊對請求進行限速，通過授權模塊判斷用戶是否有權限來操作對應的資源。Kube-apiserver 還通過準入機制，提供在訪問資源前的動態擴展能力、攔截能力。通過一系列模塊之后，請求會進入匹配資源的 handler 里，最后進入通用的 etcd 的存儲模塊。進行 List 查詢時，如果查詢的請求里指定了 meta.Name，就通過 etcd 單 key 查詢返

155、回來，否則就是范圍查詢，根據 Lablel、FieldSelector 做過濾。關于 etcd 的存儲格式，因為 etcd 是 KV 存儲，所以它的存儲格式是由對應的資源類型加 Namespace 再加對應的資源名組成的。在 etcd 中沒有存儲 Kubernetes Label、FieldSelector 這種字段 key，所以當通過標簽查詢的時候，最后都是在 Kube-apiserver 做過濾。Kube-apiserver 向 etcd 發起 Get 請求后，那 etcd 又是怎樣工作的呢?81騰訊云技術實踐精選集Kubernetes 如何從 etcd 查詢數據 etcd gRPC kV

156、 Server 收到請求后，進入 KV 模塊的 Range 接口。etcd 3.1 版本后線性讀實現是 readIndex 機制，需要從 leader 獲取最新已提交的日志索引號（commitedIndex）；等待本節點已經應用到狀態機的最高索引號大于等于 leader 返回的 commitedindex 后才能允許讀；從索引樹中獲取 key 對應的最新版本號；然后再優先從 cache 中獲取，若未命中則從 boltdb 獲取。etcd 常見故障也可以分為八大類：為發現潛在的 etcd 隱患，騰訊云引入了多維度的集群巡檢，其核心目標就是盡早發現 etcd 集群隱患因素，比如針對大集群、大資源數

157、量、超多的 CRD 等對象數量、頻繁讀寫 QPS、數據不一致等可能搞壞 etcd 集群的場景設計了對應的巡檢策略。此外騰訊云還從架構設計、etcd 穩定性優化，etcd 性能優化、測試變更管理等角度做了全方位的優化。接下來就重點介紹騰訊云大規模 etcd 集群治理經驗，還有騰訊云推出的業界首個 etcd 一站式治理平臺開源項目 kstone(https:/ etcd 集群治理騰訊云對外提供的 TKE、EKS、Mesh 目前有上百萬的開發者和企業用戶使用，他們在騰訊云上產生了大量全托管的 kubernetes 集群。同時騰訊云也是國內第一家對外提供 etcd 產品化服務的，其對內支撐了騰訊數百個

158、業務。正是因為基于 Kubernetes 和非 Kubernetes 產品大量的業務訴求，騰訊云有超大規模的 etcd 集群需要治理。治理實踐可以從運維和內核兩個角度展開。運維角度，騰訊云需要一套全自動化的集群管理系統，能快速完成集群的增刪改查。其次是一套非常強大的監控系統，覆蓋線上數以萬計的 etcd 集群。再次需要實現一套集群巡檢系統來發現集群隱患，以提高整個集群的穩定性。然后 etcd 存儲系統的數據的備份至關重要，需要一套分鐘級的冷備和實時的跨城熱備能力。最后作為云廠商，遷移永遠是必備的能力，無論是從自建遷移到云上 etcd,還是 Kubernetes 資源數據拆分等業務場景，都依賴遷

159、移能力。內核角度，在使用 etcd 過程中你可能會遇到各類 etcd 故障，騰訊云團隊在 etcd 內核方面，修復了 etcd 數據不一致、內存泄露、死鎖、panic 等眾多問題，提升了 etcd 在大規模數據場景下的啟動、讀性能等。除了這些社區已知的 bug 之外，騰訊云還需要從 0 到 1 開發基于 etcd QoS 的限速能力、基于跨城容災的同步能力。為了滿足我們以上治理訴求，騰訊云期望的 etcd 平臺需要滿足以下設計目標：擴展性。支持管理多種業務場景等 etcd 集群，支持多種遷移算法，支持多種調度策略，巡檢策略可插件化；高可用。具備 etcd 高可用部署，etcd 垂直及水平擴容，

160、etcd 穩定性優化、跨城復制、qos 特性，etcd 混沌工程測試等；高效運維及自愈。支持一致性、健康度、大對象及異常 QPS 巡檢，分級數據備份及恢復機制，etcd 節點故障自愈、自動擴容、數據遷移；可觀測性。集群管理可視化、集群 SLO 可視化、集群遷移可視化、etcd 數據可視化。有了這些設計目標之后，騰訊云團隊從開發效率、可觀測性和可運維性出發來做方案選型。其中最看重的是83騰訊云技術實踐精選集可運維性和自動化，這跟 Kubernetes 的擴展機制不謀而合。Kubernetes 提供了 operator 機制，可以非常方便地基于業務運維的領域知識去擴展開發。但 Kubernetes

161、 擴展機制又提供兩種選項，一種是 CRD、一種是 Aggeregated API，對內騰訊云數據規模特別大使用了 Aggeregated API 機制，對外開源的 kstone，使用 CRD 來方便用戶快速簡單部署。上面是 kstone 的整體架構。核心組件有兩個，第一個是 kstone-etcdcluster-controller，可以支持多種 cluster provider，還可以支持存量 etcd 集群可視化管理，我們內置了 kstone-etcd-operator 實現，基于它可實現 etcd 集群的高可用容器化部署。同時，kstone-etcdcluster-controller

162、還提供了一系列可擴展的特性支持，如巡檢、監控、備份、遷移、智能診斷。第二個核心組件是 kstone-inspection-controller，它是巡檢任務的真正執行者，目前實現了集群一致性、資源對象數、大 key、健康度、熱點寫請求、alarm 告警、備份是否成功等策略的巡檢。整個 kstone 平臺支持一鍵開啟監控、備份等所有特性，用戶還可通過可視化的 etcd 管理平臺查看 84騰訊云技術實踐精選集Kubernetes 中的數據在 etcd 中的存儲格式。同時基于 operator 自動化集群管理，用戶通過可視化平臺可以輕松實現集群的創建、擴縮容、統一納管等。與人工部署的舊方法相比效率是

163、提升百倍，同時大大減少犯錯的幾率。kstone 平臺核心的 CRD 是 EtcdCluster，描述了整個集群的集群規格、大小、內存、SSD 等。正如前面縮描述的，kstone 支持多種 cluster provider。這個 EtcdCluster CRD 是平臺型的，后端可以對接開源的 etcd operator，也可以對接內置的 Kstone operator。這個 CRD 也可以描述存量的 etcd 集群，把它導入整個平臺。新建或者導入 etcd 集群之后，可以通過它的 Status 看到整個集群的狀態信息，比如各個節點的端口、角色、狀態、版本號、各個特性開關的開啟狀態等等。Kston

164、e 平臺的第二個核心是 CRD EtcdInspection 巡檢資源，每新增一個巡檢特性就會生成對應的巡檢CRD。當開啟巡檢后，用戶就可以巡檢視圖面板，看到集群里各個巡檢特性生成的 metrics 等內容，方便定位問題。85騰訊云技術實踐精選集Kstone 平臺的遷移任務實現是通過 EtcdMigration CRD 來實現的。此 CRD 描述了遷移的源集群、目的集群信息，同時實現了支持多種算法的 Provider，最重要的是它還支持多種數據一致性的檢測策略。通過多維度數據一致性，應用層和 etcd 層會做 double check 來保證數據的萬無一失。最后，針對 Kubernetes 場

165、景遷移 etcd 導致的 client list-watch hang 住問題（遷移后的 etcd 版本號 Kube-apiserver resource version 小于原有 etcd)，我們修改了 Kubernetes 版本源碼，增加 watch 操作的 timeout 機制。Kstone 備份方面分為冷備和熱備。冷備方面，kstone平臺基于社區開源的 etcd-backup operator 擴展開發，支持分鐘級的備份到 COS 等對象存儲。熱備有幾種方案，比如可以基于 etcd 本身的跨城部署。它的缺點非常明顯，當幾個節點在不同城市，任何讀寫請求都需要涉及到兩城網絡訪問，所以讀寫

166、性能會非常差，但優點就是部署運維都非常簡單。另一個方案是社區提供的 make-mirror，核心原理就是同步服務。它在啟動的時候會從原 etcd 把所有數據從 get 接口讀出來，再獲取版本號，通過 Watch 指定對應的版本號，并監聽源集群后續新增的事件，如果有新的事件就會同步給目的集群。它核心的最大缺陷是無法保證數據一致性，還缺少數據性一致性檢測、日志、Metrics 等一系列特性，不具備生產環節可用的標準。第三個方案是 etcd 自帶的 learner，優點也是部署非常簡單，無需維護額外的組件。它也可以同步任意類型數據。它最大的缺點是當主機故障之后，沒法快速將 learner 馬上提升成

167、獨立可寫 etcd 集群，同時它依賴高版本的 etcd。方案四和方案五騰訊云自研的。方案四是 mirror-plus 版本，針對 make-mirror 做了一系列特性加強，比86騰訊云技術實踐精選集如支持斷點續存、全量同步，這樣不用再擔憂專線、公網抖動。最重要的是它自帶了多種一致性檢測，像存量檢測、快照檢測，可以實時看到哪些數據可能是不一致的。有了這一系列機制之后，即便原集群出現了中斷，也可以通過監控系統看到當前差異量多大，能否做多活切換等等。方案五的原理和 learner 類似。etcd 同步服務會偽裝成 learner 的角色加入原集群，解析 Raft 日志條目，從 Raft 日志條目解

168、析對應的讀寫請求，再轉發給目的集群。方案五缺點就是需要一定的開發時間。也需要對 etcd 有足夠的了解。為提升穩定性，騰訊云 etcd 還實現了一個核心的特性是 etcd QoS。它主要由兩大模塊組成，一個是 qos class，描述整個集群有哪些限速器，比如它支持 TokenBucketFilter，也支持 LeakyBucketFilter。用戶可以通過簡單命令加限速器名稱，指定對應的限速器類型。第二個是 QoSRule。這個模塊可以指定限速對象、請求的 key、請求的操作類型、db 使用率、請求掃描的 key 數等，在 Kubernetes event 等場景可以顯著提升集群穩定性。Ku

169、bernetes master 組件治理介紹完騰訊云 etcd 實踐后，再從整體介紹下騰訊云 Kubernetes master 組件治理實踐。騰訊云有兩種集群管理模式，一種是托管集群，它的 Kube-apiserver、etcd 組件全都是部署在騰訊云自己87騰訊云技術實踐精選集的 VPC 下，不需要用戶管理，適合于中小型客戶。第二種是獨立集群，Kube-apiserver、etcd 都在用戶自己的 VPC 下。Kubernetes master 組件治理有三類難點：如何通過一套系統來管理數萬集群的創建問題；如何實現按需擴縮容，實現成本與高可用的平衡；如何簡化運維復雜度，高效運維。針對大規模

170、集群組件的管理問題，騰訊云借鑒了 Kubernetes 本身的思想。既然 Kubernetes 提供了完善發布、自動擴收容和監控能力，完全可以用 Kubernetes 自己來管理 Kubernetes 組件。騰訊云利用 Kubernetes CRD 編寫了 master-operator 組件，創建對應的 Kube-apiserver、控制器、調度器，通過聲明式 API 幫助解決了一致性的問題。在這種場景中，控制面集群叫 MetaCluster，它會占用一個 namespace。這里有三個核心的控制面主線，第一是 master-operator，負責幾個控制面組件的創建；第二個是 tke-op

171、erator，負責一系列 add-on 組件創建；第三個是 autopilot-operator，負責集群的自動擴縮容、節點安全下線等自動化運維操作。這里每個集群都會占一個 namespace，用戶集群的 kube-apiserver 控制器都會以 deployment 形式部署在里面。針對高可用和成本優化問題，騰訊云做了畫像服務，它的架構如上圖所示。它主要有兩個組件，第一個88騰訊云技術實踐精選集是 workload-controller，負責 deployment、statefulset 等負載類型的畫像 CRD 生成。第二個組件是 workload-recommender，基于 VPA

172、擴展開發，它支持多種推薦算法，并且各個 workload 可以支持使用指定的算法。有了它就可以獲取各個組件的真實使用率情況。除了畫像服務，騰訊云還實現了上圖中的 autopilot 組件，通過它和畫像服務來實現集群各個組件的彈性擴縮容和節點安全下線（VPA+HPA+節點下線）。autopilot 的核心 CRD 資源是 ClusterScaler，它描述了各個集群里組件的擴縮容參數、比例，擴縮容觸發的事件源等。同時它支持多種 Scaler，如 CPU、內存、OOM 事件、集群大小等。其次它支持多種資源預估，一方面可以按照集群數大小來預估規格，另一方面可以按照推薦組件返回的資源大小來做預估，還可

173、以按照 OOM，集群配置等預估，最終會選取最大的給組件部署。最后，autopilot 還支持根因分析，通過根因分析模塊可以正確區分用戶的場景是否是合理的行為，如果是非合理的的行為，這時候是不可以進行擴容的。在節點縮容下線場景，騰訊云支持多種策略來獲取待縮容節點，比如低資源利用率、按標簽、按禁止調度，或者是指定的低版本的 Kubelet，這些都是可插件化的。另外 Pod Eviction Provider 也支持多種方式，如 Descheduler、Evict API、指定運維人工來操作等。最重要的是它支持 dry run 和限速，讓下線流程更加可控。用戶可以下發 CRD 看到當前這個策略會導致

174、哪些節點被縮容，會影響哪些 Pod。如果在縮容過程中發現這個 Pod 可用性會受影響，就會觸發一些擴容操作，實現安全穩定的縮容節點。89騰訊云技術實踐精選集保障穩定性經驗總結1.注意細節。墨菲定律意味著再小概率的事情都會發生，嚴重的事故往往有一小串被忽視的 bug 組成，無論是 etcd 還是 kube-apiserver 都需要一套巡檢機制去主動發現隱患、消滅故障的苗頭；2.注意數據安全和備份，同時需要機制去檢查備份是否成功、備份文件是否有效，一旦發生宕機等故障導致數據毀壞，備份是我們快速恢復業務的唯一希望；3.在設計系統的時候一定要考慮可擴展性，以及未來一些潛在的變化需求點。良好的擴展性可

175、以幫助顯著提高開發效率和集群的穩定性。更多內容可參考演講的 pdf 資料（https:/ kstone(https:/ star、fork,一起加入進來，提升 kstone 的各方面特性。在變更場景方面，騰訊云是基于 GitOps 來管理多產品、多地域、多環境、多版本、多種類型的組件。通過它可以實現一鍵開區、高效部署支撐集群和組件，可以大大減少人為的操作失誤。90騰訊云技術實踐精選集在 2021 年 ArchSummit 全球架構師峰會【深圳站】，騰訊云 CODING Nocalhost 研發負責人王煒帶來了Kubernetes 環境下極致開發體驗：實時熱加載和一鍵調試的主題分享，介紹如何使用

176、開源工具 Nocalhost 簡化 Kubernetes 環境下的應用開發，實現應用熱加載和一鍵 Debug，獲得秒級的編碼/調試/測試循環。Kubernetes 環境下極致開發體驗實時熱加載和一鍵調試王煒 騰訊云 CODING Nocalhost 研發負責人CODING DevOps 高級架構師，CNCF 大使，KubeCon 評審委員會成員，開源的云原生開發環境 Nocalhost 研發負責人，著有 Spinnaker 實戰：云原生多云環境的持續部署方案、Istio Handbook（作者之一），中國電子技術標準化研究院木蘭開源社區導師。91騰訊云技術實踐精選集K8s 環境開發困局與主流云

177、原生開發方式單體應用越來越大，會對組織架構以及協作形成挑戰，所以大部分團隊會采用微服務架構來拆分單體應用。微服務變多了之后，隨之而來又出現微服務環境差異、遷移等問題，這時候 Docker 為我們提供了很好的解決方案，有了很多 Docker 鏡像之后，這些鏡像在運行的時候還需要編排的能力，K8s 的出現為我們提供了完善的編排解決方案，目前已經幾乎成為了容器編排的事實標準。但 K8s 這套系統主要是面向運維提供能力，對于開發人員來說很容易造成困惑。同時它在開發和調試應用時會變得很困難，不可能像本地開發一樣能夠使用自己的 id 很方便地調試、打斷點。除此之外，云原生的技術體系遠比普通開發人員想象的要

178、大很多。云原生項目數以百計，完全不是原來傳統單體應用開發的知識架構和體系。雖然 CNCF 在云原生開發工具上有社區實踐，但事實上，目前社區還沒有很好地解決云原生環境下大部分場景的開發問題的實踐，這也導致每一家公司可能采用的技術?；蛘唛_發方式差異巨大。目前主流的云原生開發方式有四種：第一種是全手動的方式。在本地編碼之后，本地執行 Docker Build、Docker Tag、Docker Push，然后再執行 Kubectl 編輯更新工作負載的鏡像版本。這個流程是最慢的，每一次查看編碼效果大概需要十分鐘左右，一天可能有一半的時間在等待構建的過程。第二種是全自動化的流程，引入 CICD 流水線。

179、不過它仍然改變不了每一次編碼之后都需要重新構建鏡像的問題。第三種是借助網絡打通工具來打通本地和遠端集群的網絡，從而在本地運行源碼。一款較流行的工具叫 Telepresence，但它還是不能全盤解決問題。第四種和第三種差不多，是用云上的 K8s 集群結合 Telepresence 這款工具來做開發。92騰訊云技術實踐精選集Telepresence 背后基于網絡打通的開發方式局限性是非常明顯的，主要有三點：環境差異：工作負載聲明了 env、configmap、secret、volume 等，很難在本地復制出完全一致的環境；跨平臺差異：即便能夠將遠端的 env、configmap 掛載到本地，也難以

180、屏蔽跨平臺之間的差異；網絡限制：全量代理會使網絡拓撲產生變化，導致內網、公網訪問無法達到預期。要在 K8s 環境下獲得像本地開發一樣的體驗，主要需要解決兩個問題：本地編碼實時生效以及復用集群網絡。它們總結為一項技術，叫容器的應用熱加載，也就是騰訊云 Nocalhost 這款產品所實現的目標。容器應用熱加載原理在 Dockerfile 里會聲明 CMD 或者是 ENTRYPOINT 來告訴容器啟動的時候要執行什么命令。聲明后啟動容器，會發現聲明的進程在容器里就是 PID=1 的進程。如果能把 Dockerfile 里 PID=1 的進程替換成用源碼的方式運行，就可以實現容器的應用熱加載。構建鏡像

181、的時候，原來它是二進制的可執行文件，但是在真正需要開發的時候把它替換成以源碼的方式運行，源碼又可以編輯，就相當于實現了在容器里隨時啟停、更新業務進程。93騰訊云技術實踐精選集不過在真正實現我們的思路時還缺兩個條件。首先，Dockerfile 里只會復制二進制文件，大部分情況下，對于編譯型的語言來說是沒有源碼的。第二，編譯環境在常規的業務鏡像里是不會有的。因為業務鏡像會有一系列安全、大小要求，會要求不安裝這些，在生產上沒有必要運行的工具。要解決源碼來源的問題，可以從本地同步源碼到遠端容器里。解決編譯環境的問題，則可以把正常的業務鏡像替換為開發鏡像，用來提供語言的編譯環境。解決這兩個問題之后，最終

182、便能夠實現本地編碼后容器內實時同步，在容器內以新的代碼啟動業務，即實現了容器應用熱加載。Nocalhost 是開源產品，實現的核心原理就是本地和容器的代碼同步以及替換業務鏡像為開發鏡像。Nocalhost 由兩個端組成：Server 端：面向管理者，可選組件。高度集中管理的開發環境、開發者、應用、開發集群等開發資源，例如實現開發者間環境隔離；IDE 插件：面向一線開發人員。開發過程無需重構鏡像，本地編碼實時生效，縮短開發-調試-測試的循環反饋，提高開發和調試效率。Nocalhost Server 提供了整體的環境管理解決方案。它主要有兩個能力，第一個是可以隔離所有開發者的開發環境。它是基于 K

183、8s Namespace 來實現的，可以為團隊里面的開發者分配 Namespace 來進行環境隔離。第二個是統一管理所有的開發資源，比如集群、應用等等。Nocalhost IDE 插件主要為一線開發人員提供編碼的實時熱加載以及一鍵調試功能，支持 VScode 和 Jetbrains 全系列，幾乎覆蓋了所有 IDE 編輯器類型。Nocalhost 開發和調試演示以一套圖書管理系統為例，它是由五種不同語言編寫的微服務組成的。不同區域是由不同的微服務輸出的內容。94騰訊云技術實踐精選集假設現在有個需求，需要改 Bookinfo Authors 里的作者信息。這里有個細節，雖然訪問的是 127，但事實

184、上訪問的是遠端集群，因為后面已經做了自動端口轉發。Details、Reviews、Authors 這些服務都是由不同的微服務輸出的。假設要改 Authors 服務里面的作者信息，對于傳統的修改方法來說，要打開源碼，找到源碼地址，修改這段代碼，使用 Docker Build、Docker Tag 等一系列命令重新構建鏡像，并且使用 Kubectl 修改工作負載的鏡像版本，等待調度，最終才能看到編碼效果。在 Nocalhost 中可以直接找到 Authors 服務，右擊直接進入開發模式。進入開發模式之前需要選擇源碼來源，例如打開本地目錄，或者是從 Git 倉庫克隆，然后就正式進入開發模式了。進入開

185、發模式之后，Nocalhost 會自動替換工作負載鏡像為開發鏡像，然后打通網絡并且執行文件同步，同時自動用 IDE 打開源碼。進入開發模式之后，頁面下方會直接得到 Terminal。它是容器的 Terminal，不是本地的 Terminal，方便直接對容器的進行操作。接下來，只需要像本地開發一樣去修改代碼就可以了，這里我們以修改作者信息為例，修改完成之后，本地修改已經同步到容器內，現在只需在容器里啟動業務代碼(go build app.go)，再返回瀏覽器刷新頁面，會發現編碼已經實時生效了。95騰訊云技術實踐精選集對于編譯型語言，只需要在本地修改代碼之后，在容器里重新啟動進程就可以。對于像 P

186、ython 或者 PHP 這種腳本型的語言，甚至不需要重啟進程，本地編碼便可以實時生效。此外對于編譯型的語言，Nocalhost 還提供了熱加載功能，它和語言以及框架無關。仍然以 Authors 服務為例，右擊該服務并選擇 Remote Run 之后，Nocalhost 會自動在容器里運行業務，具體的運行命令是可以定制的。接下來只需像本地修改本地編碼一樣修改這段代碼，然后保存。保存之后會看到 Nocalhost 會自動地在容器里重啟這個業務進程，這一切都不需要開發人員干預，再返回瀏覽器查看，代碼修改已經生效。對于 Nocalhost 的一鍵調試功能，仍然以 Authors 服務為例。開發人員選

187、擇 Remote Debug 時，Nocalhost 將自動在容器里以調試模式啟動業務進程，調試命令也是可以定制的，Nocalhost 會自動打通遠端和本地的調試端口，以及控制 IDE 自動 Attach 到集群里需要開發的服務上的調試器上。接下來只需要在 IDE 里面正常打個斷點，返回瀏覽器刷新，可以看到斷點信息已經過來了。Nocalhost 右側菜單還提供了很多跟 K8s 相關的內容。這里就有個好處，開發同學人員使用 Nocalhost 時不需要學習很多 K8s 方面的基礎知識，因為右側的快捷菜單已經提供了查看日志、端口轉發以及打開服務終端等等一系列功能。從原理來講，Nocalhost 把

188、業務鏡像替換成開發鏡像。在容器里面以源碼的方式運行業務，可以直接繼承原來聲明的 Configmap、ENV 或者是掛載卷的。此外還會替換容器里的 PID=1 的進程為阻塞進程，防止容器因停止業務進程后 Crash。第二步是增加文件同步的 Sidecar，它和開發鏡像是解耦的，開發鏡像可以自己定制。第三步是在 IDE 里自動獲得遠端容器的 Terminal，這意味著所有的編碼操作、K8s 操作都可以在整個 IDE 里面形成閉環。對于管理人員來說，如果要在云原生的大背景下統一管理開發環境，Nocalhost Server 就可以很好地滿足這樣的管理訴求。它可以在 Server 端統一管理所有的用戶

189、、集群和定義 K8s 應用。除此之外，開發空間是基于 K8s Namespace 隔離的，不需要單獨幫開發者去操作 K8s 集群里的這些內容。96騰訊云技術實踐精選集Nocalhost 的開源共建與展望Nocalhost 是一款開源產品，也是免費產品。目前它在 GitHub 上有 1000 多個 Star，也是 CNCF Sandbox 項目，已經捐贈給社區了。展望未來，Nocalhost 對于開發環境來說會增加非常好的能力，叫休眠模式。系統可以自動識別用戶當前是不是在活躍，如果不活躍能自動進入休眠，把集群的 Nocalhost 或者開發空間里的工作負載的副本數調為零，讓它不占用任何計算資源。

190、這里還會增加自動喚醒功能，也就是在上班的時候可以自動地喚醒它，讓它重新具備開發空間的能力。第二個會增加的能力是 VCluster 虛擬集群，可以把它理解為是 K8s 的虛擬化，可以在 K8s 集群之上再新建集群出來。這對于某些集群的應用場景是非常有用的。因為有些應用在集群里面只能部署一套，而不同的開發人員來用的時候可能需要多套集群，這個時候資源消耗量很大，所以用 VCluster 可以解決。最后關于實踐建議，K8s 是聲明式的系統，所以如果能夠非常好地定義 K8s Manifest，就意味著有能力把開發環境定義出來。但事實上很多客戶在實踐的過程中是采用維護環境的方式，維護固定的幾套環境給開發人

191、員共用，有什么問題概不負責。而這種維護環境的方式目前來看不是很好的實踐。所以騰訊云推薦的實踐方式是定義環境，而不是維護環境。97騰訊云技術實踐精選集數據庫與存儲技術PART 0298騰訊云技術實踐精選集2019 年，Gartner 在一份報告中將 Serverless 選為最有潛力的云計算技術發展方向，稱其為云原生時代的必然發展趨勢之一。Serverless 從底層開始變革計算資源的形態，為軟件架構設計與應用服務部署帶來了新的設計思路。在各類 Serverless 應用中，數據庫的 Serverless 化被認為是頗具挑戰性的一大類別。曾幾何時，業內只有亞馬遜 AWS 發布了較為成功的 Ser

192、verless 數據庫產品。2020 年 4 月，騰訊云發布了國內第一款 Serverless 數據庫，填補了國內這一領域的市場空白，在數據庫市場獲得了大量關注與期待。為了讓更多 IT 從業者更深入了解騰訊云 Serverless 數據庫。在 2021 年 QCon 全球軟件開發大會【上海站】中，騰訊云數據庫高級工程師巫旭東發表了云原生 Serverless 數據庫的設計與實踐的主題演講，分享了騰訊云 Serverless 數據庫的誕生背景、設計理念與落地實踐。云原生 Serverless 數據庫的設計與實踐巫旭東 騰訊云數據庫高級工程師10 年互聯網研發經驗，2018 年加入騰訊后開始負責騰

193、訊云原生數據庫 TDSQL-C MySQL 及 Serverless 數據庫的探索和研發。99騰訊云技術實踐精選集傳統數據庫常見問題與解決方案在 IT 行業，新概念的誕生與崛起往往是為了解決現有方案長期存在的問題和挑戰，Serverless 數據庫亦是如此。隨著行業快速向云原生架構轉型，傳統數據庫的一系列缺陷變得愈加突出，逐漸成為系統架構中不可忽視的瓶頸環節：1.業務系統轉向微服務架構后，由于每個微服務需要單獨搭配數據庫，當微服務比較多時，輕量化數據庫的數量也隨之增加，開發環境預發布與線上微服務的相乘結果將呈爆發式增長，其成本很容易陷入失控狀態；2.很多新服務上線時，很難準確預估其計算資源需求

194、，傳統的云端預付費模式容易導致資源購買過量和浪費；部分數據庫呈現平時低頻，短時高頻的訪問特征，傳統模式不僅會造成浪費，還很難及時完成資源擴容，帶來業務損失；3.傳統數據庫的存儲與計算在同一臺服務器上完成，當用戶存儲與計算需求不匹配時，傳統購買模式會大幅增加擴容成本；4.服務數據庫容量可能超過單機上限。當業務早期沒有準備好分布式能力，或需要開發分布式事務時，傳統數據庫的這一瓶頸會對業務產生較大沖擊。之所以傳統數據庫會遇到上述問題，最主要原因在于其計算層與存儲層耦合于同一臺服務器上，很難靈活分配資源。傳統數據庫缺乏自治能力，用戶尚不清楚數據庫服務負載時就要先購買固定的計算與存儲能力；當服務器負載升

195、高時，數據庫無法自行感知資源不足情況并進行應對。與此同時，數據庫主機的計算與存儲資源比例固定，售賣時只能遵循這一固定比例，多余成本需要用戶買單。另外，傳統數據庫的擴容依賴人工響應，跨機遷移速度非常緩慢。最后，單機存儲上限大大限制了傳統數據庫的水平擴展能力。針對上述問題，行業提出了一些針對性的設計理念。例如成本問題可以通過按量計費模式解決，資源預估問題和低頻服務需求可以通過自治能力、自動擴縮容來處理。存儲池化概念能夠突破單機存儲能力瓶頸，實現動態擴縮容。100騰訊云技術實踐精選集Serverless 數據庫架構與設計理念騰訊云Serverless數據庫就是基于上述理念打造而成的新一代云原生數據庫

196、。這款數據庫的架構基石就是“存算分離”，所有計算節點共享同一份存儲層數據。對于用戶來說，不管在集群里購買多少計算節點，都只需要一份存儲資源。計算與存儲分離在不同機器上，就需要網絡 IO 來交換數據。若使用傳統的網絡 IO 技術，數據庫的計算與存儲節點交互的日志會非常龐大，且延遲很明顯。所以騰訊云自研了 Txstore 分布式存儲內核，將所有日志統一到了 redolog 的功能上。TXstore 會接收發送過來的 redolog，這樣既能把計算與存儲剝離開，又可以達到最高性能。在 Serverless 數據庫的自動駕駛架構中，分為五個層次用戶、管控、數據流、計算和存儲。用戶層就是控制臺的一些模塊

197、。管控模塊分為兩個部分，其一負責管控計算模塊的分配、回收、暫停操作。其二是副駕駛決策模塊，負責實時采集計算模塊的當前負載，根據實時負載及之前分配的計算節點資源來做評估；如果當前分配的資源不足以處理當前的負載，該模塊會向管控模塊發起擴容請求；如果計算節點負載較低，分配的資源有冗余，決策模塊會發起收容請求。極端情況下某些計算節點可能完全沒有負載。例如共享充電寶一般放在商場里面，商場晚上 10 點后就關門了，這時充電寶不會發來請求。如果數據庫還在運行，資源就會浪費一整夜。此時系統發現數據庫超過十分鐘沒有任何新連接，就會回收計算資源。但存儲資源是有狀態的，不會回收。到早上 10 點商場開門了，用戶進來

198、掃充電寶，其客戶端就會向集群的 proxy 發出連接請求。此時 proxy 發現計算節點不在，就會向管綜合來看，新一代數據庫需要做到：第一，計算與存儲分離，不再受限于某一臺服務器的計算與存儲資源；第二，實現服務自治，能夠自動計算服務器負載，實現資源動態擴縮容。綜合來看，新一代數據庫需要做到：第一，計算與存儲分離，不再受限于某一臺服務器的計算與存儲資源；第二，實現服務自治，能夠自動計算服務器負載，實現資源動態擴縮容。101騰訊云技術實踐精選集騰訊云 Serverless 數據庫的存儲池化架構是核心要素之一。傳統架構使用的是母機概念。上圖中的三個母機，藍色部分是計算資源，綠色加紅色是存儲模塊，其中

199、紅色是已經使用的模塊。母機是格式化分配，必須要對計算與存儲做相應比例的分配。綠色的模塊沒有使用，但用戶也要付費；沒有使用的空間都是預付費的能力，必須提前付費。且傳統架構中增加計算資源時，用戶必須要重新購買完整的計算與存儲母機，就可能為多余的存儲成本買單。在存算分離架構中 Master 跟 Slave 共享同一份存儲，存儲是按照 shard 分片這一最小單元做分配，每個分片固定為 2G。如果數據庫只用到 10G 的數據就只需要為 10G 付費，用到 11G 就只需為 12G 空間買單。并且因為存儲是分布式，容量不受單機存儲限制，最大可達 128T。存儲池化涉及路由表的概念。存儲池的實際物理存儲單

200、元 page 為 16K，每個 page 有自己的編號。一批 page 的集合就是 shard，其地址都會存在 DBMaster 模塊里。讀寫請求需要找到 page 時，系統找到 page 后計算得到分片號，基于分片號通過路由表找到物理位置；再計算 page 在 shard 上的偏移量，有了物理地址和偏移量可以做 page 尋址，完成一次讀寫請求的數據查找。下面是關于計算自治部分，首先是擴縮容場景?？啬K發起請求，請它喚醒計算節點。管控模塊會重新拉起計算節點，并通過路由表來關聯存儲節點。之后 proxy 發現計算節點已經拉起，會把連接重新打給計算節點。這就是數據庫具備的，從啟動到暫停再到啟動的

201、完整自動駕駛能力。102騰訊云技術實踐精選集數據庫啟動時，首先需要用戶主動填寫期望的數據庫最小與最大規格。因為有些用戶對成本比較敏感，不希望數據庫無限擴容，希望到一定的階段就停止；還有用戶希望數據庫啟動時最小規格保持在較高水平。為此騰訊云提供了一些規格列表供選擇。擴縮容時，CPU 容量不限于數據庫當前使用的數量，數據庫啟動時可以使用的 CPU 上限是規格最大的上限。因為如果系統限制用戶的 CPU 數量，那么超過限制值時性能就會下降；但擴容本身有一定延遲，在 30 秒左右，也就是說決策模塊發現業務使用的 CPU 數量超過當前的規格限制 30 秒之后才會擴容。所以騰訊云決定 CPU 數量不受當前使

202、用數量限制，并承擔 30 秒以內的多余成本，因此用戶側是無感知的。與 CPU 相比，內存是有參數限制的。數據庫的內存使用上漲后不會自動縮容，必須有參數動態限制數據庫的內存。另一方面，當用戶實際使用的 CPU 超過了當前計費值 30 秒后，系統就會向下一個規格擴容，例如從 0.25 擴容到 0.5、1 核，從而實現服務靈活自治，實際性能不受計費規格限制，且超出部分由廠商買單。但這樣一來單臺服務器可能擴容到超過主機資源上限，出現母機資源超載問題。解決母機超載問題就需要跨機遷移。這里的算法假設母機的所有計算資源總量是 S，當前母機上所有實例規格總規格是 M，擴容后規格計做 N。當 M 加 N 大于等

203、于 S，意味著一臺母機的計算資源不夠用了。這時存儲是足夠的，只需遷移計算節點，需要新找一臺機器拉起計算節點，初始化表結構。此過程可以在兩秒內完成，相比傳統架構的遷移耗時（可達數十小時）有巨大飛躍。關于計算節點的暫停與冷啟動方面，當某個實例連續十分鐘沒有連接時，系統算法會將其回收，進入“暫停中”103騰訊云技術實踐精選集狀態?？蛻舳嗽侔l起連接請求時不會直接打到實例上，而是會打到 proxy 上。后者發現數據庫暫停，就會發起喚醒請求到管控模塊，管控模塊拉起 Serverless 的計算節點。從 proxy 發起喚醒到計算節點被拉起的時間就是冷啟動時間。傳統數據庫的冷啟動必須要加載所有存儲數據，時間

204、非常漫長。但 Serverless 數據庫只需要處理計算節點，只需加載路由表，所以啟動速度非?？?，可以優化到 1.6 秒到 2 秒。冷啟動完成后，proxy 會正常向 Serverless 數據庫發起連接請求，成功連接客戶端并進行正常的讀寫操作。上圖是 Serverless 數據庫按量計費方案，其計算計費單位是 CCU。系統每秒鐘在母機上采集 CPU 當前值和五秒前的值，做減法除以 5 就得到每一秒平均 CPU；內存與存儲的使用量每秒上報。這樣 Serverless 的指標可以做到秒級采集。最終計費的單元是 CCU 和存儲，這兩個指標按小時上報扣費系統，給用戶看到按照小時計費的帳單。Serve

205、rless 數據庫落地場景騰訊云 Serverless 數據庫已上線 10 月左右，用戶量累計較多。其中較典型的應用場景是同騰訊云開發的深度合作。很多小程序開發者的云服務托管在騰訊云開發上，后者與 Serverless 數據庫做了深入耦合。一些云開發用戶對成本和業務性能非常敏感，過去他們會報告數據庫成本非常高，現在得到了明顯的成本下降效果。騰訊云函數也是 Serverless 數據庫比較早的實踐者。云函數將代碼托管到容器里，當用戶使用時拉起容器，不使用的時候把容器關掉，以提供無服務化的產品。過去計算節點在不提供服務時也會收費，而 Serverless 數據庫就填補了這塊拼圖。104騰訊云技術實

206、踐精選集上圖是實際使用中的效果展示?？梢钥吹阶笊辖堑腃PU使用核數與右上角的CCU呈現比較完整的耦合狀態，CPU 用量增加，CCU 也跟著漲了上來；10點16分 CPU 降下來的時候，CCU也會按照預期一半一半往下縮。監控管理方面，騰訊云 Serverless 數據庫與智能管家做了一些深度合作的監控管理，可以從不同的維度監控數據庫。其中包括一些 SQL 預防操作，系統感知風險后會給用戶提供操作建議。性能分析模塊發現數據庫的 CPU 或者內存出現瓶頸，會建議把最大規格再調大一點。數據庫的告警機制也比較完善，可以支持 70多個監控指標的告警。此外還有問題快速定位，可以給用戶提出一些比較好的處理建議

207、、分析復盤和優化建議。105騰訊云技術實踐精選集總結 回顧歷史，可以看到數據庫技術經歷了四個時代。最早是自建時代，開發者在購買服務器自建數據庫。這個時代的數據庫和硬件生命周期完全綁定，且運維方式比較原始。第二個是 paas 租用數據庫的時代，出現了一些運維層面的改進，且節省了硬件購買成本，但因為存算一體化所以資源彈性比較差。接下來是云原生數據庫時代，做到了存算分離，所以資源彈性有大幅改善，可以高效擴縮容。但這一代數據庫沒有自治能力，所以騰訊云在云原生數據庫的基礎上進一步設計了第四代 Serverless 數據庫，完美利用了存算分離特性。第四代數據庫可以進一步提升資源彈性，可以做到純粹按量計費，

208、且服務更加自治，有了秒級擴縮容，服務更加穩定。106騰訊云技術實踐精選集TDSQL 是騰訊云旗下金融級分布式數據庫產品，具備強一致高可用、全球部署架構、分布式水平擴展、高性能、HTAP 雙引擎、Oracle 兼容、企業級安全、便捷易運維等特性，目前金融核心系統客戶已超過 20 家，尤其在銀行傳統核心系統領域，位居國內第一陣營?？蛻艉w多家國有大行，及平安銀行、張家港銀行、昆山農商行等頭部銀行及廣泛金融行業機構。本期為大家帶來騰訊云數據庫專家工程師唐彥主題為 企業級分布式數據庫 TDSQL 元數據管控與集群調度的分享。以下是分享實錄：企業級分布式數據庫 TDSQL 元數據管控 與集群調度唐彥 騰

209、訊云數據庫專家工程師唐彥博士的研究領域主要集中于分布式存儲、大規模數據密集型系統的關鍵技術。他以第一作者的身份在領域 Top 類期刊和會議上發表多篇論文。目前在騰訊主要負責分布式數據庫 TDSQL 的元數據管理與集群管控調度的相關工作。107騰訊云技術實踐精選集TDSQL 架構介紹TDSQL 的全稱為 TencentDatabaseSQL。下圖是 TDSQL 的最新技術架構，它描繪了一個計算/存儲分離、數據面/管控面分離的高可用的原生分布式架構的關系型數據庫。TDSQL 分為三層：綠色部分是計算層，稱之為 SQLEngine；紫色部分是管控層，簡稱為 MC，負責整個集群的管控調度工作；藍色部分

210、是存儲層，稱為 TDStore。TDSQL 架構三個重要的特性：全分布式，無論在計算層還是管控層，每一層都是分布式的架構；計算與存儲分離；可實現動態可擴展功能特性。TDSQL 的四個主要功能特點分別是：高度兼容 MySQL。TDSQL 對單機遷移過來的業務，兼容度高達 100%，能夠實現無感知遷移。高可擴展性。在存儲層和計算層，用戶只需手動在管理界面上添加一個存儲節點或計算節點，后續內部的管控機制會自洽地完成整個流程。支持原生 Online DDL，可多寫架構下以原生方式實現 Online DDL。全局讀一致性。TDMetaCluster 統一分配全局唯一遞增事務時間戳，實現金融級場景下的數據

211、強一致。108騰訊云技術實踐精選集分布式架構主要分為計算層、存儲層和管控層。首先是計算層。TDSQL 計算層最大的特點是多主架構，每個節點都支持讀寫，完全相互獨立；每個計算節點為無狀態，具備擴容優勢，可實現 MySQL 的高度兼容，具備無狀態化的彈性擴容的架構特性。其次是存儲層。它是我們自研的 KV 存儲引擎。在存儲層和計算層的交互中，存儲層承擔事務協調者的角色。我們以一定方式將數據打散到每個存儲節點上，每個數據分片稱為 Region。存儲層對所有數據的狀態自身無感知，只負責數據的讀寫，所有數據的調度都由它與 MC 的交互來進行。109騰訊云技術實踐精選集最后是管控層。它是一個分布式的集群，以

212、 N 倍的方式去部署。在整個集群中，它要同時承擔管控層面和數據層面的工作。比如在數據層面，MC 負責一個全局、一個中心的嚴格遞增，是唯一的分配者角色，且同時負責管理所有的計算節點、存儲節點的元數據、MDL 鎖。以下是數據庫中常見的主功能流程：分布式事務。數據庫的訪問是天然的分布式事務。整體流程為：從 MySQL 客戶端發送請求，通過計算層對存儲層進行讀寫，讀寫過程中，存儲層和計算層都會去和 MC 交互，獲取時間戳，最終確定每個事務之間的偏序關系，完成整個流程。110騰訊云技術實踐精選集無感知擴縮容。當存儲空間不夠時就需要擴容。在擴容過程中，必然會涉及到數據的搬遷。如下圖例子所示，整個集群中只有

213、一個存儲節點，當需要擴容時，可以在界面上點擊多購買一個存儲節點。此時存儲節點上數據的分裂搬遷、計算層對最終數據路由的感知、計算層感知路由的變化后完成的重試等過程可以完全自洽地包含在整個數據庫體系中，實現業務層無感知。Online DDL。TDSQL 的分布式體系架構采用多寫架構。為達到更好的并發性能，需要在多寫的架構下，實現 Online DDL。相較同類產品，當業務嘗試在運行過程中加一列、加一個索引時，需要借助外部的工具，及堵塞業務來完成 DDL 的操作。為了更好的用戶體驗，降低對業務的影響，通過 TDSQL 可以把多寫架構下的 DDL 以原生方式去完成。111騰訊云技術實踐精選集TDSQL

214、 在分布式場景下的挑戰TDSQL 架構的三大功能特性：原生分布式，全部都是分布式，沒有中心節點管控。存算分離，計算跟存儲完全分離，不在一個服務器上。數據跟管控完全分離，數據層面完全不參與數據管理。首先是高性能方面的挑戰。在架構上，要做到分布式的完全存算分離的架構，MC 作 為 集 群 內 唯一一個中心的管控模塊，必須承擔全局授時源角色。這些特性直接、簡單，卻在工程落地時遇到諸多挑戰，主要是高性能、高可用、復雜調度三個方面。下面將著重分享我們在高性能、復雜調度方面遇到的挑戰。112騰訊云技術實踐精選集在復雜調度層面。我們設計成數據和管控完全分離的架構，數據完全存儲在TDStore上，只負責數據流

215、的讀寫。其他工作完全交由管控層去進行，MC 只需要監控整個集群的狀態做出關于存儲資源的決策。在分布式事務的整體架構圖中，可以了解到 MC 在事務過程中需要和存儲層做網絡交互，提供時間戳，這是關鍵路徑。同時 TDSQL 的計算層和存儲層都可以靈活擴縮容。存算分離、高擴展的兩個特性也意味著 MC必須要具有非常高的性能。113騰訊云技術實踐精選集TDSQL 在集群管控的探索與實踐高性能方面的探索與實踐在高性能方面，我們采用非常經典的三段式協程架構，即一個協程收、處理、最后再發。這種架構在我們突破 60 萬時就達到性能瓶頸。通過性能分析，我們意識到性能瓶頸集中在第二個協程里。于是我們將出現瓶頸的地方并

216、行化。但第二個協程增加到一定時，下個瓶頸又出現，因為協程 1 是單管道模式，新的瓶頸點集中在協程 1。我們在下個版本里做了一個略微復雜的 N 對 N 架構，也是多協程架構?；诖宋覀儼l現性能可以提升但 CPU 的消耗非常大。我們的設計目標是 MC 在性能方面有較強的表現，其性能數據能到達 500 萬。但當時盡管達到 75 核，數據還是停留在 320 萬。我們對此進行 perf 分析，發現問題主要來自 RPC 解析，因為 MC 主要網絡框架的實現是基于 GRPC 的網絡通訊，會有比較大的頭部序列化和反序列化的性能開銷。114騰訊云技術實踐精選集已知性能阻礙存在于網絡框架，我們優化的目標就成為擺脫

217、網絡框架帶來的性能限制。對此我們給時間戳的獲取開發了 TCP ROW Socket 通道。因為時間戳數據結構有一個天然優勢，即請求無狀態、無依賴，只包含兩三個整型字段。這時在網絡上發來的任何請求，MC 只需要收到一個，回答一個，可以去定制化完成請求。在棄用該框架后，性能提升飛快，在比較低的 CPU 開端的情況下，可以將性能提升到 450 萬。但在后續過程中，我們發現瓶頸出現在請求進隊列還有請求出隊列的過程中。我們使用 Go Channel 作為消息的進出隊列載體，Channel 雖然好用且輕量，但底層依舊帶鎖實現，push/pull 操作存在著百納秒級別的開銷。對此我們計劃實現無鎖隊列，需要實

218、現單生產者、單消費者模式的場景?；谶@種場景，我們實現一個簡單的信號量，作為兩者之間的喚醒機制。使用該優化方案后，資源的消耗明顯降低且達到更高的性能，峰值吞吐突破 750 萬。115騰訊云技術實踐精選集最初 500 萬的目標雖已完成，但我們團隊仍認為性能數據還可以更好。以下為經典的 CPU 緩存的 MESI 狀態轉換圖。一行 CPU 的 Cache Line 可以容納 64 個字節，在我們的數據結構中，將其中多個 8 字節的變量放在同一個緩存，如果一個更新非常多，另一個更新的少，就會影響另一個原子變量的讀寫。從圖片右邊可知，在這里把變量的 8 字節對齊后，就解決 CPU 緩存行的問題，性能數據

219、也從 750 萬上升至 920 萬。此時我們的目標是實現單中心的千萬級別的性能數據。為了進一步實現單中心的千萬級別的性能數據，我們從業務場景進一步深挖。在整個集群中，MC 在時間戳方面是單一的提供者，而集群中眾多的計算節點和存儲節點會產生源源不斷的請求，因此在分析生產者和消費者速度時，我們發現生產者速度遠遠跟不上消費者速度。為此我們進行了簡單的改造，即來一批請求再消費一批時間戳，以批量請求方式去喚醒消費者。為了適應業務場景，我們還對該優化做了開關，運維人員可以根據業務場景的需求進行調節。執行批量化操作后，整體峰值已經提升至兩千萬，許多數據庫實例的業務場景都無法到達這種高壓力。116騰訊云技術實

220、踐精選集下圖為 TDSQL 原生數據庫下，我們通過一系列優化手段達到 2000 萬性能數據的過程。復雜調度方面的探索與實踐由于實現數據面與管控面的分離，MC 要負責整個集群所有跟資源相關的管控。如圖所示，圖中畫有 MC 的主要功能。MC 需要負責時間戳的提供，管理全局的唯一 ID 的分配、DDL 的協調、計算層管控層資源的元數據以及數據分片的管理。在管控層的不同層面，所有跟管理調度相關的工作都集中在 MC。117騰訊云技術實踐精選集為了實現復雜調度，我們首先劃分資源層級，制定可用的具有可擴展性的基礎框架，將 MC 模塊從管理任務中釋放。將每個資源層級必須劃分清楚，使得數據路徑上的所有模塊只需要

221、被動執行，不需要更新狀態。我們從集群層面、復制組層面和副本層面進行劃分，劃分出許多子狀態及子步驟。比如在擴容過程中，有一個數據分片，副本分布在 123 三個存儲節點中，如果要進行數據遷移使得一主兩備變為 1234 分布，任意時刻這四個節點都知道自己要做的原子子步驟，整個遷移過程實現零感知。遷移過程包含五個原子子步驟：先在節點 4 上創建新部分，再將新部分加入到原本的數據復制同步組中，去掉的副本的狀態設置為 offline，最后再把該副本刪除。在分布式數據庫中隨時可能有節點掛掉，但通過步驟劃分，無論是 MC 掛掉還是 TDStore 掛掉，節點拉起來后都知道要如何操作。通過這樣的機制，存儲層對每

222、個任務的推進或回滾完全無感知，全部由 MC 來做協調。118騰訊云技術實踐精選集該機制主要有以下三方面的效果：首先是性能。該機制對性能提升的促進非常顯著，在集群比較大時可以輕松支持 EB 級存儲。比如在 500 萬數據分片的量級下，MC 用 20 個核就能完全支持。通過數據狀態與調度狀態的分離，大大降低了 MC 負載。性能上的收益還體現在存儲層上。在任意時刻它只需要接收到一個原子步驟即可。因此在代碼層面，存儲層不需要任何關注數據資源狀態的代碼，更有利于進行性能優化。其次是健壯性。每個任務都是有限的狀態機，任意一個參與者，如管控或存儲，出現交互中斷，都能夠以確定方式進行任務的回滾或恢復。最后是可

223、擴展性。每個管控任務分為多個原子步驟進行，有利于以插件式方式去定義其他更多更復雜的任務。整個過程中只需要將原子步驟拼裝組合，MC 就可以實現復雜調度。119騰訊云技術實踐精選集數據分布方面的探索與實踐原始版本中，MC 對數據分布管理只有物理位置概念，基于擴展引擎和分布式協議打造的 KV 存儲引擎，數據分片在整個分布式存儲集群中按照主鍵從空到正無窮的字符序來進行分布。比如創建表或二級索引時，如果要表達成 KV 形式，主鍵和二級索引都有對應的 ID。存儲層中以 Key 區間代表一個數據分片，如 01-02數據分片，落在存儲節點 1 上，02-03 數據分片，落到存儲節點 2 上。這種情況下，同一張

224、表的數據的主鍵和二級索引會落在不同的 TDStore 上，這就會造成很大的負面影響。舉個例子，有一張表，每天有大量不同的流水寫入，有三億行數據，業務為方便查詢，做了 20 個索引。在最壞的情況下，20 個索引分別落在不同的 Region，又落在了不同的 TDStore。數據庫使用者從操作上更新了一行，但可能會發展成 20 個涉及到 60 個參與者的分布式事務，帶來 60 次同步的性能損耗。在這種情況下，我們針對經常出現的業務場景對兩階段提交進行優化，讓更多的提交變成一階段提交。我們設立表內數據的概念，每個數據在物理層面都可以知道每個 Key 落在哪個 TDStore，但無法感知到它們屬于哪個二

225、級索引。對此我們需要建立關系去創建表，使得在創建表和索引時，MC 可以感知到每個 Key 在物理意義上屬于哪個 TDStore，邏輯意義上屬于哪些表的分區、屬于哪些表的二級索引。我們還引入了復制組的概念。在原始版本中，每個數據分片是一個復制組，現在則是將多個 Region 歸屬于一個復制組，通過管控體系架構的改變，將表數據和二級索引放在同一復制組里。這種做法的好處有兩方面：一方面，業務中常常按照分區鍵來劃分事務，一次性修改的數據非常大，可能只落在同一復制組里，這時需要進行多次網絡交互才能完成一個分布式事務，優化后只需要一次落盤即可完成；另一方面的好處是計算下120騰訊云技術實踐精選集推，由于計

226、算層可以感知到要寫的主鍵、二級索引都在同一 TDStore 的同一復制組內，就可以提前將邏輯下推到存儲層中完成。接下來解決的問題是表與表之間的親和性。在部分系統中，以一定規則如哈希去分區的表結構中，在更新表1 分區時，也會去訪問表 2 的 1 分區。這就要求管控層必須理解表與表之間的概念。如果能感知到它們是在同一組事務里被操作的單位，就可以更好地改善事務的兩階段提交。對此我們提供了一個擴展語法。假如用戶有需求，可以去指定他所傾向的數據分布策略，為該策略命名，允許在該分布策略里再指定分區策略。如下圖所示，當下面第三行創建表時，如果有兩個表在業務場景中經常被訪問，就可以將它們關聯到同一 DP 組里

227、，MC 會在后臺創建表。所有的分布策略都會通過 MC 進行，MC 可以在后臺將這些關聯的表做背后的調度優化。這就為更多跨表之間的操作提供較多的可能性。121騰訊云技術實踐精選集Risk&Opportunity未來我們仍有許多挑戰需要克服。首先是全局事務時間戳，目前 MC 承擔許多的管控操作，后續我們計劃將其設計成多進程模式，全局事務時間戳獨占一個進程。其次是Lieutenant 分流，我們計劃增加副隊長角色，分流部分網絡。最后是數據親和調度的利用也是我們未來會去重點攻堅的領域。122騰訊云技術實踐精選集擁有二十余年歷史的 PostgreSQL 是世界上歷史最悠久、功能最強大的開源關系型數據庫之

228、一。隨著行業步入云原生時代，PostgreSQL 也隨之煥發了新的生機。PostgreSQL 與云原生架構的結合帶來了許多新的機遇與能力，是數據庫從業者非常關注的技術主題。在 2021年 QCon 全球軟件開發大會【上海站】中，來自騰訊云的數據庫高級工程師唐陽做了題為 TDSQL-C PostgreSQL 在云原生架構下的新活力的演講，分享了 PostgreSQL 在云原生架構下的設計思路、方法與實現細節和亮點，以及這兩者的結合在實踐中具備的特性優勢。TDSQL-C PostgreSQL 在云原生架構下的新活力唐陽 騰訊云數據庫高級工程師擁有 8 年豐富的數據庫運維管理經驗，主要負責騰訊云數據

229、庫 PostgreSQL 系列產品規劃與設計。123騰訊云技術實踐精選集傳統數據庫架構常見問題在實踐中，傳統數據庫架構經常面臨一些受制于技術特性難以解決的問題：首先是數據庫選型。某在線業務包含了用戶訂單、結算、交易等核心系統，但業務團隊人數有限，人員儲備不足，而對未來流量的預估規模較大，且規劃有分析類業務。面對這樣復雜而苛刻的要求，數據庫選型就成為了一大難題。第二個問題是備份。線上業務使用的數據庫數據量計 20TB。運維每次發版本需要備份，但每次備份都需要兩三天時間，導致運維痛苦不堪。第三個問題是擴容。某次運營活動效果絕佳，流量峰值超過預測峰值，需要緊急擴容，但傳統模式下，短時間無法完成大數據

230、量搬遷，錯過了活動高峰期帶來巨大損失。進一步分析上述問題可知：數據庫選型既要滿足現有在線業務，又要提供實時交易分析能力；數據量較大時需要分庫分表，進行分布式改造；數據庫要具備快速擴容能力；要具備快速備份/恢復能力。傳統數據庫架構存在的主要瓶頸是缺乏足夠彈性，因而性能大大受限，上述問題很難得到根本解決。云原生時代數據庫演進之路云原生時代，行業開始探索基于云原生的設計來實現云原生數據庫，解決傳統數據庫面臨的諸多問題。云計算的核心目標是解決彈性效率擴展與成本問題。傳統的云 PaaS 服務將線下的數據庫搬到了云上，基于124騰訊云技術實踐精選集原有的架構能力，將相關的運維操作做成了一系列功能供用戶直接

231、使用，但無法解決上述問題。隨著行業發展，新一代云原生數據庫開始充分利用云端優勢，基于云端來做核心定義與特性：計算節點可以任意調度，對數據庫的讀寫操作能立刻完成，無需先調整配置參數；任意調度，數據庫的狀態核心是數據，需要保證數據的一致性、可靠性。為了實現任意調度需要做到狀態分離，令計算節點只需少量狀態，甚至沒有狀態，隨用隨??；保證數據不丟失、數據完整、數據一致。狀態分離后需要使用日志提供保障，因此需要基于日志做持久化；保證擴容效率。通過數據分片大幅提升數據搬遷效率；通過存儲多副本保障數據可靠性；應用分離理念后，數據相關操作集中到數據存儲層本身，將備份與恢復相關的邏輯下沉到存儲層實現，提升效率與性

232、能的同時對用戶無感；數據庫相關操作都通過 API 控制；數據庫服務具備高可用性。為了實現上述目標，云原生數據庫實現了存算分離這項核心設計變革。存算分離概念有多種實踐方法，例如，數據庫部署在一臺服務器上，用另一臺服務器掛存儲協議過去也算是存算分離，但這種方法卻沒有分離狀態。真正的存算分離需要將重狀態的動作放在下層，對用戶無感，而上層實現需要對接數據庫實際需求，為此拋棄臟塊向磁盤刷新的動作，將查詢處理、事務管理與緩存相關功能放在計算層實現；在存儲層實現日志持久化、日志回放、備份恢復、數據頁校驗等動作就自然成為理想存算分離的一種實現方案。實現上述能力后，多個計算節點可以共享數據。為了在分離和不刷新臟

233、塊之后保證數據一致性，就需要穩定的日志系統。日志即數據庫理念是貫穿于整個云原生數據庫的設計核心。寫入數據時，傳統數據庫內核的常規模式是對變更數據事務生成一條記錄寫在日志中，再通過日志的寫進程寫入磁盤，之后向計算層報告寫入成功可以提交，事務就完成了。同時用戶更改了內存中的數據，使內存中的臟塊把變更動作寫入磁盤中，最終完成了整個數據庫的更新。云原生數據庫取消了刷盤動作。寫入數據的第一步，計算機發起動作把日志交給存儲層，告訴后者現在發起了變更要記錄下來。因為底層是分布式存儲，所以至少需要兩個存儲節點寫日志落盤成功。內存里的相應數據塊也會被寫入，并通過剛剛寫入到存儲中的日志使數據塊形成更新鏈，用戶讀取

234、時完成寫入操作。全部操125騰訊云技術實踐精選集當某個存儲節點或者多個存儲節點達到了設置的存儲閾值時，監控系統會自動看到磁盤不足的狀況，將有空閑的服務器加入到存儲集群。加入成功后，系統會自動將其他冗余節點中的數據拷貝到新服務器中，這就是整個存儲層的擴容邏輯。上述邏輯的核心是存儲層將用戶數據按照邏輯結構分成多個池，每個池按照實際情況分為多個段。所有的操作都是基于段來進行的，這樣可以避免超大文件復制緩慢的問題。遷移、復制等動作對用戶無感，讀取數據時是從節點讀取，會自動跳過正在復制的數據節點，從而將 IO 打散，避免 IO 爭搶等問題。得益于存算分離的架構，計算節點很容易添加。傳統架構擴容時會拉起從

235、庫，數據遷移完成后通過路由將流量重新打到新庫上，將其直接啟動為主庫，就完成了遷移動作。存算分離架構下也是同理，沒有任何區別的。但由于無需搬遷數據，主從切換過程對于用戶沒有感知，具備更高的可用性。備份恢復看似是數據庫的周邊功能，但確實是最重要的功能之一，并且在數據量較大的場景中是最不好做的。備份恢復分為邏輯備份與物理備份，邏輯備份是將數據的定義語句和插入語句全部提取出來生成文件，成本作都在存儲層執行，實現存算分離。這樣做的目的是減少 IO 操作。之前既要寫日志，又要寫數據；現在只寫日志，速度能夠大幅提升。數據讀取時與傳統模式區別不大，完成存算分離的設計后，存儲層是通過分布式存儲實現的。分布式存儲

236、是基于用戶態的存儲能力。存儲層的隔離通過用戶態實現，一個數據庫實例對應一個池，每一個池至少會被分成 3 份，不同的節點存儲數據。每個存儲節點通過 Raft 協議進行數據的復制。126騰訊云技術實踐精選集較大，所以一般場景下會做物理備份。物理備份操作需要讀取線上正在運行的庫，所以通常使用從庫備份，避免影響主庫。但備份速度受制于存儲大小，存儲越大，備份的速度越慢。為解決這個問題，分布式存儲引入多個副本，其中備份副本是可以讀取的數據。如前所述，底層存儲不會從內存中把數據塊寫到數據文件，而是從日志來恢復，恢復時也是同樣的機制，無需再轉換一次，直接將文件復制走即可。但數據一直變化的情況下，就要保證數據的

237、一致性。正常情況下，備份副本與其它數據副本是一樣的，需要發起備份操作時就停止日志恢復，這時數據一定是一致的，直接把備份副本文件復制走即可。這樣就不需要尋找數據文件的一致性點，同時復制備份副本的過程就是備份所需的全部過程。完成備份操作之后，日志恢復操作重新啟動，這里備份副本不是存儲層數據可靠性的核心依賴點，下一次備份操作發起時重復前述過程即可，由此一來，備份速度得到了數量級提升?；謴筒僮鞲唵?，只需將備份文件復制回來放回去即可。這是云原生存算分離架構的最大優勢之一，備份恢復操作可以輕松完成。最后一點，存儲層的粒度 Segment 很小，可以根據具體的業務或整體服務器的負載情況來靈活調整復制粒度，

238、避免實際業務訪問時出現峰值問題，相關動作還可以通過管控系統自動調配、自動地合理均衡。127騰訊云技術實踐精選集新活力在何處？PG 數據庫是全球最強大的開源數據庫，堪稱數據庫中的瑞士軍刀，PG 是一專多用的全棧式數據庫，有豐富的插件支持，幾乎能夠完成一切業務需求。PG 數據庫與云原生數據庫結合后，誕生了很多新的優勢與活力。云原生數據庫的設計通過架構，打破了傳統數據庫的一些壁壘限制，解決了彈性、備份、高可用相關的很多問題，將數據庫的能力真正意義上地釋放了出來。例如，PG 的存儲能力之前受制于服務器的規格，但與云原生結合后 PG 可以處理更大的數據量。同時 PG 是多進程架構，可以充分利用有大量 C

239、PU 核心的服務器，充分利用云端具備的計算資源。分布式存儲場景下可以實現分級存儲能力，可以根據數據冷熱特性，將不同類型的數據存儲在不同速度和成本的物理介質上，取得性能與成本的平衡。由于云原生架構的高彈性優勢，計算資源能夠靈活實時配合業務需求，業務有需求時迅速拉起計算節點，需求減少后就按需關閉，這樣就能充分利用計算資源。進一步來說，以高彈性為基礎，Serverless 數據庫就可以完美落地。云原生概念的誕生就是為了解決實際應用中的許多問題，基于云原生理念設計的數據庫，為用戶提供了更多選擇和能力，打開了更多可能性。128騰訊云技術實踐精選集目前，大多數應用程序都需要使用緩存對數據訪問進行加速，所以

240、“緩存+存儲”就成了一種常見的存儲架構。但引入緩存后，對業務開發、數據運維以及數據一致性等方面提供了新一輪的挑戰。企業該如何通過調整存儲結構滿足“緩存+存儲”的場景需求？又該如何基于低延遲、高吞吐、Redis 持久化等方面進行優化？在 2021 年 QCon 全球軟件開發大會【上海站】中，騰訊云數據庫專家工程師伍旭飛發表了“緩存+存儲”架構下 Redis 持久化的探索與實踐主題演講，并為大家分享了 Tendis 在高性能、低延遲、持久化方面的實踐經驗?！熬彺?存儲”架構下Redis 持久化的探索與實踐伍旭飛 騰訊云數據庫專家工程師10 余年互聯網開發經驗，2018 年加入騰訊云數據庫團隊，負責

241、 NOSQL 數據開發以及新硬件在 NOSQL 數據庫應用的探索。129騰訊云技術實踐精選集傳統緩存架構的挑戰移動互聯網時代高速發展，拓展了海量的用戶數，而用戶數的暴增也給業務帶來了高并發、低延遲以及非結構化數據呈指數級增長等難題。因此，高并發、大存儲、低延時就成為了亟需解決的問題。業務的競爭越來越大以后，就開始引入緩存，主要目的則是為了提高并發、降低延遲、解決熱點以及降低成本，但在傳統的緩存架構中，還會出現一致性問題、擊穿問題，雪崩問題以及大 key 問題。在傳統緩存架構中，也歷經了如下幾個階段：首先判斷能否命中，如果無法命中就讀取存儲，再更新緩存，最后返回數據；如果命中就直接返回數據。但在

242、這種情況下，擊穿問題仍舊比較明顯，比如在游戲開服時，由于都是新用戶，緩存無法命中一定會擊穿數據庫。此外，在并行更新時還會存在一致性問題以及大 Key 更新加載慢的問題。其次，演進到先更新/刪除緩存的架構，但在并行更新的場景下，依然會存在臟數據；隨后，又發展到了延遲雙刪的架構，先刪除緩存，延遲 N 秒后再次刪除緩存。但這個方案對于一致性的要求比較高，還是容易出問題：一方面，刪除失敗會導致臟數據，另一方面，雙刪會給存儲帶來額外的壓力。為此，又延伸出了第四種方案，即當刪除失敗后放入隊列中重試，但這個方案同樣存在問題，比如，大 hash/list/zset 從存儲加載到緩存的過程依然很慢，并且只能保證

243、最終一致性，無法保證強一致性。伍旭飛還在演講中提到，因為涉及成本問題，不可能把所有的緩存全部攢在內存里，所以一定要把緩存淘汰。130騰訊云技術實踐精選集業界的一次努力嘗試基于傳統緩存架構遇到的挑戰，騰訊云做了 Tendis 混存版，用以嘗試解決上述遇到的問題：它是利用改進版的 Redis 做緩存，然后用 Sink 組件部署在不同的機器上，同步在一個持久化的存儲 Tendis 上。具體來說，有兩個淘汰策略：第一個方案是 TTL 淘汰，即超過 TTL 指定的時間戳以后就過期淘汰，但這里存在的問題是，如果 TTL 設置不當會導致雪崩；第二個方案是緩存打滿被動淘汰 LRU/LFU，但依賴緩存打滿被動淘

244、汰，會導致性能變得很差，還會導致延遲抖動。但這個思路也存在幾個問題：Redis 緩存所有 Key 成本太高；異步情況下，一致性問題未解決；異步落冷導致性能抖動。所以，對于云數據庫來說，想用一個方案來滿足不同場景以及不同用戶的需求，其實是非常難的，很難做到一個比較完美的狀態。經過上一次的問題之后，我們也在思考次世代的數據庫應該怎么做？像 Mysql 這樣的數據庫，它主要適配以前的傳統硬件，但在今天這個時代，隨機讀寫依然比順序讀寫慢，但是差距已經大幅縮小。拿 NVME SSD 測試，4K 讀寫延遲低于 100 微秒，4K 隨機讀寫大于 10w+。AEP/BPS 新硬件的速度提升131騰訊云技術實踐

245、精選集了一個數量級，讀寫延遲在350納秒左右，4K 隨機讀的速度在600w左右，4K隨機寫的速度在200W左右。那么如何能在這樣的硬件設備下將其發揮出最大的優勢，我們也在想怎么在存儲引擎方面，給行業注入一些新鮮的血液。傳統的存儲引擎 RocksDB 是基于機械硬盤優化的，讀寫放大更明顯，適合多讀寫少的場景。因為它讀的時間不可控，Complication 抖動無法避免；SST 文件內的熱點數據無法聚合；而 Innodb 則適合基于 Range 的查詢，針對 Key 讀寫，IO 路徑長；另外，緩存是基于 Page 的，KV 緩存命中的效果不可控。那我們該如何使用 Redis 的存儲引擎？基于 IO

246、 訪問，我們具有讀多寫少、單 Key 查找為主、隨機訪問多的特點，并且極少數 range 查詢采用的是 b+tree，都可以用 AEP/BPS 來加速持久化。其次，還應該具備熱點動態聚合的能力，比如一個游戲注冊用戶有兩千萬、活躍用戶五萬，如果沒有熱聚合能力，熱點數據可能在磁盤上每一頁都有，為了加一個 key，就會把所有的頁都加進來。但具備熱聚合能力以后，就可以自適應地把這些數據聚合在更加熱的頁面里。它的好處也很明顯，能夠增大緩存的命中率、提升 IO 讀寫的訪問時間。除此以外，我們還希望冷數據可以下沉，一方面可以降低成本，冷的數據下去以后，熱的數據自然就能浮上來。另一方面，將 DRAM/AEP

247、提供給熱數據還能夠提升性能。降冷算法主要包含 LRU 主動降冷、LFU 主動降冷以及驅逐被動降冷三部分。因為引入了降冷流程，那就需要提供給更多的場景來適用，通過 DRAM、AEP、SSD 多節點存儲，可以滿足各種個性化場景配置，比如，多級存儲靈活配置、提速場景、降成本場景以及歸檔場景等等。革命成果KeewiDB在騰訊云即將發布的 KeewiDB 中，解決了一致性問題、擊穿問題以及雪崩問題。針對一致性問題，KeewiDB 通過內聚的三級緩存機制(dram+persist memeory+ssd)，利用持久內存的持132騰訊云技術實踐精選集久化能力，大大降低了 IO 的負載，提升了并發性能，對外部

248、客戶而言，天然地解決了持久化能力。針對擊穿問題，KeewiDB 通過內聚的三級緩存機制(dram+persist memeory+ssd)，提供了智能的熱聚合作用，熱數據將大量緩存在持久內存中，緩解擊穿問題。此外，緩存并不能徹底避免冷數據讀取，KeewiDB 專門為 Redis 數據結構打造了合適的存儲模型，大大降低了 IO 路徑長度，再加上優先緩存 Index 等措施，即便是全冷數據，也能達到非常高的 qps 和低延遲。針對雪崩問題，通過三級緩存熱聚合能力，可以大大減少冷數據訪問，通過優先緩存索引機制，將冷數據的 IO 訪問路徑降低到極致，從而保證了即使有冷數據，性能和延遲也能滿足要求，避免

249、上層業務大量失敗，瘋狂重試最終打爆業務。最后在易用性方面，通過一系列技術上的精心設計并把新硬件特性打包在一起，KeewiDB 試圖解放開發人員的負擔，使其能夠更加聚焦業務，取得成功。133騰訊云技術實踐精選集在數據量持續爆增、數據日益多樣化的今天，傳統數據庫的迭代速度已經追不上數據的增速，且企業對數據庫計算和存儲能力的要求越來越高。面對當前的挑戰和機遇，國產數據庫廠商的研發創新速度不斷加快，可以說云計算時代的到來，扭轉了國外商業數據庫一家獨大的局面。目前，國產數據庫領域正處于百花齊放的狀態，已經有越來越多的行業巨頭參與到了數據庫的建設中，騰訊云便是其中之一。為了更深入地了解騰訊云數據庫的發展歷

250、程，從而進一步透視國產數據庫的發展方向，InfoQ 和騰訊云數據庫專家工程師竇賢明聊了聊云數據庫的發展、前景與挑戰。云原生數據庫的“能與不能”竇賢明 騰訊云數據庫專家工程師云原生 MySQL、云原生 PGSQL、TencentDB For PGSQL 等云數據庫產品負責人；十余年工作經驗，7+年云產品研發經驗，從 0 到 1 研發多款云數據庫產品，致力于提供易用、穩定、安全的云數據庫服務，專注于數據庫內核研發、云數據庫產品研發等技術方向。134騰訊云技術實踐精選集單一數據庫不能解決所有問題進入基礎軟件領域已有十余年光景，竇賢明親歷了云數據庫從零到一的建設過程，作為整個浪潮的參與者和見證者，他對

251、技術、產品以及市場都有著更加深刻的認識。據他介紹，當開發人員在部署一個傳統數據庫時，需要涉及購買硬件、部署機房、建立網絡、部署實例、規劃資源等等一系列操作；在維護傳統數據庫時，還需要進行擴容、監控、告警、日志、參數設置等等操作，而云數據庫的出現便能夠更加輕松、簡單地實現上述工作。開發人員可以直接在云數據庫控制臺完成數據庫的申請和創建，幾分鐘內便能準備就緒、投入使用，通過云數據庫提供的控制臺，還可以對所有實例進行統一管理。云數據庫還支持物理備份、邏輯備份、備份恢復及秒級回檔等功能，以此來保障數據的安全性。此外，傳統數據庫的價格高昂，動輒就需要投入數十萬元的成本采購設備，而云數據庫則能夠按需付費，

252、用多少付多少。盡管相較于傳統數據庫，云數據庫已經能夠幫助企業解決大部分問題，但竇賢明告訴 InfoQ：“單一數據庫不可能解決所有問題，云數據庫在存儲成本、HA 切換、網絡瓶頸方面依然存在優化的空間?！比缦聢D所示，Master 和 RO 雖然對應的是同一份數據，但在存儲上實際有六份數據；而每多加一個 RO 節點就會多出三份數據，也使得整個集群的存儲副本數近一步放大；高吞吐的數量會使網絡問題成為瓶頸，在共享存儲側也有大量網絡浪費。135騰訊云技術實踐精選集云原生數據庫應運而生目前，竇賢明與他團隊研發的云原生 MySQL（TDSQL-C MySQL）、云原生 PostgreSQL（TDSQL-C P

253、ostgreSQL）便能夠很好地解決存儲成本、彈性擴容等問題。作為新一代企業級云原生分布式數據庫，它的初衷是為了讓運維人員更省心，讓數據庫的運維變得簡單，具體來說，TDSQL-C 有以下產品特點：全面兼容：100%兼容開源數據庫引擎 MySQL 5.7 和 8.0 以及 PostgreSQL 10。幾乎無需改動代碼，即可完成現有數據庫的查詢、應用和工具平滑遷移。高性能：具有商用數據庫的強勁性能，最高性能是 MySQL 數據庫八倍、PostgreSQL 數據庫的四倍。海量存儲：最高 128TB 的海量存儲，無服務器 Serverless 架構，自動擴縮容，輕松應對業務數據量動態變化和持續增長?？?/p>

254、速恢復：計算節點實現無狀態，支持本地和跨設備的秒級故障切換和恢復；支持基于快照的秒級備份和回檔。數據高可靠：集群支持安全組和 VPC 網絡隔離。自動維護數據和備份的多個副本，保障數據安全可靠，可靠性達 99.9999999%。彈性擴展：計算節點可根據業務需要快速升降配，秒級完成擴容，結合彈性存儲，實現計算資源的成本最優。TDSQL-C MySQL/PostgreSQL 基于共享存儲實現了存算分離架構，Master 和 RO 是基于一份數據放在共享存儲中，RO 只從共享存儲中讀取所需的 page，不需要寫入存儲，并且 RO 可以從主庫接收 WAL 在緩存中重放，以此保持緩存中 Page 持續更新

255、。這樣一來，云原生數據庫便解決了業務容量和計算節點的擴容的問題。TDSQL-C 還能夠自動判斷計算層面的資源，實現計算關停和熱啟動，且啟動時間大概在 3s 以內即可完成。136騰訊云技術實踐精選集在 11 月 4 日的騰訊數字生態大會 Techo Day 上，騰訊云副總裁李綱還宣布了云原生數據庫 TDSQL-C 的全新升級：吞吐率提升 50%、將 IO 延遲降低 80%，整體性能提升 85%；帶來全新形態 Serverless，通過全局工作流預測以及動態擴縮資源，進一步降低成本，做到真正的按需計費。在騰訊云發布的 Q3 財報中，也首次提到數據庫對企業服務的貢獻，財報顯示：“我們的 PaaS 解

256、決方案TDSQL 數據庫已經被 3000 多個來自金融、公共服務和電信垂直行業的客戶采用。我們為中國十大銀行中的六家提供服務，并在不同金融機構的核心系統中不斷增加滲透，展示了我們在數據安全、可靠性和一致性方面的能力”。李綱表示，國產數據庫即將進入規?；A段，未來五年，騰訊云數據庫即將助力 1000 家金融機構實現核心系統數據庫國產化。攻克最嚴苛的領域在竇賢明看來，現階段云數據庫能夠解決企業怎樣的問題想必已經沒有分歧，但對于一些傳統企業來說，畢竟要將自己所有的業務數據遷移到公有云上，安全性成了他們最大的顧慮。關于這一點，他表示：“扭轉行業內的固有認知是當下的一大挑戰，云是一門信任的生意，需要長期

257、積累的過程才能扭轉這樣的局面?！蹦敲?，對于騰訊云數據庫來說，怎么做才能加速對行業的滲透？“只要攻克了最為嚴苛的領域，就能證明我們可以滿足絕大多數企業的需求?！备]賢明給出了這樣的答案。而由于金融領域本身的業務特點，使其在數據一致性、高可用，性能成本以及水平伸縮等方面都有非常嚴苛的要求，也因此，金融領域成為騰訊云數據庫勢必要攻克的一塊高地。騰訊云副總裁李綱也曾公開表示：“國產數據庫的發展一般會經過互聯網企業、民生政務、傳統行業應用、金融核心業務這幾個階段的打磨，其中金融行業對數據庫要求最為苛刻，不僅數據容錯度低，而且還要符合信息安全等級規范?！弊鳛閲a分布式數據庫的重磅產品，TDSQL 在背后支撐

258、了全國第七次人口普查、防疫健康碼、張家港農商行核心系統的落地應用等等，且服務了國內前 10 大銀行中的 6 家；在政務、電信運營商等領域，也已經服務了超過 3000 家金融政企客戶。此外，在保險行業，TDSQL 正在幫助太平洋保險集團實現全面數據庫國產化。在這些金融及政務項目中，TDSQL 的 Oracle 兼容性得到了充分驗證，兼容度高達 98%以上，這能幫助業務在極短時間內，極小業務改動量的情況下，快速完成測試驗證和上線。137騰訊云技術實踐精選集在采訪過程中，竇賢明還為我們介紹了一個“微服務+國產分布式數據庫”的架構案例：昆山農商行將新核心系統劃分成公共服務微服務集群、賬務微服務集群和歷

259、史微服務集群，并把這三個微服務集群運行在一套 TDSQL 集群中。由于 TDSQL 保障了微服務間一致性讀的問題，使得企業在應用微服務組織結構的同時，也能解決存儲分布式擴容的問題。持續迭代數據庫的五個基本能力縱觀騰訊云數據庫產品家族，包含了關系型數據庫、非關系型數據庫以及數據庫遷移、智能運維、可視化平臺等相關應用。除了兼容主流的 MySQL、MariaDB、Redis、Mongo 等開源技術，騰訊云數據庫也有內部自研的產品分布式數據庫 TDSQL 和云原生數據庫 TDSQL-C，基于這樣多點開花的局面，也讓我們不禁產生了一個疑問：面向未來，騰訊云數據庫重點突圍的方向會是什么？“穩定、安全、易用

260、，高效、成本低”竇賢明這樣告訴 InfoQ，由于基礎軟件與應用軟件在迭代速度上有著很大的不同，所以它不可能一天一個新概念。在他看來，做數據庫要學會坐冷板凳，需要朝以上五個基本能力持續演進、迭代并逐步做到極致。竇賢明介紹說：“當前我們已經做到了 99.95%，未來需要朝 99.99%，甚至更高的目標去努力?！币驗楫斣茢祿鞗]有了穩定性、可靠性、安全性等最基本的東西，一切都將成為空談，也勢必會被市場所拋棄?！霸诮酉聛淼?510 年里，國內數據庫行業將會出現一個很大的變化，相信過不了多久，大家會認可國產數據庫是更好的數據庫?！倍@句話背后，不僅僅代表了騰訊云數據庫的信心，更體現出了國產數據庫從業者的

261、底氣與實力。138騰訊云技術實踐精選集隨著云服務基礎設施建設的發展，存算分離架構逐漸成為業內趨勢，也成為騰訊云主要對外推進的方向。騰訊云基于對象存儲 COS 的數據湖數據底座，打造了騰訊云原生的數據湖三層加速方案。在 2021 年 QCon 全球軟件開發大會【上海站】，騰訊云技術專家程力帶來了題為騰訊云存儲數據湖三層加速的演講，重點介紹騰訊云對象存儲 COS 的三層加速方案中的 GooseFS 產品，通過實際案例和架構分析等方面，透視騰訊云的整體數據湖技術發展和演進方向，結合大數據、AI、訓練等核心場景，展望未來騰訊云的數據湖整體計劃。騰訊云存儲數據湖三層加速程力 騰訊云技術專家主要負責騰訊云

262、對象存儲數據湖方向，主要負責三層加速和 GooseFS 設計和研發，同時是開源社區 Apache Hadoop Committer 和 Apache Ozone PMC。139騰訊云技術實踐精選集云原生生態下的存算分離從大數據到 AI，各種應用場景都出現了存算一體和存算分離兩種不同的思路。HDFS 等方案將計算節點和存儲節點部署在一起，好處是獲得了數據本地性，數據存儲比較穩定，而缺陷在于：運維壓力比較大，無法做到彈性化。因此，隨著數據存儲的進一步發展出現了存算分離部署的思路，計算節點會大面積地運用所有業務機器上的資源來做計算業務，把數據分離到遠端的云存儲上。今天的各大云廠商都是在走存儲計算分離

263、的路線。最近幾年，云廠商又開始發力數據湖整體架構，將格式化和非格式化數據都存儲到同一個存儲方案中，也就是一種處理結構化和非結構化數據的方式，繼續發展下去，計算和存儲則都開始走向云原生化。騰訊云的對象存儲 COS 始于 2014 年，很早就發展到了億級數據量，并支持騰訊內部的各種上云業務。對象存儲在可靠性和彈性方面有天然優勢，還具備協議兼容、接口兼容、數據安全全鏈路保障等特性。時至今日，隨著用戶數據規模迅速擴大，HDFS 等傳統存算一體方案的弊端凸顯，具備性能、成本、高可用和可靠性優勢的對象存儲方案成為了數據湖數據底座的首選。在開始做數據湖存儲之前，騰訊云已經有了像 COSN 這樣的 Hadoo

264、p Compatible File System 實現。騰訊云想利用這個 COSN 的文件系統接口進入 Hadoop 的生態系統，把很多大數據業務接到騰訊云上。但在對接上 Spark、Flink 等服務后，騰訊云發現對用戶來說，COSN 這樣簡單的文件系統實現并不能滿足很多極端的業務場景需求，例如 COSN 的 OLAP 實時查詢能力、批流一體能力都存在一些效率缺陷。同時，對象存儲本身針對隨機讀、隨機寫等場景，需要花費大量讀放大來滿足對應的帶寬需求。此外，大數據業務的峰值不是一直維持在很穩定的狀態，而是會有毛刺現象、長尾效應。為了避免這些問題，云廠商存儲服務團隊可能需要提前準備很多容量滿足帶寬

265、需求。在這樣的背景下，基于提升用戶體驗、降低成本的考慮，騰訊云開始發展數據湖生態系統。140騰訊云技術實踐精選集云原生數據湖三層加速2021 年，騰訊云提出了數據湖的三層加速方案。該方案分為計算端的 GooseFS、數據端的元數據加速與存儲端的 COS 加速器三個層次。GooseFS 是一個緩存層的文件系統實現。這個緩存系統主要是為了給客戶提供存儲計算分離架構缺失的數據本地性，并增加了 Hive Table 緩存等特性；元數據加速器主要解決 List 和 Rename 的性能瓶頸。List 和 Rename 優化是大數據存儲領域的重點問題，元數據加速器就是要解決 B 端客戶使用 Hive、Sp

266、ark 時遇到的此類痛點；存儲端的 COS 加速器就是數據加速器。近年來，客戶普遍希望跨層、跨區、跨 AZ 建設數據中心，于是會出現各個區的數據都服務同一個周期性任務的情況。此時 COS 加速器可以將數據緩存到離計算端最近的數據中心甚至機柜上，完成網絡互通，從而降低成本。141騰訊云技術實踐精選集具體而言，數據湖三層加速架構可以完成以下任務：GooseFS 緩存加速的一個重要特性是支持針對 Hive Table 做 Table 級緩存。例如，客戶某個任務是以周單位做 Hive 查詢來編制報表，于是每周的數據都會不斷進入緩存，但緩存系統的容量有限，所以 GooseFS 支持 Hive Table

267、 Level 緩存，能夠感知到 Hive Table 的元信息。當客戶數據按照時間分割成不同 partition，緩存系統會在啟停任務時將最近一周的數據提前緩存在緩存介質里，這樣任務只會讀到緩存里的熱數據。針對企業級用戶，一些客戶極端場景可能會通過上述特性節省 25%-30%的計算資源。因為計算資源在跨節點遠端讀數據的過程中會阻塞很多計算線程，也就是說，緩存系統不僅僅釋放存儲壓力，更重要的是讓計算資源更快地將作業進去下去。GooseFS 下一步會提供 Hudi 和 Iceberg Table Level 預熱支持。在很多批流一體場景中，流式數據延遲的情況是比較頻繁出現的，上述特性可以降低此類場

268、景中的成本負擔。數據端加速器針對 AZ 提供了數據本地化支持。用戶只需要知道一個新的 Endpoint 就可以方便地使用。如果出現 miss cache，加速器就會從 COS 回源。142騰訊云技術實踐精選集元數據一致性是大數據領域的一大痛點。例如，List 不成功往往會導致 Hive 任務卡死，rename 不成功會導致 Spark 任務在前期做的所有 MapReduce 進程都要全部重試。如果 rename 都失敗，可能會有一些節點掛掉，整個集群都需要重啟。所以 list 和 rename 是存儲計算分離架構中導致效率低下的主要原因。騰訊云的元數據加速器將 Metadata Store 改

269、成了樹形結構，新加入了文件系統級別的管理，旨在降低諸如新建目錄等操作的成本。未來元數據加速器還會提供文件桶，其自帶降冷備、生命周期管理操作、以及很多對象存儲所需的增值特性，滿足大數據、AI 等場景的客戶需求。下面分別介紹 GooseFS 的一些獨有特性。GooseFS Namespace 的邏輯類似 Hadoop Namespace，可以掛載到底層存儲空間或私有化存儲上。一套 GooseFS 緩存可以將公有云數據和私有化數據同時藏在緩存文件系統之后。假設業務場景需要公有云數據和私有化數據同時服務一些作業，GooseFS Namespace 就可以起到比較方便的作用。目前 GooseFS 后臺支

270、持普通的 COS、云上 CHDFS 服務、CSP、TStore 等私有化服務。GooseFS 還支持數據湖結構化，客戶執行 ETR 任務，用 Flink 將數據導入到緩存的同時，GooseFS 可以實時從 CheckPoint 之間更新的增量中提取一些特征服務一些查詢作業。同時 GooseFS 也支持云原生部署和使用，利用開源 Fluid 組件，K8s 服務可以將 GooseFS 緩存 Pod 和計算 Pod 部署在同一個宿主機上，Pod 的生命周期也可以保持一致，GooseFS 本身也支持 CSI 掛載模式，大大簡化了 K8s PV 掛載和銷毀操作。因為 GooseFS 支持云原生，所以在部

271、署形態上支持 EMR，可以用 Yarn 來調度它的 Master 和 Worker。GooseFS 還支持 TKE（騰訊的 K8s 服務），整體思路與 EMR 類似。大數據與 AI 下的數據湖架構案例以某實時訓練平臺為例，類似場景中在機器執行 TensorFlow 任務時，內存消耗量往往并不大，但服務器為了支撐 GPU 資源卻分配了很多內存，所以 GooseFS 緩存系統能夠充分利用客戶已購買的機器上剩余的內存資源提供數據端加速，從而提升訓練效率。143騰訊云技術實踐精選集GooseFS Table 在大數據場景應用較多。該特性基于 Hive Table 和 Table partition 級

272、別進行緩存，主要針對離線周期性作業和數據量比較大的資源。某 OCR 搜索框架實例利用了 GooseFS 提供的分布式緩存框架，充分利用了閑置內存來降低任務時延。在沒有分布式緩存框架支持時，由于每個特征庫分配的搜索場景各有不同，所以會存在數據傾斜問題，而 GooseFS 能夠更好地利用剩余內存資源，解決數據傾斜問題，提升跨節點搜索效率。在自動駕駛場景中，經常出現的問題是小圖片文件特別多，因而解析過程很長、碎片文件極多，且海量小文件的加速特別消耗內存資源，甚至會擠占計算作業的內存分配。為此，騰訊云先做了一項前期的優化，將很多內部有關聯的小文件拼起來合并進一個 tfrecord。第二項優化利用了 G

273、ooseFS 本身的緩存，利用 GooseFS 加上小文件合并的優化之后，系統效率可以達到理論上限的 95.6%。這里的經驗是很多機器學習場景中大量數據是只讀不刪的，使用緩存能夠抵消很多反復讀取的開銷。最后，騰訊云還通過 GooseFS 為有混合云需求的客戶統一了公有云和私有云的服務，提供完整的混合云體驗。通過這種方案，客戶就可以將敏感數據保存在私有云中，并在執行訓練作業時調用公有云的非敏感數據與私有云的敏感數據，同時避免敏感數據泄露的風險。144騰訊云技術實踐精選集前端業務架構PART 03145騰訊云技術實踐精選集騰訊實時音視頻（Tencent Real-Time Communicatio

274、n，TRTC）是騰訊云基于 QQ 在音視頻通話技術上的積累，它還結合了騰訊瀏覽服務 TBS WebRTC 能力與騰訊實時音視頻 SDK，為用戶提供多平臺互通、高品質、可定制化的實時音視頻互通服務解決方案。目前騰訊云團隊正在開發 TRTC Web SDK 新架構。在 2021 年GMTC 全球大前端技術大會【深圳站】中，來自騰訊云的高級工程師，音視頻 Web SDK 開發李宇翔，重點分享了新架構中運用了哪些設計思想和技巧，來提高程序的性能和代碼的可維護性。TRTC Web SDK 新架構設計解析李宇翔 騰訊云高級工程師&音視頻 Web SDK 開發目前在騰訊云從事 TRTC 的 Web 端技術研

275、發工作。80 后老程序員，熱愛技術，樂于分享，2006 年畢業后就進入視頻會議行業，有多年音視頻領域的技術積累，先后在蘇寧、vivo 從事前端架構和管理工作。著有開源軟件 Monibuca、Jessibuca 等。146騰訊云技術實踐精選集背景介紹騰訊云的 TRTC 產品主要提供了音視頻領域的一些基礎功能，并通過 SDK 供用戶使用，用戶可以使用 TRTC 提供的底層能力構建自己的產品。TRTC 提供的能力主要分為終端和云端兩個部分：云端部分均基于騰訊云，而終端部分覆蓋了主流的 Windows、macOS、iOS、Android 等原生端，以及小程序等 Web 端。WebRTC 是 TRTC

276、SDK 使用的開源解決方案。WebRTC 本質上是前端可以調用的中間算法與模塊，對前端工程師而言，相當于一個封裝到瀏覽器內部的黑盒。WebRTC 方案有自己的優勢和劣勢，優勢包括無需插件即可運行、前端開發難度低、開源免費、自帶 P2P 功能等。而 WebRTC 方案的劣勢也比較明顯：1.編解碼器是封裝好的，無法自定義；2.傳輸方式固定，無法自定義；3.服務端需要適配 WebRTC，即便云端有很多自制功能，接入了自有體系，依舊需要通過WebRTC 實現溝通；4.WebRTC 無法運行在 Worker 中，只能運行在主線程上。為了解決上述問題，騰訊云團隊自行開發了一套 WebRTC 的替代方案：該

277、替代方案主要分為算法層和傳輸層兩部分：傳輸層的選擇更加靈活，支持現有和未來出現的各種 Web 傳輸方案，如 DataChannel、WebSocket、WebTransport 等；算法層面支持 WebRTC 的所有模塊，通過 Webassembly 的方式在瀏覽器運行，從而支持自定義編解碼。該方案要求 M94 版本以上的瀏覽器環境，考慮到目前 M94 剛剛發布不久，就已經有 40%的占有率，這個方案的兼容性是比較樂觀的。新老架構對比從下圖中可以明顯發現，新舊方案 SDK 使用的主要技術是有一些差異的：147騰訊云技術實踐精選集從架構層面來看，WebRTC SDK 的架構如下圖所示：可以看到

278、Client、LocalStream、RemoteStream 是對外暴露的部分，為了實現平穩迭代升級，如下圖所示，新方案的第一個版本整體架構沒有變化。在改造過程中，團隊還對原有的開源代碼做了優化。以 Client 類為例，原始代碼多達 3500 行，現在經過分層優化實現了大幅瘦身。老方案的代碼以 JavaScript 為主，很容易出錯，所以新方案轉向了 TypeScript。TypeScript的強類型檢查、148騰訊云技術實踐精選集如何解決性能問題向新方案第一次遷移的過程中，團隊就遇到了性能問題，其原因在于主線程的壓力過大。典型的前端腳本執行機制如下圖所示：引用跳轉、類型約束等特性可以明顯

279、提升開發效率。與此同時，TypeScript 可以支持漸進式遷移，項目無需一次性全部轉換到 TS，遷移成本非常低。149騰訊云技術實踐精選集一般情況下，瀏覽器以 60hz 的速度渲染頁面，每 16ms 渲染一次 UI 并執行腳本，16ms 中剩余的時間 CPU 會空閑，但由于界面特別復雜，渲染耗時過長，腳本執行時間就會不足，導致腳本無法正常執行：第二種情況，JS 代碼中包含了 wasm 執行部分，導致腳本執行時間過長，留給渲染的時間減少，就會導致渲染卡頓的現象。為此，新方案選擇用 Worker 分工方式來降低 CPU 占用。主線程主要做渲染與采集，其它工作盡可能放到 Worker 中執行。Wo

280、rker 中有定時器可以做到精確執行，不受 UI 線程渲染影響。加入 Worker 后整體架構如下圖所示：150騰訊云技術實踐精選集其中 Worker 線程負責與后端網絡通訊，后端先同 Worker 通訊，Worker 再把一部分數據傳給主線程。這里的設計原則是盡量減少線程間通訊，避免主線程與 Worker 之間通訊過于頻繁增大開銷。為此，Worker 端需要更為復雜的設計，包含了大部分耦合度較高的主要邏輯：151騰訊云技術實踐精選集優雅管理生命周期生命周期是指一件事情從開始到終結的完整周期，例如進房到退房、發布到取消發布、訂閱到結束訂閱等。其中，能夠被用戶感知到的周期（如進房到退房）稱為宏觀

281、生命周期。在開發環境中，一些復雜頁面可能并沒有明顯的開始與結束的區分。如果程序開發中出現大量生命周期，其中存在眾多異常情況，程序就要在每一種生命周期出現異常時做判斷。如何以更好的模式，優雅地管理這些生命周期，是新 SDK 架構面臨的挑戰。除宏觀生命周期外還有微觀生命周期。以一場分享活動舉例，活動開始到結束的過程相當于程序啟動到退出的過程。每一位參會者都有自己獨立的生命周期，就像程序中每一個生成的對象都有自己的生命周期。正常情況下，分享活動會按照流程有序推進直到結束，但有時遇到天氣、災害等不可抗力的因素時，活動就需要立刻結束，這就相當于程序中的突發事件導致生命周期發生了變化。為了更好地處理微觀生

282、命周期，團隊引入了 ReactiveX 響應式編程技術。響應式編程其實就是發布訂閱者模式。上圖左邊的觀察者與右邊的訂閱者形成了一個宏觀生命周期。左邊開始訂閱，生命周期開始；左邊的發布者發布結束，生命周期就完成。中途出現異?；蛘呷∠嗛?，生命周期也會終結。152騰訊云技術實踐精選集從上圖的代碼視角來看，左側程序主要采集生命周期，用來采集音視頻數據，右邊代碼負責編碼。這兩者形成了一個生命周期，先采集數據然后編碼，兩者互相依賴，出現異常時，例如編碼生命周期突然結束，就需要通知采集周期同樣結束，反之亦然。使用 ReactiveX 可以清晰地撰寫上述生命周期相關的代碼，這種編程方式與常見的事件驅動編程模

283、型是有很大不同的。在事件驅動模型中涉及大量回調，程序開發的視角類似于一場活動的主辦方視角。主辦方要事無巨細地關注活動中的所有細節，開發者也需要對每一個事件的所有邏輯做好處理，這樣才能保證程序正常運行。而發布訂閱模式可以稱為參與者視角。每一位參與者只關心最終的調遣，比如通知演講人演講即將開始，演講人不用關心之前發生了哪些事件，只要在通知自己開始的時候上臺演講即可。演講結束亦是如此。這種參與者視角不直接處理回調，而是將原來的回調轉化為一個信號，各個信號再自由組合成需要的信號。組合完成后的信號就是最后要處理邏輯的事件。在 ReactiveX 三極管模型中，有一個主信號不斷發出數據，還有控制信號用來終

284、止主信號和響應邏輯。主信號、響應邏輯和控制信號等都有自己的微觀生命周期，它們整體形成宏觀生命周期。宏觀生命周期結束時，就可以通知所有微觀生命周期自動結束。宏觀生命周期可以通過控制信號控制，而所有的控制信號也是信號，可以被其他控制信號所控制。各種控制信號的組合最終可以實現級聯控制：153騰訊云技術實踐精選集為了讓整個過程更加優雅無痛，團隊引入了 Go 語言中的 Context 模型，它是一個可以取消的輕量對象，可以攜帶少量數據、級聯結束，還可以被傳遞和持有。例如進房之后，首先創建 roomCtx，推拉流都依賴于 roomCtx，推拉流操作都可能中途啟動或停止，但如果 roomCtx 退房就要結束

285、所有周期。傳統代碼要在退房代碼中寫很多判斷，比如退的時候判斷是否正在推流，如果是就停止推流，等等。改用新方式實現會優雅許多，在退房的回調函數里只寫一行代碼取消 Context，它取消會觸發子級 Context 全部取消，自動將其他微觀生命周期全部終止。這樣就無需關心其它生命周期的狀態，只需關心 Context 是否結束即可，就實現了更優雅的生命周期管理，有效減輕了開發過程中的心智負擔。目前這套 SDK 新方案還在開發之中，預計在性能、穩定性等指標上會有明顯提升。154騰訊云技術實踐精選集云剪輯是騰訊云創多媒體引擎產品矩陣中的剪輯產品。在云剪輯服務中，實時渲染引擎是關鍵的底層技術。在探索與落地在

286、線剪輯工具的過程中遇到了不少挑戰：如何設計高效的實時渲染架構？如何實現復雜的視頻效果？如何保證頁面性能與導出質量？在 2021 年GMTC 全球大前端技術大會【深圳站】中，來自騰訊云的高級工程師，云創多媒體引擎剪輯模塊負責人成銳林，分享了云剪輯實時渲染引擎的設計理念與技術細節。云剪輯實時渲染引擎設計成銳林 騰訊云高級工程師&云創多媒體引擎剪輯模塊負責人當前在騰訊云音視頻從事視頻剪輯工具開發工作，在前端編輯工具領域有一定積累，目前較多關注前端多媒體技術及相關行業應用。155騰訊云技術實踐精選集云創多媒體實時渲染引擎云創多媒體引擎的產品矩陣包含協同審片、在線剪輯、云直播等產品。本場分享主要介紹視頻

287、剪輯相關內容。視頻剪輯主要有在線視頻剪輯、小程序視頻剪輯和模板視頻剪輯幾個業務場景，用戶可以在瀏覽器、微信小程序里剪輯視頻，也可以通過視頻模版快速批量生產視頻。云剪輯有三大技術特點：第一，要求實時預覽，對畫面的調整能夠實時展現給用戶，這對渲染引擎的設計有一定要求；第二，交互比較復雜，主要是媒體資源操作、時間軸操作以及視頻畫面元素操作，保證操作的流暢性和數據的穩定性都是重要的內容，這對前端頁面邏輯的設計有一定要求；第三，多端渲染、Web 渲染、小程序渲染和服務端渲染需要保證效果一致性。實時渲染引擎由軌道數據和時間驅動渲染，通過上述架構設計來保證渲染準確性和實時性。通過游戲的架構，為后續各種素材、

288、特效的補充提供了很大的拓展性，能夠支撐各種復雜的業務需求，父子關系分層樹設計也是一個關鍵點。156騰訊云技術實踐精選集幀畫面的更新分為播放行為與用戶操作行為，每一幀更新前會做一些渲染準備工作，找到時間軸上當前應該被渲染的元素、不應該被渲染的元素以及根據預測即將被渲染的元素，均稱為 Clip。首先由 Preloader 進行元素關鍵內容的預加載，并放入緩存中心，其次找出所有當前時刻應該被渲染的 Clip 進行畫面更新。Clip 的生命周期主要有載入、更新和銷毀，Clip 的底層由 BaseClip 進行基礎屬性和操作行為的支撐，例如元素寬高、位置等基礎屬性的設置，拖拽、縮放和旋轉等基礎操作，以及

289、提供資源加載等必要邏輯。該引擎大量使用 WebGL Shader 實現視頻效果的添加，如特效、轉場、蒙版、出入場動畫等。157騰訊云技術實踐精選集設計好渲染引擎的 ShaderController 模塊后，會對基類 uniform 進行一個嚴格的約束，編寫的時候需要使用約定的 uniforms，在程序中可以使用各種通用方法，例如計算比例、計算位置、計算取色、計算進度、計算縮放等等，在傳入 WebGL 程序時，把這部分的代碼與編寫的渲染主邏輯代碼進行合并封WebGL 繪制流程有如圖所示步驟。WebGL 本質上是基于光柵化的 API，光柵化是把頂點數據轉換為片元的過程，片元中的每個元素對應幀緩沖區

290、的一個像素點顏色，WebGL 只關注投影矩陣的坐標和顏色兩個方面的內容，有兩種著色器，頂點著色器可以提供投影矩陣的坐標，片元著色器可以提供投影矩陣的顏色。主要代碼邏輯會聚焦在片元著色器上，也就是計算每一個像素點應該呈現什么顏色，下面通過一個常見的轉場效果來讓大家了解到背后發生的事情。158騰訊云技術實踐精選集編輯器包括素材管理、剪輯軌道和預覽器三大模塊。在素材選型環節，我們引入的每一種素材都經過了仔細地調研和思考，不允許使用有特定環境依賴的內容，例如瀏覽器環境的 DOM 元素，這樣的約束讓渲染引擎能有更多場景應用的可能性。剪輯軌道部分通過大量的性能調優工作來保障用戶體驗。此外，編輯器還支持自定

291、義素材，可以與行業工具結合，將后者生成的素材導入編輯器進行視頻創作。該剪輯項目前端基于 Vue 構建，所以離不開 Vuex 的使用，其中的 EventBus 負責組件間的通信，降低模塊耦合度，設計要求是所有子組件不可以直接觸達 Vuex 以保持組件的高內聚。裝，降低編寫 Shader 復雜度。渲染引擎不是一個獨立的存在，它需要配合軌道數據才有意義，拼裝軌道數據就離不開編輯器的部分了。159騰訊云技術實踐精選集時間軸模塊就是上述 Vuex+EventBus 設計模式的一個經典應用。視圖數據提交到視圖中控形成主體，所有軌道元素通過 Vuex 計算，用戶行為觸發后進行元素更新，這種設計模式可以明顯提

292、高剪輯流暢度，同時這種高內聚設計使得時間軸模塊可以在直播剪輯、AI 剪輯等頁面得到很好地復用。有了操作邏輯自然離不開所操作的對象，在媒體元素導入這部分也有一些有趣的設計。市面上 Web 剪輯工具的資源管理有兩種模式，一種是純云端模式，另一種是純本地模式。純本地模式的問題是可能出現軌道的丟失，需要用戶重新找回資源。但純云端模式也有問題，需要等待文件上傳、轉碼完成后才能使用素材，影響用戶體驗。于是項目引入了本地云端雙模式來支撐剪輯工作流，一個文件導入后可以先截取封面、雪碧圖，用戶可以無需等待立即開始剪輯，待文件全部上傳完成后再使用云端資源更新軌道數據，從而增強用戶體驗。用戶可能需要添加一些商業化的

293、特效、素材，可以通過素材制作工具制作團隊素材，用戶在自己的專屬平臺上添加素材后，所有團隊成員都可以使用這些素材，并且可以分發到小程序上使用，視頻模板也可以在多端使用。在視頻導出環節，以 OpenGL 作為基座，通過 WebGL 膠水層實現渲染邏輯的復用。160騰訊云技術實踐精選集在這個架構中，一個渲染進程驅動程序運行，封裝編解碼拓展、共享內存拓展。得益于渲染引擎分層架構的設計，渲染部分的邏輯可以得到很好的復用。共享內存拓展用于音視頻幀數據的傳遞，編解碼拓展被渲染主進程所調度。得益于渲染引擎的幀精確設計，在所有端都能實現精確的渲染效果。引擎會判斷哪些幀應該被什么邏輯調度（編碼/縮放/轉場/疊加等

294、），根據復雜程度進行不同的渲染調度以確保效率。離線調度框架會完成所有片段的封裝和轉封裝工作，進而完成視頻的生產流程。161騰訊云技術實踐精選集技術展望WebCodecs 是 Web 端新一代的高效編解碼技術，它的出現讓瀏覽器音視頻業務有了無限的想象空間。為了確保發布的質量，引擎的每一個基礎功能（視頻拼接、轉場、裁剪、特效等）都通過軌道數據生成基礎用例，這個基礎用例就是該軌道數據產生視頻幀雪碧圖，截取頻率是一秒一張。在構建環節根據軌道數據生成新的視頻幀雪碧圖與用例雪碧圖進行圖片相似度比對，來確保新的迭代內容沒有影響到原來的所有功能。但用戶行為可能會非常復雜，可以在軌道上疊加無數元素，疊加出來的效

295、果可能是意想不到的，所以增加了影子旁路環節，在迭代的預發布階段啟動影子系統，通過真實環境產生的雪碧圖和影子任務產生的雪碧圖進行比對，來發現新版本是否存在渲染問題，這個流程能夠很好地保障渲染引擎的發布質量。用戶可以通過以下幾種方式接入云渲染能力：剪輯 PaaS：IFrame 接：快速整合剪輯頁面所有能力，并支持多種定制化配置媒體資源互通：可與客戶媒體資源高效互通組件化 SDK：模塊化：軌道元素與剪輯能力模塊化封裝，用戶可自行設計前端交互進行軌道數據的組裝實時預覽：播放器 SDK 實時預覽組裝的軌道數據服務端 API：協議導出：提供 API 底層能力供自主組裝軌道協議進行視頻導出模板導出：在模板軌

296、道數據基礎上進行資源的替換，批量生產視頻程序插件：模板互通：通過在 Web 頁面制作通用素材、模板，小程序端使用與分發導出互通：小程序支持本地導出，也可通過云端導出實現更高的效率與更優畫質162騰訊云技術實踐精選集上圖是純瀏覽器端無 wasm 依賴的視頻制作流程。輸入一個媒體文件，對其解封裝，解析出來視頻軌和音頻軌，提取 samples 為 WebCodecs 提供 encodedChunk 數據，之后數據通過 VideoDecoder 進行解碼工作，解碼后會在它的回調函數 output 中返回 VideoFrame 對象，VideoFrame 和 AudioData 都只是輕量級的 Java

297、Script 對象，但它們持有對更重內存的引用例。如實際的像素數據或 GPU 緩沖區，所以要注意釋放的時機。拿到解碼后的視頻幀數據就可以為其添加各種視頻效果了，處理后的結果再封裝成 VideoFrame 交給 VideoEncoder，在編碼器回調函數 output 中得到 encodedChunk，就可以進行視頻的封裝工作了，這就是 WebCodecs 與視頻制作的整體流程。但目前 WebCodecs 也不是很完善，例如 WebCodecs 音頻編碼還僅支持 opus。因此，要封裝出來被主流播放器所支持的 MP4 文件，還需要通過例如 ffmpeg wasm 對音軌需要多一步轉碼過程，aac

298、 編碼已經在 WebCodecs 的工作計劃中了，未來可期。對 WebCodecs 未來發展還是有不少展望的，例如加入編碼緩沖區配置、幀對齊解碼、HDR/HEVC 支持等。我們會做好技術儲備，與視頻工作流整合為客戶創造更好的體驗。163騰訊云技術實踐精選集跨平臺開發架構是前端開發的熱點主題。騰訊云團隊在積極探索 Flutter 等跨平臺開發框架，并將其應用在了音視頻處理 SDK 的開發中，使用戶可以利用跨平臺 SDK 快速開發多端音視頻處理應用。在 2021 年GMTC 全球大前端技術大會【深圳站】中，來自騰訊云的高級工程師，音視頻跨端負責人牛贊分享了利用跨終端框架如何進行實時音視頻渲染，并深

299、入底層優化視頻渲染的性能。音視頻跨平臺應用與元宇宙未來暢想牛贊 騰訊云高級工程師&音視頻跨端負責人2015 年加入騰訊，先后負責過王者榮耀、英雄聯盟競猜、QQ 會員等業務，目前負責騰訊云音視頻 TRTC 跨終端框架 SDK的業務研發工作。164騰訊云技術實踐精選集跨平臺技術演進當前，跨平臺開發框架是前端開發行業非常流行的開發技術?？缙脚_框架為開發工作帶來了諸多優勢：一次開發、多端運行；組件復用、提升效率；節省公司人力成本；節省開發者學習成本等等。在 Hybrid App 階段，其依托于前端環境，開發迭代速度非?？?，但它受限于 WebView，性能比較差。2015 年 ReactNative 誕

300、生，核心改變是拋棄了低效的 webview 渲染，而是轉成 Native 控件，交由系統進行繪制，這樣既保留了前端這套開發體系，又最大限度的保證了渲染的性能。2018 年谷歌推出了 Flutter 框架，一套代碼可以構建多平臺應用，支持熱更新，方便開發者快速開發調試。它的底層基于 dart 語言，可以同時支持 JIT 和 AOT 編譯，其自渲染引擎可以讓跨平臺應用性能達到原生水平。從業界指標來看，今天 Flutter 的熱度趨勢已經超過了 ReactNative，是目前最被看好的跨平臺方案。需要強調的是，Flutter 開發與 Web 開發存在一些差異。例如下圖所示：右圖給一個 DIV 元素塊

301、定義一些居中屬性，可以定義一些 CSS 樣式。但 Flutter 有所不同。在 Flutter 的世界里，所有的底層組件是一個個小部件，比如一個居中屬性、一種字體顏色，或者一個布局屬性等。例如要寫一個居中樣式，可能就要把 Text 的文本塊包裹在 Center 下，因此 Flutter 的設計機制要求開發者在組織代碼語言時，盡量把 UI 組件拆分得足夠細。因為它沒有樣式與分離的概念，寫代碼很容易嵌套。165騰訊云技術實踐精選集Flutter 視頻渲染及 SDK 接入提效TRTC Flutter SDK 基于原生 Android 和 iOS SDK 進行封裝，音視頻底層的音視頻采集、編碼、解碼能

302、力可以被 Flutter 直接復用。另外考慮到 Flutter 后續可能支持更多的平臺，我們將實現層設計的更加具有擴展性。為了方便開發者使用我們 API，我們將美顏/設備/音效相關的 API 都聚合在一起，更加易用，視頻渲染部分也做了很多優化，GPU 性能基本能達到原生 SDK 的水平。接下來，從 SDK 視頻渲染性能和 SDK 接入效率兩個方面，來介紹下我們面臨的挑戰和解決方案。第一個挑戰點是視頻在 Flutter 里如何渲染？如果我們要用 Flutter 定義的消息通道機制來實現這個功能，就需要將攝像頭采集的每一幀畫面數據從原生傳遞到 Flutter 中，這樣做代價將會非常大，將圖像幀數據

303、通過消息通道實時傳輸，必然會引起 CPU 和 GPU 的巨大消耗。為此 Flutter 提供了兩種機制實現這一功能。第一種方案是外接紋理，它可以將原生端 opengl 圖像數據共享給 Flutter 進行渲染，需要原生 SDK 提供視頻幀圖像數據回調接口，實現較為復雜；第二種方案是 PlatformView，主要適用于 Flutter 中不太容易實現的組件，如 WebView、視頻播放器、地圖等，給 Flutter 提供了嵌入Android 和 iOS 平臺原生 view 的能力。166騰訊云技術實踐精選集底層 Android SDK 提供了一個視頻渲染的組件，視頻渲染的畫面會畫到這個 vie

304、w 上，我們要做的就是利用 PlatformView 的能力把安卓的 view 嵌入到 Flutter 去。PlatformView 對應于安卓其實是 AndroidView，AndroidView 組件的第一個參數用于和 Android 的 view 建立關聯，在 view 創建好后，通信層會把這個 viewId 回調出來，Flutter 根據 viewId 找到對應的 view 并渲染出來。按照 PlatfromView 實現的官方文檔操作和設置之后，視頻畫面就能顯示出來。但用一部低端設備測試時發現，房間有 6 個用戶的時候，第二屏畫面會出現異常情況。利用 perfdog 性能狗工具進行性

305、能分析后，發現 GPU 占用非常高，影響了視頻畫面的繪制。于是，我們先從視頻列表進行優化。ListView 默認不支持懶加載，這里通過 ListView.builder 支持懶加載，并去掉默認的預加載支持，更進一步優化對非可視區域視頻進行回收，比如訪問到第二屏的時候，停止對第一屏視頻的渲染，優化之后視頻畫面得以正常顯示。第一階段性能優化之后分析發現，Flutter 的 CPU、內存占用與 Android 原生占用接近，但 GPU 差距比較明顯。同時渲染四個畫面，Flutter 占用比原生 SDK 差了約 15%。于是團隊從 PlatformView 的底層實現原理入手開始優化。對于 Andro

306、id 來說，在虛擬顯示模式下，它的底層也是用外接紋理來渲染的，中間多了一層附加的圖形緩沖區，它會將原生 SDK 視頻 view 的每個像素都流經中間圖形緩沖區，渲染成紋理圖像數據，然后輸出到 SurfaceTexture，這里的 SurfaceTexture 相當于一個畫板，會浪費顯存和繪圖性能。優化思路是將視頻的幀數據直接輸出到 SurfaceTexture 上，這需要原生 SDK 把采集好的音視頻數據不直接繪制到原生 view 上，而把視頻的紋理數據一幀幀回調出來。這樣就能通過 opengl 將視頻幀數據直接輸出到畫板上，繞過緩沖區。167騰訊云技術實踐精選集比如，有遠端用戶進房，本機通過

307、云服務收到進房信號，調用 Flutter SDK 發出開始拉流指令，SDK 進而會調用原生 SDK，原生 SDK 把視頻 view 一幀幀的視頻畫面回調出來，最終輸出到 SurfaceTexture 上，Flutter 最終拿到通信層返回的一個 textureId，這個 textureId 是在原生側繪圖數據對應的 ID，通過 ID 可以直接在 GPU 中找到相應的繪圖數據并使用，最后繪制由 Flutter 的渲染引擎完成。上述優化完成后，GPU 性能提升了約 10 個百分點，基本接近 Android 原生 SDK 的性能水平。168騰訊云技術實踐精選集第二個挑戰點是客戶接入如何提效的問題，原

308、始的 SDK 有很多 API，學習理解這些 API 的成本是非常高的?？蛻糁耙尤霕I務通常都需要比較久的耗時，基本上都需要兩三個月的時間。為了加速客戶的接入流程，團隊建設了一系列場景化方案，讓客戶可以參考這些場景化方案實現來提升接入效率。音視頻場景包括了音視頻通話、多人會議、在線教育、互動直播、語音聊天室、狼人殺、在線醫療、在線 K 歌等等。設計場景方案的過程中我們采用了 UI+場景 SDK 分離的設計模式，用戶可直接參考我們的 UI 界面開發，如果想自己設計 UI，可使用封裝好的場景 SDK 組件開發。以一個在線教育的場景為例，該 SDK 是針對在線教育場景中，使用實時音視頻 TRTC 和

309、即時通信 IM 能力的二次封裝，在封裝基本的音視頻聊天、屏幕分享能力的同時，針對在線教育場景封裝了老師開始問答、學生舉手、老師邀請學生上臺回答、結束回答等相關能力。這里定義的接口不超過30個，而且更加場景語義化，客戶對接起來門檻就會比較低。目前已經有越來越多的公司在新項目中嘗試使用 Flutter，有做互動直播場景的日本直播平臺 yell live、幣安、騰訊游戲青少年直播；有做教育的潭州教育、力拓飛遠；還有做音視頻通話的智聯招聘等等。如果新業務有音視頻方面的需求，那 Flutter 是一個非常不錯的選擇。目前 Flutter 主要應用在 Android 和 iOS 移動端雙端，但 Flutt

310、er 的愿景是成為一個多端運行的 UI 框架，不僅支持移動端，還包括 Web 和桌面端。目前，騰訊團隊也已經對 Web 端和桌面端做了支持，實現了基礎的音視頻通話功能。隨著未來 Flutter 對 Web 端和桌面端的支持越來越完善，Flutter 將能夠幫助開發者用一套代碼打通移動端、桌面端和 Web 端。音視頻與元宇宙未來暢想元宇宙的概念起源于科幻小說，描述了人們以虛擬形象在虛擬三維空間中與各種軟件交互的世界。比如電影黑客帝國頭號玩家都是對元宇宙暢想的實現。也因為疫情的原因，線上會議、在線教育得到迅速普及，人們在虛擬空間的停留時間也越來越長。169騰訊云技術實踐精選集未來，企業視頻會議體驗

311、將是以沉浸感、低延遲和擬真感為特征的，可以想象這樣的辦公場景：人們在元宇宙的世界中可以隨時召集同事面對面討論，可以在任何地方、任何時間建立一個虛擬的會議室，所有人都能借助 AR、VR 的設備以一個虛擬的身份進入房間，徹底告別上下班通勤和面對面社交，完全在虛擬的世界中辦公、開會和協作。這樣的場景該如何實現呢？這里就要提一下 Unity 跨平臺的游戲引擎。Unity 在元宇宙相關的概念上早有布局，它在 2020 年提供了 MARS 工具幫助開發者快速開發 AR 應用程序，再結合騰訊云提供的音視頻 Unity SDK，可以幫助開發者快速實現在游戲中的音視頻通話，拉近游戲內每一位玩家的距離，增加游戲互

312、動體驗，帶來更好的沉浸感。隨著科技的發展，音視頻通信的延遲會越來越低，元宇宙的生態建設也會越來越完善，以前電影里的設想場景也會慢慢實現。170騰訊云技術實踐精選集近年來，Serverless 概念的興起有效提升了軟件開發的生產效率，也讓它在 web 開發領域越來越被重視。雖然 Serverless 解決了 Web 開發的后端服務邏輯和運維面臨的許多問題，但沒有覆蓋前端和具體的應用開發領域。而對于前端和通用的應用問題，基于云原生的低代碼平臺可以更進一步，抽象前端 UI/交互邏輯并結合 Serverless 服務，在很多場景中幫助開發者擺脫重復交互邏輯和膠水代碼的困境，讓開發者能夠迅速實現想法、應

313、對海量流量，實現快速產品化迭代。在 2021 年 ArchSummit 全球架構師峰會【上海站】，騰訊云云開發前端負責人朱展介紹了騰訊云云開發低代碼平臺的架構和實踐，并說明了解決前后端應用中更高階抽象問題的思路和方法。朱展 騰訊云云開發前端負責人主導設計開發了騰訊云云開發平臺。對前端組件化、海量服務等有多年經驗。目前專注于云開發低碼產品的構建，致力為開發者提供穩定易用的技術產品。Serverless 時代的低代碼實踐171騰訊云技術實踐精選集背景介紹：為什么軟件開發需要低碼平臺根據咨詢機構Gartner報告，2023 年全球超過 50%的大中企業會將低代碼應用平臺作為主要戰略應用平臺之一，至

314、2024 年，低代碼開發的應用程序將占應用程序開發總量的 65%以上。由此可見，低代碼開發已經成為了軟件開發產業的未來趨勢之一。開發領域有個很有意思的觀點：開發可靠安全應用的最佳方式就是不寫代碼。在軟件開發著作人月神話中提到，所有軟件活動都包含兩個任務，分別是主要任務與次要任務：主要任務就是打造由抽象軟件實體構成的復雜抽象概念。次要任務則是使用編程語言表達這些抽象實體，在空間和時間限制內將它們映射成機器語言。172騰訊云技術實踐精選集通俗來講，主要任務是產品業務邏輯的定義，次要任務是實現業務邏輯的各種技術手段。拿一個電商小程序舉例，主要任務是定義應用中各個概念的邏輯，比如商品、訂單、用戶這些概

315、念的定義，它們具備哪些屬性，商品上架流程要怎樣流轉，用戶購買商品的流程要怎樣流轉，這些定義了產品的最核心邏輯。而次要任務是實現產品核心邏輯的方式和手段，比如服務端我們是要用 Node.js 還是 PHP、Java，應用框架要用 koa 還是 Express、NEST；單測怎么寫，文檔怎么生成等等這些都是為產品目標服務的。具體到研發過程中，從代碼到用戶可用產品的過程分為兩大步驟：第一個步驟是把代碼變成產品，需要經過測試、發布等流程；第二個步驟是將產品與線上系統進行集成，與其它產品做好溝通協作工作。整個周期中需要涉及很多角色和細分步驟，比如產品需要做需求分析，設計需要做交互和視覺，研發需要做編碼、

316、調試等，測試進行功能測試，運維需要進行線上服務的運維保障。經過眾多角色和步驟的配合會帶來額外的成本以及效率的損失，而我們面對眾多需求是需要有更高效率的開發方式。低代碼技術在很多場景能有效提供這種高效的開發，一般來說低代碼平臺會帶來幾個好處：封裝研發任務 復雜度隔離 提供應用范式 降低開發門檻很多研發和運維的復雜任務如服務器擴縮容、安全加固等，會由平臺提供封裝后的服務，同時平臺一般也會提供眾多行業和領域的相關模板幫助應用的快速創建。整體來說，低代碼平臺本意是希望研發能專注于產品的主要任務。需要注意的是，低代碼不像無代碼那樣只能專注于某一些封裝程度很高的領域，無代碼一般缺乏足夠的靈活性，而低代碼平

317、臺則一般具備足夠的靈活性來滿足多變的需求。173騰訊云技術實踐精選集低代碼實踐：產品研發中的封裝在具體的研發工作中，開發人員一般分為前端和后端。在端側，我們面對的問題通常是研發人力不足，很多企業都需要有自己的前端應用，但卻缺乏配套的研發人力。為了解決這一問題，業內出現了很多跨平臺方法來實現一次編寫、處處運行的效果，例如 Web 應用、小程序等。另一個手段是組件驅動開發，組件驅動開發的思想就是把整個應用從下到上拆分成原子、分子、區塊以及模板、頁面。應用里最小的原子組件是不可分割的，類似標題、按鈕、圖片、視頻等，它們必須組成分子組件才會有一定交互功能。區塊組織就是一些分子組件加上一些業務數據的聚合

318、體，例如，一個表單是分子組件，加上用戶權限就可以形成一個登錄區塊。區塊組織是一個真正的功能組件，能獨立承載具體的業務能力。這些功能抽象成一個模板，模板再復制成多個頁面，甚至跨應用復制到其它應用里，這就是端側組件化的基本思想。在服務端，應用部署為一個服務時，往往需要關注服務器負載、流量擴縮容、容災、備份等能力。而這些事項是典型的次要任務，與產品邏輯之間沒有必然聯系，產品研發真正關注的是自身的業務邏輯。有了 Serverless 后，研發人員就不用關注底層資源的情況了。騰訊云開發 Serverless 的能力可以歸納為微信生態、彈性/隔離、擴展能力和降本增效四部分。首先，它和微信生態結合比較緊密，

319、能夠復用微信的一些能力，比如免流量、安全、高性能等。它的彈性擴縮容能力會利用騰訊云某一個云服務的海量資源，按用戶使用率和流量自動擴縮容。最終，Serverless 低代碼平臺的價值就體現在分離主要任務和次要任務，讓產品研發、業務人員專注于主要任務，把研發運維的部分打包起來交給平臺的專業人員來處理。174騰訊云技術實踐精選集騰訊云微搭低碼平臺的架構設計與實踐從 2020 年開始，騰訊云自研了名為微搭的 Serverless 低代碼平臺。騰訊云微搭低碼平臺的主要能力可以分為四個層級：1.多端能力，通過可視化編輯做出來的產品能夠發布到小程序、Web 端上；2.擴展體系，微搭能夠針對前端和后端進行自定

320、義邏輯的定義來滿足各類擴展的需求；3.應用構建邏輯層包含表單引擎、數據源等，可以根據可視化配置生成相應的流程接口以及權限控制類的服務能力，直接提供給 UI、前端使用；4.承載服務的是 Serverless 云原生架構，包含云存儲、云函數、云托管等。這一架構能夠隨意擴縮容，不使用時成本為零。最終，Serverless 低代碼平臺的價值就體現在分離主要任務和次要任務，讓產品研發、業務人員專注于主要任務，把研發運維的部分打包起來交給平臺的專業人員來處理。175騰訊云技術實踐精選集微搭低碼平臺主要是從應用的描述和聲明、動態表單、應用動態發布流程幾個視角出發來設計平臺架構的。所謂描述應用，在前端就是將交

321、互和視覺呈現給用戶，服務端則要負責承載產品邏輯。前端要有樣式和頁面，頁面下有組件，組件要有屬性以及事件。服務端需要一些接口定義、登錄設置以及數據同步給前端組件的設計。微搭用常見的 JSON 和 JSON Schema 來描述應用，即應用 DSL。在微搭里每一個應用都是一個結構化的 JSON 數據，包含上述所有前端內容。同時開發人員可以自己寫一些代碼來滿足擴展性的自定義訴求。自定義代碼可以是客戶端也可以是服務端代碼。服務端代碼會直接部署到數據源云函數中。應用發布時會將應用 DSL 聲明發布成線上服務運行的代碼。微搭使用了開源工具 Cloudbase Framework 來進行應用部署，它可以聲明

322、端側邏輯代碼的部署位置、服務端函數定義、函數配置、需求資源數量等等，使用這個工具可以把低代碼平臺預設好的前端頁面以及數據接口定義，一鍵發布到云開發的環境上。動態表單也是低代碼領域使用非常廣泛的特性。一般來說，一個表單除了包含字段的信息之外，在低代碼場景里還需要描述組件 UI 的信息。定義一個表單字段時，首先要聲明它的字段類型，然后進一步聲明它的格式和細分類型。定義好之后才能夠去做組件選擇以及 Ul 展示。比如說一個枚舉類型可以用下拉列表和平鋪單選的形式來呈現。在產品細化交互時需要通過一些聲明式配置來實現這類需求。176騰訊云技術實踐精選集總結下來，微搭低代碼發布應用的流程分為如下步驟：關于微搭

323、低代碼平臺的應用運行時方面，它的數據流是從前端開始，對應的小程序、Web 等，后面是服務端都是 Serverless 運行環境，包含接入層、邏輯服務和資源層。用戶從端發送一個請求，它會先經過云開發 Serverless 接入層，這里會判斷用戶是否有訪問權限等。邏輯層承載在云函數上，負責整體的邏輯控制，管理接口、權限等內容。邏輯層下面是資源層，包含數據庫、靜態托管以及存儲、權限等服務。平臺還提供擴展能力，允許用戶自己編寫客戶端和服務端代碼，對接第三方服務。177騰訊云技術實踐精選集微搭低碼平臺的演進方向與規劃微搭發布還不到一年，是比較年輕的低碼平臺，現在也處于比較早期的階段。微搭當前專注于 C

324、端的小程序端和 Web 端的低代碼開發服務。未來除了 C 端之外，還會有配套的 B 端運營管理系統。用戶能夠用低代碼的方式在管理系統中生成相應的管理功能。這里還會有一些 BI 分析、用戶增長等統計信息。微搭團隊還希望將來能夠做到多云部署。因為 Serverless 目前與廠商綁定比較嚴重，所以將來要設法將云開發的產品部署到其它廠商的平臺上去。微搭的另一個發展方向是用可視化的方式聲明流程以及一些代碼級別的任務。用戶可以不用代碼，用線框圖來描述比較宏觀的流程，在每個節點綁定表單和對應的用戶權限等內容，進而翻譯成代碼做成產品和工作流。最后的主題則是平臺解鎖，云開發的端上內容并沒有平臺鎖定的問題，用戶

325、本來可以部署到任意一個靜態托管上。唯一有問題的是平臺鎖定的點，涉及云開發 Serverless 的一些特殊接口，包括用戶登錄、函數、存儲，以及數據庫等四類接口。如果能在本地適配云開發在云端的一些行為，比如，云開發里的 Code Function 也能夠在本地，實現類似的能力，就可以很好地開展低代碼平臺后端的多云適配工作，最終完成平臺解鎖的目標。178騰訊云技術實踐精選集架構設計PART 04179騰訊云技術實踐精選集隨著近年來 Node.js 以及其相關生態的成熟，業界各大前端團隊也逐步將 Node.js 落地到實際業務中，但要將 Node.js 服務做好并不容易：性能優化、應對峰值大流量、高

326、可用保障等等都需要長期的建設與打磨，業界相關的經驗也較少。騰訊云 CloudBase 團隊從創立之初就選用了 Node 相關技術棧來開發核心數據流服務，目前每天承載十億以上的流量，服務了下游多個公有云產品。在 2021 年GMTC 全球大前端技術大會【深圳站】中，騰訊云 CloudBase 前端負責人王偉嘉發表了題為十億級 Node.js 網關的架構設計與工程實踐的演講，以 CloudBase 核心網關為出發點，講述海量 Node.js 服務的整體架構設計思路，以及如何進行性能優化以及高可用保障。十億級 Node.js 網關的架構設計與工程實踐王偉嘉 騰訊云 CloudBase 前端負責人畢業

327、于復旦大學，現任騰訊云 CloudBase 前端負責人，Node.js Core Collaborator，騰訊 TC39 代表。目前在騰訊云 CloudBase 團隊負責小程序云開發、Webify 等公有云產品的核心設計和研發，服務了下游數十萬開發者和用戶，對 Node.js 服務架構、全棧開發、云原生開發、Serverless 有較豐富的經驗，先后在阿里 D2、GMTC、騰訊 TWeb 等大會上發表過技術演講。180騰訊云技術實踐精選集網關快速入門CloudBase 網關介紹網關這個詞到處都在用，它可以工作在硬件層，也可以工作在網絡層，還可以工作在應用層。本文主要討論工作在七層的網關。它主

328、要做的事情包括：作為公有云服務的入口，可以把公有云過來的請求定向到用戶的資源上；對接后端資源。云開發有很多內部資源，它可以把請求對接到這樣的云資源上；做身份鑒權。云開發有自己的一套身份鑒權體系。請求過來如果是帶有身份的，網關會對身份進行鑒權。實踐中，網關還要考慮基礎框架、性能優化、日志、監控、高可用、DevOps 等一系列需求。騰訊云開發 CloudBase 是一個云端開發的底層架構，承載了多種云開發業務。CloudBase 網關內部是基于 Nest.js 來做的，它的內部架構分成了兩層：一層是 Controller，主要控制各種資源的邏輯，底層是 Service，這一層非常厚，分成了幾大部分

329、：第一大塊是邏輯模塊，主要處理內部服務模塊的很多內容，最上面一層主要處理跟資源相關的請求邏輯，中間一層做內部集群的邏輯，最下面一層會有各種 Client；第二大塊是旁路的功能性模塊，包括打日志、本地緩存管理、本地配置管理 DNS 等旁路服務。整體設計思路就是高內聚低耦合，業務邏輯和 IO 解耦，保證可測試性。181騰訊云技術實踐精選集以上是 CloudBase 網關的整體鏈路架構，最上層是分布在邊緣的 CDN 節點，在 CDN 節點會回源到部署在各個地方的集群，這些集群又可以訪問后面不同區域的資源，因為公有云的資源也是按區域來劃分的。這里引出了網關的兩個核心要求：首先，作為網關肯定要求速度很快

330、，延遲很低。其次，要穩定，要扛住海量的客戶端請求，需要極高的可用性，快和穩分別對應性能優化和可用性提升。網關性能優化網關是網絡組件，大部分時間都消耗在 IO，而不是它本身的計算上，重 IO 輕計算組件的請求模式是比較固定的，客戶發送過來的請求實際上就是那么幾種，很少有客戶的請求是完全隨機生成的請求。所以可以針對這種情況做緩存設計，整體優化方向就是減少 IO 消耗，并把整條核心鏈路優化好。核心服務性能優化核心服務優化的業務邏輯很多，可以把業務邏輯做異步化，讓它后臺運行。比如，校驗的邏輯會放到后臺異步進行，而不是每次請求來了實時校驗。182騰訊云技術實踐精選集第二個優化點是請求體流式傳輸，Node

331、 提供的原生的客戶端里，Body 已經是 Stream 對象了，但大部分人都會默認引用 Body Parser，把 Stream 轉成 Javascript 對象再處理。實際上，對于網關來說這一層是沒有意義的，所以這一部分的消耗可以直接去掉，去掉 Body Parser 這一步。第三點是請求后端的時候，Nginx 這樣的組件通常都是短連接模式，但實際上有些業務情況比較特殊，是大租戶模式，相當于所有用戶共用同一套 Nginx，再啟用短連接模式就會有 TIME_WAIT 的問題，所以這里會啟用長連接。當然長連接也會帶來進一步的問題，又要去修復長連接的問題。最后一點就是因為請求模式比較固定，可以設計

332、比較合理的緩存機制。啟用長連接機制之所以短連接會有問題，是因為請求用戶資源的時候，自己的網關所在的服務是在資源上云的平面，就是自己的內部服務。但是用戶的公有云資源實際上是在另一個網絡平面，在公有云的 VPC 上面，這兩個網絡平面之間的穿透是需要走網關的。這個網關可以理解為一臺虛擬設備，是四層轉發的 Nginx，單實例可以承載6.5 萬的 TCP 連接數。TCP 連接斷開之后會進入 TIME_WAIT 的階段，在 Linux 內核里會等待兩倍的時間，默認是 60 秒，120 秒之后才會釋放連接，也就是在 120 秒內，它的端口都處于被占用的狀態，很容易就能算出來，單個穿透網關能夠承載的最大額定

333、QPS 不到 600，肯定不能滿足用戶需求。解決這樣問題有幾種方法，一種是改它的 TCP 傳輸層的內核參數，啟用重用、快速回收這些機制，但這需要騰訊網絡側的同事定制系統內核，成本會非常高；第二種是騰訊云 CLB 的方法，CLB 內部也是類似 Nginx 的組件，它們直接擴 VM 的數量，但這樣做業務成本是扛不住的，所以也放棄了；最后一種就是改成長連接機制，單個穿透網關可以最大承載 6.5 萬個連接數，相當于幾乎 6.5 萬個并發。對于同 IP PORT，它可以直接復用連接，所以穿透網關的連接數限制就不再是瓶頸。但長連接會導致競態的問題，首先客戶端跟服務端成功建立了長連接，之后可能有一段時間靜默，沒有HTTP 請求。這個連接保持但是沒有請求，服務端會主動把 TCP 連接關閉掉，發送關閉的包到客戶端，但客戶端在收到關閉信息之前，客戶端可能正好發送了新的 HTTP，請求包體出去。這時服務端的連接