20000英尺 Dapr

在第1章中,我們討論了分散式微服務應用程式的吸引力。 但是,我們也指出它們會大幅增加架構和操作的複雜度。 有了這一點,問題就變成了,您如何「讓蛋糕」和「吃過?」。 也就是說,您如何利用分散式架構的靈活性,並將其複雜性降至最低?

Dapr (或 分散式應用程式運行 時間)是建立新式分散式應用程式的新方法。

以原型的形式開始發展成為高度成功的開放原始碼專案。 Microsoft 的贊助者,與客戶和開放原始碼的社區密切合作,以設計和建立 Dapr。 Dapr 專案彙集了所有背景的開發人員,以解決開發分散式應用程式時最棘手的一些挑戰。

本書從 .NET 開發人員的觀點來看,Dapr。 在本章中,您將會建立對 Dapr 及其運作方式的概念理解。 稍後,我們會針對您如何在應用程式中使用 Dapr,提供實用的實際操作指示。

Imagine 在20000英尺的 jet 中飛行。 您可以查看視窗,並從廣泛的觀點來看看下面的環境。 讓我們對 Dapr 進行相同的動作。 以20000英尺將您自己的 Dapr 視覺化。 您會看到什麼?

Dapr 及其解決的問題

Dapr 解決了新式分散式應用程式固有的大型挑戰: 複雜度

透過可插入元件的架構,Dapr 可大幅簡化分散式應用程式背後的配管。 它提供 動態粘連 ,可將您的應用程式與 Dapr 執行時間的基礎結構功能系結。

考慮需要讓其中一個服務具狀態嗎? 您的設計是什麼。 您可以撰寫以狀態存放區(例如 Redis Cache)為目標的自訂程式碼。 不過,Dapr 提供現成可用的狀態管理功能。 您的服務會叫用透過 Dapr 元件 設定 yaml 檔動態繫結到狀態存放區 元件 的 Dapr 狀態管理 建立區塊。 Dapr 隨附數個預先建立的狀態存放區元件,包括 Redis。 使用此模型,您的服務會將狀態管理委派給 Dapr 執行時間。 您的服務沒有基礎元件的 SDK、程式庫或直接參考。 您甚至可以將狀態存放區從 Redis 變更為 MySQL 或 Cassandra,而不需要變更程式碼。

圖2-1 顯示20000英尺的 Dapr。

Dapr 于20000英尺 圖 2-1。 在20000英尺 Dapr。

在圖的頂端列中,請注意 Dapr 如何提供適用于熱門開發平臺的特定語言 Sdk。 Dapr v1.0 包含 Go、Node.js、Python、.NET、JAVA 和 JavaScript 的支援。 本書著重于 Dapr .net SDK,它也提供 ASP.NET Core 整合的直接支援。

雖然特定語言的 Sdk 可以增強開發人員體驗,但 Dapr 是平臺中立的。 本質上,Dapr 的程式設計模型會透過標準 HTTP/gRPC 通訊協定來公開功能。 任何程式設計平臺都可以透過其原生 HTTP 和 gRPC Api 來呼叫 Dapr。

圖形中央的藍色方塊代表 Dapr 建築組塊。 每個都會公開您的應用程式可以使用的分散式應用程式功能。

底部的資料列強調 Dapr 的可攜性,以及可在其上執行的各種不同環境。

Dapr 架構

到目前為止,jet 會輪流 Dapr,以高度遞減,讓您深入瞭解 Dapr 的運作方式。

積木

從新的觀點來看,您會看到更詳細的 Dapr 組建區塊

建立區塊會封裝分散式基礎結構功能。 您可以透過 HTTP 或 gRPC Api 存取這些功能。 圖2-2 顯示 Dapr v 1.0 的可用區塊。

Dapr 組建區塊

圖 2-2。 Dapr 組建區塊。

下表說明每個區塊所提供的基礎結構服務。

建置組塊 描述
狀態管理 針對長時間執行的具狀態服務,支援內容相關資訊。
服務調用 使用平臺中立的通訊協定和知名的端點,叫用直接、安全的服務對服務呼叫。
發佈和訂閱 在服務之間執行安全且可調整的發佈/訂閱訊息。
綁定 利用雙向通訊,從外部資源引發的事件觸發程式碼。
可檢視性 監視和測量跨網路服務的訊息呼叫。
密碼 安全地存取外部秘密存放區。
動作項目 將邏輯和資料封裝在可重複使用的動作專案物件中。

建立區塊會從您的服務抽象化分散式應用程式功能的執行。 圖2-3 顯示此互動。

Dapr 組建區塊整合

圖 2-3。 Dapr 組建區塊整合。

組建區塊會叫用 Dapr 元件,以提供每個資源的具體實作為。 您服務的程式碼只會察覺到組建區塊。 它不會對外部 Sdk 或程式庫有任何相依性,Dapr 會為您處理此項配管。 每個建立區塊都是獨立的。 您可以在應用程式中使用一個、部分或全部。 作為加值的 Dapr 建築組塊,製作業界最佳作法,包括全方位的可檢視性。

我們會在後續章節中提供每個 Dapr 組建區塊的詳細說明和程式碼範例。 此時,jet 更進一步。 從新的觀點來看,您現在可以深入瞭解 Dapr 元件層。

單元

雖然組建區塊會公開 API 來叫用分散式應用程式功能,但 Dapr 元件會提供具體的實作為進行。

請考慮 Dapr 狀態存放區 元件。 它提供統一的方式來管理 CRUD 作業的狀態。 若未變更您的服務程式代碼,您可以在下列任何 Dapr 狀態元件之間切換:

  • AWS DynamoDB
  • Aerospike
  • Azure Blob 儲存體
  • Azure CosmosDB
  • Azure 表格儲存體
  • Cassandra
  • Cloud Firestore (資料存放區模式)
  • CloudState
  • Couchbase
  • Etcd
  • HashiCorp Consul
  • Hazelcast
  • Memcached
  • MongoDB
  • PostgreSQL
  • Redis
  • RethinkDB
  • SQL Server
  • Zookeeper

每個元件都會透過常見的狀態管理介面,提供必要的實作為:

 type Store interface {
   Init(metadata Metadata) error
   Delete(req *DeleteRequest) error
   BulkDelete(req []DeleteRequest) error
   Get(req *GetRequest) (*GetResponse, error)
   Set(req *SetRequest) error
   BulkSet(req []SetRequest) error
}

提示

Dapr 執行時間以及所有 Dapr 元件都是以 Golang 或 Go、language 撰寫的。 Go 是開放原始碼社區的熱門語言,可證明 Dapr 間的跨平臺承諾。

您可能會開始使用 Azure Redis Cache 作為狀態存放區。 您可以使用下列設定來指定它:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: statestore
  namespace: default
spec:
  type: state.redis
  version: v1
  metadata:
  - name: redisHost
    value: <HOST>
  - name: redisPassword
    value: <PASSWORD>
  - name: enableTLS
    value: <bool> # Optional. Allowed: true, false.
  - name: failover
    value: <bool> # Optional. Allowed: true, false.

在 [ 規格 ] 區段中,您可以將 Dapr 設定為使用 Redis 快取來進行狀態管理。 此區段也包含元件特定的中繼資料。 在此情況下,您可以使用它來設定其他 Redis 設定。

之後,應用程式便已準備好進入生產階段。 在生產環境中,您可能會想要將狀態管理變更為 Azure 資料表儲存體。 Azure 資料表儲存體提供經濟實惠且高度持久的狀態管理功能。

在撰寫本文時,Dapr 會提供下列元件類型:

元件 描述
服務探索 服務調用建立區塊用來與裝載環境整合,以提供服務對服務探索。
State 提供統一的介面,可與各種不同的狀態存放區執行互動。
Pub/sub 提供統一的介面,可與各種不同的訊息匯流排執行互動。
綁定 提供統一的介面來觸發外部系統的應用程式事件,並使用選擇性的資料裝載叫用外部系統。
中介軟體 允許自訂中介軟體插入要求處理管線,並叫用要求或回應上的其他動作。
秘密存放區 提供統一的介面來與外部秘密存放區互動,包括雲端、邊緣、商業、開放原始碼服務。

當 jet 完成 Dapr 時,您會回頭查看並瞭解它如何連接在一起。

側車架構

Dapr 會透過 側車架構公開其組建區塊和元件。 側車可讓 Dapr 在不同的記憶體進程中執行,或與您的服務分開執行。 Sidecar 提供隔離和封裝,因為它們不是服務的一部分,而是連接到它。 這種分隔可讓每一個都有自己的執行時間環境,並以不同的程式設計平臺為基礎。 圖2-4 顯示側車模式。

側車架構

圖 2-4。 側車架構。

此模式名為「側車」,因為它類似於加裝到機車的「側車」。 在上圖中,請注意 Dapr 側車如何附加至您的服務,以提供分散式應用程式功能。

裝載環境

Dapr 具有跨平臺支援,而且可以在許多不同的環境中執行。 這些環境包括 Kubernetes、一組 vm,或邊緣環境,例如 Azure IoT edge。

針對本機開發,開始使用的最簡單方式是使用 自我裝載模式。 在自我裝載模式中,微服務和 Dapr sidecar 會在不含容器協調器的個別本機進程(例如 Kubernetes)中執行。 如需詳細資訊,請參閱 下載並安裝 DAPR CLI

圖2-5 顯示在兩個不同的記憶體進程中裝載的應用程式和 Dapr,會透過 HTTP 或 gRPC 進行通訊。

自我裝載的側車架構

圖 2-5。 自我裝載的 Dapr 側車。

根據預設,Dapr 會安裝適用于 Redis 和 Zipkin 的 Docker 容器,以提供預設狀態管理和可檢視性。 如果您不想在本機電腦上安裝 Docker,甚至可以 在不含任何 Docker 容器的自我裝載模式中執行 Dapr。 不過,您必須手動安裝 Redis 的預設元件,例如狀態管理和 pub/sub。

Dapr 也會在 容器化環境中執行,例如 Kubernetes。 圖2-6 顯示在不同的側邊車輛容器中執行的 Dapr,以及相同 Kubernetes pod 中的應用程式容器。

Kubernetes 託管的側車架構

圖 2-6。 Kubernetes-hosted Dapr 側車。

Dapr 效能考慮

如您所見,Dapr 會公開側車架構,以將您的應用程式與分散式應用程式功能分離。 叫用 Dapr 作業需要至少一個跨進程的網路呼叫。 圖2-7 提供 Dapr 流量模式的範例。

Dapr 流量模式

圖 2-7。 Dapr 流量模式。

在上圖中,其中一個可能會詢問每次呼叫所產生的延遲和負荷。

Dapr 團隊投入了大量的效能。 大量的工程工作讓 Dapr 有效率。 Dapr sidecar 之間的呼叫一律會使用 gRPC 來進行,這會提供高效能和小型二進位承載。 在大部分的情況下,額外的額外負荷應為毫秒。

為了提高效能,開發人員可以使用 gRPC 來呼叫 Dapr 構成要素。

gRPC 是現代化、高效能的架構, (RPC) 通訊協定來發展舊的 遠端程序呼叫 。 gRPC 使用 HTTP/2 作為其傳輸通訊協定,透過 HTTP RESTFul 服務提供顯著的效能增強功能,包括:

  • 透過相同連線傳送多個平行要求的多工支援-HTTP 1.1 一次會將處理限制為一個要求/回應訊息。
  • 雙向全雙工通訊,可同時傳送用戶端要求和伺服器回應。
  • 內建串流,可讓要求和回應以非同步方式串流處理大型資料集。

若要深入瞭解,請參閱適用于 Azure 電子書的架構 Cloud-Native .Net 應用程式gRPC 總覽

Dapr 和服務網格

服務網格是適用于分散式應用程式的另一項快速演進技術。

服務網格是具有內建功能的可設定基礎結構層,可處理服務對服務的通訊、復原能力、負載平衡和遙測捕捉。 它會將這些疑慮的責任移出服務和服務網格層。 如同 Dapr,服務網格也會遵循側車架構。

圖2-8 顯示可執行服務網格技術的應用程式。

服務網格

圖 2-8。 具有側邊汽車的服務網格。

上圖顯示每個服務一起執行的側車 proxy 攔截訊息的方式。 您可以使用服務特定的流量規則來設定每個 proxy。 它瞭解訊息,並且可以將訊息路由傳送到您的服務和外界。

因此問題變成「正在 Dapr 服務網狀」。

雖然兩者都使用側車架構,但每種技術都有不同的用途。 Dapr 提供分散式應用程式功能。 服務網格提供專用的網路基礎結構層。

由於每個層級都在不同的層級運作,因此兩者可以在相同的應用程式中一起運作。 例如,服務網格可以提供服務之間的網路通訊。 Dapr 可提供應用程式服務,例如狀態管理或動作專案服務。

圖2-9 顯示同時實行 Dapr 和服務網格技術的應用程式。

Dapr 和服務網格一起

圖 2-9。 Dapr 和服務網格一起進行。

Dapr 線上檔涵蓋 Dapr 和服務網格整合。

摘要

本章介紹 Dapr 的分散式應用程式執行時間。

Dapr 是 Microsoft 贊助的開放原始碼專案,可與客戶和開放原始碼社區密切合作。

在其核心中,Dapr 有助於降低分散式微服務應用程式固有的複雜度。 它是以建立區塊 Api 的概念為基礎。 Dapr 組建區塊會公開常見的分散式應用程式功能,例如狀態管理、服務對服務調用,以及 pub/sub 訊息。 Dapr 元件位於建立區塊底下,並提供每項功能的具體執行。 應用程式會透過設定檔系結至各種元件。

在下一章中,我們會提供有關如何在應用程式中使用 Dapr 的實際實際操作指示。

參考資料