![1.png](https://ucc.alicdn.com/pic/developer-ecology/d2a143057519457cbdfbb7f9606ebe87.png)

作者 | 敖小劍  阿里雲高階技術專家、Dapr Maintainer

Dapr 是 2019 年 10 月微軟開源的分散式執行時，在今年 2 月份剛剛釋出了 v1.0 正式版本。雖然推出至今不過一年半時間，但 Dapr 發展勢頭十分迅猛，目前已經在 GitHub 上收穫了 1.2w 星。阿里是 Dapr 開源專案的深度參與者和早期採用者，率先進行了生產落地，集團內部有十幾個應用在使用 Dapr；目前已有 2 位 Dapr成員，是Dapr 專案中除微軟之外程式碼貢獻最多的公司。

雖然 Dapr 在國外有很高的關注度，但在國內知名度非常低，而且現有的少量 Dapr 資料也偏新聞資訊和簡單介紹，缺乏對 Dapr 的深度解讀。在 Dapr v1.0 釋出之際，我希望可以透過這篇文章幫助大家對 Dapr 形成一個準確的認知：掌握 Dapr 專案的發展脈絡，瞭解其核心價值和願景，領悟 Dapr 專案背後的“道之所在”—— 雲原生。

# 回顧：Service Mesh 原理和方向

## 1. Service Mesh 的定義

首先，讓我們先快速回顧一下“Service Mesh”的定義，這是 Dapr 故事的開始。

以下內容摘錄自我在 2017 年 10 月 QCon 上海做的演講 "Service Mesh：下一代微服務"：

>Service Mesh 是一個基礎設施層，用於處理服務間通訊。現代雲原生應用有著複雜的服務拓撲，服務網格負責在這些拓撲中實現請求的可靠傳遞。 
>在實踐中，服務網格通常實現為一組輕量級網路代理，它們與應用程式部署在一起，而對應用程式透明。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/00585cf75c78489eba8c076cdae1a3e4.png)

在 Service Mesh 的定義中，簡短地描述了 Service Mesh 的關鍵特徵：

- 定位基礎設施層；

- 功能是服務間通訊；

- 採用 Sidecar 部署；

- 特別強調無侵入、對應用透明。

熟悉 Service Mesh 的同學，想必對下面這張圖片不會陌生：

![3.png](https://ucc.alicdn.com/pic/developer-ecology/186f84ec356140b9af365c0d61284424.png)

## 2. Sidecar 模式

和傳統 RPC 框架相比，Service Mesh 的創新之處在於引入了 Sidecar 模式：

![4.png](https://ucc.alicdn.com/pic/developer-ecology/aa02bbf311354ac58e56282d1f366c99.png)

引入 Sidecar 之後，服務間通訊由 Sidecar 接管，而 Sidecar 由控制平面統一控制，從而實現了服務間通訊能力的下沉，使得應用得以大幅簡化。

我們再來快速回顧一下 Service Mesh 的基本思路：

![5.png](https://ucc.alicdn.com/pic/developer-ecology/de2924575d6b41b1886defc47c9ed8df.png)

- 引入 Sidecar 之前：業務邏輯和非業務邏輯混合在一個程式內，應用既有業務邏輯，也有各種非業務的功能（體現為各種客戶端 SDK）。

- 引入 Sidecar 之後：客戶端 SDK 的功能剝離，業務程式專注於業務邏輯，而 SDK 中的大部分功能被拆解為獨立程式，以 Sidecar 的模式執行。

透過引入 Sidecar 模式，Service Mesh 成功實現了 **關注點分離** 和 **獨立維護** 兩大目標。

## 3. Service Mesh 的發展趨勢

以 Istio 專案為例，我總結了最近一兩年來 Service Mesh 的發展趨勢（注意這些內容不是本文的重點，請快速閱讀，簡單瞭解即可）：

![6.png](https://ucc.alicdn.com/pic/developer-ecology/ea6bebc74d7a4690b15b47fa23aa8132.png)

### **1）協議支援**

Istio 中通訊協議的支援主要在 HTTP 和 gRPC，各家廠商在提供更多協議支援，包括 Dubbo、Thrift、Redis。也有一些社群力量在做補充，如趙化冰同學的 Aeraki 專案。

### **2）虛擬機器支援**

虛擬機器的支援最近成為 Istio 的重要關注點：

- Istio 0.2：Mesh Expansion
- Istio 1.1：ServiceEntry
- Istio 1.6：WorkloadEntry
- Istio 1.8：WorkloadGroup 和智慧 DNS 代理
- Istio 1.9：虛擬機器整合

### **3）易用性**

- Istio 1.5：控制平面單體化，合併多個元件為 istiod（這是 Istio 開源以來最大的一次架構調整之一）。

- Istio 1.7：主推 Operator 安裝方式，增強 istioctl 工具，支援在 Sidecar 啟動之後再啟動應用容器。

- Istio 1.8：改善升級和安裝, 引入 istioctl bug-report

### **4）可觀測性**

Istio 1.8：正式移除 Mixer，在 Envoy 基於 wasm 重新實現 Mixer 功能 （Istio 最大的架構調整之一）Istio 1.9：遠端獲取和載入 wasm 模組。

### **5）外部整合**

和非 service mesh 體系的相互訪問，實現應用在兩個體系之間的平滑遷移。

- Istio 曾計劃透過 MCP 協議提供統一的解決方案。

- Istio 1.7：MCP 協議被廢棄，改為 mcp over xds。

- Istio 1.9：Kubernetes Service API 支援 (alpha)，對外暴露服務。

從上面列出的內容，可以看到 Istio 在最近一兩年間還是在非常努力地完善自身，雖然過程有些曲折和往復（比如頑固不化的堅持 Mixer 到最後聽從全社群的呼喚徹底廢棄了 Mixer，開始支援虛擬機器後來實質性放棄再到最近重新重視，引入 Galley 再廢棄 Galley，引入 MCP 再變相放棄 MCP），但整體上說 Istio 還是在朝 Product Ready 的大方向在努力。

備註：當然，社群對 Istio 的演進速度以及 Product Ready 的實際狀態還是很不滿意的，以至於出現了這個梗：Make Istio Product Ready (Again, and Again…)。

## 4. Service Mesh 回顧總結

我們前面快速回顧了 Service Mesh 的定義、Sidecar 模式的原理，以及粗略羅列了一下最近一兩年間 Service Mesh 的發展趨勢，主要是為了告知大家這樣一個資訊：

> 雖然 Service Mesh 蓬勃發展，但核心元素始終未變。

從 2016 年 Linkerd 的 CEO William Morgon 給出 Service Mesh 的定義，到 2021 年 Istio 都發布到了 1.9 版本，整整六年期間，Service Mesh 有了很多的變化，但以下三個核心元素始終未變：

![7.png](https://ucc.alicdn.com/pic/developer-ecology/69f6533e35b34a5491d62fe25143384e.png)

- 定位：Service Mesh 的定位始終是提供 服務間通訊 的基礎設施層，範圍包括 HTTP 和 RPC——支援 HTTP1.1/REST，支援 HTTP2/gRPC，支援 TCP 協議。也有一些小的嘗試如對 Redis 、 Kafka 的支援。

- 部署：Service Mesh 支援 Kubernetes 和虛擬機器，但都是採用 Sidecar 模式部署，沒有采用其他方式如 Node 部署、中心化部署。

- 原理：Service Mesh 的工作原理是 原協議轉發，原則上不改變協議內容（通常只是 header 有些小改動）。為了達到零侵入的目標，還引入了 iptables 等流量劫持技術。

# 演進：雲原生分散式應用執行時

在快速完成 Service Mesh 的回顧之後，我們開始本文第二部分的內容：當 Sidecar 模式進一步推廣，上述三個核心元素髮生變化時，Sidecar 模式將會如何演進？

## 1. 實踐：更多 Mesh 形態

我之前在螞蟻金服的中介軟體團隊做 Service Mesh 相關的內容，可能很多朋友是從那個時候開始認識我。當時螞蟻不僅僅做了 Service Mesh，還將 Service Mesh 的 Sidecar 模式推廣到其他的中介軟體領域，陸陸續續探索了更多的 mesh 形態：

![8.png](https://ucc.alicdn.com/pic/developer-ecology/bf62e704ca90455287b2318c99d85606.png)

這個圖片摘錄自我在 2019 年 10 月的上海 QCon 上做的主題演講 "詩和遠方：螞蟻金服 Service Mesh 深度實踐"，當時我們分享了包括訊息 Mesh、資料庫 Mesh 等在內的多種 mesh 形態。

## 2. 理論昇華：Multi-Runtime 理念的提出

最近有越來越多的專案開始引入 Sidecar 模式， Sidecar 模式也逐漸被大家認可和接受。就在 2020 年，Bilgin Ibryam 提出了 Multi-Runtime 的理念，對基於 Sidecar 模式的各種產品形態進行了實踐總結和理論昇華。

首先我們介紹一下 Bilgin Ibryam 同學，他是《Kubernetes Patterns》一書的作者，Apache Camel 專案的 committer，目前工作於 Red Hat 。

2020 年初，Bilgin Ibryam 發表文章 "Multi-Runtime Microservices Architecture" ，正式提出了多執行時微服務架構（別名 Mecha/ 機甲，非常帥氣的名字）。在這篇文章中，Bilgin Ibryam 首先總結了分散式應用存在的四大類需求，作為 Multi-Runtime 的理論出發點：

![9.png](https://ucc.alicdn.com/pic/developer-ecology/ed9fb5e7887b45d38fdf70193dbb388c.png)

這四大類需求中，生命週期管理類的需求主要是透過 PaaS 平臺如 kubernetes 來滿足，而 Service Mesh 提供的主要是網路中的點對點通訊，對於其他通訊模式典型如 pub-sub 的訊息通訊模式並沒有覆蓋到，此外狀態類和繫結類的需求大多都和 Service Mesh 關係不大。

Multi-Runtime 的理論推導大體是這樣的——基於上述四大類需求，如果效仿 Service Mesh，從傳統中介軟體模式開始，那麼大體會有下面兩個步驟：

![10.png](https://ucc.alicdn.com/pic/developer-ecology/68a43de53fc142548dc4fead091da7ee.png)

- 步驟一：將應用需要的分散式能力外移到各種 runtime，此時會出現數量眾多的各種 Sidecar 或者 proxy，如上面中列出來的 Istio、Knative、Cloudstate、Camel、Dapr 等。

- 步驟二：這些 runtime 會逐漸整合，只保留少量甚至只有一兩個 runtime。這種提供多種分散式能力的 runtime 也被稱為 Mecha。

步驟二完成後，每個微服務就會由至少一個 Mecha Runtime 和應用 Runtime 共同組成，也就是每個微服務都會有多個（至少兩個）runtime，這也就是 Multi-Runtime / Mecha 名字的由來。

## 3. Multi-Runtime 和雲原生分散式應用

將 Multi-Runtime / Mecha 的理念引入到雲原生分散式應用的方式：

![11.png](https://ucc.alicdn.com/pic/developer-ecology/6ff1ff165cfa454093a903d692466070.png)

- 能力：Mecha 是通用的，高度可配置的，可重用的元件，提供分散式原語作為現成的能力。

- 部署：Mecha 可以與單個 Micrologic 元件一起部署（Sidecar 模式），也可以部署為多個共享（如 Node 模式）。

- 協議：Mecha 不對 Micrologic 執行時做任何假設。它與使用開放協議和格式（如 HTTP/gRPC，JSON，Protobuf，CloudEvents）的多語言微服務甚至單體一起使用。

- 配置：Mecha 以簡單的文字格式（例如 YAML，JSON）宣告式地配置，指示要啟用的功能以及如何將其繫結到 Micrologic 端點。

- 整合：與其依靠多個代理來實現不同的目的（例如網路代理，快取代理，繫結代理），不如使用一個 Mecha 提供所有這些能力。

## 4. Multi-Runtime 的特點和差異

雖然同為 Sidecar 模式，但是和 Service Mesh 相比，Multi-Runtime 有自身的特點：

- 提供能力的方式和範圍：Multi-Runtime 提供的是分散式能力，體現為應用需要的各種分散式原語，並不侷限於單純的服務間點對點通訊的網路代理.

- Runtime 部署的方式：Multi-Runtime 的部署模型，不侷限於 Sidecar 模式，Node 模式在某些場景下（如 Edge/IoT，Serverless FaaS）可能會是更好的選擇。

- 和 App 的互動方式：Multi-Runtime 和應用之間的互動是開放而有 API 標準的，Runtime 和 Micrologic 之間的“協議”體現在 API 上，而不是原生的 TCP 通訊協議。另外 Multi-Runtime 不要求無侵入，還會提供各種語言的 SDK 以簡化開發。

Multi-Runtime 和 Service Mesh 的差異總結如下圖所示：

![12.png](https://ucc.alicdn.com/pic/developer-ecology/2874b29b87ad4c92b7a74ad45e297888.png)

## 5. Multi-Runtime 的本質

至此我介紹了 Multi-Runtime 架構的由來，相信讀者對 Multi-Runtime 的特點以及和 Service Mesh 的差異已經有所瞭解。為了加深大家的理解，我來進一步分享一下我個人對 Multi-Runtime 的感悟：

**Multi-Runtime 的本質是面向雲原生應用的分散式能力抽象層。**

![13.png](https://ucc.alicdn.com/pic/developer-ecology/60787f06da52480fad6e3ffa8953c551.png)

何為 “分散式能力抽象層”?

如上圖所示，左側是分散式應用存在的四大類需求：生命週期、網路、狀態、繫結。從需求上說 Multi-Runtime 要為分散式應用提供這四大類需求下所列出的各種具體的分散式能力。以 Sidecar 模式為應用提供這些能力容易理解，但關鍵在於 Multi-Runtime 提供這些能力的方式。和 Service Mesh 採用原協議轉發不同，Multi-Runtime 的方式是：

- 將能力抽象為 API：很多分散式能力沒有類似 HTTP 這種業界通用的協議，因此 Multi-Runtime 的實現方式是將這些能力抽象為和通訊協議無關的 API，只用於描述應用對分散式能力的需求和意圖，儘量避免和某個實現繫結。

- 為每種能力提供多種實現：Multi-Runtime 中的能力一般都提供有多種實現，包括開源產品和公有云商業產品。

- 開發時：這裡我們引入一個“面對能力程式設計”的概念，類似於程式語言中的“不要面對實現程式設計，要面向介面程式設計”。Multi-Runtime 中提倡面向“能力（Capability）”程式設計，即應用開發者面向的應該是已經抽象好的分散式能力原語，而不是底層提供這些能力的具體實現。

- 執行時：透過配置在執行時選擇具體實現，不影響抽象層 API 的定義，也不影響遵循“面對能力程式設計”原則而開發完成的應用。

備註：分散式能力的通用標準 API，將會是 Multi-Runtime 成敗的關鍵，Dapr 的 API 在設計和實踐中也遇到很大的挑戰。關於這個話題，我稍後將單獨寫文章來闡述和分析。

# 介紹：分散式應用執行時 Dapr

在快速回顧 Service Mesh 和詳細介紹 multi-runtime 架構之後，我們已經為了解 Dapr 奠定了良好的基礎。現在終於可以開始本文的正式聶榮，讓我們一起來了解 Dapr 專案。

## 1. 什麼是 Dapr？

![14.png](https://ucc.alicdn.com/pic/developer-ecology/e7758e8e3710448095842ece8686bba2.png)

Dapr 是一個開源專案，由微軟發起，下面是來自 Dapr 官方網站的權威介紹：

Dapr is a portable, event-> driven runtime that makes it easy for any developer to build resilient, stateless and stateful applications that run on the cloud and edge and embraces the diversity of languages and developer frameworks. Dapr 是一個可移植的、事件驅動的執行時，它使任何開發者都能輕鬆地構建執行在雲和邊緣的彈性、無狀態和有狀態的應用程式，並擁抱語言和開發者框架的多樣性。

參考並對照 Service Mesh 的定義，我們對上述 Dapr 定義的分析如下：

![15.png](https://ucc.alicdn.com/pic/developer-ecology/939118f52ae14ca99cc198039550b460.png)

- 定位：Dapr 將自身定義為執行時（runtime），而不是 Service Mesh 中的 proxy。

- 功能：Dapr 為應用提供各種分散式能力，以簡化應用的開發。上面定義中提及的關鍵點有彈性、支援有狀態和無狀態、事件驅動。

- 多語言：對多語言的支援是 Sidecar 模型的天然優勢，Dapr 也不例外，考慮到 Dapr 為應用提交的分散式能力的數量，這可能比 Service Mesh 只提供服務間通訊能力對應用的價值更高。而且由於 Dapr 語言 SDK 的存在，Dapr 可以非常方便的和各程式語言的主流開發框架整合，如 Java 下和 Spring 框架整合。

- 可移植性：Dapr 適用的場景包括各種雲（公有云，私有云，混合雲）和邊緣網路，Multi-Runtime 架構的幾個關鍵特性如"面向能力程式設計"、標準 API、可執行時配置實現等為 Dapr 帶來了絕佳的跨雲跨平臺的可移植性。

我們將在後面的介紹中詳細展開 Dapr 的這些特性。在開始之前，這裡有一個小小的花絮—— “Dapr” 專案名字的由來：

![16.png](https://ucc.alicdn.com/pic/developer-ecology/1db06ce89cc2411497956afe8ed9d85d.png)

## 2. Dapr Sidecar 的功能和架構

和 Service Mesh 類似，Dapr 同樣基於 Sidecar 模式，但提供的功能和使用場景要比 Service Mesh 的複雜多，如下圖所示：

![17.png](https://ucc.alicdn.com/pic/developer-ecology/07709ac159314de487411ebd9177e57c.png)

Dapr 的 Sidecar，除了可以和 Service Mesh 一樣支援服務間通訊（目前支援 HTTP1.1/REST 協議和 gRPC 協議外，還可以支援到更多的功能，如 state（狀態管理）、pub-sub（訊息通訊），resource binding（資源繫結，包括輸入和輸出）。

每個功能都有多種實現，在上圖中我簡單摘錄了這幾個能力的常見實現，可以看到實現中既有開源產品，也有公有云的商業產品。注意這只是目前 Dapr 實現中的一小部分，目前各種實現（在 Dapr 中被稱為元件，我們下面會介紹）已經有超過 70 個，而且還在不斷的增加中。

在 Dapr 的架構中，有三個主要組成部分：API、Building Blocks 和 Components，如下圖所示：

![18.png](https://ucc.alicdn.com/pic/developer-ecology/919266cfe3f14bd0886d4c1a42f34a45.png)

- Dapr API：Dapr 提供兩種 API，HTTP1.1/REST 和 HTTP2/gRPC，兩者在功能上是對等的。

- Dapr Building Blocks：翻譯為構建塊，這是 Dapr 對外提供能力的基本單元，每個構建塊對外提供一種分散式能力。

- Dapr components：元件層，這是 Dapr 的能力實現層，每個元件都會實現特定構建塊的能力。

為了幫助大家理解 Dapr 的架構，我們回顧一下前面重點闡述的 Multi-Runtime 的本質：

![19.png](https://ucc.alicdn.com/pic/developer-ecology/1c395ed77dc84b4cb6efbd555e04568a.png)

Multi-Runtime 的本質是面向雲原生應用的分散式能力抽象層。

結合 Multi-Runtime 理念，我們再來理解 Dapr Runtime 的架構：

![20.png](https://ucc.alicdn.com/pic/developer-ecology/ab3e3be352d245b0b4b51acf288d17a4.png)

- Dapr Building Blocks 提供“能力”。

- Dapr API 提供對分散式能力的“抽象”，對外暴露 Building Block 的能力。

- Dapr Components 是 Building Block 能力的具體“實現”。

## 3. Dapr 的願景和現有能力

下圖來自 Dapr 官方，比較完善地概括了 Dapr 的能力和層次架構：

![21.png](https://ucc.alicdn.com/pic/developer-ecology/2a0137769e324123afe8cf7ef868458a.png)

- 居中藍色的是 Dapr Runtime：這裡列出了 Dapr 目前已經提供的構建塊。

- Dapr Runtime 對外透過遠端呼叫提供能力，目前有 HTTP API 和 gRPC API。

- 由於 Sidecar 模式的天然優勢，Dapr 支援各種程式語言，而且 Dapr 官方為主流語言（典型如 Java、golang、c++、nodejs、.net、python）提供了 SDK。這些 SDK 封裝了透過 HTTP API 或者 gRPC API 和 Dapr Runtime 進行互動的能力。

- 最下方是可以支援 Dapr 的雲平臺或者邊緣網路，由於每個能力都可以由不同的元件來完成，因此理論上只要 Dapr 的支援做的足夠完善，就可以實現在任何平臺上，總是能找到基於開源產品或者基於雲廠商商業化產品的可用元件。

結合以上幾點，Dapr 提出了這樣一個願景：

**Any language, any framework, anywhere**

即：可以使用任意程式語言開發，可以和任意框架整合，可以部署在任意平臺。下圖是 Dapr 目前已有的構建塊和他們提供的能力的簡單描述：

![22.png](https://ucc.alicdn.com/pic/developer-ecology/962f44859f5641e7b04703b3cdb02755.png)

## 4. Dapr 的控制平面

和 Service Mesh 的架構類似，Dapr 也有控制平面的概念：

![23.png](https://ucc.alicdn.com/pic/developer-ecology/835a1705ab3940da8e47ea222d3d9383.png)

Dapr 的控制平面元件有：

- Dapr Actor Placement
- Dapr Sidecar Injector
- Dapr Sentry
- Dapr Operator

比較有意思的是：Istio 為了簡化運維，已經將微服務架構的控制平面進行了合併，控制平面迴歸到傳統的單體模式。而 Dapr 的控制平面目前還是微服務架構，不知道未來會不會效仿 Istio。

備註：出於控制篇幅的考慮，本文不對 Dapr 的構建塊和控制平面進行詳細展開，稍後預計會另有單獨文章做詳細介紹，對 Dapr 有興趣的同學可以關注。

## 5. Dapr 的發展歷程和阿里巴巴的參與

Dapr 是一個非常新的開源專案，發展至今也才大約一年半的時間，不過社群關注度還不錯（主要是國外），在 GitHub 上目前有接近 12000 顆星（類比：Envoy 16000，Istio 26000，Linkerd 7000）。Dapr 專案的主要里程碑是：

- 2019 年 10 月：微軟在 GitHub 上開源了 Dapr，釋出 0.1.0 版本。

- 2021 年 2 月：Dapr v1.0 版本釋出。

阿里巴巴深度參與 Dapr 專案，不僅僅以終端使用者的身份成為 Dapr 的早起採用者，也透過全面參與 Dapr 的開源開發和程式碼貢獻成為目前 Dapr 專案中的主要貢獻公司之一，僅次於微軟：

![24.png](https://ucc.alicdn.com/pic/developer-ecology/157dd4a6e8684b4b9dc907038f50caeb.png)

- 2020 年中：阿里巴巴開始參與 Dapr 專案，在內部試用功能並進行程式碼開發。

- 2020 年底：阿里巴巴內部小規模試點 Dapr，目前已經十幾個應用在使用 Dapr 。

備註：關於 Dapr 在阿里巴巴的實踐，請參閱我們剛剛發表在 Dapr 官方部落格上的文章 "How Alibaba is using Dapr"。

目前我們已經有兩位 Dapr Committer 和一位 Dapr Maintainer，在 2021 年預計我們會在 Dapr 專案上有更多的投入，包括更多的開原始碼貢獻和落地實踐，身體力行的推動 Dapr 專案的發展。歡迎更多的國內貢獻者和國內公司一起加入到 Dapr 社群。

## 6. Dapr 快速體驗

在 Dapr 的官方文件中提供了 Dapr 安裝和 quickstudy 的內容，可以幫助大家快速的安裝和體驗 Dapr 的能力和使用方式。

為了更加快捷和方便的體驗 Dapr，我們透過 阿里雲知行動手實驗室 提供了一個超級簡單的 Dapr 入門教程，只要大約十分鐘就可以快速體驗 Dapr 的開發、部署過程：_[https://start.aliyun.com/course?id=gImrX5Aj](https://start.aliyun.com/course?id=gImrX5Aj)_。

有興趣的同學可以實際體驗一下。

# 展望：應用和中介軟體的未來形態

在本文的最後部分，我們展望一下應用和中間的未來形態。

## 1. 雲原生的時代背景

首先要申明的是，我們闡述的所有這些內容，都是基於一個大的前提：雲原生。

下面這張圖片，摘錄自我在 2019 年 10 月 QCon 大會上的演講 "詩和遠方：螞蟻金服 Service Mesh 深度實踐" :

![25.png](https://ucc.alicdn.com/pic/developer-ecology/783ea4fb176a4a77820c782ac8f76164.png)

當時（2019 年）我們剛完成了 Kubernetes 和 Service Mesh 的探索和大規模落地，並開始 Serverless 的新探索，我在文中做了一個雲原生落地總結和是否採納 Service Mesh 的建議，大體可以概括為（直接援引原文）：

- 有一點我們是非常明確的：Mesh 化是雲原生落地的關鍵步驟。

- 如果雲原生是你的詩和遠方，那麼 Service Mesh 就是必由之路。

- Kubernetes / Service Mesh / Serverless 是當下雲原生落地實踐的三駕馬車，相輔相成，相得益彰。

兩年之後的今天，回顧當時對雲原生髮展戰略大方向的判斷，感觸良多。上面這張圖片我稍加調整，增加了 Multi-Runtime/ 容器 / 多雲 / 混合雲的內容，修改如下圖：

![26.png](https://ucc.alicdn.com/pic/developer-ecology/6251d0a5f2b94503bef66f1d39aa7ea3.png)

和 2019 年相比，雲原生的理念得到了更廣泛的認可和採納：多雲、混合雲成為未來雲平臺的主流方向；Service Mesh 有了更多的落地實踐，有更多的公司使用 Service Mesh；Serverless 同樣在過去兩年間快速發展。

雲原生的歷史大潮還在進行中，而在雲原生背景下，應用和中介軟體將何去何從？

## 2. 應用的期望就是中介軟體的方向

讓我們暢想雲原生背景下處於最理想狀態的業務應用，就當是個甜美的夢吧：

- 應用可以使用任意喜愛而適合的語言編寫，可以快速開發和快速迭代。

- 應用需要的能力都可以透過標準的 API 提供，無需關心底層具體實現。

- 應用可以部署到任意的雲端，不管是公有云、私有云還是混合雲，沒有平臺和廠商限制，無需程式碼改造。

- 應用可以根據流量彈性伸縮，頂住波峰的壓力，也能在空閒時釋放資源。

- ……

我個人的對雲原生應用未來形態的看法是：Serverless 會是雲上應用的理想形態和主流發展方向；而多語言支援、跨雲的可移植性和應用輕量化將會是雲原生應用的三個核心訴求。

![27.png](https://ucc.alicdn.com/pic/developer-ecology/e89fe2500534430289fffe0cad82c6ac.png)

**應用對雲原生的期望，就是中介軟體前進的方向！**

過去幾年間，中介軟體在雲原生的美好目標推動下摸索著前進，未來幾年也必將還是如此。Service Mesh 探索了 Sidecar 模式，Dapr 將 Sidecar 模式推廣到更大的領域：

- 完善的多語言支援和應用輕量化的需求推動中介軟體將更多的能力從應用中分離出來。

- Sidecar 模式會推廣到更大的領域，越來越多的中介軟體產品會 開始 Mesh 化，整合到 Runtime。

- 對廠商鎖定的天然厭惡和規避，會加劇對可移植性的追求，從而進一步促使為下沉到 Runtime 的中分散式能力提供標準而業界通用的 API。

- API 的標準化和社群認可，將成為 Runtime 普及的最大挑戰，但同時也將推動各種中介軟體產品改進自身實現，實現中介軟體產品和社群標準 API 之間的磨合與完善。

在雲原生需求推動下，多語言支援、跨雲的可移植性和應用輕量化，預計將成為未來幾年間中介軟體產品的突破點和重點發展方向，如下圖所示：

![28.png](https://ucc.alicdn.com/pic/developer-ecology/4784196ecaa847bab274c54f199c3ab8.png)

在目前的雲原生領域，Dapr 專案是一個非常引人注目的新生力量。Dapr 是探路者，開啟 Multi-Runtime 理念的全新探索，而這必然是一個艱難的過程。非常期待有更多的個人和公司，和我們一起加入 Dapr 社群，一起探索，共同成長！

備註：關於 Dapr API 標準化的話題，以及 Dapr 在定義 API 和實現 API 遇到的挑戰，在現場曾有一段熱烈的討論，我將稍後整理出單獨的文章，結合 state API 的深度實踐和新的 configuration API 的設計過程，深入展開，敬請關注。

# 尾聲

在這篇文章的最後，讓我們用這麼一段話來總結全文：

Dapr 在 Service Mesh 的基礎上進一步擴充套件 Sidecar 模式的使用場景，一方面提供天然的多語言解決方案，滿足雲原生下應用對分散式能力的需求，幫助應用輕量化和 Serverless 化，另一方面提供面向應用的分散式能力抽象層和標準 API，為多雲、混合雲部署提供絕佳的可移植性，避免廠商鎖定。

**Dapr 將引領雲原生時代應用和中介軟體的未來**。

### 附錄：參考資料

本文相關的參考資料如下：

- Dapr 官網 和 Dapr 官方文件：部分 Dapr 介紹內容和圖片摘錄自 dapr 官方網站。

- Multi-Runtime Microservices Architecture: multi-runtime 介紹的內容和圖片部分援引自 Bilgin Ibryam 的這篇文章

### **作者簡介**

敖小劍，資深碼農，微服務專家，Service Mesh 佈道師，Dapr maintainer。專注於基礎架構，Cloud Native 擁護者，敏捷實踐者，堅守開發一線打磨匠藝的架構師。目前就職阿里雲，在雲原生應用平臺負責 Dapr 開發。

一年增加 1.2w 星，Dapr 能否引領雲原生中介軟體的未來？

相關文章