螞蟻於雨：2021 年雲原生技術發展現狀及未來趨勢

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

雲原生這個詞含義廣泛，涉及到資源的高效利用、交付、部署及運維等方方面面。

從系統層次分可以區分出雲原生基礎設置【如存儲、網絡、管理平臺 K8s】、雲原生中間件、雲原生應用架構以及雲原生交付運維體系，本次專場的四個議題也基本涵蓋了這四大方向：

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

1. 雲原生服務的爆炸半徑

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

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

覆盤整個事故的直接原因是：CAP 定理對可用性和一致性的定義限定非常嚴格，並不適合應用於實際的生產系統。因此作爲線上控制面的配置中心的數據應該在保證最終一致性的前提下，首先保證可用性。

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

圖片

但是這中間有一個誤區：有時候一些冗餘手段可能因爲雪崩效應反而會導致系統的可靠性降低。

如上面的事故，人爲的配置錯誤導致了一連串的軟件體系故障，且這些故障之間是高度強相關的，最終導致了雪崩效應，可以稱之爲 “水平擴展的毒藥效應”。此時思考的維度就從“在不可靠軟硬件體系上提供可靠服務” 進一步拓展爲“通過各種隔離手段減小事故的爆炸半徑”：當不可避免的故障發生時，儘量把故障損失控制到最小，保障在可接受範圍內，保證服務可用。

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

使用 SkyWalking 監控 Kubernetes 事件

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

如何提升 K8s 系統的可觀測性，一直是各大雲平臺的中心技術難題。K8s 系統可觀測性的基礎數據是 K8s event，這些事件包含了 Pod 等資源從請求到調度以及資源分配的全鏈路信息。

圖片

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

圖片

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

圖片

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

快手中間件 Mesh 化實踐

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

圖片

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

圖片

上圖是快手的 Service Mesh 架構圖，很明顯借鑑了 Dapr 的思想：下沉基礎組件的能力到數據平面，把請求協議和接口標準化。一些具體的工作有：

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

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

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

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

圖片

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

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

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

作爲這個議題的講師，我在演講中並沒有過多強調 Dubbo 3.0 已有的特性，而是着重演講了 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 之所以要做柔性服務，其背景是在雲原生時代節點異常是常態，服務容量精準評估測不準：

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

圖片

自適應限流的基本思想是基於排隊論的 little's law 的改進：queue_size = limit * (1 - rt_noload/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 都可以實現出來讓用戶去選擇。

上面整體內容，社區還在討論中，並非最終實現版本。

場外

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

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

**技術瑣話 **

以分佈式設計、架構、體系思想爲基礎，兼論研發相關    的點點滴滴，不限於代碼、質量體系和研發管理。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/pRaUQBnEME9C9hNK8TXejw

猜你喜歡