2021 年云原生技術(shù)發(fā)展現(xiàn)狀及未來趨勢(shì)

本人有幸擔(dān)任了 2021 年 GIAC 會(huì)議云原生專場(chǎng)的出品人兼講師，組織了前后四個(gè)場(chǎng)子的演講，在這個(gè)過程中個(gè)人同時(shí)作為聽眾從這些同行的演講中學(xué)到了很多非常有用的知識(shí)。本文算是對(duì) 2021 GIAC 云原生專場(chǎng)的側(cè)記，管中窺豹，以觀 2021 年云原生技術(shù)發(fā)展現(xiàn)狀及未來一段時(shí)間內(nèi)的趨勢(shì)。

云原生這個(gè)詞含義廣泛，涉及到資源的高效利用、交付、部署及運(yùn)維等方方面面。

從系統(tǒng)層次分可以區(qū)分出云原生基礎(chǔ)設(shè)置【如存儲(chǔ)、網(wǎng)絡(luò)、管理平臺(tái) K8s】、云原生中間件、云原生應(yīng)用架構(gòu)以及云原生交付運(yùn)維體系，本次專場(chǎng)的四個(gè)議題也基本涵蓋了這四大方向：

• 亞馬遜的資深技術(shù)專家黃帥的《一個(gè)云原生服務(wù)的爆炸半徑治理》

• 快手基礎(chǔ)架構(gòu)中心服務(wù)網(wǎng)格負(fù)責(zé)人姜濤的《快手中間件 Mesh 化實(shí)踐》

• Tetrate 可觀測(cè)性工程師柯振旭的《使用 SkyWalking 監(jiān)控 Kubernetes 事件》

• 本人以 Dubbogo 社區(qū)負(fù)責(zé)人出品的《Dubbogo 3.0：Dubbo 在云原生時(shí)代的基石》

下面根據(jù)個(gè)人現(xiàn)場(chǎng)筆記以及個(gè)人回憶分別記述各個(gè)議題的要點(diǎn)。因時(shí)間以及本人能力有限，一些錯(cuò)誤難免，還請(qǐng)行家多多指正。

個(gè)人理解，黃的這個(gè)議題屬于云原生應(yīng)用架構(gòu)范疇。

其演講內(nèi)容首先從亞馬遜 AWS 十年前的一個(gè)故障說開：AWS 某服務(wù)的配置中心是一個(gè) CP 系統(tǒng)，一次人為的網(wǎng)絡(luò)變更導(dǎo)致配置中心的冗余備份節(jié)點(diǎn)被打垮，當(dāng)運(yùn)維人員緊急恢復(fù)變更后，由于配置中心不可用【有效副本數(shù)少于一半】導(dǎo)致了整個(gè)存儲(chǔ)系統(tǒng)其他數(shù)據(jù)節(jié)點(diǎn)認(rèn)為配置數(shù)據(jù)一致性不正確拒絕服務(wù)，最終導(dǎo)致整個(gè)系統(tǒng)服務(wù)崩潰。

復(fù)盤整個(gè)事故的直接原因是：CAP 定理對(duì)可用性和一致性的定義限定非常嚴(yán)格，并不適合應(yīng)用于實(shí)際的生產(chǎn)系統(tǒng)。因此作為線上控制面的配置中心的數(shù)據(jù)應(yīng)該在保證最終一致性的前提下，首先保證可用性。

更進(jìn)一步，現(xiàn)代分布式系統(tǒng)的人為操作錯(cuò)誤、網(wǎng)絡(luò)異常、軟件 Bug、網(wǎng)絡(luò)/存儲(chǔ)/計(jì)算資源耗盡等都是不可避免的，分布式時(shí)代的設(shè)計(jì)人員一般都是通過各種冗余【如多存儲(chǔ)分區(qū)、多服務(wù)副本】手段保證系統(tǒng)的可靠性，在不可靠的軟硬件體系之上構(gòu)建可靠的服務(wù)。

但是這中間有一個(gè)誤區(qū)：有時(shí)候一些冗余手段可能因?yàn)檠┍佬?yīng)反而會(huì)導(dǎo)致系統(tǒng)的可靠性降低。

如上面的事故，人為的配置錯(cuò)誤導(dǎo)致了一連串的軟件體系故障，且這些故障之間是高度強(qiáng)相關(guān)的，最終導(dǎo)致了雪崩效應(yīng)，可以稱之為“水平擴(kuò)展的毒藥效應(yīng)”。此時(shí)思考的維度就從“在不可靠軟硬件體系上提供可靠服務(wù)”進(jìn)一步拓展為“通過各種隔離手段減小事故的爆炸半徑”：當(dāng)不可避免的故障發(fā)生時(shí)，盡量把故障損失控制到最小，保障在可接受范圍內(nèi)，保證服務(wù)可用。

針對(duì)這個(gè)思路，黃給出了如下故障隔離手段：

• 服務(wù)粒度適中

  微服務(wù)的服務(wù)粒度并不是拆分的越細(xì)越好。如果服務(wù)粒度過細(xì)，會(huì)導(dǎo)致服務(wù)數(shù)量過多，其第一個(gè)后果就是導(dǎo)致一個(gè)組織內(nèi)幾乎無(wú)人能搞清楚服務(wù)整體邏輯的來龍去脈，增加維護(hù)人員的負(fù)擔(dān)：大家只敢小修小補(bǔ)無(wú)人敢做出大幅度的優(yōu)化改進(jìn)。

  服務(wù)粒度過細(xì)的第二個(gè)后果是造成整體微服務(wù)單元體指數(shù)級(jí)增加，造成容器編排部署成本上升。適中的服務(wù)粒度要兼顧架構(gòu)體系的進(jìn)化與部署成本的降低。
  

• 充分隔離

  進(jìn)行服務(wù)編排時(shí)，獲取數(shù)據(jù)中心的電源和網(wǎng)絡(luò)拓?fù)湫畔?，保證強(qiáng)相關(guān)系統(tǒng)之間部署做到“不遠(yuǎn)”且“不近”。

  “不近”是指同一個(gè)服務(wù)的副本不在使用同一個(gè)電源的同一個(gè)機(jī)柜部署，也不在使用了同一個(gè)網(wǎng)絡(luò)平面的 Azone 內(nèi)部署。“不遠(yuǎn)”是指部署距離不能太遠(yuǎn)，例如多副本可以同城多 IDC 部署。使用這兩個(gè)原則兼顧性能與系統(tǒng)可靠性。

• 隨機(jī)分區(qū)

  所謂的隨機(jī)分區(qū)這塊，其實(shí)質(zhì)就是在混合服務(wù)請(qǐng)求，保證某個(gè)服務(wù)的請(qǐng)求可以走多通道【隊(duì)列】，保證在某些通道掛掉的情況下不影響某個(gè)服務(wù)的請(qǐng)求處理，應(yīng)用隨機(jī)分區(qū)技術(shù)，將用戶打散在多個(gè) Cell 中，大幅度降低爆炸半徑。

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

• 混沌工程

  通過持續(xù)內(nèi)化的混沌工程實(shí)踐，提前踩雷，盡量減少“故障點(diǎn)”，提升系統(tǒng)可靠性。

這個(gè)議題雖然被安排在第三場(chǎng)演講，屬于云原生交付運(yùn)維體系，但是與上個(gè)議題關(guān)聯(lián)性比較強(qiáng)，所以先在此記述。

如何提升 K8s 系統(tǒng)的可觀測(cè)性，一直是各大云平臺(tái)的中心技術(shù)難題。K8s 系統(tǒng)可觀測(cè)性的基礎(chǔ)數(shù)據(jù)是 K8s event，這些事件包含了 Pod 等資源從請(qǐng)求到調(diào)度以及資源分配的全鏈路信息。

SkyWalking 提供了 logging/metrics/tracing 等多維度可觀測(cè)性能力，原來只是被用于觀測(cè)微服務(wù)系統(tǒng)，今年提供了 skywalking-kubernetes-event-exporter 接口，專門用于監(jiān)聽 K8s 的 event，對(duì)事件進(jìn)行提純、收集、發(fā)送至 SkyWalking 后端進(jìn)行分析和存儲(chǔ)。

柯同學(xué)在演講過程中花費(fèi)了相當(dāng)多的精力演講整個(gè)系統(tǒng)的可視化效果如何豐富，個(gè)人感興趣的點(diǎn)如下圖所示：以類似于大數(shù)據(jù)流式編程的手段對(duì) event 進(jìn)行過濾分析。

其可視化效果與流式分析手段都是螞蟻 Kubernetes 平臺(tái)可借鑒的。

快手的姜濤在這個(gè)議題中主要講解了快手 Service Mesh 技術(shù)的實(shí)踐。

姜把 Service Mesh 分為三個(gè)世代。其實(shí)劃分標(biāo)準(zhǔn)有很多，如何劃分都有道理。很明顯，姜把 Dapr 劃入了第三個(gè)世代。

上圖是快手的 Service Mesh 架構(gòu)圖，很明顯借鑒了 Dapr 的思想：下沉基礎(chǔ)組件的能力到數(shù)據(jù)平面，把請(qǐng)求協(xié)議和接口標(biāo)準(zhǔn)化。一些具體的工作有：

• 統(tǒng)一運(yùn)維，提高可觀測(cè)性與穩(wěn)定性，進(jìn)行故障注入和流量錄制等；

• 對(duì) Envoy 等做了二次開發(fā)，只傳輸變更的數(shù)據(jù)、按需獲取，解決單實(shí)例服務(wù)數(shù)過多的問題；

• 對(duì)協(xié)議棧和序列化協(xié)議做了大量的優(yōu)化；

• 實(shí)施了面向失敗設(shè)計(jì)，Service Mesh 可以 fallback 為直連模式。

  
  

個(gè)人感興趣的是姜提到了 Service Mesh 技術(shù)在快手落地時(shí)面臨的三個(gè)挑戰(zhàn)：

• 成本問題：復(fù)雜環(huán)境下的統(tǒng)一部署與運(yùn)維。

• 復(fù)雜度問題：規(guī)模大、性能要求高、策略復(fù)雜。

• 落地推廣：對(duì)業(yè)務(wù)來說不是強(qiáng)需求。
  

特別是第三個(gè)挑戰(zhàn)，Service Mesh 一般的直接收益方不在業(yè)務(wù)端，而是基礎(chǔ)架構(gòu)團(tuán)隊(duì)，所以對(duì)業(yè)務(wù)不是強(qiáng)需求，而且快手這種實(shí)時(shí)業(yè)務(wù)平臺(tái)對(duì)性能非常敏感，Service Mesh 技術(shù)又不可避免地帶來了延遲的增加。

為了推動(dòng) Service Mesh 技術(shù)的落地，快手的解決手段是：

• 首先務(wù)必保證系統(tǒng)穩(wěn)定性，不急于鋪開業(yè)務(wù)量；

• 搭車公司重大項(xiàng)目，積極參與業(yè)務(wù)架構(gòu)升級(jí)；
  

• 基于 WASM 擴(kuò)展性，與業(yè)務(wù)共建；
  

• 選取典型落地場(chǎng)景，樹立標(biāo)桿項(xiàng)目。
  

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

很顯然這個(gè)路線也是深受 Dapr 影響，理論或者架構(gòu)上創(chuàng)新性不大，更側(cè)重于對(duì)開源產(chǎn)品進(jìn)行標(biāo)準(zhǔn)化并在快手落地。

在演講中姜提到了 Serivce Mesh 技術(shù)落地的兩個(gè)標(biāo)桿：螞蟻集團(tuán)和字節(jié)跳動(dòng)。其實(shí)他們成功的很重要原因之一就是高層對(duì)先進(jìn)技術(shù)的重視以及業(yè)務(wù)側(cè)的大力配合。

作為這個(gè)議題的講師，我在演講中并沒有過多強(qiáng)調(diào) Dubbo 3.0 已有的特性，而是著重演講了 Service Mesh 的形態(tài)以及柔性服務(wù)兩塊內(nèi)容。

Dubbo 3.0 比較重要的一個(gè)點(diǎn)就是 Proxyless Service Mesh，這個(gè)概念其實(shí)是 gRPC 的濫觴，也是近期 gRPC 生態(tài)力推的重點(diǎn)，其優(yōu)點(diǎn)是性能無(wú)損，微服務(wù)升級(jí)方便。但是 gRPC 自身的多語(yǔ)言生態(tài)非常豐富，且 gRPC 鼓吹這個(gè)概念的另一個(gè)原因作為一個(gè)中庸的強(qiáng)調(diào)穩(wěn)定性的框架其性能不甚優(yōu)秀，如果考慮 Proxy Service Mesh 形態(tài)則其性能更加堪憂。

而 Dubbo 生態(tài)的最大劣勢(shì)是除了 Java 和 Go 外，其他多語(yǔ)言能力不甚優(yōu)秀，個(gè)人覺得跟著 gRPC 邯鄲學(xué)步，完全把其他語(yǔ)言能力屏蔽在外不是什么好主意。Dubbogo 社區(qū)出品的 dubbo-go-pixiu 項(xiàng)目在網(wǎng)關(guān)與 sidecar 兩種形態(tài)下解決 Dubbo 生態(tài)的多語(yǔ)言能力，把南北流量和東西流量統(tǒng)一到 Pixiu 中。

不管是何種形態(tài)的 Service Mesh 技術(shù)，其在國(guó)內(nèi)的發(fā)展已經(jīng)渡過第一波高潮，自螞蟻集團(tuán)和字節(jié)跳動(dòng)這兩個(gè)標(biāo)桿之后走向了寥落，其自身還需要不斷進(jìn)化，更緊密地與業(yè)務(wù)結(jié)合起來讓中小廠家看到其業(yè)務(wù)價(jià)值，才會(huì)迎來其后續(xù)的第二波高潮。

Service Mesh 自身特別適合在 K8s 之上幫助中小廠家把服務(wù)遷移到的混合云或多云環(huán)境，這些環(huán)境大都使用了大量的開源軟件體系，能夠幫助他們擺脫特定云廠商依賴。

Dubbo 3.0 的柔性服務(wù)，基本上可以理解為反壓技術(shù)。Dubbo 與 Dubbogo 之所以要做柔性服務(wù)，其背景是在云原生時(shí)代節(jié)點(diǎn)異常是常態(tài)，服務(wù)容量精準(zhǔn)評(píng)估測(cè)不準(zhǔn)：

• 機(jī)器規(guī)格：大規(guī)模服務(wù)下機(jī)器規(guī)格難免異構(gòu)【如受超賣影響】，即使同規(guī)格機(jī)器老化速度也不一樣；

• 服務(wù)拓?fù)鋸?fù)雜：分布式服務(wù)拓?fù)浣Y(jié)構(gòu)在不斷進(jìn)化；
  

• 服務(wù)流量不均衡：有洪峰有波谷；
  

• 依賴的上游服務(wù)能力不確定性：緩存/db 能力實(shí)時(shí)變化。
  

其應(yīng)對(duì)之道在于：在服務(wù)端進(jìn)行自適應(yīng)限流，在服務(wù)調(diào)用端【客戶端】進(jìn)行自適應(yīng)負(fù)載均衡。

自適應(yīng)限流的基本思想是基于排隊(duì)論的 little's law 的改進(jìn)：queue_size = limit * (1 - rt_noload/rt)，各個(gè)字段的意義如下：

• limit 一段時(shí)間內(nèi)的 qps 上限。

• rt_noload 一段時(shí)間窗口內(nèi)的 RT 最小值。

• rt 一段時(shí)間內(nèi)的平均 RT，或者可直接取值 P50 RT。
  

即以兩種形態(tài)的 RT 來評(píng)估 method 級(jí)別服務(wù)的合適性能。RT 增大反映了整體 load{cpu/memory/network/goroutine} 增大，性能就會(huì)下降。反之，RT 減小反映了服務(wù)端能夠處理更多請(qǐng)求。

自適應(yīng)限流：服務(wù)端是在 method 級(jí)別計(jì)算 queue_size，同時(shí)計(jì)算當(dāng)前 method 的使用的 goroutine 數(shù)量 inflight【假設(shè)每處理一個(gè)客戶端請(qǐng)求耗費(fèi)一個(gè) goroutine】，服務(wù)端每次收到某個(gè) method 的新請(qǐng)求后理解實(shí)時(shí)計(jì)算 queue_size，如果 inflight > queue_size，就拒絕當(dāng)前請(qǐng)求，并把 queue_size - inflight 差值通過 response 包反饋給 client。

自適應(yīng)負(fù)載均衡：客戶端通過心跳包或者 response 收到 server 返回的某個(gè) method 的負(fù)載 queue_size - inflight，可以采用基于權(quán)重的負(fù)載均衡算法進(jìn)行服務(wù)調(diào)用，當(dāng)然為了避免羊群效應(yīng)造成某個(gè)服務(wù)節(jié)點(diǎn)的瞬時(shí)壓力也可以提供 P2C 算法，Dubbogo 都可以實(shí)現(xiàn)出來讓用戶去選擇。

上面整體內(nèi)容，社區(qū)還在討論中，并非最終實(shí)現(xiàn)版本。

從 2017 年到現(xiàn)在，個(gè)人參加了大大小小十幾次國(guó)內(nèi)各種級(jí)別的技術(shù)會(huì)議，身份兼具出品人和講師。演講水平不高，但基本的時(shí)間控制能力還可以，做到不拉場(chǎng)。這次主持 GIAC 的云原生分場(chǎng)，聽眾對(duì)本專場(chǎng)的評(píng)分是 9.65【所有專場(chǎng)橫向評(píng)分】，總體表現(xiàn)尚可。

很有幸生活在這個(gè)時(shí)代，見證了云原生技術(shù)大潮的起起伏伏。亦很有幸工作在阿里這個(gè)平臺(tái)，見證了 Dubbogo 3.0 在阿里云釘釘內(nèi)部的各個(gè)場(chǎng)景的逐步落地。