一年增加 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 理念，我們再來了解 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 開發。