簡介： 作者於雨擔任了 2021 年 GIAC 會議雲原生專場的出品人兼講師，組織了前后四個場子的演講，在這個過程中作者同時作為聽眾從這些同行的演講中學到了很多非常有用的知識。本文算是對 2021 GIAC 雲原生專場的側記，管中窺豹，以觀 2021 年雲原生技術發展現狀及未來一段時間內的趨勢。
作者 | 於雨
本人有幸擔任了 2021 年 GIAC 會議雲原生專場的出品人兼講師，組織了前后四個場子的演講，在這個過程中個人同時作為聽眾從這些同行的演講中學到了很多非常有用的知識。本文算是對 2021 GIAC 雲原生專場的側記，管中窺豹，以觀 2021 年雲原生技術發展現狀及未來一段時間內的趨勢。
雲原生這個詞含義廣泛，涉及到資源的高效利用、交付、部署及運維等方方面面。
從系統層次分可以區分出雲原生基礎設置【如存儲、網絡、管理平台 K8s】、雲原生中間件、雲原生應用架構以及雲原生交付運維體系，本次專場的四個議題也基本涵蓋了這四大方向：
- 亞馬遜的資深技術專家黃帥的《一個雲原生服務的爆炸半徑治理》
- 快手基礎架構中心服務網格負責人姜濤的《快手中間件 Mesh 化實踐》
- Tetrate 可觀測性工程師柯振旭的《使用 SkyWalking 監控 Kubernetes 事件》
- 本人以 Dubbogo 社區負責人出品的《Dubbogo 3.0：Dubbo 在雲原生時代的基石》
下面根據個人現場筆記以及個人回憶分別記述各個議題的要點。因時間以及本人能力有限，一些錯誤難免，還請行家多多指正。
雲原生服務的爆炸半徑
個人理解，黃的這個議題屬於雲原生應用架構范疇。
其演講內容首先從亞馬遜 AWS 十年前的一個故障說開：AWS 某服務的配置中心是一個 CP 系統，一次人為的網絡變更導致配置中心的冗余備份節點被打垮，當運維人員緊急恢復變更后，由於配置中心不可用【有效副本數少於一半】導致了整個存儲系統其他數據節點認為配置數據一致性不正確拒絕服務，最終導致整個系統服務崩潰。
復盤整個事故的直接原因是：CAP 定理對可用性和一致性的定義限定非常嚴格，並不適合應用於實際的生產系統。因此作為線上控制面的配置中心的數據應該在保證最終一致性的前提下，首先保證可用性。
更進一步，現代分布式系統的人為操作錯誤、網絡異常、軟件 Bug、網絡/存儲/計算資源耗盡等都是不可避免的，分布式時代的設計人員一般都是通過各種冗余【如多存儲分區、多服務副本】手段保證系統的可靠性，在不可靠的軟硬件體系之上構建可靠的服務。
如上面的事故，人為的配置錯誤導致了一連串的軟件體系故障，且這些故障之間是高度強相關的，最終導致了雪崩效應，可以稱之為“水平擴展的毒葯效應”。此時思考的維度就從“在不可靠軟硬件體系上提供可靠服務”進一步拓展為“通過各種隔離手段減小事故的爆炸半徑”：當不可避免的故障發生時，盡量把故障損失控制到最小，保障在可接受范圍內，保證服務可用。
針對這個思路，黃給出了如下故障隔離手段：
- 服務粒度適中微服務的服務粒度並不是拆分的越細越好。如果服務粒度過細，會導致服務數量過多，其第一個后果就是導致一個組織內幾乎無人能搞清楚服務整體邏輯的來龍去脈，增加維護人員的負擔：大家只敢小修小補無人敢做出大幅度的優化改進。服務粒度過細的第二個后果是造成整體微服務單元體指數級增加，造成容器編排部署成本上升。適中的服務粒度要兼顧架構體系的進化與部署成本的降低。
- 充分隔離進行服務編排時，獲取數據中心的電源和網絡拓撲信息，保證強相關系統之間部署做到“不遠”且“不近”。“不近”是指同一個服務的副本不在使用同一個電源的同一個機櫃部署，也不在使用了同一個網絡平面的 Azone 內部署。“不遠”是指部署距離不能太遠，例如多副本可以同城多 IDC 部署。使用這兩個原則兼顧性能與系統可靠性。
- 隨機分區所謂的隨機分區這塊，其實質就是在混合服務請求，保證某個服務的請求可以走多通道【隊列】，保證在某些通道掛掉的情況下不影響某個服務的請求處理，應用隨機分區技術，將用戶打散在多個 Cell 中，大幅度降低爆炸半徑。與 K8s APF 公平限流算法中的洗牌分片（Shuffle Sharding）頗為相似。
- 混沌工程通過持續內化的混沌工程實踐，提前踩雷，盡量減少“故障點”，提升系統可靠性。
使用 SkyWalking 監控 Kubernetes 事件
這個議題雖然被安排在第三場演講，屬於雲原生交付運維體系，但是與上個議題關聯性比較強，所以先在此記述。
如何提升 K8s 系統的可觀測性，一直是各大雲平台的中心技術難題。K8s 系統可觀測性的基礎數據是 K8s event，這些事件包含了 Pod 等資源從請求到調度以及資源分配的全鏈路信息。
快手中間件 Mesh 化實踐
快手的姜濤在這個議題中主要講解了快手 Service Mesh 技術的實踐
- 統一運維，提高可觀測性與穩定性，進行故障注入和流量錄制等；
- 對 Envoy 等做了二次開發，只傳輸變更的數據、按需獲取，解決單實例服務數過多的問題；
- 對協議棧和序列化協議做了大量的優化；
- 實施了面向失敗設計，Service Mesh 可以 fallback 為直連模式。
個人感興趣的是姜提到了 Service Mesh 技術在快手落地時面臨的三個挑戰：
- 成本問題：復雜環境下的統一部署與運維。
- 復雜度問題：規模大、性能要求高、策略復雜。
- 落地推廣：對業務來說不是強需求。
特別是第三個挑戰，Service Mesh 一般的直接收益方不在業務端，而是基礎架構團隊，所以對業務不是強需求，而且快手這種實時業務平台對性能非常敏感，Service Mesh 技術又不可避免地帶來了延遲的增加。
為了推動 Service Mesh 技術的落地，快手的解決手段是：
- 首先務必保證系統穩定性，不急於鋪開業務量；
- 搭車公司重大項目，積極參與業務架構升級；
- 基於 WASM 擴展性，與業務共建；
- 選取典型落地場景，樹立標桿項目。
姜在最后給出了快手下半年的 Service Mesh 工作：
在演講中姜提到了 Serivce Mesh 技術落地的兩個標桿：螞蟻集團和字節跳動。其實他們成功的很重要原因之一就是高層對先進技術的重視以及業務側的大力配合。
Dubbogo 3.0：Dubbo 在雲原生時代的基石
作為這個議題的講師，我在演講中並沒有過多強調 Dubbo 3.0 已有的特性，而是着重演講了 Service Mesh 的形態以及柔性服務兩塊內容。
而 Dubbo 生態的最大劣勢是除了 Java 和 Go 外，其他多語言能力不甚優秀，個人覺得跟着 gRPC 邯鄲學步，完全把其他語言能力屏蔽在外不是什么好主意。Dubbogo 社區出品的 dubbo-go-pixiu 項目在網關與 sidecar 兩種形態下解決 Dubbo 生態的多語言能力，把南北流量和東西流量統一到 Pixiu 中。
不管是何種形態的 Service Mesh 技術，其在國內的發展已經渡過第一波高潮，自螞蟻集團和字節跳動這兩個標桿之后走向了寥落，其自身還需要不斷進化，更緊密地與業務結合起來讓中小廠家看到其業務價值，才會迎來其后續的第二波高潮。
Service Mesh 自身特別適合在 K8s 之上幫助中小廠家把服務遷移到的混合雲或多雲環境，這些環境大都使用了大量的開源軟件體系，能夠幫助他們擺脫特定雲廠商依賴。
Dubbo 3.0 的柔性服務，基本上可以理解為反壓技術。Dubbo 與 Dubbogo 之所以要做柔性服務，其背景是在雲原生時代節點異常是常態，服務容量精准評估測不准：
- 機器規格：大規模服務下機器規格難免異構【如受超賣影響】，即使同規格機器老化速度也不一樣；
- 服務拓撲復雜：分布式服務拓撲結構在不斷進化；
- 服務流量不均衡：有洪峰有波谷；
- 依賴的上游服務能力不確定性：緩存/db 能力實時變化。
其應對之道在於：在服務端進行自適應限流，在服務調用端【客戶端】進行自適應負載均衡。
- 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 都可以實現出來讓用戶去選擇。上面整體內容，社區還在討論中，並非最終實現版本。
總結
從 2017 年到現在，個人參加了大大小小十幾次國內各種級別的技術會議，身份兼具出品人和講師。演講水平不高，但基本的時間控制能力還可以，做到不拉場。這次主持 GIAC 的雲原生分場，聽眾對本專場的評分是 9.65【所有專場橫向評分】，總體表現尚可。
很有幸生活在這個時代，見證了雲原生技術大潮的起起伏伏。亦很有幸工作在阿里這個平台，見證了 Dubbogo 3.0 在阿里雲釘釘內部的各個場景的逐步落地。
原文鏈接
本文為阿里雲原創內容，未經允許不得轉載。