什么是Service Mesh？

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

Service Mesh 定義

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

Service Mesh 解決的痛點(diǎn)

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

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

Istio 介紹

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

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

Service Mesh 小結(jié)

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

Service Mesh 定位就是提供服務(wù)間通信的基礎(chǔ)設(shè)施，社區(qū)里主要支持 RPC 和http 。

采用 Sidecar 方式部署，支持部署在 Kubernetes 和虛擬機(jī)之上。

Service Mesh 采用原協(xié)議轉(zhuǎn)發(fā)，所以 Service Mesh 也被稱為網(wǎng)絡(luò)代理。正是由于這種方式方式，所以可以做到對(duì)應(yīng)用的零侵入。

什么是Dapr？

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

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

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

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

因?yàn)槌杀竞脱邪l(fā)效率等原因，F(xiàn)aaS 受到了越來(lái)越多客戶的選擇，F(xiàn)aaS 對(duì)多語(yǔ)言和編程 API 的友好性上有了更多訴求，那么 Service Mesh 在這兩塊還是不能給客戶帶來(lái)額外的的價(jià)值。

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

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

Multiple Runtime 理念推導(dǎo)

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

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

Mecha 的組件能力是抽象的，任何一個(gè)開(kāi)源產(chǎn)品可以快速進(jìn)行擴(kuò)展和集成。
Mecha 需要有一定的可配置能力，可以通過(guò) yaml/json 進(jìn)行配置和激活。這些文件格式最好能和主流的云原生方式對(duì)齊。
Mecha 提供標(biāo)準(zhǔn)的 API ，和主應(yīng)用之間的交互的網(wǎng)絡(luò)通信基于此 API 來(lái)完成，不再是原協(xié)議轉(zhuǎn)發(fā)，這樣對(duì)于組件擴(kuò)展和 SDK 的維護(hù)都能帶來(lái)極大的便利性。
分布式能力中的生命周期，可以將部分能力交接過(guò)底層的基礎(chǔ)設(shè)施，比如 K8s。當(dāng)然有些復(fù)雜的場(chǎng)景，可能需要 K8s、APP、Mecha Runtime 一起來(lái)完成。
既然最理想只剩下一個(gè) Runtime , 那么為什么還叫 Multiple Runtime 呢？因?yàn)閼?yīng)用本身其實(shí)也是一個(gè) Runtime ，再加上 Mecha Runtime ，所以至少是兩個(gè) Runtime 。

Dapr 介紹

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

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

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

Dapr 特性

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

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

Dapr 核心模塊

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

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

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

Dapr 核心：Component & Building Block

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

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

Dapr 整體架構(gòu)

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

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

Dapr 微軟落地場(chǎng)景

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

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

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

Dapr 小結(jié)

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

和 Service Mesh 差異點(diǎn)：

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

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

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

阿里在 Dapr 上的探索

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dapr展望

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

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

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

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

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

Multiple Runtime理念能夠真正落地，并且能夠持續(xù)發(fā)展；
以Dapr為例，期望能將Dapr面向分布式能力的API推動(dòng)成為一個(gè)行業(yè)標(biāo)準(zhǔn)，并且這個(gè)標(biāo)準(zhǔn)是需要持續(xù)發(fā)展的；
K8s和Serverless技術(shù)的持續(xù)發(fā)展，未來(lái)可以將彈性做到極致。