DotNet Core 遇見 Dapr，爲雲原生而生的分佈式應用運行時

Dapr 是一個由微軟主導的雲原生開源項目，國內雲計算巨頭阿里雲也積極參與其中，2019 年 10 月首次發佈，到今年 2 月正式發佈 V1.0 版本。在不到一年半的時間內，github star 數達到了 1.2 萬，超過同期的 kubernetes、istio、knative 等，發展勢頭迅猛，業界關注度非常高。

什麼是雲原生

雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中，構建和運行可彈性擴展的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式 API。

這些技術能夠構建容錯性好、易於管理和便於觀察的松耦合系統。結合可靠的自動化手段，雲原生技術使工程師能夠輕鬆地對系統作出頻繁和可預測的重大變更。

雲原生計算基金會（CNCF）致力於培育和維護一個廠商中立的開源生態系統，來推廣雲原生技術。我們通過將最前沿的模式民主化，讓這些創新爲大衆所用。

什麼是 Dapr

Dapr(Distributed Application Runtime)分佈式應用運行時，是一個可移植的、事件驅動的運行時，它使任何開發人員能夠輕鬆構建出彈性的、無狀態和有狀態的應用程序，並可運行在雲平臺或邊緣計算中，它同時也支持多種編程語言和開發框架。

Dapr 願景

可移植，事件驅動，彈性，有狀態和無狀態，雲和邊端，語言無關，框架無關。

Any language, Any framework, Anywhere

其核心是要提供一個有標準，可配置，包含各種分佈式能力的運行時。

如今，我們正經歷着上雲浪潮。開發人員對 Web + 數據庫應用結構（例如經典 3 層設計）非常熟悉，並且使用得手，但對本身能支持分佈式的微服務應用結構卻感覺陌生。成爲分佈式系統專家很難，並且你也不需要這麼做。開發人員希望專注於業務邏輯，同時希望平臺爲其提供可伸縮的、彈性的、可維護性和雲原生架構的其他功能。

這就是 Dapr 所要解決的。Dapr 將構建微服務應用的最佳實踐設計成開放、獨立和模塊化的方式，讓你能夠選擇的任意開發語言和框架構建可移植應用程序。每個構建塊都是完全獨立的，您可以採用其中一個或多個或全部來構建你的應用。

此外，Dapr 是和平臺無關的，這意味着您可以在本地、Kubernetes 羣集或者其它集成 Dapr 的託管環境中運行應用程序。這使得您能夠在雲平臺和邊緣計算中運行微服務應用。

使用 Dapr，您可以使用任何語言、任何框架輕鬆構建微服務應用，並運行在任何地方。

Dapr 發展歷程

阿里巴巴深度參與 Dapr 項目，不僅僅以終端用戶的身份成爲 Dapr 的早期採用者，也通過全面參與 Dapr 的開源開發和代碼貢獻成爲目前 Dapr 項目中的主要貢獻公司之一，僅次於微軟：

Dapr 引領雲原生的未來

分佈式應用所需：

Multi runtime 是由 RedHat 首席架構師 Bilgin Ibryam 提出的，實際上 multi runtime 和 dapr 並沒有直接的關係，multi runtime 的提出是在 dapr 開源之後。作者的文章重點對當今分佈式應用的需求做了歸類，並且分析了當前流行的雲原生項目是如何滿足這些分佈式需求，包括 kubernetes，istio，dapr 等，最後，作者對分佈式應用和中間件的未來發展，做了推導和預測，這就是 multiruntime。

過去，我們對雲原生的全景：

有了 Dapr 之後，我們對雲原生的全景：

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

Service Mesh 探索了 Sidecar 模式，Dapr 將 Sidecar 模式推廣到更大的領域：

預測未來：

Dapr 與 Istio、Linkerd 或 OSM 等服務網格相比如何？

Dapr 不是一個服務網格。雖然服務網側重於細粒度網絡控制，但 Dapr 專注於幫助開發人員構建分佈式應用程序。Dapr 和服務網都使用 sidecar 模式，並隨應用程序一起運行，它們確實具有一些重疊的功能，但也提供獨特的優勢。

雖然 Dapr 和服務網格確實提供了一些重疊功能，但 dapr 不是服務網格，其中服務網格被定義爲網絡的服務網格。與專注於網絡問題的服務網格不同，Dapr 專注於提供構建基塊，使開發人員更容易將應用程序構建爲微服務。Dapr 以開發人員爲中心，而服務網格以基礎設施爲中心。

在大多數情況下，開發人員不需要意識到他們正在構建的應用程序將部署在包括服務網格在內的環境中，因爲服務網格會攔截網絡流量。服務網格主要由系統操作員管理和部署。但是，Dapr 構建塊 API 旨在供開發人員在其代碼中明確使用。

Dapr 與服務網格共享的一些常見功能包括：

重要的是，Dapr 通過以開發人員爲中心的關注點提供服務發現和調用。這意味着，通過 Dapr 的服務調用 API，開發人員在服務名稱上調用一種方法，而服務網格則處理網絡概念，如 IP 和 DNS 地址。但是，Dapr 不爲路由或流量拆分等流量行爲提供功能。流量路由通常使用應用程序的入口代理處理，並且不必使用服務網格。此外，Dapr 還爲狀態管理、發佈 / 訂閱、Actor 等提供了其他應用級別的構建塊。

Dapr 和服務網之間的另一個區別是可觀察性（跟蹤和指標）。服務網格在網絡級別運行，並跟蹤服務之間的網絡調用。Dapr 通過服務調用來達到此操作，但 Dapr 也使用寫入 Cloud Events 信封的跟蹤 Id 在發佈 / 訂閱調用上提供可觀察性（跟蹤和指標）。這意味着 Dapr 的指標和跟蹤比使用服務到服務調用和發佈 / 訂閱進行通信的應用程序的服務網格更爲廣泛。

下圖捕獲 Dapr 和服務網格提供的重疊功能和獨特功能：

Dapr 三駕馬車

Dapr 的設計是典型的分層架構，其核心理念，是利用抽象層來實現應用關注點的分離，用以降低分佈式應用的複雜性。

在 Dapr 的架構中，核心的三個組成部分：API，Building Blocks和Components。

Dapr API

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

應用如何能使用到這些分佈式能力，這是 Dapr 最核心的設計，也是 dapr 應用和非 dapr 應用最關鍵的區別: dapr 利用標準 API 暴露各種分佈式能力。API 定義了應用所需的分佈式能力。dapr 提供兩種 API: HTTP1.1/REST和HTTP2/gRPC，兩者在功能上是等價的。這些 API 是平臺無關的，或者說是實現無關的，這是 dapr 能否流行的一個關鍵。

應用只需要按照 API 規範發起，不管是服務訪問，還是存儲，還是發佈消息到隊列裏，都是 HTTP 接口。不管是操作 redis 還是 mysql 都是一樣的 API。在應用看來，一切所需的能力，都可以用 HTTP 協議來表示，這些能力的獲取是標準化的，只要應用需要的分佈式能力不變，那應用的代碼就不需要改變。

將「分佈式原語」映射到 HttpAPI 上，極大地減少了程序員心智的開銷。在應用代碼中不再需要引入相關的組件調用庫，不需要去封裝組件的具體調用方式，不需要對不同的實現做區分。

另外在用戶應用側，dapr 還提供了多種語言的 SDK，這些 SDK 的目的是用更便捷的方式來暴露 buildingBlocks 的 API，用更加語義化的方法調用，來封裝 Http/gRPC 的調用。

Dapr Building Blocks(構建塊)

翻譯爲構建塊，這是 Dapr 對外提供能力的基本單元，每個構建塊對外提供一種分佈式能力。

Dapr 對外提供能力的基本單元，是對分佈式能力的抽象和歸類，包括以下幾大類:

Dapr 目前已有的構建塊和他們提供的能力的簡單描述：

Building Block構建塊是可以從您的代碼中調用的 HTTP 或 gRPC API，並且由一個或多個 Dapr 組件組成。

構建塊解決了構建彈性微服務應用程序中的常見挑戰，並編纂了最佳實踐和模式。Dapr 由一組構建塊組成，並且具有可擴展性以添加新的構建塊。

下圖顯示了構建塊如何公開了可被代碼調用的公共 API，並使用組件來實現構建塊的能力。

以下是 Dapr 提供的構建塊類型:

每個構建塊都是獨立的，這意味着您可以採用其中一個或多個或全部來構建應用。在當前 Dapr 的初始版本中，提供了以下構建塊：

SqrY1d

Dapr Components(組件)

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

Components 提供和各種分佈式實現的對接，包括自建的，雲上的，邊緣等等。

理論上 building block 可以組合使用任意的 components，一個 component 也可以被不同的 building block 使用。比如 actor 和 state 都會使用 state component; 另一個例子，service invocation 會使用 namere solution 和 middleware component，而且不同的場景下，可以選擇不同的 component 實現。

Component 類型和實現：在實現層面，每一種 component 類型定義了一系列接口（interface definition），每一種 component 類型有多種 component 實現，他們都實現了 component 類型要求的接口（interface）。

三駕馬車的關係

Dapr API 如何實現

比如一個電商系統，需要持久化存儲，傳統的做法是，我們要先決策使用什麼存儲，mysql 或者 redis 等，我們需要在代碼裏引入相應的 SDK，編寫各異的實現，未來如果應用想要切換存儲類型，或者從本地存儲遷移到雲上，改動非常大。

假設這個系統的特徵是讀多寫少，那我們傾向於用樂觀鎖來更新數據。業務提出來的「用樂觀鎖控制併發寫入」這就是一個典型的分佈式需求，而這種需求的實現在不同的存儲系統中不盡相同，比如 mysql 是需要用戶顯式指定一個字段作爲版本信息，用戶寫操作是需要把版本信息傳回服務器，而 redis 樂觀鎖需要用戶指定在 redis server 端 watch 某個 key。類似的需求還有數據庫一致性，是使用最終一致性還是強一致性，各種存儲實現也不同。

如上圖所示，如果接入使用 dapr runtime，應用發起存儲調用非常簡單，不需要在應用代碼裏引入 redis 或者 mysql 的 SDK，也不用關心實際存儲使用是什麼通信協議，應用代碼裏只需要使用分佈式原語和 dapr runtime 通信，通信的協議是簡單的 Http 或者 gRPC，dapr runtime 去實現這些分佈式能力。

Dapr 服務發現 (Service Invocation)

主要能力：

在 kubernetes 中使用 dapr，dapr 會爲每個服務生成一個新的 service（以 - dapr 結尾），sidecar 之間的通信都是 gRPC，每個應用需要指定一個 app-id 用於服務發現，應用需要顯示的發起對 runtimeAPI 的調用，沒有類似 mesh 的 iptables 透明攔截。

大家可以腦洞一下，如果 dapr 這種模式能大規模流行，那市面上大部分 RPC 是不是都不再需要了，如今大部分 RPC 雖然各有專長，但是大部分功能都是類似的，服務發現、編解碼、網絡傳輸，有的 RPC 框架還帶服務治理的能力。大部分能力目前都可以由 mesh 或者 dapr 這類 runtime 來提供，這也是一個明顯的趨勢。

Dapr 狀態管理 (State Management)

主要能力：

State 提供一致的鍵值對存儲抽象，這裏不包括關係型或者其他類型的存儲。總的來說，在雲原生領域（以 kubernetes 和 etcd 爲代表），鍵值對存儲的適用範圍更廣。另外相比其他存儲類型，鍵值對存儲引擎的接口抽象更容易實現，即使是關係型數據庫，也能輕鬆的實現對鍵值對 API 的支持。

但仍然不是所有的存儲引擎都能提供等價的鍵值對存儲能力。爲了保證應用程序的可移植性，這裏的確是需要一些適配工作。比如像 Memcached，Cassandra 這些是不支持事務的，而很多數據庫也不能提供基於 ETag 的樂觀鎖能力。

對於併發控制，在 API 層，Dapr 利用HTTP ETags來實現併發控制，類似 kubernetes 對象的resource version，具體地：Dapr 在返回數據時，會帶上 Etag 屬性。如果用戶需要使用樂觀鎖做更新操作，請求中需要帶回 Etag，只有當 Etag 和服務器上數據的相同時，更新操作纔會成功。如果更新操作沒有帶上 Etag，那併發模式將是last-write-wins。

Dapr 發佈和訂閱 (Publish And Subscribe)

使用發佈和訂閱模式，微服務間可以充分的解耦。

主要能力：

Runtime 不僅可以做能力的對接適配，還可以做增強，這是一個例子：如果消息組件原生支持消息有效期，那 Runtime 直接轉發 TTL 相關操作，過期的行爲由組件直接控制，而對於那些不支持消息有效期的組件，Dapr 會在 Runtime 中補齊相關的過期功能。(Cloud Event 裏有 Expiration)

Dapr 綁定 (Bindings)

Bindings 其實和之前的 pub/sub 非常類似，也是利用異步通信傳遞消息。它倆主要的區別是：pub/sub 主要面向的是 dapr 內部應用，而 bindings 主要解決的和外部依賴系統的輸入輸出。

實際上它倆下層的 components 有很多是重疊的，比如說 kafka，redis 既可以作爲內部消息傳遞，也可以作爲外部消息傳遞。pub/sub 基本可以等同於消息隊列，但 bindings 主要是處理事件（trigger handler），比如 twitter 關鍵字事件，比如 github webhooks 等。

Dapr 併發模型 (Actor)

Actor 是一種併發編程的模型，Actor 表示的是一個最基本的計算單元，封裝了可以執行的行爲和私有狀態。actor 之間相互隔離，它們並不互相共享內存，也就是說，一個 actor 能維持一個私有的狀態，並且這個狀態不可能被另一個 actor 所改變。在 actor 模型裏每個 actor 都有地址 (信箱)，所以它們才能夠相互發送消息。每個 actor 只能順序地處理消息。單個 actor 不考慮併發。

Dapr 中 actor 是虛擬的，它們並不一定要常駐內存。它們不需要顯式創建或銷燬。dapr actor runtime 在第一次接收到該 actor ID 的請求時自動激活 actor。如果該 actor 在一段時間內未被使用，那麼 runtime 將回收內存對象。如果以後需要重新啓動，它還將還原 actor 的一切原有數據。

Actor placement service 爲系統提供了 actor 分發和管理，placement 會跟蹤 actor 類型和所有實例的分區，並將這些分區信息同步到每個 dapr 實例中，並跟蹤他們的創建和銷燬。

Dapr 中間件原則 (Middleware Pipelines)

注意 middleware pipelines 是一個 component 類型，而不是 building block。

Dapr 官方提供流量管控的能力比較弱，和 istio 相比的話，目前 dapr 只有重試，加密等少數的管控能力，但 dapr 提供一個擴展的方式：這就是 middleware pipelines，用戶可以按需編寫不同的實現，並把他們級聯起來使用。

其實這種方式在各種編程語言 web 框架中非常常見，只是叫法不同，有的叫裝飾者模型，有的叫洋蔥模型，其實模式都是一樣：請求在路由到用戶代碼之前，會先按序執行 middleware pipelines，請求經過應用處理後，再按相反順序執行上述 middleware pipeline。通常在前序中對 request 做相應的增強處理，在後續中對 response 做增強處理。

咋一看這可能是一個不太起眼的功能，但和傳統 web 框架的 middleware 不一樣，dapr runtime 本身是在應用進程之外，所以不存在語言限制的問題。這使得 middleware 提供的功能可以跨語言共享。比如 dapr 原生沒有提供限流和自定義鑑權的功能（呼聲很高的 2 個場景），我們可以遵循 middleware 的接口按需實現，然後植入 dapr 運行時中。

Dapr 部署模式 (託管方式)

Dapr 可以託管在多種環境中，包括用於本地開發的自託管，或部署到一組 VM、Kubernetes 和邊緣環境（如 Azure IoT Edge）。

Dapr 使用 sidecar 模式來暴露 building blocks 的能力，這裏的 sidecar 除了包括 sidecar container 外，還可以是 sidecar process。

在非容器化環境中，用戶應用和 dapr runtime 都是獨立的進程；而在 kubernetes 這種容器化環境中，dapr runtime 作爲 sidecar container 注入到業務 pod 中，這和 service mesh sidecar 模式是一致的。

自託管

在自託管模式下，Dapr 作爲單獨的 sidecar 進程運行，服務代碼可以通過 HTTP 或 gRPC 調用該進程。在自託管模式下，您還可以將 Dapr 部署到一組 VM 上。

Dapr 可以配置爲在開發人員本地計算機上以自託管模式運行。每個運行的服務都有一個 Dapr 運行時進程 (或 sidecar)，配置爲使用狀態存儲，pub/sub，綁定組件和其他構建塊。

您可以使用 Dapr CLI 在本地機器上運行啓用了 Dapr 的應用程序。

Kubernetes 託管

在容器託管環境（如 Kubernetes）中，Dapr 作爲 sidecar 容器運行，和應用程序容器在同一個 pod 中。

Dapr 可以配置爲在任何 Kubernetes 集羣上運行。在 Kubernetes 中，dapr-sidecar-injector 和 dapr-operator 服務提供一流的集成，以將 Dapr 作爲 sidecar 容器啓動在與服務容器相同的 pod 中，併爲在集羣中部署的 Dapr 組件提供更新通知。

dapr-sentry 服務是一個認證中心，它允許 Dapr sidecar 實例之間的相互 TLS 進行安全數據加密。

Dapr 儀表盤 (控制面板)

整個控制面還是一個微服務。和 istio 早期有點類似。

Dapr Dashboard是一個 WebUI，可幫助您可視化本地計算機或 Kubernetes 上運行的 Dapr 實例的信息。

Dapr 性能

sidecar 模式會帶來額外的性能開銷。以我們使用 service mesh 的經驗來看，這種模式的性能開銷主要是 2 個方面，一個是流量經過 sidecar 的攔截、流量管控和轉發損耗，另一個是 sidecar 需要從控制面同步管理數據，sidecar 需要存儲和處理這些數據，這可能會給數據面內存和 CPU 帶來壓力，特別是大規模場景下。

在官方對 daprV1.0 的性能測試數據看: 在不開啓 mtls 和遙測的情況下，延遲 P90 大概增加 1.4ms，在開啓 mtls 和 0.1 tracingrate 情況下，P90 數據大概還會增加了 3ms 左右。

這個數據要比 istio 好，dapr sidecar 沒有太多的流量管控和修改的功能，也沒有使用 iptables 攔截，開銷相對較小。爲了儘可能提高通信效率，dapr sidecar 之間的通信固定使用 gRPC 協議。而且 dapr 從數據面同步的數據量也非常少，所以也不會有類似 istio 場景下頻繁 reload xDS 的問題。

但相比 service mesh，dapr sidecar 管控了更多的流量類型，比如狀態存儲，應用系統對這類流量的延遲變化更加敏感，用戶在接入 dapr 之前需要慎重評估。

Dapr 開發工具支持

DotNet Core SDK

雖然 Dapr 獨立於任何編程語言，但它可以輕鬆地集成到具有特定語言的 SDK 應用程序中。隨着我們看到越來越多的開發人員使用 Dapr，我們對這些 SDK 的投資已增加，以幫助簡化 Dapr 集成。Dapr 爲爪哇腳本、Python、爪哇、.NET、Go 以及最近添加的 Rust 和 C++ 提供 SDK。此外，根據社區反饋，Java SDK 中增加了許多改進，包括虛擬角色、鍵入類和與 Spring Boot Web 框架的集成。對於. NET，還改進了類型類別，並與 ASP.NET 核心 Web 框架集成。作爲未來路線圖的一部分，計劃爲其他 SDK 提供類似的支持。

Visual Studio Code 擴展

能夠在沒有任何雲依賴的情況下開發本地機器上的應用程序，這對生產力和成本非常重要，也是 Dapr 的關鍵目標。Dapr 視覺工作室代碼（VS 代碼）預覽擴展可幫助開發人員使用 Dapr 調試應用程序，與 Dapr 運行時間進行交互，並與 DaprCLI 合併。

Dapr 入門教程 (阿里知行動手實驗室)

十分鐘快速領略開源分佈式運行時 Dapr 應用的開發、部署過程

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

參考

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/rPCFl9ZKU3tdMvI5lmC6UA

猜你喜歡