簡介：Faas 場景下，比較吸引用戶的是成本和研發(fā)效率，成本主要通過按需分配和極致的彈性效率來達(dá)成。而應(yīng)用開發(fā)者期望通過 FaaS 提供多語言的編程環(huán)境，提升研發(fā)效率，包括啟動時間、發(fā)布時間、開發(fā)的效率。 ?

作者｜曹勝利
?

什么是Service Mesh？

從 2010 年的時候，SOA 架構(gòu)就已經(jīng)在中大型互聯(lián)網(wǎng)公司中開始流行，阿里也在2012 年開源了 Dubbo 。而之后微服務(wù)架構(gòu)開始流行，大量互聯(lián)網(wǎng)和傳統(tǒng)企業(yè)都投身到微服務(wù)的建設(shè)中。在國內(nèi)逐漸形成了Dubbo 和 Spring Cloud 兩大微服務(wù)陣營。在2016 年的時候，微服務(wù)領(lǐng)域一個更具有前沿性，更加符合容器和 Kubernetes 的微服務(wù)方案正在孕育，這個技術(shù)被稱為 Service Mesh。時至今日，Service Mesh 理念已經(jīng)得到了大范圍普及，很多公司都在 Service Mesh 領(lǐng)域有了落地。

Service Mesh 定義

Service Mesh 是一個基礎(chǔ)設(shè)施層，主要圍繞服務(wù)間通信來進行。現(xiàn)在的云原生應(yīng)用的服務(wù)拓?fù)浣Y(jié)構(gòu)非常復(fù)雜，Service Mesh 可以在這種復(fù)雜拓?fù)浣Y(jié)構(gòu)中實現(xiàn)可靠的請求傳送。Service Mesh 是以 Sidecar 的方式運行，應(yīng)用旁邊會運行一個獨立的 Service Mesh 進程，Service Mesh 負(fù)責(zé)遠(yuǎn)程服務(wù)的通信。軍用三輪摩托車和 Service Mesh 非常相像，軍用三輪摩托車上一個士兵負(fù)責(zé)開車，一個士兵負(fù)責(zé)對人發(fā)起射擊。

Service Mesh 解決的痛點

?

傳統(tǒng)的微服務(wù)架構(gòu)大都以 RPC 通信框架為基礎(chǔ)，在 RPC SDK 中提供了服務(wù)注冊/發(fā)現(xiàn)，服務(wù)路由，負(fù)載均衡，全鏈路跟蹤等能力。應(yīng)用業(yè)務(wù)邏輯和 RPC SDK 在同一個進程中，這種方式給傳統(tǒng)微服務(wù)架構(gòu)帶了很多挑戰(zhàn)：中間件能力相關(guān)代碼侵入到了業(yè)務(wù)代碼中，耦合性很高；推動 RPC SDK 的升級成本非常高，進而也導(dǎo)致了 SDK 版本分化非常嚴(yán)重。同時這種方式對應(yīng)用開發(fā)者的要求比較高，需要有豐富的服務(wù)治理的運維能力，有中間件的背景知識，使用中間件的門檻偏高。

通過 Service Mesh 方式將一些 RPC 的能力進行下沉，這樣可以很好的實現(xiàn)關(guān)注點分離、職責(zé)邊界的明確。隨著容器和 Kubernetes 技術(shù)的發(fā)展，Service Mesh 已經(jīng)成為云原生的基礎(chǔ)設(shè)施。

Istio 介紹

?

在 Service Mesh 領(lǐng)域中， Istio 毫無疑問是當(dāng)中的王者。Istio 由控制面和數(shù)據(jù)面構(gòu)成，在 ServiceMesh 中，不同的 Service 之間，通過 Proxy Sidecar 進行通信。Istio 最核心功能是流量管理，通過數(shù)據(jù)面和控制面協(xié)調(diào)完成。Istio 是由 Google 聯(lián)合IBM，Lyft 一起發(fā)起的，是 CNCF 生態(tài)版圖 Service Mesh 領(lǐng)域的最純正血統(tǒng)，有望成為Service Mesh事實標(biāo)準(zhǔn)。
?

Istio 的數(shù)據(jù)面默認(rèn)使用 Envoy，Envoy 是社區(qū)里默認(rèn)的最佳數(shù)據(jù)面。Istio 數(shù)據(jù)面和控制面的交互協(xié)議是 xDS。
?

Service Mesh 小結(jié)

?

最后，對 Service Mesh 做下小結(jié)：
?

• Service Mesh 定位就是提供服務(wù)間通信的基礎(chǔ)設(shè)施，社區(qū)里主要支持 RPC 和http 。
• 采用 Sidecar 方式部署，支持部署在 Kubernetes 和虛擬機之上。
• Service Mesh 采用原協(xié)議轉(zhuǎn)發(fā)，所以 Service Mesh 也被稱為網(wǎng)絡(luò)代理。正是由于這種方式方式，所以可以做到對應(yīng)用的零侵入。

什么是Dapr？

?

Service Mesh 遇到的挑戰(zhàn)

?

用戶在云上部署業(yè)務(wù)的形態(tài)主要有普通應(yīng)用類型和FaaS類型。Faas 場景下，比較吸引用戶的是成本和研發(fā)效率，成本主要通過按需分配和極致的彈性效率來達(dá)成。而應(yīng)用開發(fā)者期望通過 FaaS 提供多語言的編程環(huán)境，提升研發(fā)效率，包括啟動時間、發(fā)布時間、開發(fā)的效率。
?

Service Mesh 的實現(xiàn)，本質(zhì)是原協(xié)議轉(zhuǎn)發(fā)，原協(xié)議轉(zhuǎn)發(fā)可以給應(yīng)用帶來零侵入的優(yōu)勢。但是原協(xié)議轉(zhuǎn)發(fā)也帶來了一些問題，應(yīng)用側(cè)中間件SDK還需要去實現(xiàn)序列化和編解碼工作，所以在多語言實現(xiàn)方面還有一定成本；隨著開源技術(shù)的不斷發(fā)展，使用的技術(shù)也在不斷迭代，如果想從 Spring Cloud 遷移到 Dubbo ，要么應(yīng)用開發(fā)者需要切換依賴的 SDK，如果想借助Service Mesh來達(dá)到這個效果，Service Mesh 需要進行協(xié)議轉(zhuǎn)換，成本較高。
?

Service Mesh 更加聚焦于服務(wù)間的通訊，而對其他形態(tài)的 Mesh 的支持上非常少。比如 Envoy， 除了在 RPC 領(lǐng)域比較成功外，在 Redis、消息等領(lǐng)域的嘗試都未見成效。螞蟻的 Mosn 中支持了 RPC 和消息的集成。整體多 Mesh 形態(tài)的需求是存在的，但是各個 Mesh 產(chǎn)品各自發(fā)展，缺少抽象和標(biāo)準(zhǔn)。如此多形態(tài)的 Mesh ，是共用一個進程嗎？如果是共用一個進程，那么是共用一個端口嗎？許多問題都沒有答案。而控制面方面，從功能角度來看的話，大都圍繞流量來展開。看過 xDS 協(xié)議里的內(nèi)容，核心是圍繞發(fā)現(xiàn)服務(wù)和路由來展開。其他類型的分布式能力，在 Service Mesh的控制面中基本沒有涉及，更談不上抽象各種類似 xDS 的協(xié)議去支持這些分布式能力。
?

因為成本和研發(fā)效率等原因，FaaS 受到了越來越多客戶的選擇，FaaS 對多語言和編程 API 的友好性上有了更多訴求，那么 Service Mesh 在這兩塊還是不能給客戶帶來額外的的價值。

分布式應(yīng)用的需求

?

?

Bilgin Ibryam 是 Kubernetes Patterns 的作者，是 RedHat 的首席中間件架構(gòu)師，在 Apache 社區(qū)里非常活躍。他發(fā)表了一篇文章對當(dāng)前分布式的一些困難和問題進行了抽象，將分布式應(yīng)用需求分成了 4 個大種類：生命周期、網(wǎng)絡(luò)、狀態(tài)、綁定。每種類型下面還有一些子能力，如 Point-to-Point， pub/sub， Caching 等比較經(jīng)典的中間件能力。應(yīng)用對分布式能力有如此多的需求，而 Service Mesh 顯然不能滿足應(yīng)用的當(dāng)前的需求。Biligin Ibryam 還在文章中提出了 Multiple Runtime 的理念來解決Service Mesh 的困境。

Multiple Runtime 理念推導(dǎo)

??

在傳統(tǒng)的中間件模式下，應(yīng)用和分布式能力是在一個進程中，以 SDK 方式進行集成。隨著各種基礎(chǔ)設(shè)施下沉，各種分布式能力從應(yīng)用中移到了應(yīng)用外。如 K8s 負(fù)責(zé)了生命周期相關(guān)的需求，Istio、Knative 等都負(fù)責(zé)一些分布式能力。如果將這些能力都移動到獨立的 Runtime 中，那么這種情況無論從運維層面還是資源層面來看，都是沒辦法接受的。所以這時候肯定需要將部分 Runtime 進行整合，最理想的方式肯定是整合成一個。這種方式被定義成 Mecha ，中文意思是機甲的意思，就像日本動漫里主人公變身穿上機甲，機甲的每個部件就像一個分布式能力，機甲里的人對應(yīng)的是主應(yīng)用，也叫 Micrologic Runtime 。 這兩個 Runtime 可以是一對一的 Sidecar 方式，這種非常適合傳統(tǒng)的應(yīng)用；也可以是多對一的 Node 模式，適合邊緣場景或者網(wǎng)管模式下。

那么對于將各種分布式能力進行整合的 Mecha Runtime 這一目標(biāo)本身問題不大，那么怎么整合呢？對 Mecha 有什么要求呢？

Mecha 的組件能力是抽象的，任何一個開源產(chǎn)品可以快速進行擴展和集成。

Mecha 需要有一定的可配置能力，可以通過 yaml/json 進行配置和激活。這些文件格式最好能和主流的云原生方式對齊。

Mecha 提供標(biāo)準(zhǔn)的 API ，和主應(yīng)用之間的交互的網(wǎng)絡(luò)通信基于此 API 來完成，不再是原協(xié)議轉(zhuǎn)發(fā)，這樣對于組件擴展和 SDK 的維護都能帶來極大的便利性。

分布式能力中的生命周期，可以將部分能力交接過底層的基礎(chǔ)設(shè)施，比如 K8s。當(dāng)然有些復(fù)雜的場景，可能需要 K8s、APP、Mecha Runtime 一起來完成。

既然最理想只剩下一個 Runtime , 那么為什么還叫 Multiple Runtime 呢？因為應(yīng)用本身其實也是一個 Runtime ，再加上 Mecha Runtime ，所以至少是兩個 Runtime 。
?

Dapr 介紹

?

前面的 Multiple Runtime 介紹地比較抽象，可以來從 Dapr 來重新理解下 Multiple Runtime 。Dapr 是 Multiple Runtime 的一個很好的踐行者，所以 Dapr 肯定和應(yīng)用共存的，要么是 Sidecar 模式，要么是 Node 模式。Dapr 這個詞其實是不是造出來的，而是 Distributed Application Runtime 的首字母拼接而成，Dapr 這個圖標(biāo)可以看出來是一個帽子，這個帽子其實是一個服務(wù)生的帽子，表示的含義是要為應(yīng)用做好服務(wù)。
?

Dapr 是由微軟開源的，阿里巴巴深度參與合作。當(dāng)前的 Dapr 已經(jīng)發(fā)布 1.1 版本，現(xiàn)在已經(jīng)接近生產(chǎn)的能力。

?

既然 Dapr 是 Multiple 的最佳實踐者，那么 Dapr 的運行機制也是基于 Mulitple Runtime 的理念來構(gòu)建的。Dapr 對分布式能力進行了抽象，定義了一套分布式能力的 API，而且這些 API 是基于 Http 和 gRPC 來構(gòu)建的，這種抽象和能力在 Dapr 中被稱為 Building Block；Dapr 為了支持開源產(chǎn)品和商業(yè)化等不同類型的產(chǎn)品對 Dapr中的分布式能力進行擴展，內(nèi)部擁有一套 SPI 擴展機制，這種 SPI 機制叫 Components 。應(yīng)用開發(fā)者在使用 Dapr 之后，只需要針對各種分布式能力的 API 來進行編程，而無需過多關(guān)注具體的實現(xiàn)，而 Dapr 中根據(jù) Yaml 文件可以自由激活對應(yīng)的組件。
?

Dapr 特性

?

應(yīng)用開發(fā)者使用各種多語言的 Dapr SDK 就可以直接擁有各種分布式能力。當(dāng)然開發(fā)者也可以自己基于 HTTP 和 gRPC 來完成調(diào)用。Dapr 可以運行在大部分環(huán)境里，包括你自己電腦的環(huán)境，或者任何 Kubernetes 環(huán)境下，或者邊緣計算場景，或者阿里云、AWS、GCP 等云廠商。

Dapr 社區(qū)里已經(jīng)集成了 70+ 的 components 實現(xiàn)，應(yīng)用開發(fā)者可以快速進行選擇和使用。相似能力的組件的替換，可以通過 Dapr 里完成，應(yīng)用側(cè)可以做到無感知。
?

Dapr 核心模塊

??

我們從 Dapr 產(chǎn)品模塊緯度來解析下，看為什么 Dapr 是 Mulitiple Runtime 的一個很好實踐。
?

Component 機制確保了可以快速擴展能力的實現(xiàn)，現(xiàn)在社區(qū)已經(jīng)有的 Components實現(xiàn)已經(jīng)有 70 個以上，不只包含開源產(chǎn)品，還包含云上的商業(yè)化產(chǎn)品。
?

Building Block 表示的的分布式能力，現(xiàn)在只支持 7 個，后續(xù)需要更多的分布式能力能夠進來。BuildingBlock 現(xiàn)在支持了 HTTP 和 gRPC 這兩種開放，而且普及度已經(jīng)非常高的協(xié)議。而 Dapr 中 Building Block 下具體那些 Components 會被激活，需要依賴 YAML 文件來進行。正因為 Dapr 中采用了 HTTP、gRPC 的方式暴露能力，所以在應(yīng)用側(cè)想要支持多語言的標(biāo)準(zhǔn)的API編程界面就變得更為容易了。
?

Dapr 核心：Component & Building Block

?

Dapr Component 是 Dapr 插件擴展的核心，是 Dapr 的 SPI 。現(xiàn)在支持的 Components 有 Bindings 、Pub/Sub、Middleware、ServiceDiscovery、Secret Stores、State。擴展點里有些是功能緯度的如Bindings，pub/sub,state 等，有些是橫向的如 Middleware。假設(shè)你想實現(xiàn)Redis的Dapr集成，你只需要去實現(xiàn) Dapr 的State Component。Dapr Building Block是Dapr提供出來的能力，支持 gRPC 和 HTTP 方式。現(xiàn)在支持的能力有 Service Invocation，State，Pub/Sub 等。

一個 Building Block 由 1 個或多個 Component 組成，Binding的Building Block 包含 Bindings 和 Middleware 兩個 Component 。

Dapr 整體架構(gòu)

?

Dapr 和 Istio 一樣，也有數(shù)據(jù)面和控制面。控制面有 Actor Placement，Sidecar Injector， Sentry， OPerator。Actor Placement 主要為 Actor 服務(wù)，Sentry 做安全和證書相關(guān)的工作，Sidecar Injector 主要負(fù)責(zé) Dapr Sidecar 的注入。Dapr 里激活某個組件實現(xiàn)是通過 YAML 文件來完成的，YAML 文件可以通過兩種方式來指定：一種是本地指定運行時參數(shù)，另外一種是通過控制平面 Operator 來完成，將組件激活的文件以 K8s CRD 方式存儲并下發(fā)到 Dapr的Sidecar 中。控制面的 2 個核心組件都依賴于 K8s 來運行。現(xiàn)在的 Dapr Dashboard 功能還很弱，短期還不到增強的方向，現(xiàn)在各個組件的集成之后，各個組件的運維還需要在原來的控制臺里完成，Dapr 控制平面不參與具體組件實現(xiàn)的運維。

Dapr 標(biāo)準(zhǔn)運行形式是和應(yīng)用在同一個 Pod 中，但分屬于兩個容器。Dapr 的其他內(nèi)容，前面已經(jīng)做了足夠的介紹，這里不做介紹了。
?

Dapr 微軟落地場景

?

Dapr 經(jīng)歷了 2 年左右的發(fā)展，在微軟內(nèi)部的落地情況是怎么樣的呢？

Dapr 的 github 上有兩個項目：workflows 和 Azure Functions Dapr extensions。Azure Logic App 是微軟的一個基于云上的自動工作流平臺。而 Workflows，就是整合了 Azure Logic App 和 Dapr。Azure Logic App 中有幾個關(guān)鍵的概念，Trigger 和 Connector 和 Dapr 非常契合。Trigger 可以使用 Dapr 的 Input Binding 來完成，依賴 Dapr 的 Input Binding 的大量組件實現(xiàn)，可以擴大流量入口的類型。而 Connector 和 Dapr 的 Output Binding 或者 Service Invocation 的能力非常匹配，可以快速訪問外部資源。Azure Functions Dapr extensions 則是基于Azure Function extension 做的 Dapr 支持，可以讓 Azure Function 快速使用上Dapr 的各種 Building Block 的能力，同時能給函數(shù)開發(fā)者帶來多語言的相對簡單一致的編程體驗。

Azure API Management Service和上面提到的兩個落地場景的角度不太一致，它是前提是應(yīng)用之間已經(jīng)通過Dapr Sidecar方式進行訪問，應(yīng)用的提供的服務(wù)通過Dapr來進行暴露。這時候如果非K8s的應(yīng)用或者跨集群的應(yīng)用想要訪問當(dāng)前集群的服務(wù)，就需要一個網(wǎng)關(guān)，這個網(wǎng)關(guān)可以直接暴露Dapr的能力，在網(wǎng)關(guān)中會增加一些安全和權(quán)限的控制。當(dāng)前支持3種Building Block：Service Invocation、pub/sub、resource Bindings。
?

Dapr 小結(jié)

?

Dapr 提供的面向能力的 API ，能夠給開發(fā)者帶來支持多語言的一致的編程體驗，同時這些 API 的SDK相對比較輕量級。這些特性非常適合 FaaS 場景。而隨著 Dapr 集成生態(tài)的不斷完善，開發(fā)者面向能力編程的優(yōu)勢將進一步擴大，通過 Dapr 可以更加方便地將 Dapr 組件的實現(xiàn)進行替換，而無需開發(fā)者做代碼的調(diào)整。當(dāng)然原來的組件和新的組件實現(xiàn)，必須是相同類型的分布式能力。
?

和 Service Mesh 差異點：
?

提供能力：Service Mesh 專注服務(wù)調(diào)用；Dapr 提供的分布式能力范圍更廣，覆蓋多種分布式原語。

工作原理：Service Mesh 采用原協(xié)議轉(zhuǎn)發(fā)做到零侵入；Dapr 采用多語言SDK + 標(biāo)準(zhǔn)API + 各種分布式能力。

面向領(lǐng)域：Service Mesh 對傳統(tǒng)微服務(wù)的無侵入升級支持很友好；Dapr 對面向應(yīng)用的開發(fā)者提供了更加友好的編程體驗。

阿里在 Dapr 上的探索

?

阿里在 Dapr 的發(fā)展路線

?

2019 年 10 月，微軟開源了 Dapr，發(fā)布了 0.1.0 的版本。這時候，阿里和微軟正好因為 OAM 已經(jīng)展開一些合作，了解到了 Dapr 這個項目，所以就開始對其進行評估。在 2020 年初的時候，阿里和微軟在阿里巴巴線下做了一輪 Dapr 的溝通，了解到了微軟對 Dapr 的看法、投入，以及后續(xù)的發(fā)展計劃。此時阿里已經(jīng)認(rèn)定 Dapr 這個項目具有較大的價值。一直到 2020 年中，才開始圍繞 Dapr 開始投入工作。到 10 月份，Dapr 在函數(shù)計算場景下開始線上灰度部分功能，到今天為止，函數(shù)計算相關(guān)的 Dapr 的所有功能的灰度已經(jīng)基本完成，開始開放公測。到 2021 年 2 月份，終于發(fā)布了 1.0 版本。
?

阿里云函數(shù)計算集成 Dapr

?

除了極致彈性等運維側(cè)的好處之外，函數(shù)計算區(qū)別于中臺應(yīng)用的地方還在于，函數(shù)計算更加關(guān)注能夠給開發(fā)者帶來更好的研發(fā)體驗，提升整體的研發(fā)效率。而 Dapr 能夠給函數(shù)計算的價值就是提供多語言的統(tǒng)一的面向能力的編程界面，而開發(fā)者無需關(guān)注具體的產(chǎn)品。像 Java 語言如果要使用阿里云上的 OSS 服務(wù)，需要引入 maven 依賴，同時需要寫一些 OSS 代碼，而通過 Dapr 你只需要調(diào)用 Dapr SDK 的 Binding 方法即可以做到，方便編程的同時，整個可運行包也無需引入多余的依賴包，而是可控的。

函數(shù)計算英文名是 Function Compute，簡稱為 FC。FC 的架構(gòu)包含的系統(tǒng)比較多，和開發(fā)者相關(guān)的主要包括 Function Compute Gateway和函數(shù)運行的環(huán)境。FC Gateway主要負(fù)責(zé)承接流量，同時會根據(jù)承接的流量的大小，當(dāng)前的 CPU、內(nèi)存使用情況，對當(dāng)前函數(shù)實例進行擴縮容。函數(shù)計算運行時環(huán)境部署在一個 Pod 中，函數(shù)實例在主容器中，dapr 則是在 sidecar 容器中。當(dāng)有外部流量訪問函數(shù)計算的服務(wù)時，流量會先走到 Gateway ，Gateway 會根據(jù)訪問的內(nèi)容將流量轉(zhuǎn)發(fā)到提供當(dāng)前服務(wù)的函數(shù)實例中，函數(shù)實例接收到請求之后如果需要訪問外部資源，就可以通過Dapr 的多語言 SDK 來發(fā)起調(diào)用。這時候 SDK 會向 Dapr實例發(fā)起gRPC請求，而在dapr 實例中回根據(jù)請求的類型和 body 體，選擇對應(yīng)的能力和組件實現(xiàn)，進而向外部資源發(fā)起調(diào)用。
??

在 Service Mesh 場景下，Mesh 以 Sidecar 形式存在，和應(yīng)用部署在同一個 Pod 的兩個容器里，可以很好滿足 Service Mesh 的需求。但是在函數(shù)計算場景下，Dapr作為獨立容器方式運行過于消耗資源，而且多個函數(shù)實例本身部署在一個 Pod 中以便節(jié)省資源開支和秒級彈性。所以在函數(shù)計算場景下，需要將函數(shù)實例和Dapr進程部署在同一個容器下，但是以兩個進程方式存在。
?

函數(shù)計算場景下，可以設(shè)置預(yù)留實例數(shù)，表示當(dāng)前函數(shù)最小實例數(shù)。如果有預(yù)留的實例，但是這些實例長久沒有流量訪問需要進入暫停/休眠狀態(tài)，這種方式和 AWS 的方式是一致的。進入休眠狀態(tài)的函數(shù)，實例內(nèi)的進程或者線程需要停止運行。函數(shù)運行時中增加了 Extension 結(jié)構(gòu)，來支持 Dapr 生命周期的調(diào)度。當(dāng)函數(shù)實例進入休眠狀態(tài)時，extension 通知 Dapr 進入休眠狀態(tài)；當(dāng)函數(shù)實例恢復(fù)運行之后，extension 通知 Dapr 重新恢復(fù)之前運行的狀態(tài)。Dapr 內(nèi)部的組件實現(xiàn)需要能支持這種方式的生命周期管理，以 Dubbo 為例，Dubbo 的注冊中心 nacos 需要定時往 Nacos server 發(fā)送心跳保持了解，同時 Dapr 集成的Dubbo Consumer也需要往Dubbo Provider 發(fā)送心跳。當(dāng)進入暫態(tài)之后，心跳都需要退出；當(dāng)恢復(fù)運行之后，整個運行狀態(tài)需要恢復(fù)。
?

上面講到的函數(shù)計算和 Dapr 結(jié)合的點，都是基于對外的流量，那么流入的流量呢？消息的流量是否可以直接流入到 Dapr ，而無需經(jīng)過 Gateway 呢？要做到這一點，還需要在 Dapr Sidecar 將一些性能數(shù)據(jù)及時上報給 Gateway ，方便 Gateway 可以做到資源的彈性。
?

SasS 業(yè)務(wù)上云

?

隨著阿里內(nèi)部孵化的SaaS業(yè)務(wù)越來越多，SaaS業(yè)務(wù)對外服務(wù)的訴求非常強烈。而SaaS業(yè)務(wù)對多云部署的訴求非常強烈，客戶期望SaaS業(yè)務(wù)能部署在阿里云公有云或者華為專有云上。而且客戶期望底層依賴的技術(shù)是開源的或者標(biāo)準(zhǔn)的云廠商的商業(yè)化產(chǎn)品。

以阿里一個SaaS業(yè)務(wù)上云來說明，左側(cè)是阿里內(nèi)部原來的系統(tǒng)，右側(cè)是改造之后的系統(tǒng)，改造的目標(biāo)是將依賴的阿里內(nèi)部的系統(tǒng)切換成開源軟件，Ali RPC切換到Dubbo，而阿里內(nèi)部的Cache，Message，Config分別切換到Redis、RocketMq和Nacos。期望通過Dapr來實現(xiàn)最小代價的切換。
?

既然想用Dapr來完成這個使命，那么最簡單粗暴的方法肯定是讓應(yīng)用依賴Dapr的SDK，但是這種方式改造成本太高，所以我們在保持原來API不變的情況下，將底層實現(xiàn)適配到Dapr SDK。通過這種方式，應(yīng)用就可以直接使用原來的API訪問Dapr，只需要升級對應(yīng)的依賴JAR包版本。改造之后，開發(fā)者還是面向原來的SDK進行編程，但是底層已經(jīng)被替換成了Dapr的面向能力編程，所以在遷移過程中，應(yīng)用可以使用一套代碼，而無需為每個云環(huán)境或者不同技術(shù)維護不同的分支。集團內(nèi)部用Dapr Sidecar的時候，會使用rpc.yaml、cache.yaml、msg.yaml、config.yaml來激活組件實現(xiàn)，而在公有云上回通過dubbo.yaml、redis.yaml、rocketmq.yaml、nacos.yaml文件來激活適合阿里云環(huán)境的組件實現(xiàn)。這種通過不同yaml文件激活不同組件來屏蔽組件實現(xiàn)的方式給SaaS業(yè)務(wù)多云部署形態(tài)帶來了極大的便利。
?

釘釘是Dapr的重要合作伙伴和推動者，和云原生團隊合作推進Dapr在釘釘落地。通過將一些中間件能力下沉到Dapr Sidecar之后，屏蔽了底層相似能力的中間件實現(xiàn)。但是釘釘還有自己的業(yè)務(wù)痛點，釘釘通用的業(yè)務(wù)組件是強業(yè)務(wù)綁定，需要具體的業(yè)務(wù)進行一些定制，這樣同時導(dǎo)致了復(fù)用度很低，所以釘釘期望通過將部分業(yè)務(wù)組件能力下沉到Dapr。這樣可以讓不同業(yè)務(wù)有相同的編程體驗，而組件維護者只需要維護好Components實現(xiàn)。

?

Dapr展望

?

基礎(chǔ)設(shè)施下沉成為軟件發(fā)展趨勢

?

軟件架構(gòu)的發(fā)展歷史及其精彩。回顧阿里巴巴系統(tǒng)架構(gòu)演進的歷史，能讓人了解國內(nèi)甚至全球的軟件架構(gòu)的發(fā)展歷史。淘寶最開始成立的時候，是單體應(yīng)用；隨著業(yè)務(wù)規(guī)模的發(fā)展，系統(tǒng)首先對硬件進行升級這種Scale Up的方式；但是很快發(fā)現(xiàn)這種方式遇到了各種各樣的問題，所以在2008年開始引入了微服務(wù)的解決方案；SOA的解決方案是分布式的，對于穩(wěn)定性，可觀測性等方面，需要引入熔斷、隔離、全鏈路監(jiān)控等高可用方案；接下來面臨的問題是怎么在機房、IDC層面來讓業(yè)務(wù)達(dá)到99.99%以上可用的SLA，這時候就有了同城雙機房、異地多活等解決方案。而隨著云技術(shù)的不斷發(fā)展，阿里巴巴擁抱和引導(dǎo)云原生技術(shù)的發(fā)展，積極擁抱云原生技術(shù)，以K8s為基礎(chǔ)，積極開展云原生技術(shù)的升級。

從這個歷史中，我們可以發(fā)現(xiàn)，軟件架構(gòu)新的訴求越來越多，原先底層基礎(chǔ)設(shè)施無法完成只能交給應(yīng)用側(cè)富SDK去完成，在K8s和容器逐漸成為標(biāo)準(zhǔn)之后，重新將微服務(wù)和一些分布式能力還給基礎(chǔ)設(shè)施。未來的趨勢是以Service Mesh和Dapr為代表的分布式能力下沉，釋放云和云原生技術(shù)發(fā)展的紅利。
?

云原生場景下的應(yīng)用開發(fā)者的訴求

?

未來的應(yīng)用開發(fā)者，應(yīng)該期望能夠面向能力，無言無關(guān)，不和具體云廠商和技術(shù)綁定的開發(fā)體驗，同時通過云技術(shù)的紅利能夠做到極致的彈性帶來的成本優(yōu)勢。我相信這個理想還是有可能實現(xiàn)的一天的，從當(dāng)前的角度出發(fā)，怎么樣才能完成這個目標(biāo)呢？

Multiple Runtime理念能夠真正落地，并且能夠持續(xù)發(fā)展；

以Dapr為例，期望能將Dapr面向分布式能力的API推動成為一個行業(yè)標(biāo)準(zhǔn)，并且這個標(biāo)準(zhǔn)是需要持續(xù)發(fā)展的；

K8s和Serverless技術(shù)的持續(xù)發(fā)展，未來可以將彈性做到極致。

?

Dapr 社區(qū)方向

?

最后來看下Dapr的社區(qū)發(fā)展：

1.推動 API 標(biāo)準(zhǔn)化，集成更多分布式能力；
2.更多Component集成，Dapr 生態(tài)完善；
3.更多公司落地，拓展產(chǎn)品邊界和打磨 Dapr 產(chǎn)品， 達(dá)到生產(chǎn)可用；
4.進入 CNCF， 成員云原生的 Multiple Runtime 的事實標(biāo)準(zhǔn)。

點擊https://developer.aliyun.com/community/cloudnative，了解更多云原生內(nèi)容

原文鏈接：https://developer.aliyun.com/article/785943?

版權(quán)聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的Dapr 在阿里云原生的实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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