2021 年雲原生技術發展現狀及未來趨勢

個人有幸擔任了 2021 年 GIAC 會議雲原生專場的出品人兼講師，組織了前後四個場子的演講，在這個過程中個人同時作為聽衆從這些同行的演講中學到了很多非常有用的知識。本文算是對 2021 GIAC 雲原生專場的側記，管中窺豹，以觀 2021 年雲原生技術發展現狀及未來一段時間内的趨勢。

雲原生這個詞含義廣泛，涉及到資源的高效利用、傳遞、部署及運維等方方面面。從系統層次分可以區分出雲原生基礎設定【如存儲、網絡、管理平台 K8s】、雲原生中間件、雲原生應用架構以及雲原生傳遞運維體系，本次專場的四個議題也基本涵蓋了這四大方向：

• 1 亞馬遜的資深技術專家黃帥的 《一個雲原生服務的爆炸半徑治理》
• 2 快手基礎架構中心服務網格負責人姜濤的 《快手中間件 Mesh 化實踐》
• 3 Tetrate 可觀測性工程師柯振旭的 《使用 SkyWalking 監控 Kubernetes 事件》
• 4 本人以 Dubbogo 社群負責人出品的《Dubbogo 3.0：Dubbo 在雲原生時代的基石》

下面根據個人現場筆記以及個人回憶分别記述各個議題的要點。因時間以及本人能力有限，一些錯誤難免，還請行家多多指正。

1 雲原生服務的爆炸半徑

個人了解，黃的這個議題屬于雲原生應用架構範疇。

其演講内容首先從亞馬遜 AWS 十年前的一個故障說開：AWS 某服務的配置中心是一個 CP 系統，一次人為的網絡變更導緻配置中心的備援備份節點被打垮，當運維人員緊急恢複變更後，由于配置中心不可用【有效副本數少于一半】導緻了整個存儲系統其他資料節點認為配置資料一緻性不正确拒絕服務，最終導緻整個系統服務崩潰。

複盤整個事故的直接原因是：CAP 定理對可用性和一緻性的定義限定非常嚴格，并不适合應用于實際的生産系統。是以作為線上控制面的配置中心的資料應該在保證最終一緻性的前提下，首先保證可用性。

更進一步，現代分布式系統的人為操作錯誤、網絡異常、軟體 Bug、網絡/存儲/計算資源耗盡等都是不可避免的，分布式時代的設計人員一般都是通過各種備援【如多存儲分區、多服務副本】手段保證系統的可靠性，在不可靠的軟硬體體系之上建構可靠的服務。

但是這中間有一個誤區：有時候一些備援手段可能因為雪崩效應反而會導緻系統可靠性地降低。如上面的事故，人為的配置錯誤導緻了一連串的軟體體系故障，且這些故障之間是高度強相關的，最終導緻了雪崩效應，可以稱之為 “水準擴充的毒藥效應”。此時思考的次元就從 “在不可靠軟硬體體系上提供可靠服務” 進一步拓展為 “通過各種隔離手段減小事故的爆炸半徑”：當不可避免的故障發生時，盡量把故障損失控制到最小，保障在可接受範圍内，保證服務可用。

針對這個思路，黃給出了如下故障隔離手段：

• 服務粒度适中

  微服務的服務粒度并不是拆分的越細越好。如果服務粒度過細，會導緻服務數量過多，其第一個後果就是導緻一個組織内幾乎無人能搞清楚服務整體邏輯的來龍去脈，增加維護人員的負擔：大家隻敢小修小補無人敢做出大幅度的優化改進。

  服務粒度過細的第二個後果是造成整體微服務單元體指數級增加，造成容器編排部署成本上升。适中的服務粒度要兼顧架構體系的進化與部署成本的降低。

• 充分隔離

  進行服務編排時，擷取資料中心的電源和網絡拓撲資訊，保證強相關系統之間部署做到 “不遠” 且 “不近”。

  “不近”是指同一個服務的副本不在使用同一個電源的同一個機櫃部署，也不在使用了同一個網絡平面的 AZone 内部署。“不遠” 是指部署距離不能太遠，例如多副本可以同城多 IDC 部署。使用這兩個原則兼顧性能與系統可靠性。

• 随機分區

  所謂的随機分區這塊，其實質就是在混合服務請求，保證某個服務的請求可以走多通道【隊列】，保證在某些通道挂掉的情況下不影響某個服務的請求處理，應用随機分區技術，将使用者打散在多個 Cell 中，大幅度降低爆炸半徑。

  與 K8s APF 公平限流算法中的洗牌分片（Shuffle Sharding）頗為相似。

• 混沌工程

  通過持續内化的混沌工程實踐，提前踩雷，盡量減少 “故障點”，提升系統可靠性。

2 使用 SkyWalking 監控 Kubernetes 事件

這個議題雖然被安排在第三場演講，屬于雲原生傳遞運維體系，但是與上個議題關聯性比較強，是以先在此記述。

如何提升 K8s 系統的可觀測性，一直是各大雲平台的中心技術難題。K8s 系統可觀測性的基礎資料是 K8s event，這些事件包含了 Pod 等資源從請求到排程以及資源配置設定的全鍊路資訊。

SkyWalking 提供了 logging/metrics/tracing 等多元度可觀測性能力，原來隻是被用于觀測微服務系統，今年提供了 skywalking-kubernetes-event-exporter 接口，專門用于監聽 K8s 的 event，對事件進行提純、收集、發送至 SkyWalking 後端進行分析和存儲。

柯同學在演講過程中花費了相當多的精力演講整個系統的可視化效果如何豐富，個人感興趣的點如下圖所示：以類似于大資料流式程式設計的手段對 event 進行過濾分析。

其可視化效果與流式分析手段都是螞蟻 Kubernetes 平台可借鑒的。

3 快手中間件mesh化實踐

快手的姜濤在這個議題中主要講解了快手 Service Mesh 技術的實踐。

姜把 Service Mesh 分為三個世代。其實劃分标準有很多，如何劃分都有道理。很明顯，姜把 Dapr 劃入了第三個世代。

上圖是快手的 Service Mesh 架構圖，很明顯借鑒了 Dapr 的思想：下沉基礎元件的能力到資料平面，把請求協定和接口标準化。一些具體的工作有：

• 1 統一運維，提高可觀測性與穩定性，進行故障注入和流量錄制等
• 2 對 Enovy 等做了二次開發，隻傳輸變更的資料、按需擷取，解決單執行個體服務數過多的問題
• 3 對協定棧和序列化協定做了大量的優化
• 4 實施了面向失敗設計，Service Mesh 可以 fallback 為直連模式

個人感興趣的是姜提到了 Service Mesh 技術在快手落地時面臨的三個挑戰：

• 成本問題：複雜環境下的統一部署與運維。
• 複雜度問題：規模大、性能要求高、政策複雜。
• 落地推廣：對業務來說不是強需求。

特别是第三個挑戰，Service Mesh 一般的直接收益方不在業務端，而是基礎架構團隊，是以對業務不是強需求，而且快手這種實時業務平台對性能非常敏感，Service Mesh 技術又不可避免地帶來了延遲的增加。

為了推動 Service Mesh 技術的落地，快手的解決手段是：

• 1 首先務必保證系統穩定性，不急于鋪開業務量；
• 2 搭車公司重大項目，積極參與業務架構更新；
• 3 基于 WASM 擴充性，與業務共建；
• 4 選取典型落地場景，樹立标杆項目。

姜在最後給出了快手下半年的 Service Mesh 工作：

很顯然這個路線也是深受 Dapr 影響，理論或者架構上創新性不大，更側重于對開源産品進行标準化并在快手落地。

在演講中姜提到了 Serivce Mesh 技術落地的兩個标杆：螞蟻集團和位元組跳動。其實他們成功的很重要原因之一就是高層對先進技術的重視以及業務側的大力配合。

4 Dubbogo 3.0：Dubbo 在雲原生時代的基石

作為這個議題的講師，我在演講中并沒有過多強調 Dubbo 3.0 已有的特性，畢竟聽衆可是花費了 7800 大洋購買了會議門票。我着重演講了 Service Mesh 的形态以及柔性服務兩塊内容。

Dubbo 3.0 比較重要的一個點就是 Proxyless Service Mesh，這個概念其實是 gRPC 的濫觞，也是近期 gRPC 生态力推的重點，其優點是性能無損，微服務更新友善。但是 gRPC 自身的多語言生态非常豐富，且 gRPC 鼓吹這個概念的另一個原因作為一個中庸的強調穩定性的架構其性能不甚優秀，如果考慮 Proxy Service Mesh 形态則其性能更加堪憂。

而 Dubbo 生态的最大劣勢是除了 Java 和 Go 外，其他多語言能力不甚優秀，個人覺得跟着 gRPC 邯鄲學步，完全把其他語言能力屏蔽在外不是什麼好主意。Dubbogo 社群出品的 Dubbo-go-pixiu 項目在網關與 sidecar 兩種形态下解決 Dubbo 生态的多語言能力，把南北流量和東西流量統一到 Pixiu 中。

不管是何種形态的 Service Mesh 技術，其在國内的發展已經渡過第一波高潮，自螞蟻集團和位元組跳動這兩個标杆之後走向了寥落，其自身還需要不斷進化，更緊密地與業務結合起來讓中小廠家看到其業務價值，才會迎來其後續的第二波高潮。Service Mesh 自身特别适合在 K8s 之上幫助中小廠家把服務遷移到的混合雲或多雲環境，這些環境大都使用了大量的開源軟體體系，能夠幫助他們擺脫特定雲廠商依賴。

Dubbo 3.0 的柔性服務，基本上可以了解為反壓技術。Dubbo 與 Dubbogo 之是以要做柔性服務，其背景是在雲原生時代節點異常是常态，服務容量精準評估測不準：

• 1 機器規格：大規模服務下機器規格難免異構【如受超賣影響】，即使同規格機器老化速度也不一樣
• 2 服務拓撲複雜：分布式服務拓撲結構在不斷進化
• 3 服務流量不均衡：有洪峰有波谷
• 4 依賴的上遊服務能力不确定性：緩存/db 能力實時變化

其應對之道在于：在服務端進行自适應限流，在服務調用端【用戶端】進行自适應負載均衡。

自适應限流的基本思想是基于排隊論的 little's law 地改進：queue_size = limit * (1 - rt_noload/rt)，各個字段的意義如下：

• limit 一段時間内的 qps 上限
• rt_noload 一段時間視窗内的 RT 最小值
• rt 一段時間内的平均 RT，或者可直接取值 P50 RT

即以兩種形态的 RT 來評估 method 級别服務的合适性能。RT 增大反映了整體 load{cpu/memory/network/goroutine} 增大，性能就會下降。反之，RT 減小反映了服務端能夠處理更多請求。

自适應限流：服務端是在 method 級别計算 queue_size，同時計算目前 method 的使用的 goroutine 數量 inflight【假設每處理一個用戶端請求耗費一個 goroutine】，服務端每次收到某個 method 的新請求後了解實時計算 queue_size，如果 inflight > queue_size，就拒絕目前請求，并把 queue_size - inflight 內插補點通過 response 包回報給 client。

自适應負載均衡：用戶端通過心跳包或者 response 收到 server 傳回的某個 method 的負載 queue_size - inflight，可以采用基于權重的負載均衡算法進行服務調用，當然為了避免羊群效應造成某個服務節點的瞬時壓力也可以提供 P2C 算法，Dubbogo 都可以實作出來讓使用者去選擇。

上面整體内容，社群還在讨論中，并非最終實作版本。

5 場外

從 2017 年到現在，個人參加了大大小小十幾次國内各種級别的技術會議，身份兼具出品人和講師。演講水準不高，但基本的時間控制能力還可以，做到不拉場。這次主持 GIAC 的雲原生分場，聽衆對本專場的評分是 9.65【所有專場橫向評分】，總體表現尚可。

很有幸生活在這個時代，見證了雲原生技術大潮的起起伏伏。亦很有幸工作在阿裡這個平台，見證了 Dubbogo 3.0 在阿裡雲釘釘内部的各個場景地逐漸落地。

本周推薦閱讀

• 螞蟻集團 SOFATracer 原理與實踐
• 螞蟻集團萬級規模 K8s 叢集 etcd 高可用建設之路
• 我們做出了一個分布式注冊中心
• 還在為多叢集管理煩惱嗎？OCM來啦！

更多文章請掃碼關注“金融級分布式架構”公衆号