如今你構建軟體,您可以從數量眾多的雲服務中進行選擇。僅 AWS 就每個月都在不斷為其200多項服務新增新服務,而其他雲提供商也都在跟上。 如果您的公司想與您的競爭對手競爭,您就需要充分利用這些服務,這些服務在不同的雲提供商都有它的特色服務,我們的應用如何做到既是標準化又是可以個性化的,就拿訊息佇列來說吧,設定和管理您的訊息佇列並不會為您的產品增加任何價值,在Azure中期望使用Azure ServerBus,在阿里雲你期望使用rocketmq,在私有云的k8s叢集裡你可以自由的選擇rabbitmq,nat或者是redis,通過Dapr的components 讓你無論是 Pub/Sub還是Binding 模組做到訊息佇列自由。
如果沒有Dapr,你如何處理這個問題呢?通常都是讓開發人員在具體的雲提供商上平臺選擇他們想要的,雖然這聽起來很有效,但對於幾乎所有軟體組織來說都是不切實際的,也不可取,因為開發人員會被各種選擇所淹沒。 應對這一挑戰的方法是提供滿足您特定需求的這些服務的一個子集,通常這是在平臺團隊中協作完成的,並在PaaS平臺中體現出來。
Thoughtworks 的MartinFlow.Com有篇文章:介意平臺執行差異: 開發人員生產力平臺越來越被認為是管理工程團隊認知負荷和縮短新功能上市時間的一種方式。然而,為了成功執行平臺戰略,組織需要培養一些基線能力。平臺團隊需要將平臺視為一個軟體產品,需要與使用者對話,關注可靠的運營,以及健康的團隊環境。Dapr 正是專門為構建平臺而構建的,與其他方法相比具有一些優勢,下面我認為特別重要的4點:
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.rabbitmq version: v1 metadata: - name: queueName value: queue1 - name: host value: amqp://admin:123456@192.168.43.101:5672 - name: durable value: true - name: deleteWhenUnused value: false - name: ttlInSeconds value: 60 - name: prefetchCount value: 0 - name: exclusive value: false - name: maxPriority value: 5
對於 Kubernetes 開發人員來說,這很簡單。這還有一個額外的好處,即我們可以無縫地融入龐大的 Kubernetes 工具生態系統。 特別是在當前流行的 GitOps ,而且在非 Kubernetes 開發人員也可以使用的。
2、 強大而靈活的組合
Dapr 每個標準的 API 背後的實現可能相當複雜,可能涉及設定正確的雲提供商資源,如許可權、網路、VPC 和資料庫例項等等。 Dapr中的每個構建塊都有來自雲提供商的託管資源,Dapr 已經包括了AWS、Azure、GCP和阿里雲的支援,並且社群正在增加各類元件的支援。
這些微服務基本構建塊為開發人員提供跨平臺跨語言的API實現。開發者可以專注於她請求的服務的屬性,這些組合還可以與遺留或本地服務一起使用,這對於處於某種轉型路徑上的任何團隊都至關重要。
3、在在 K8s 的幫助下生產就緒
一個優秀的開發者平臺應該被視為一個產品,這包括許多方面,但一個重要的方面是它以高度可用的方式執行。我們有一種架構和執行分散式應用程式的方法哪就是採用 Kubernetes, Dapr的最佳實踐是建立在Kubernetes之上,它使用 Kubernetes 控制器和持續協調的概念來執行平臺,如果有什麼東西壞了(它會),Dapr 將檢查並修復狀態,也就是你經常聽到 Kubernetes 專家說的類似 Operators 和 control plane 的東西。
4、開源和開放治理
選擇一個優秀的開發者平臺的一個重要特徵是開源的,由於開發人員平臺將成為您軟體交付的重要組成部分,您將希望確保您的投資安全。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/