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

作者 | 敖小劍 阿里雲高級技術專家、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 是一個基礎設施層，用於處理服務間通訊。現代雲原生應用有着復雜的服務拓撲，服務網格負責在這些拓撲中實現請求的可靠傳遞。 
在實踐中，服務網格通常實現為一組輕量級網絡代理，它們與應用程序部署在一起，而對應用程序透明。

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

• 定位基礎設施層；

• 功能是服務間通訊；

• 采用 Sidecar 部署；

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

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

2. Sidecar 模式

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

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

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

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

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

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

3. Service Mesh 的發展趨勢

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

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 有了很多的變化，但以下三個核心元素始終未變：

• 定位：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 形態：

這個圖片摘錄自我在 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 的理論出發點：

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

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

• 步驟一：將應用需要的分布式能力外移到各種 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 的理念引入到雲原生分布式應用的方式：

• 能力：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 的差異總結如下圖所示：

5. Multi-Runtime 的本質

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

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

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

如上圖所示，左側是分布式應用存在的四大類需求：生命周期、網絡、狀態、綁定。從需求上說 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？

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 定義的分析如下：

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

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

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

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

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

2. Dapr Sidecar 的功能和架構

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

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

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

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

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

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

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

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

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

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

• Dapr Building Blocks 提供“能力”。

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

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

3. Dapr 的願景和現有能力

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

• 居中藍色的是 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 目前已有的構建塊和他們提供的能力的簡單描述：

4. Dapr 的控制平面

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

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 項目中的主要貢獻公司之一，僅次於微軟：

• 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。

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

展望：應用和中間件的未來形態

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

1. 雲原生的時代背景

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

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

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

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

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

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

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

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

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

2. 應用的期望就是中間件的方向

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

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

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

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

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

• ……

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

應用對雲原生的期望，就是中間件前進的方向！

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

• 完善的多語言支持和應用輕量化的需求推動中間件將更多的能力從應用中分離出來。

• Sidecar 模式會推廣到更大的領域，越來越多的中間件產品會 開始 Mesh 化，整合到 Runtime。

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

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

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

在目前的雲原生領域，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 開發。