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

作者 | 于雨

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

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

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

• 亞馬遜的資深技術(shù)專家黃帥的《一個云原生服務(wù)的爆炸半徑治理》
• 快手基礎(chǔ)架構(gòu)中心服務(wù)網(wǎng)格負(fù)責(zé)人姜濤的《快手中間件 Mesh 化實踐》
• Tetrate 可觀測性工程師柯振旭的《使用 SkyWalking 監(jiān)控 Kubernetes 事件》
• 本人以 Dubbogo 社區(qū)負(fù)責(zé)人出品的《Dubbogo 3.0：Dubbo 在云原生時代的基石》

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

云原生服務(wù)的爆炸半徑

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

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

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

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

但是這中間有一個誤區(qū)：有時候一些冗余手段可能因為雪崩效應(yīng)反而會導(dǎo)致系統(tǒng)的可靠性降低。

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

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

• 服務(wù)粒度適中微服務(wù)的服務(wù)粒度并不是拆分的越細(xì)越好。如果服務(wù)粒度過細(xì)，會導(dǎo)致服務(wù)數(shù)量過多，其第一個后果就是導(dǎo)致一個組織內(nèi)幾乎無人能搞清楚服務(wù)整體邏輯的來龍去脈，增加維護(hù)人員的負(fù)擔(dān)：大家只敢小修小補無人敢做出大幅度的優(yōu)化改進(jìn)。服務(wù)粒度過細(xì)的第二個后果是造成整體微服務(wù)單元體指數(shù)級增加，造成容器編排部署成本上升。適中的服務(wù)粒度要兼顧架構(gòu)體系的進(jìn)化與部署成本的降低。
• 充分隔離進(jìn)行服務(wù)編排時，獲取數(shù)據(jù)中心的電源和網(wǎng)絡(luò)拓?fù)湫畔?#xff0c;保證強相關(guān)系統(tǒng)之間部署做到“不遠(yuǎn)”且“不近”。“不近”是指同一個服務(wù)的副本不在使用同一個電源的同一個機柜部署，也不在使用了同一個網(wǎng)絡(luò)平面的 Azone 內(nèi)部署。“不遠(yuǎn)”是指部署距離不能太遠(yuǎn)，例如多副本可以同城多 IDC 部署。使用這兩個原則兼顧性能與系統(tǒng)可靠性。
• 隨機分區(qū)所謂的隨機分區(qū)這塊，其實質(zhì)就是在混合服務(wù)請求，保證某個服務(wù)的請求可以走多通道【隊列】，保證在某些通道掛掉的情況下不影響某個服務(wù)的請求處理，應(yīng)用隨機分區(qū)技術(shù)，將用戶打散在多個 Cell 中，大幅度降低爆炸半徑。與 K8s APF 公平限流算法中的洗牌分片（Shuffle Sharding）頗為相似。
• 混沌工程通過持續(xù)內(nèi)化的混沌工程實踐，提前踩雷，盡量減少“故障點”，提升系統(tǒng)可靠性。

使用 SkyWalking 監(jiān)控 Kubernetes 事件

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

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

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

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

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

快手中間件 Mesh 化實踐

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

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

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

• 統(tǒng)一運維，提高可觀測性與穩(wěn)定性，進(jìn)行故障注入和流量錄制等；
• 對 Envoy 等做了二次開發(fā)，只傳輸變更的數(shù)據(jù)、按需獲取，解決單實例服務(wù)數(shù)過多的問題；
• 對協(xié)議棧和序列化協(xié)議做了大量的優(yōu)化；
• 實施了面向失敗設(shè)計，Service Mesh 可以 fallback 為直連模式。

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

• 成本問題：復(fù)雜環(huán)境下的統(tǒng)一部署與運維。
• 復(fù)雜度問題：規(guī)模大、性能要求高、策略復(fù)雜。
• 落地推廣：對業(yè)務(wù)來說不是強需求。

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

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

• 首先務(wù)必保證系統(tǒng)穩(wěn)定性，不急于鋪開業(yè)務(wù)量；
• 搭車公司重大項目，積極參與業(yè)務(wù)架構(gòu)升級；
• 基于 WASM 擴展性，與業(yè)務(wù)共建；
• 選取典型落地場景，樹立標(biāo)桿項目。

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

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

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

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

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

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

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

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

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

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

• 機器規(guī)格：大規(guī)模服務(wù)下機器規(guī)格難免異構(gòu)【如受超賣影響】，即使同規(guī)格機器老化速度也不一樣；
• 服務(wù)拓?fù)鋸?fù)雜：分布式服務(wù)拓?fù)浣Y(jié)構(gòu)在不斷進(jìn)化；
• 服務(wù)流量不均衡：有洪峰有波谷；
• 依賴的上游服務(wù)能力不確定性：緩存/db 能力實時變化。

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

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

• limit 一段時間內(nèi)的 qps 上限。
• rt_noload 一段時間窗口內(nèi)的 RT 最小值。
• rt 一段時間內(nèi)的平均 RT，或者可直接取值 P50 RT。

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

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

自適應(yīng)負(fù)載均衡：客戶端通過心跳包或者 response 收到 server 返回的某個 method 的負(fù)載 queue_size - inflight，可以采用基于權(quán)重的負(fù)載均衡算法進(jìn)行服務(wù)調(diào)用，當(dāng)然為了避免羊群效應(yīng)造成某個服務(wù)節(jié)點的瞬時壓力也可以提供 P2C 算法，Dubbogo 都可以實現(xiàn)出來讓用戶去選擇。上面整體內(nèi)容，社區(qū)還在討論中，并非最終實現(xiàn)版本。

總結(jié)

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

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

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的2021 年云原生技术发展现状及未来趋势的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。