什么是Service Mesh？

從 2010 年的時(shí)候，SOA 架構(gòu)就已經(jīng)在中大型互聯(lián)網(wǎng)公司中開始流行，阿里也在2012 年開源了 Dubbo 。而之后微服務(wù)架構(gòu)開始流行，大量互聯(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ù)間通信來進(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ù)的通信。軍用三輪摩托車和 Service Mesh 非常相像，軍用三輪摩托車上一個(gè)士兵負(fù)責(zé)開車，一個(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)用開發(fā)者的要求比較高，需要有豐富的服務(wù)治理的運(yùn)維能力，有中間件的背景知識(shí)，使用中間件的門檻偏高。

通過 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 毫無疑問是當(dāng)中的王者。Istio 由控制面和數(shù)據(jù)面構(gòu)成，在 ServiceMesh 中，不同的 Service 之間，通過 Proxy Sidecar 進(jìn)行通信。Istio 最核心功能是流量管理，通過數(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ā)效率，成本主要通過按需分配和極致的彈性效率來達(dá)成。而應(yīng)用開發(fā)者期望通過 FaaS 提供多語言的編程環(huán)境，提升研發(fā)效率，包括啟動(dòng)時(shí)間、發(fā)布時(shí)間、開發(fā)的效率。

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

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

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

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

Bilgin Ibryam 是 Kubernetes Patterns 的作者，是 RedHat 的首席中間件架構(gòu)師，在 Apache 社區(qū)里非?；钴S。他發(fā)表了一篇文章對(duì)當(dāng)前分布式的一些困難和問題進(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 的理念來解決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 中，那么這種情況無論從運(yùn)維層面還是資源層面來看，都是沒辦法接受的。所以這時(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)本身問題不大，那么怎么整合呢？對(duì) Mecha 有什么要求呢？

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

Dapr 介紹

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

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

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

Dapr 特性

應(yīng)用開發(fā)者使用各種多語言的 Dapr SDK 就可以直接擁有各種分布式能力。當(dāng)然開發(fā)者也可以自己基于 HTTP 和 gRPC 來完成調(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)用開發(fā)者可以快速進(jìn)行選擇和使用。相似能力的組件的替換，可以通過 Dapr 里完成，應(yīng)用側(cè)可以做到無感知。

Dapr 核心模塊

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

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

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

Dapr 核心：Component & Building Block

Dapr Component 是 Dapr 插件擴(kuò)展的核心，是 Dapr 的 SPI ?，F(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提供出來的能力，支持 gRPC 和 HTTP 方式?，F(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 做安全和證書相關(guān)的工作，Sidecar Injector 主要負(fù)責(zé) Dapr Sidecar 的注入。Dapr 里激活某個(gè)組件實(shí)現(xiàn)是通過 YAML 文件來完成的，YAML 文件可以通過兩種方式來指定：一種是本地指定運(yùn)行時(shí)參數(shù)，另外一種是通過控制平面 Operator 來完成，將組件激活的文件以 K8s CRD 方式存儲(chǔ)并下發(fā)到 Dapr的Sidecar 中。控制面的 2 個(gè)核心組件都依賴于 K8s 來運(yùn)行?，F(xiàn)在的 Dapr Dashboard 功能還很弱，短期還不到增強(qiáng)的方向，現(xiàn)在各個(gè)組件的集成之后，各個(gè)組件的運(yùn)維還需要在原來的控制臺(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 來完成，依賴 Dapr 的 Input Binding 的大量組件實(shí)現(xiàn)，可以擴(kuò)大流量入口的類型。而 Connector 和 Dapr 的 Output Binding 或者 Service Invocation 的能力非常匹配，可以快速訪問外部資源。Azure Functions Dapr extensions 則是基于Azure Function extension 做的 Dapr 支持，可以讓 Azure Function 快速使用上Dapr 的各種 Building Block 的能力，同時(shí)能給函數(shù)開發(fā)者帶來多語言的相對(duì)簡(jiǎn)單一致的編程體驗(yàn)。

Azure API Management Service和上面提到的兩個(gè)落地場(chǎng)景的角度不太一致，它是前提是應(yīng)用之間已經(jīng)通過Dapr Sidecar方式進(jìn)行訪問，應(yīng)用的提供的服務(wù)通過Dapr來進(jìn)行暴露。這時(shí)候如果非K8s的應(yīng)用或者跨集群的應(yīng)用想要訪問當(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 ，能夠給開發(fā)者帶來支持多語言的一致的編程體驗(yàn)，同時(shí)這些 API 的SDK相對(duì)比較輕量級(jí)。這些特性非常適合 FaaS 場(chǎng)景。而隨著 Dapr 集成生態(tài)的不斷完善，開發(fā)者面向能力編程的優(yōu)勢(shì)將進(jìn)一步擴(kuò)大，通過 Dapr 可以更加方便地將 Dapr 組件的實(shí)現(xiàn)進(jìn)行替換，而無需開發(fā)者做代碼的調(diào)整。當(dāng)然原來的組件和新的組件實(shí)現(xiàn)，必須是相同類型的分布式能力。

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

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

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

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

阿里在 Dapr 上的探索

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

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

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

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

函數(shù)計(jì)算英文名是 Function Compute，簡(jiǎn)稱為 FC。FC 的架構(gòu)包含的系統(tǒng)比較多，和開發(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)有外部流量訪問函數(shù)計(jì)算的服務(wù)時(shí)，流量會(huì)先走到 Gateway ，Gateway 會(huì)根據(jù)訪問的內(nèi)容將流量轉(zhuǎn)發(fā)到提供當(dāng)前服務(wù)的函數(shù)實(shí)例中，函數(shù)實(shí)例接收到請(qǐng)求之后如果需要訪問外部資源，就可以通過Dapr 的多語言 SDK 來發(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)比較多，和開發(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)有外部流量訪問函數(shù)計(jì)算的服務(wù)時(shí)，流量會(huì)先走到 Gateway ，Gateway 會(huì)根據(jù)訪問的內(nèi)容將流量轉(zhuǎn)發(fā)到提供當(dāng)前服務(wù)的函數(shù)實(shí)例中，函數(shù)實(shí)例接收到請(qǐng)求之后如果需要訪問外部資源，就可以通過Dapr 的多語言 SDK 來發(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)行過于消耗資源，而且多個(gè)函數(shù)實(shí)例本身部署在一個(gè) Pod 中以便節(jié)省資源開支和秒級(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)久沒有流量訪問需要進(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)，來支持 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 ，而無需經(jīng)過 Gateway 呢？要做到這一點(diǎn)，還需要在 Dapr Sidecar 將一些性能數(shù)據(jù)及時(shí)上報(bào)給 Gateway ，方便 Gateway 可以做到資源的彈性。

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

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

以阿里一個(gè)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來實(shí)現(xiàn)最小代價(jià)的切換。

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

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

Dapr展望

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

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

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

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

未來的應(yīng)用開發(fā)者，應(yīng)該期望能夠面向能力，無言無關(guān)，不和具體云廠商和技術(shù)綁定的開發(fā)體驗(yàn)，同時(shí)通過云技術(shù)的紅利能夠做到極致的彈性帶來的成本優(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ā)展，未來可以將彈性做到極致。