作者 | 敖小劍

Dapr 將引領(lǐng)云原生時(shí)代應(yīng)用和中間件的未來。

Dapr 是由微軟發(fā)起的云原生開源新項(xiàng)目，在今年 2 月份剛剛發(fā)布了 v1.0 正式版本。雖然推出至今不過一年半時(shí)間，但 Dapr 發(fā)展勢(shì)頭十分迅猛，目前已經(jīng)在 GitHub 上收獲了 1.2w 星。阿里是 Dapr 開源項(xiàng)目的深度參與者和早期采用者，率先進(jìn)行了生產(chǎn)落地，目前已有十幾個(gè)應(yīng)用在使用 Dapr。

雖然 Dapr 在國(guó)外有很高的關(guān)注度，但在國(guó)內(nèi)知名度非常低，而且現(xiàn)有的少量 Dapr 資料也偏新聞資訊和簡(jiǎn)單介紹，缺乏對(duì) Dapr 的深度解讀。在 Dapr v1.0 發(fā)布之際，我希望可以通過這篇文章幫助大家對(duì) Dapr 形成一個(gè)準(zhǔn)確的認(rèn)知：掌握 Dapr 項(xiàng)目的發(fā)展脈絡(luò)，了解其核心價(jià)值和愿景，領(lǐng)悟 Dapr 項(xiàng)目背后的“道之所在”—— 云原生。

1回顧：Service Mesh 原理和方向

Service Mesh 的定義

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

以下內(nèi)容摘錄自我在 2017 年 10 月 QCon 上海做的演講 “Service Mesh：下一代微服務(wù)”：

Service Mesh 是一個(gè)基礎(chǔ)設(shè)施層，用于處理服務(wù)間通訊。現(xiàn)代云原生應(yīng)用有著復(fù)雜的服務(wù)拓?fù)?#xff0c;服務(wù)網(wǎng)格負(fù)責(zé)在這些拓?fù)渲袑?shí)現(xiàn)請(qǐng)求的可靠傳遞。

在實(shí)踐中，服務(wù)網(wǎng)格通常實(shí)現(xiàn)為一組輕量級(jí)網(wǎng)絡(luò)代理，它們與應(yīng)用程序部署在一起，而對(duì)應(yīng)用程序透明。

在 Service Mesh 的定義中，簡(jiǎn)短地描述了 Service Mesh 的關(guān)鍵特征：1. 定位基礎(chǔ)設(shè)施層；2. 功能是服務(wù)間通訊；3. 采用 Sidecar 部署；4. 特別強(qiáng)調(diào)無侵入、對(duì)應(yīng)用透明。

熟悉 Service Mesh 的同學(xué)，想必對(duì)下面這張圖片不會(huì)陌生：

Sidecar 模式

和傳統(tǒng) RPC 框架相比，Service Mesh 的創(chuàng)新之處在于引入了 Sidecar 模式：

引入 Sidecar 之后，服務(wù)間通訊由 Sidecar 接管，而 Sidecar 由控制平面統(tǒng)一控制，從而實(shí)現(xiàn)了服務(wù)間通訊能力的下沉，使得應(yīng)用得以大幅簡(jiǎn)化。

我們?cè)賮砜焖倩仡櫼幌?Service Mesh 的基本思路：

• 引入 Sidecar 之前：業(yè)務(wù)邏輯和非業(yè)務(wù)邏輯混合在一個(gè)進(jìn)程內(nèi)，應(yīng)用既有業(yè)務(wù)邏輯，也有各種非業(yè)務(wù)的功能（體現(xiàn)為各種客戶端 SDK）。

• 引入 Sidecar 之后：客戶端 SDK 的功能剝離，業(yè)務(wù)進(jìn)程專注于業(yè)務(wù)邏輯，而 SDK 中的大部分功能被拆解為獨(dú)立進(jìn)程，以 Sidecar 的模式運(yùn)行。

通過引入 Sidecar 模式，Service Mesh 成功實(shí)現(xiàn)了 關(guān)注點(diǎn)分離 和 獨(dú)立維護(hù) 兩大目標(biāo)。

Service Mesh 的發(fā)展趨勢(shì)

以 Istio 項(xiàng)目為例，我總結(jié)了最近一兩年來 Service Mesh 的發(fā)展趨勢(shì)（注意這些內(nèi)容不是本文的重點(diǎn)，請(qǐng)快速閱讀，簡(jiǎn)單了解即可）：

?協(xié)議支持

Istio 中通訊協(xié)議的支持主要在 HTTP 和 gRPC，各家廠商在提供更多協(xié)議支持，包括 Dubbo、Thrift、Redis。也有一些社區(qū)力量在做補(bǔ)充，如趙化冰同學(xué)的 Aeraki 項(xiàng)目。

?虛擬機(jī)支持

虛擬機(jī)的支持最近成為 Istio 的重要關(guān)注點(diǎn)：

• Istio 0.2：Mesh Expansion

• Istio 1.1：ServiceEntry

• Istio 1.6：WorkloadEntry

• Istio 1.8：WorkloadGroup 和智能 DNS 代理

• Istio 1.9：虛擬機(jī)集成

?易用性

• Istio 1.5：控制平面單體化，合并多個(gè)組件為 istiod（這是 Istio 開源以來最大的架構(gòu)調(diào)整之一）

• Istio 1.7：主推 Operator 安裝方式，增強(qiáng) istioctl 工具，支持在 Sidecar 啟動(dòng)之后再啟動(dòng)應(yīng)用容器

• Istio 1.8：改善升級(jí)和安裝， 引入 istioctl bug-report

?可觀測(cè)性

Istio 1.8：正式移除 Mixer，在 Envoy 基于 wasm 重新實(shí)現(xiàn) Mixer 功能 （Istio 最大的架構(gòu)調(diào)整之一）Istio 1.9：遠(yuǎn)程獲取和加載 wasm 模塊

?外部集成

通過與非 service mesh 體系的相互訪問，實(shí)現(xiàn)應(yīng)用在兩個(gè)體系之間的平滑遷移。

• Istio 曾計(jì)劃通過 MCP 協(xié)議提供統(tǒng)一的解決方案

• Istio 1.7：MCP 協(xié)議被廢棄，改為 mcp over xds

• Istio 1.9：Kubernetes Service API 支持 (alpha)，對(duì)外暴露服務(wù)

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

備注：當(dāng)然，社區(qū)對(duì) Istio 的演進(jìn)速度以及 Product Ready 的實(shí)際狀態(tài)還是很不滿意的，以至于出現(xiàn)了這個(gè)梗：Make Istio Product Ready (Again, and Again…)

Service Mesh 回顧總結(jié)

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

雖然 Service Mesh 蓬勃發(fā)展，但核心元素始終未變

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

定位：Service Mesh 的定位始終是提供 服務(wù)間通訊 的基礎(chǔ)設(shè)施層，范圍包括 HTTP 和 RPC——支持 HTTP1.1/REST，支持 HTTP2/gRPC，支持 TCP 協(xié)議。也有一些小的嘗試如對(duì) Redis 、 Kafka 的支持。

部署：Service Mesh 支持 Kubernetes 和虛擬機(jī)，但都是采用 Sidecar 模式部署，沒有采用其他方式如 Node 部署、中心化部署。

原理：Service Mesh 的工作原理是 原協(xié)議轉(zhuǎn)發(fā)，原則上不改變協(xié)議內(nèi)容（通常只是 header 有些小改動(dòng)）。為了達(dá)到零侵入的目標(biāo)，還引入了 iptables 等流量劫持技術(shù)。

2演進(jìn)：云原生分布式應(yīng)用運(yùn)行時(shí)

在快速完成 Service Mesh 的回顧之后，我們開始本文第二部分的內(nèi)容：當(dāng) Sidecar 模式進(jìn)一步推廣，上述三個(gè)核心元素發(fā)生變化時(shí)，Sidecar 模式將會(huì)如何演進(jìn)？

實(shí)踐：更多 Mesh 形態(tài)

我之前在螞蟻金服的中間件團(tuán)隊(duì)做 Service Mesh 相關(guān)的內(nèi)容，可能很多朋友是從那個(gè)時(shí)候開始認(rèn)識(shí)我。當(dāng)時(shí)螞蟻不僅僅做了 Service Mesh，還將 Service Mesh 的 Sidecar 模式推廣到其他的中間件領(lǐng)域，陸陸續(xù)續(xù)探索了更多的 mesh 形態(tài)：

這個(gè)圖片摘錄自我在 2019 年 10 月的上海 QCon 上做的主題演講 "詩和遠(yuǎn)方：螞蟻金服 Service Mesh 深度實(shí)踐"，當(dāng)時(shí)我們分享了包括消息 Mesh、數(shù)據(jù)庫 Mesh 等在內(nèi)的多種 mesh 形態(tài)。

理論升華：Multi-Runtime 理念的提出

最近有越來越多的項(xiàng)目開始引入 Sidecar 模式， Sidecar 模式也逐漸被大家認(rèn)可和接受。就在 2020 年，Bilgin Ibryam 提出了 Multi-Runtime 的理念，對(duì)基于 Sidecar 模式的各種產(chǎn)品形態(tài)進(jìn)行了實(shí)踐總結(jié)和理論升華。

首先我們介紹一下 Bilgin Ibryam 同學(xué)，他是《Kubernetes Patterns》一書的作者，Apache Camel 項(xiàng)目的 committer，目前工作于 Red Hat 。

2020 年初，Bilgin Ibryam 發(fā)表文章 "Multi-Runtime Microservices Architecture" ，正式提出了多運(yùn)行時(shí)微服務(wù)架構(gòu)（別名 Mecha/ 機(jī)甲，非常帥氣的名字）。在這篇文章中，Bilgin Ibryam 首先總結(jié)了分布式應(yīng)用存在的四大類需求，作為 Multi-Runtime 的理論出發(fā)點(diǎn)：

這四大類需求中，生命周期管理類的需求主要是通過 PaaS 平臺(tái)如 kubernetes 來滿足，而 Service Mesh 提供的主要是網(wǎng)絡(luò)中的點(diǎn)對(duì)點(diǎn)通訊，對(duì)于其他通訊模式典型如 pub-sub 的消息通訊模式并沒有覆蓋到，此外狀態(tài)類和綁定類的需求大多都和 Service Mesh 關(guān)系不大。

Multi-Runtime 的理論推導(dǎo)大體是這樣的——基于上述四大類需求，如果效仿 Service Mesh，從傳統(tǒng)中間件模式開始，那么大體會(huì)有下面兩個(gè)步驟：

步驟一：將應(yīng)用需要的分布式能力外移到各種 runtime，此時(shí)會(huì)出現(xiàn)數(shù)量眾多的各種 Sidecar 或者 proxy，如上面中列出來的 Istio、Knative、Cloudstate、Camel、Dapr 等。

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

步驟二完成后，每個(gè)微服務(wù)就會(huì)由至少一個(gè) Mecha Runtime 和應(yīng)用 Runtime 共同組成，也就是每個(gè)微服務(wù)都會(huì)有多個(gè)（至少兩個(gè)）runtime，這也就是 Multi-Runtime / Mecha 名字的由來。

Multi-Runtime 和云原生分布式應(yīng)用

將 Multi-Runtime / Mecha 的理念引入到云原生分布式應(yīng)用的方式：

• 能力：Mecha 是通用的，高度可配置的，可重用的組件，提供分布式原語作為現(xiàn)成的能力。

• 部署：Mecha 可以與單個(gè) Micrologic 組件一起部署（Sidecar 模式），也可以部署為多個(gè)共享（如 Node 模式）。

• 協(xié)議：Mecha 不對(duì) Micrologic 運(yùn)行時(shí)做任何假設(shè)。它與使用開放協(xié)議和格式（如 HTTP/gRPC，JSON，Protobuf，CloudEvents）的多語言微服務(wù)甚至單體一起使用。

• 配置：Mecha 以簡(jiǎn)單的文本格式（例如 YAML，JSON）聲明式地配置，指示要啟用的功能以及如何將其綁定到 Micrologic 端點(diǎn)。

• 整合：與其依靠多個(gè)代理來實(shí)現(xiàn)不同的目的（例如網(wǎng)絡(luò)代理，緩存代理，綁定代理），不如使用一個(gè) Mecha 提供所有這些能力。

Multi-Runtime 的特點(diǎn)和差異

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

• 提供能力的方式和范圍：Multi-Runtime 提供的是分布式能力，體現(xiàn)為應(yīng)用需要的各種分布式原語，并不局限于單純的服務(wù)間點(diǎn)對(duì)點(diǎn)通訊的網(wǎng)絡(luò)代理

• Runtime 部署的方式：Multi-Runtime 的部署模型，不局限于 Sidecar 模式，Node 模式在某些場(chǎng)景下（如 Edge/IoT，Serverless FaaS）可能會(huì)是更好的選擇。

• 和 App 的交互方式：Multi-Runtime 和應(yīng)用之間的交互是開放而有 API 標(biāo)準(zhǔn)的，Runtime 和 Micrologic 之間的“協(xié)議”體現(xiàn)在 API 上，而不是原生的 TCP 通訊協(xié)議。另外 Multi-Runtime 不要求無侵入，還會(huì)提供各種語言的 SDK 以簡(jiǎn)化開發(fā)。

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

Multi-Runtime 的本質(zhì)

至此我介紹了 Multi-Runtime 架構(gòu)的由來，相信讀者對(duì) Multi-Runtime 的特點(diǎn)以及和 Service Mesh 的差異已經(jīng)有所了解。為了加深大家的理解，我來進(jìn)一步分享一下我個(gè)人對(duì) Multi-Runtime 的感悟：

Multi-Runtime 的本質(zhì)是面向云原生應(yīng)用的 分布式能力抽象層

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

如上圖所示，左側(cè)是分布式應(yīng)用存在的四大類需求：生命周期、網(wǎng)絡(luò)、狀態(tài)、綁定。從需求上說 Multi-Runtime 要為分布式應(yīng)用提供這四大類需求下所列出的各種具體的分布式能力。以 Sidecar 模式為應(yīng)用提供這些能力容易理解，但關(guān)鍵在于 Multi-Runtime 提供這些能力的方式。和 Service Mesh 采用原協(xié)議轉(zhuǎn)發(fā)不同，Multi-Runtime 的方式是：

• 將能力抽象為 API：很多分布式能力沒有類似 HTTP 這種業(yè)界通用的協(xié)議，因此 Multi-Runtime 的實(shí)現(xiàn)方式是將這些能力抽象為和通訊協(xié)議無關(guān)的 API，只用于描述應(yīng)用對(duì)分布式能力的需求和意圖，盡量避免和某個(gè)實(shí)現(xiàn)綁定。

• 為每種能力提供多種實(shí)現(xiàn)：Multi-Runtime 中的能力一般都提供有多種實(shí)現(xiàn)，包括開源產(chǎn)品和公有云商業(yè)產(chǎn)品。

• 開發(fā)時(shí)：這里我們引入一個(gè)“面對(duì)能力編程”的概念，類似于編程語言中的“不要面對(duì)實(shí)現(xiàn)編程，要面向接口編程”。Multi-Runtime 中提倡面向“能力（Capability）”編程，即應(yīng)用開發(fā)者面向的應(yīng)該是已經(jīng)抽象好的分布式能力原語，而不是底層提供這些能力的具體實(shí)現(xiàn)。

• 運(yùn)行時(shí)：通過配置在運(yùn)行時(shí)選擇具體實(shí)現(xiàn)，不影響抽象層 API 的定義，也不影響遵循“面對(duì)能力編程”原則而開發(fā)完成的應(yīng)用。

備注：分布式能力的通用標(biāo)準(zhǔn) API，將會(huì)是 Multi-Runtime 成敗的關(guān)鍵，Dapr 的 API 在設(shè)計(jì)和實(shí)踐中也遇到很大的挑戰(zhàn)。關(guān)于這個(gè)話題，我稍后將單獨(dú)寫文章來闡述和分析。

3介紹：分布式應(yīng)用運(yùn)行時(shí) Dapr

在快速回顧 Service Mesh 和詳細(xì)介紹 multi-runtime 架構(gòu)之后，我們已經(jīng)為了解 Dapr 奠定了良好的基礎(chǔ)。現(xiàn)在終于可以開始本文的正式內(nèi)容，讓我們一起來了解 Dapr 項(xiàng)目。

什么是 Dapr？

Dapr 是一個(gè)開源項(xiàng)目，由微軟發(fā)起，下面是來自 Dapr 官方網(wǎng)站的權(quán)威介紹：

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 是一個(gè)可移植的、事件驅(qū)動(dòng)的運(yùn)行時(shí)，它使任何開發(fā)者都能輕松地構(gòu)建運(yùn)行在云和邊緣的彈性、無狀態(tài)和有狀態(tài)的應(yīng)用程序，并擁抱語言和開發(fā)者框架的多樣性。

參考并對(duì)照 Service Mesh 的定義，我們對(duì)上述 Dapr 定義的分析如下：

• 定位：Dapr 將自身定義為運(yùn)行時(shí)（runtime），而不是 Service Mesh 中的 proxy。

• 功能：Dapr 為應(yīng)用提供各種分布式能力，以簡(jiǎn)化應(yīng)用的開發(fā)。上面定義中提及的關(guān)鍵點(diǎn)有彈性、支持有狀態(tài)和無狀態(tài)、事件驅(qū)動(dòng)。

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

• 可移植性：Dapr 適用的場(chǎng)景包括各種云（公有云，私有云，混合云）和邊緣網(wǎng)絡(luò)，Multi-Runtime 架構(gòu)的幾個(gè)關(guān)鍵特性如"面向能力編程"、標(biāo)準(zhǔn) API、可運(yùn)行時(shí)配置實(shí)現(xiàn)等為 Dapr 帶來了絕佳的跨云跨平臺(tái)的可移植性。

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

Dapr Sidecar 的功能和架構(gòu)

和 Service Mesh 類似，Dapr 同樣基于 Sidecar 模式，但提供的功能和使用場(chǎng)景要比 Service Mesh 的復(fù)雜多，如下圖所示：

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

每個(gè)功能都有多種實(shí)現(xiàn)，在上圖中我簡(jiǎn)單摘錄了這幾個(gè)能力的常見實(shí)現(xiàn)，可以看到實(shí)現(xiàn)中既有開源產(chǎn)品，也有公有云的商業(yè)產(chǎn)品。注意這只是目前 Dapr 實(shí)現(xiàn)中的一小部分，目前各種實(shí)現(xiàn)（在 Dapr 中被稱為組件，我們下面會(huì)介紹）已經(jīng)有超過 70 個(gè)，而且還在不斷的增加中。

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

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

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

• Dapr components：組件層，這是 Dapr 的能力實(shí)現(xiàn)層，每個(gè)組件都會(huì)實(shí)現(xiàn)特定構(gòu)建塊的能力。

為了幫助大家理解 Dapr 的架構(gòu)，我們回顧一下前面重點(diǎn)闡述的 Multi-Runtime 的本質(zhì)：

Multi-Runtime 的本質(zhì)是面向云原生應(yīng)用的分布式能力抽象層

結(jié)合 Multi-Runtime 理念，我們?cè)賮砝斫?Dapr Runtime 的架構(gòu)：

• Dapr Building Blocks 提供“能力”

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

• Dapr Components 是 Building Block 能力的具體“實(shí)現(xiàn)”

Dapr 的愿景和現(xiàn)有能力

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

• 居中藍(lán)色的是 Dapr Runtime：這里列出了 Dapr 目前已經(jīng)提供的構(gòu)建塊

• Dapr Runtime 對(duì)外通過遠(yuǎn)程調(diào)用提供能力，目前有 HTTP API 和 gRPC API

• 由于 Sidecar 模式的天然優(yōu)勢(shì)，Dapr 支持各種編程語言，而且 Dapr 官方為主流語言（典型如 Java、golang、c++、nodejs、.net、python）提供了 SDK。這些 SDK 封裝了通過 HTTP API 或者 gRPC API 和 Dapr Runtime 進(jìn)行交互的能力。

• 最下方是可以支持 Dapr 的云平臺(tái)或者邊緣網(wǎng)絡(luò)，由于每個(gè)能力都可以由不同的組件來完成，因此理論上只要 Dapr 的支持做的足夠完善，就可以實(shí)現(xiàn)在任何平臺(tái)上，總是能找到基于開源產(chǎn)品或者基于云廠商商業(yè)化產(chǎn)品的可用組件。

結(jié)合以上幾點(diǎn)，Dapr 提出了這樣一個(gè)愿景：

Any language, any framework, anywhere

即：可以使用任意編程語言開發(fā)，可以和任意框架集成，可以部署在任意平臺(tái)。

下圖是 Dapr 目前已有的構(gòu)建塊和他們提供的能力的簡(jiǎn)單描述：

Dapr 的控制平面

和 Service Mesh 的架構(gòu)類似，Dapr 也有控制平面的概念：

Dapr 的控制平面組件有：

• Dapr Actor Placement

• Dapr Sidecar Injector

• Dapr Sentry

• Dapr Operator

比較有意思的是：Istio 為了簡(jiǎn)化運(yùn)維，已經(jīng)將微服務(wù)架構(gòu)的控制平面進(jìn)行了合并，控制平面回歸到傳統(tǒng)的單體模式。而 Dapr 的控制平面目前還是微服務(wù)架構(gòu)，不知道未來會(huì)不會(huì)效仿 Istio。

備注：出于控制篇幅的考慮，本文不對(duì) Dapr 的構(gòu)建塊和控制平面進(jìn)行詳細(xì)展開，稍后預(yù)計(jì)會(huì)另有單獨(dú)文章做詳細(xì)介紹，對(duì) Dapr 有興趣的同學(xué)可以關(guān)注。

Dapr 的發(fā)展歷程和阿里巴巴的參與

Dapr 是一個(gè)非常新的開源項(xiàng)目，發(fā)展至今也才大約一年半的時(shí)間，不過社區(qū)關(guān)注度還不錯(cuò)（主要是國(guó)外），在 GitHub 上目前有接近 12000 顆星（類比：Envoy 16000，Istio 26000，Linkerd 7000）。Dapr 項(xiàng)目的主要里程碑是：

• 2019 年 10 月：微軟在 GitHub 上開源了 Dapr，發(fā)布 0.1.0 版本

• 2021 年 2 月：Dapr v1.0 版本發(fā)布

阿里巴巴深度參與 Dapr 項(xiàng)目，不僅僅以終端用戶的身份成為 Dapr 的早期采用者，也通過全面參與 Dapr 的開源開發(fā)和代碼貢獻(xiàn)成為目前 Dapr 項(xiàng)目中的主要貢獻(xiàn)公司之一，僅次于微軟：

• 2020 年中：阿里巴巴開始參與 Dapr 項(xiàng)目，在內(nèi)部試用功能并進(jìn)行代碼開發(fā)

• 2020 年底：阿里巴巴內(nèi)部小規(guī)模試點(diǎn) Dapr，目前已經(jīng)十幾個(gè)應(yīng)用在使用 Dapr 。

備注：關(guān)于 Dapr 在阿里巴巴的實(shí)踐，請(qǐng)參閱我們剛剛發(fā)表在 Dapr 官方博客上的文章 "How Alibaba is using Dapr"

目前我們已經(jīng)有兩位 Dapr Committer 和一位 Dapr Maintainer，在 2021 年預(yù)計(jì)我們會(huì)在 Dapr 項(xiàng)目上有更多的投入，包括更多的開源代碼貢獻(xiàn)和落地實(shí)踐，身體力行的推動(dòng) Dapr 項(xiàng)目的發(fā)展。歡迎更多的國(guó)內(nèi)貢獻(xiàn)者和國(guó)內(nèi)公司一起加入到 Dapr 社區(qū)。

Dapr 快速體驗(yàn)

在 Dapr 的官方文檔中提供了 Dapr 安裝和 quickstudy 的內(nèi)容，可以幫助大家快速的安裝和體驗(yàn) Dapr 的能力和使用方式。

為了更加快捷和方便的體驗(yàn) Dapr，我們通過 阿里云知行動(dòng)手實(shí)驗(yàn)室 提供了一個(gè)超級(jí)簡(jiǎn)單的 Dapr 入門教程，只要大約十分鐘就可以快速體驗(yàn) Dapr 的開發(fā)、部署過程：

https://start.aliyun.com/course?id=gImrX5Aj

有興趣的同學(xué)可以實(shí)際體驗(yàn)一下。

4展望：應(yīng)用和中間件的未來形態(tài)

在本文的最后部分，我們展望一下應(yīng)用和中間的未來形態(tài)。

云原生的時(shí)代背景

首先要申明的是，我們闡述的所有這些內(nèi)容，都是基于一個(gè)大的前提：云原生。

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

當(dāng)時(shí)（2019 年）我們剛完成了 Kubernetes 和 Service Mesh 的探索和大規(guī)模落地，并開始 Serverless 的新探索，我在文中做了一個(gè)云原生落地總結(jié)和是否采納 Service Mesh 的建議，大體可以概括為（直接援引原文）：

• 有一點(diǎn)我們是非常明確的：Mesh 化是云原生落地的關(guān)鍵步驟

• 如果云原生是你的詩和遠(yuǎn)方，那么 Service Mesh 就是必由之路。

• Kubernetes / Service Mesh / Serverless 是當(dāng)下云原生落地實(shí)踐的三駕馬車，相輔相成，相得益彰。

兩年之后的今天，回顧當(dāng)時(shí)對(duì)云原生發(fā)展戰(zhàn)略大方向的判斷，感觸良多。上面這張圖片我稍加調(diào)整，增加了 Multi-Runtime/ 容器 / 多云 / 混合云的內(nèi)容，修改如下圖：

和 2019 年相比，云原生的理念得到了更廣泛的認(rèn)可和采納：多云、混合云成為未來云平臺(tái)的主流方向；Service Mesh 有了更多的落地實(shí)踐，有更多的公司使用 Service Mesh；Serverless 同樣在過去兩年間快速發(fā)展。

云原生的歷史大潮還在進(jìn)行中，而在云原生背景下，應(yīng)用和中間件將何去何從？

應(yīng)用的期望就是中間件的方向

讓我們暢想云原生背景下處于最理想狀態(tài)的業(yè)務(wù)應(yīng)用，就當(dāng)是個(gè)甜美的夢(mèng)吧：

• 應(yīng)用可以使用任意喜愛而適合的語言編寫，可以快速開發(fā)和快速迭代。

• 應(yīng)用需要的能力都可以通過標(biāo)準(zhǔn)的 API 提供，無需關(guān)心底層具體實(shí)現(xiàn)。

• 應(yīng)用可以部署到任意的云端，不管是公有云、私有云還是混合云，沒有平臺(tái)和廠商限制，無需代碼改造。

• 應(yīng)用可以根據(jù)流量彈性伸縮，頂住波峰的壓力，也能在空閑時(shí)釋放資源。

• ……

我個(gè)人對(duì)云原生應(yīng)用未來形態(tài)的看法是：Serverless 會(huì)是云上應(yīng)用的理想形態(tài)和主流發(fā)展方向；而多語言支持、跨云的可移植性和應(yīng)用輕量化將會(huì)是云原生應(yīng)用的三個(gè)核心訴求。

應(yīng)用對(duì)云原生的期望，就是中間件前進(jìn)的方向！

過去幾年間，中間件在云原生的美好目標(biāo)推動(dòng)下摸索著前進(jìn)，未來幾年也必將還是如此。Service Mesh 探索了 Sidecar 模式，Dapr 將 Sidecar 模式推廣到更大的領(lǐng)域：

• 完善的多語言支持和應(yīng)用輕量化的需求推動(dòng)中間件將更多的能力從應(yīng)用中分離出來

• Sidecar 模式會(huì)推廣到更大的領(lǐng)域，越來越多的中間件產(chǎn)品會(huì) 開始 Mesh 化，整合到 Runtime。

• 對(duì)廠商鎖定的天然厭惡和規(guī)避，會(huì)加劇對(duì)可移植性的追求，從而進(jìn)一步促使為下沉到 Runtime 中的分布式能力提供標(biāo)準(zhǔn)而業(yè)界通用的 API。

• API 的標(biāo)準(zhǔn)化和社區(qū)認(rèn)可，將成為 Runtime 普及的最大挑戰(zhàn)，但同時(shí)也將推動(dòng)各種中間件產(chǎn)品改進(jìn)自身實(shí)現(xiàn)，實(shí)現(xiàn)中間件產(chǎn)品和社區(qū)標(biāo)準(zhǔn) API 之間的磨合與完善。

在云原生需求推動(dòng)下，多語言支持、跨云的可移植性和應(yīng)用輕量化，預(yù)計(jì)將成為未來幾年間中間件產(chǎn)品的突破點(diǎn)和重點(diǎn)發(fā)展方向，如下圖所示：

在目前的云原生領(lǐng)域，Dapr 項(xiàng)目是一個(gè)非常引人注目的新生力量。Dapr 是探路者，開啟 Multi-Runtime 理念的全新探索，而這必然是一個(gè)艱難的過程。非常期待有更多的個(gè)人和公司，和我們一起加入 Dapr 社區(qū)，一起探索，共同成長(zhǎng)！

備注：關(guān)于 Dapr API 標(biāo)準(zhǔn)化的話題，以及 Dapr 在定義 API 和實(shí)現(xiàn) API 遇到的挑戰(zhàn)，在現(xiàn)場(chǎng)曾有一段熱烈的討論，我將稍后整理出單獨(dú)的文章，結(jié)合 state API 的深度實(shí)踐和新的 configuration API 的設(shè)計(jì)過程，深入展開，敬請(qǐng)關(guān)注。

5尾聲

在這篇文章的最后，讓我們用這么一段話來總結(jié)全文：

Dapr 在 Service Mesh 的基礎(chǔ)上進(jìn)一步擴(kuò)展 Sidecar 模式的使用場(chǎng)景，一方面提供天然的多語言解決方案，滿足云原生下應(yīng)用對(duì)分布式能力的需求，幫助應(yīng)用輕量化和 Serverless 化，另一方面提供面向應(yīng)用的分布式能力抽象層和標(biāo)準(zhǔn) API，為多云、混合云部署提供絕佳的可移植性，避免廠商鎖定。

Dapr 將引領(lǐng)云原生時(shí)代應(yīng)用和中間件的未來。

附錄：參考資料

本文相關(guān)的參考資料如下：

• Dapr 官網(wǎng) 和 Dapr 官方文檔：部分 Dapr 介紹內(nèi)容和圖片摘錄自 dapr 官方網(wǎng)站

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

作者介紹

敖小劍，資深碼農(nóng)，微服務(wù)專家，Service Mesh 布道師，Dapr maintainer。專注于基礎(chǔ)架構(gòu)，Cloud Native 擁護(hù)者，敏捷實(shí)踐者，堅(jiān)守開發(fā)一線打磨匠藝的架構(gòu)師。目前就職阿里云，在云原生應(yīng)用平臺(tái)負(fù)責(zé) Dapr 開發(fā)。

相關(guān)文章：

• 云原生 | 阿里巴巴的Dapr實(shí)踐與探索

• Dapr 可視化指南

• Dapr 知多少 | 分布式應(yīng)用運(yùn)行時(shí)

• Dapr 正式發(fā)布 1.0

• Dapr 交通流量控制示例

• Dapr是如何簡(jiǎn)化微服務(wù)的開發(fā)和部署

• 微軟開源微服務(wù)運(yùn)行時(shí)Dapr，賦能云原生應(yīng)用開發(fā)

• Dapr微服務(wù)應(yīng)用開發(fā)系列0：概述

• Dapr微服務(wù)應(yīng)用開發(fā)系列1：環(huán)境配置

• Dapr微服務(wù)應(yīng)用開發(fā)系列2：Hello World與SDK初接觸

• Dapr微服務(wù)應(yīng)用開發(fā)系列3：服務(wù)調(diào)用構(gòu)件塊

• Dapr微服務(wù)應(yīng)用開發(fā)系列4：狀態(tài)管理構(gòu)件塊

總結(jié)

以上是生活随笔為你收集整理的一年增加1.2w星，Dapr能否引领云原生中间件的未来？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。