如今你構建軟件，您可以從數量眾多的云服務中進行選擇。僅 AWS 就每個月都在不斷為其200多項服務添加新服務，而其他云提供商也都在跟上。如果您的公司想與您的競爭對手競爭，您就需要充分利用這些服務，這些服務在不同的云提供商都有它的特色服務，我們的應用如何做到既是標準化又是可以個性化的，就拿消息隊列來說吧，設置和管理您的消息隊列并不會為您的產品增加任何價值，在Azure中期望使用Azure ServerBus，在阿里云你期望使用rocketmq，在私有云的k8s集群里你可以自由的選擇rabbitmq，nat或者是redis，通過Dapr的components 讓你無論是 Pub/Sub還是Binding 模塊做到消息隊列自由。

如果沒有Dapr，你如何處理這個問題呢？通常都是讓開發人員在具體的云提供商上平臺選擇他們想要的，雖然這聽起來很有效，但對于幾乎所有軟件組織來說都是不切實際的，也不可取，因為開發人員會被各種選擇所淹沒。應對這一挑戰的方法是提供滿足您特定需求的這些服務的一個子集，通常這是在平臺團隊中協作完成的，并在PaaS平臺中體現出來。

Thoughtworks 的MartinFlow.Com有篇文章：介意平臺執行差異：開發人員生產力平臺越來越被認為是管理工程團隊認知負荷和縮短新功能上市時間的一種方式。然而，為了成功執行平臺戰略，組織需要培養一些基線能力。平臺團隊需要將平臺視為一個軟件產品，需要與用戶對話，關注可靠的運營，以及健康的團隊環境。Dapr 正是專門為構建平臺而構建的，與其他方法相比具有一些優勢，下面我認為特別重要的5點：

1、開發者友好的API

首先要正確的是API。平臺構建者需要一種方法來放置護欄并為開發人員提供可以輕松使用的 API， Dapr 基于 Open Application Model (OAM)，最佳實踐基于Kubernetes之上，對外提供標準的Http和Grpc 的API，? 開發人員創建資源來請求特定服務也就很容易，例如利用Binding 構建塊來使用Rabbitmq 消息隊列，開發人員將執行簡單的 kubectl apply ，然后通過標準的Http和Grpc 的API調用：

apiVersion: dapr.io/v1alpha1 kind: Component metadata:name: RabbitBinding spec:type: bindings.rabbitmqversion: v1metadata:- name: queueNamevalue: queue1- name: hostvalue: amqp://admin:123456@192.168.43.101:5672- name: durablevalue: true- name: deleteWhenUnusedvalue: false- name: ttlInSecondsvalue: 60- name: prefetchCountvalue: 0- name: exclusivevalue: false- name: maxPriorityvalue: 5對于 Kubernetes 開發人員來說，這很簡單。這還有一個額外的好處，即我們可以無縫地融入龐大的 Kubernetes 工具生態系統。特別是在當前流行的 GitOps ，而且在非 Kubernetes 開發人員也可以使用的。Dapr利用Sidecar的模式，把代碼中的一些橫切關注點需求（Cross-cutting）分離和抽象出來，從而達到運行環境的獨立和對外部依賴（包括服務之間）的獨立.2、 強大而靈活的組合Dapr 每個標準的 API 背后的實現可能相當復雜，可能涉及設置正確的云提供商資源，如權限、網絡、VPC 和數據庫實例等等。Dapr中的每個構建塊都有來自云提供商的托管資源，Dapr 已經包括了AWS、Azure、GCP和阿里云的支持，并且社區正在增加各類組件的支持。這些微服務基本構建塊為開發人員提供跨平臺跨語言的API實現。開發者可以專注于她請求的服務的屬性，這些組合還可以與遺留或本地服務一起使用，這對于處于某種轉型路徑上的任何團隊都至關重要。3、強大的編程模型-Actors 和函數Dapr 包含專門實現 virtual actors 模式 的運行時。通過 Dapr 的實現，您可以根據 Actors 模型編寫 Dapr Actor，而 Dapr 利用底層平臺提供的可擴展性和可靠性保證，通過Actors的模式，讓微服務可以以單線程的代碼實現大規模并行處理。實際上，Actors這部分功能的開發人員就是來自于Service Fabric團隊，兩者的API也基本保持一致。通過這樣的模式，也把Actors這種模式引入到了其他運行平臺。同時，Dapr還可以和微軟開源的FaaS開發框架Azure Functions進行集成，Dapr開發團隊也基于Azure Logic App的邊緣運行時版本為微服務應用提供了Workflows的能力。OpenFunction 正是基于 Dapr 提供了一套靈活的 functions framework 機制（其中包含了借鑒 Google functions-framework 處理 HTTP 函數的部分）實現了與各種復雜中間件的對接，并搭載兩種運行時——以 Knative serving 為基礎的同步函數運行時，和以 KEDA 結合 Dapr 為基礎的異步函數運行時 OpenFunctionAsync，以期實現對實際生產中大部分應用場景的覆蓋。4、在在 K8s 的幫助下生產就緒一個優秀的開發者平臺應該被視為一個產品，這包括許多方面，但一個重要的方面是它以高度可用的方式運行。我們有一種架構和運行分布式應用程序的方法哪就是采用 Kubernetes， Dapr的最佳實踐是建立在Kubernetes之上，它使用 Kubernetes 控制器和持續協調的概念來運行平臺，如果有什么東西壞了（它會），Dapr 將檢查并修復狀態，也就是你經常聽到 Kubernetes 專家說的類似 Operators 和 control plane 的東西。

5、開源和開放治理

選擇一個優秀的開發者平臺的一個重要特征是開源的，由于開發人員平臺將成為您軟件交付的重要組成部分，您將希望確保您的投資安全。Dapr 不僅是開源的（當前采用MIT協議，捐獻給CNCF之后將會改成Apache 2.0），正在捐獻給CNCF，目前正處于盡職調查階段，它也是公開社區管理的，Dapr于 2020 年 9 月首次轉變為開放治理模式，2021年9月成立了STC（ Dapr 指導和技術委員會），專注于與更廣泛的 Dapr 社區合作，制定指導和技術委員會的章程、職責和愿景，并與成員一起引導以確保供應商中立。具體參見 https://blog.dapr.io/posts/2021/09/20/announcing-daprs-steering-and-technical-committee/

總結

以上是生活随笔為你收集整理的为什么 Dapr 如此令人兴奋的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。