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