譯者注

在正式閱讀本文之前，我們有必要先了解下什么是“10 倍好”。

10 倍好理論最早出自彼得·蒂爾的《從 0 到 1》，他說一個新創企業，要想獲得快速成長，其提供的解決方案要比現有方案好 10 倍以上，這個好 10 倍，可以是成本低 10 倍，效能強 10 倍，或易用性優 10 倍。

為什么 3 倍 5 倍不行，要好 10 倍呢？因為：消費者會高估已有解決方案 3 倍以上，創業者會高估自己方案 3 倍以上，因此你要創造一個比現狀好 10 倍的方案。只要這樣，客戶才有動力，愿意掙脫現有方案的慣性，冒著風險去嘗試你的方案。這就是 10 倍好理論，真正創新或顛覆性的產品和服務，至少要比目前做法好 10 倍才有可能成功。?

翻譯本文的主要原因還是想借此深入了解 10 倍好理論，Dapr 只是一個載體。這個思考框架，不但對初創企業有用，對于成熟的大公司開發新產品開拓新市場，都有很大幫助。在整個云原生浪潮之下，Dapr 是否是一個 10 倍好平臺？未來是否還可能出現其他 10 倍好的軟件或者產品呢？

本文作者??Bilgin Ibryam 最近加入了開發者軟件初創公司 Diagrid Inc，他是Apache Software Foundation 的 committer 和 member，前紅帽架構師。他也是一個開源的布道師，曾在 2020 年初 提出的Multi-Runtime Microservices Architecture（多運行時微服務架構）。

正文

01 概述

一個新想法要傳播，一個項目要被廣泛采用并成為主流，它必須至少比現狀好 10 倍，以證明為改變所付出的努力是合理的。微服務架構改進了大多數組織的發布周期，從每季度（12周）或更長到每周甚至更短。Docker 使得在一臺主機上運行數十個服務而沒有資源沖突成為可能，而不只是 10 個。Kubernetes 使運維人員能夠維護 10?倍以上的服務。這些都是 10 倍改進的例子。但是，實施新想法和采用新技術也會帶來成本和新的缺點。識別領域邊界、實現網絡彈性、定位問題、測試和運行微服務的成本是在單體架構中不存在的。學習 Kubernetes、習慣異步協調行為和調試問題都需要全新的技能和工具，這些都是成本。然而，這些新架構和工具對組織的整體價值的重要性證明了變革的痛苦都是有意義的。在這篇文章中，我們將探討為什么 Dapr 是一個在正確的時間出現的 10 倍好的運行時，它為組織中的不同角色提供了什么好處，以及它的缺點是什么。

Dapr 給整個組織都帶來了好處：

Dapr 提供了一種與傳統基于 SDK 的方法不同的方法來使用集成特性。Dapr是一個通過?sidecar?為分布式系統提供 API 的工具包，這使它成為云原生應用程序的一個很好的解決方案，無論是新的綠地應用還是遷移現有的棕地應用。雖然 Dapr 主要用于開發人員構建應用，但它也改善了運行這些應用的運維人員的工作方式，同時也有益于試圖使組織的應用和工具庫井然有序的架構師的。讓我們先看看 Dapr 為企業中的各種角色帶來了什么好處，然后再看看使用它的成本。

02?給開發者帶來的好處

開發人員有廣泛的責任，從理解業務，創建新的應用，維護舊的應用，甚至在業務沒有涉及到的領域進行創新。在本文中，我們主要關注開發人員如何創建新的分布式應用，并將它們交付到快速迭代的業務中。從這個角度來看，Dapr 可以在哪些方面顯著地幫助開發者?

#?服務調用

微服務是新應用的主要架構模式，服務間的同步通信是其核心。Dapr 服務調用 API 可以幫助開發人員處理服務發現、服務間安全通信、請求超時、重試、負載均衡等問題。

# 發布與訂閱

伴隨微服務的另一個架構趨勢是使用帶有某種發布-訂閱實現的事件驅動交互模型。Dapr 提供了一個平臺無關的 API 來發送和接收消息，該 API 通過可插入組件機制與各種消息 broker 和 queue 系統集成。這支持跨本地和生產環境的可移植性，以及在提供不同發布-訂閱和其他平臺服務的不同云廠商上部署相同的應用程序。

# 三方庫集成

現代云原生應用的另一個必要性是與第三方服務和知名 API 的集成。使用 Dapr 的 binding API，你可以用來自數十個外部系統的事件觸發你的應用，并通過保持你的代碼不受 SDK 的影響來與外部系統進行交互。這使開發人員不必深入了解如何使用特定的 SDK 來連接到外部系統或從特定端點的故障中恢復。最終的結果是，開發人員可以專注于業務邏輯并創建可移植的應用，而無需在應用中使用特定環境或特定云平臺提供程序的綁定。

# 開發環境

為本地和共享的測試環境構造一個擬生產環境一直是一個挑戰。其它的不說，它需要給應用添加配置、發現其他本地運行的服務、訪問外部依賴項(如數據庫、消息代理、云服務的本地代理)等。在擁有許多開發人員的大型組織中，創建專用測試環境的成本可能很高，而且必須共享其中的一些依賴項。Dapr 的配置 API 允許開發人員使用配置并在配置項更改時訂閱更改。Dapr 的服務調用 API 允許發現部署在本地或生產環境中的服務。Dapr 的發布/訂閱和狀態 API 允許在不更改應用程序代碼的情況下交換消息代理和狀態存儲。這樣，開發人員就可以針對本地 Redis 代理進行開發，并僅通過配置將其替換為生產中的云服務。Dapr 還簡化了多個開發人員之間共享消息代理和狀態存儲的過程。Dapr 可以充當基礎開發者平臺，允許多個團隊創建可移植和多語言應用。

# 其它

Dapr 中還有其他功能可以提高開發人員的工作效率，但這超出了本文的目的。Dapr 的狀態管理 API 可以使用抽象狀態存儲執行 CRUD 操作；Dapr 參與者可以實現大量小的、獨立的、隔離的狀態和邏輯單元；其他原語（如分布式鎖）可以提供對資源的互斥訪問；在現有功能的基礎上構建的新功能（如編排長時間運行的流程）也將出現。所有這些使得 Dapr 成為一個強大的分布式工具箱，很難被云原生開發人員忽視。

03?給運維者帶來的好處

這是另一大類 IT 人員，就這個職位而言，它包括傳統的運維團隊、站點可靠性工程師，甚至是較新的平臺工程師團隊。所有的團隊都不是在編寫應用程序，而是保持應用的運行，并使開發人員能夠更有效地完成工作。雖然 Dapr 主要是一個開發人員工具包，但一旦引入到應用程序中，它也會改善運營團隊的工作。讓我們看看 Dapr 是如何幫助大規模自動化和操作大量應用的。

# 安全

安全是許多團隊的責任，但在這里，我們將總結 Dapr 在應用安全方面幫助運維類團隊的領域。

• Dapr 有一個專門的 secrets 構建塊，允許開發者從 Azure Key Vault、Hashicorp Vault等 secrets 商店獲取 secrets。最酷的是，這些 secrets 可以用于特定的應用程序，也可以用于其他 Dapr 組件，如狀態存儲、發布/訂閱組件。

• 從網絡的角度來看，Dapr 具有與服務網格重疊的功能。Dapr 有助于通過 mTLS 對服務實例之間的通信進行加密。Dapr 允許運維人員和開發人員自帶證書，或者讓 Dapr 自動創建和持久化自簽名根證書和頒發者證書。

• mTLS 可以加密 sidecar 之間的流量，而 Dapr 支持 API 令牌身份驗證，在應用程序和 sidecar 之間提供額外的安全級別。啟用基于令牌的身份驗證會導致 Dapr 和/或應用程序要求對其 API 的每個傳入請求都包含一個身份驗證令牌，然后才允許該請求通過。這種方法通過將代理到代理身份驗證擴展到應用程序到應用程序，提供了真正的端到端服務調用安全性。

• Dapr OAuth 2.0 特性允許您在端點上啟用 OAuth 授權，以便通過 Dapr 的任何方法調用在傳遞給用戶代碼之前都需要得到授權。這不需要編寫任何額外的代碼，除了中間件配置。

• Dapr 中的訪問控制提供配置策略，限制調用應用的操作可以通過服務調用在被調用的應用程序上執行什么操作。要限制特定操作對被調用應用程序的訪問，以及從調用應用程序（通過SPIFFE id）限制 HTTP verbs 對被調用應用程序的訪問，可以在配置中定義訪問控制策略規范。

• 在零信任的網絡中，或通過前端將 Dapr 暴露給外部流量時，可以根據應用的實際需要調整 Dapr API 的作用域，減少攻擊面。

• 根據其本質，Dapr sidecar 在業務邏輯和運行流程的基礎架構代碼之間創建了一個邊界。將應用程序代碼與基礎架構代碼分離，有助于識別漏洞的范圍，并通過推出只涉及受影響部分的代碼的新版本，幫助更快地進行補救。

如上所述，Dapr 的安全好處是多方面的，有些是顯性的功能，有些是間接的好處，這要歸功于它的 sidecar 架構。Dapr 的非侵入性意味著你可以只使用你想要的功能，并將 Dapr 與其他類似的工具（如服務網格）結合起來。

# 彈性

Dapr 為流行的彈性模式提供實現，如超時、重試/回退、熔斷。Dapr 的優點在于，這些模式不僅可以應用于執行服務調用的應用，還可以應用于 Dapr 組件。這意味著，除了內置的彈性特性外，與其他系統交互的組件還可以通過彈性模式從額外的容錯中獲益。

# 可觀測性

由于 Dapr 位于服務交互的請求路徑上，并充當到其他系統的粘合劑，它可以訪問到豐富的應用 metrics、traces 和 logs 數據，這是大多數其他框架所不能做到的。Dapr 中可觀測性數據的主要來源如下。

• Dapr 公開了一個 Prometheus metrics 端點，您可以利用該端點更好地理解 Dapr 的行為，并為特定條件設置警報。

• Dapr 攔截所有應用程序流量，并自動注入相關 id 以跟蹤分布式事務。由于 Dapr 不僅限于服務對服務的交互，它還可以通過各種協議和 API 跟蹤和監視與外部系統的交互。它將 Zipkin 協議與 OpenTelemetry 收集器結合使用，用于分布式跟蹤和度量收集，并支持許多開箱即用的后端，例如，Stackdriver、Zipkin、New Relic 等等。

• Dapr 數據平面?（sidecar）和控制平面（系統組件）都產生日志。此外，還可以啟用 API 日志，它將記錄所有出入 Dapr sidecar 的 API 調用，這對于理解應用程序的網絡行為非常方便。

#?黃金路徑/Golden Paths

“黃金路徑”一詞是由 Spotify 的平臺工程團隊在 IT 領域引入的。它代表了通過“受祝福的”工具和過程來構建軟件的一種武斷的和內部支持的路徑。這個想法并不是限制或阻礙開發人員，而是允許他們通過做出更少的決策和在日常活動中不重復工作來使用他們的生產力和創造力，以實現更高的目標。在實踐中，這意味著為開發人員提供經過驗證的、受支持的，即創造軟件和其他常見任務的黃金路徑。讓我們來看看 Dapr 的哪些方面使其成為具有黃金路徑的開發人員平臺的基礎。

• Dapr 是一個多語言框架，具有 .Net、Python、Java、Go、PHP、Javascript、C++、Rust 的客戶端 SDK。但是 Dapr 并不一定要使用這些庫，因為從設計上來說 Dapr 是多語言的，并且它可以通過 HTTP 被用任何語言編寫的應用程序所使用。這使得 Dapr 不僅對使用 Java 或 .Net 的典型集成和中間件團隊具有吸引力，而且對使用 Python 的數據工程師、Node 和 PHP 開發人員以及其他人員也具有吸引力。

• Dapr 是一個多環境框架。在本地運行、使用多租戶特性在共享測試環境中運行或在生產環境中運行都很輕松。它即可以在本地運行，也可以在云端運行或在邊緣運行。除了在不同的環境中運行之外，Dapr binding 還允許它連接到在不同環境中運行和變化的各種服務，而無需更改任何應用程序代碼。

• Dapr 是非侵入式的。它不作為庫包含在應用程序中，也不像服務網格那樣攔截所有應用程序流量。因此，由您選擇使用哪個構建塊，并由您的應用程序決定何時與 Dapr API 交互。這使得 Dapr 功能只有在合理的情況下才可選擇使用。

• 分離 Dapr 配置的關注點。Dapr 功能作為構建塊 API 向應用開發人員開放。但是這些構建塊依賴于提供實現的組件。通常情況下，這些組件將由對平臺和云基礎設施具有較高權限的運營團隊配置，并作為隨時可用的方式提供給開發人員。這種分離允許運營指導，甚至控制開發人員可以使用哪些基礎設施，哪些不可以。

所有這些特性使得 Dapr 作為組織內的基礎平臺在組織中非常具有吸引力。通常，這些功能作為黃金路徑提供，并由平臺工程團隊集中自動化和管理。Dapr 足夠通用，適合大多數團隊，非侵入性，只在需要時使用，易于從平臺團隊集中管理和配置。

04?給架構師帶來的好處

在其他事情中，架構師的角色是技術和業務之間的接口，并使用組合的知識使開發和運維團隊朝著業務目標對齊。為了優化跨多個團隊和時代的技術、人員和流程，單個開發人員可能不知道這些。有了架構師角色的定義，讓我們看看 Dapr 可以幫助解決哪些架構方面的問題。

# 多語言支持

如果您是一個團隊中的開發人員，您可能已經掌握了一種編程語言，非常了解它的依賴庫和工具生態系統，并且不受組織中其他團隊每天使用的東西的影響。如果您是一個與多個團隊打交道的企業級架構師，從事多個項目，并且您的工作時間范圍比項目的長度還要長，那么情況就不同了。要設計一個解決方案，您必須知道團隊正在使用什么語言、可用的框架、他們提供什么功能、他們的許可、生命周期、支持等等。另一方面，Dapr 被設計成多語言，它不會對使用的語言做任何假設。這使得所有 Dapr 構建模塊、組件和模式都可以在相同的條款下向所有人開放。雖然這在短期內對單個開發人員或團隊來說可能不是一個重要的特征，但從組織層面和更長的時間框架來看，這是非常重要的。

# 部署選擇多樣化

如今，多云并不是美好的最終目標，而是許多架構師不得不面對的丑陋現實。許多組織既有部署在內部的軟件，也有一個或多個云提供商提供的平臺。這有時是為了從某些業務安排、特定的云特性中獲益，有時是由于收購或影子 IT 而偶然發生的。無論出于什么原因，能夠在不同的環境中運行應用，甚至擁有遷移的選項都是可取的。有時在設計解決方案的早期階段以及在采購和確認最終環境之前需要這種可選性，有時在后期作為備份選項。設計解決方案的架構師與在實現期間已經擁有可用環境的開發人員相比，在頭腦中會有不同的時間框架和不同的假設。Dapr 被設計為在 Kubernetes 上運行最好，但它也可以在虛擬機、云或邊緣上運行。它具有可以連接到不同云服務的綁定，無論您的應用程序在哪里運行。所有這些使得 Dapr 成為通用模式和連接器的可移植實現，為架構師設計跨環境和實現可移植性的解決方案提供了一個公共基礎。

#?知識可遷移

技術的可移植性中很少提及的一個方面是知識和人的可移植性。例如，在一個新項目中使用 Java 并不是因為它的字節碼可以移植到多個操作系統上，而是因為它的 JVM 是可靠的，而且當核心開發人員離開時，有數百萬的開發人員可以雇傭。使用 Hibernate （它是一個 ORM 框架）不是為了與另一個數據庫交換數據庫，而是因為它有一個經過多年驗證的實現，它有眾所周知的模式和編程模型，您可以找到一個知道它如何工作的開發人員。人們使用 Kubernetes 并不是因為 Kubernetes 可以移植到不同的云提供商，而是因為所有的運維知識和實踐都可以從一個云提供商移植到另一個云提供商，并由同一個運維團隊在內部應用。只有在與重用知識相結合的情況下，重用代碼才是有效的。這和 Dapr 的想法是一樣的。Dapr 提供了可移植到不同團隊和環境的公共連接器、模式和分布式系統原語的實現。它是迄今為止創建的最非侵入性、可移植的分布式系統工具包。一旦學習了，同樣的開發、運維和架構知識就可以移植到組織的各個部分，并應用到各種項目中。

# 可維護

維護是更改和更新軟件以跟上新需求、修復bug、優化性能等的過程。它是軟件生命周期中分散的一個方面，這使得在新項目的早期階段考慮它不那么重要，但從長期來看，它可能成為最昂貴的階段。擁有一個易于維護性的平臺是具有長遠眼光的架構師所欣賞的加分項。Dapr 的哪些方面有助于軟件維護?

• 更少的依賴：無論使用哪種語言，Dapr 都提供了到廣泛的外部系統的連接器，從而減少了項目中的第三方庫依賴。這意味著在本地存儲庫、工件存儲庫和容器注冊中緩存的庫更少。這意味著跨項目跟蹤更新、安全修復和許可影響的庫更少。這意味著對項目時間規劃和預算的外部影響更小。
  

• 基于 API 的依賴：Dapr 也是一個外部依賴，但它作為一個獨立的進程運行，通過定義良好的 API 和版本控制策略來訪問它。因此，您可以通過更新 Dapr 版本和重新啟動您的應用程序 Pod 來應用 Dapr 安全補丁。這意味著開發團隊不必更改應用程序的依賴關系、測試它、構建它、創建容器等等（當然，除非使用了 Dapr 客戶端庫，并且 bug 在客戶端庫中，而您正在更新客戶端庫）。這意味著開發團隊不必為了應用緊急修復程序或定期升級到外部依賴的最新版本而停止對某個特性的工作。Dapr 升級可以由平臺工程團隊執行，并作為一個通用基礎提供給開發人員，他們可以通過一個穩定的 API 使用它，就像云服務一般。
  

• 聲明性和配置驅動：Dapr 功能通過 HTTP 和 gRPC API 公開，但 Dapr 配置了類似 Kubernetes 的聲明式 API。事實上，無論您是否在 Kubernetes 中使用 Dapr, Dapr 配置文件都是一個 Kubernetes CRD。聲明性 API 更容易理解和維護，并且允許您通過用于其他云原生項目的相同自動化工具和實踐來配置和調優 Dapr。
  

• 關注點分離：使用 Dapr 可以創建松散耦合的應用程序組件，這些組件可以很容易地交換并連接到它們的軟件環境。注意，這也是六邊形架構的定義，Dapr 很適合這種定義。在使用 Dapr 時，技術集成職責集中在 Dapr 中，業務邏輯封裝在應用層中。這提供了與六邊形體系結構相同的好處，例如延遲和更改技術決策，在隔離外部系統的情況下測試和更改業務邏輯。
  

# 生態系統的一部分

當微服務是占主導地位的綠地應用架構、開源是占主導地位的開發模型、開放標準是占主導地位的創新和采用模型時，Dapr 就出現了。因此，我們看到 Docker 和 Kubernetes 等新技術的采用速度最快。我們看到了諸如 Prometheus、Zipkin、Jaeger、Fluentd 等互補技術的不斷增長，以及由此產生的諸如 OpenTelemetry、W3C Trace Context、Kubernetes API、CloudEvents 等開放標準。作為 CNCF 的一個孵化項目，Dapr 建立在與 Kubernetes 相同的云原生原則之上，它有利于與其他云原生項目互補，為終端用戶帶來復合的業務價值。雖然 sidecar 早在 Kubernetes 之前就已經存在了，但是現在的行業已經發展到更好地理解這種架構，并且能夠更好地使用和操作這種編程模型。

05?Dapr 的缺點

消極工程是一個術語，用來描述做主要工作時必須做的前提工作。例如，采用微服務之前你需要考慮并處理網絡錯誤。為了使用 Kubernetes，你需要學習分布式系統，并使用YAML編寫代碼....如果以上所有的例子都說明了為什么 Dapr 是一個 10x 框架，以及它如何積極地幫助各種角色，那么使用 Dapr 的缺點是什么？以下是一些最常被指出的 Dapr 的缺點。

# 邏輯上的復雜性

采用 Dapr 的最大挑戰之一是多個移動部件帶來的復雜性增加。我之所以說它是可感知的，是因為如果你在做微服務，你已經在處理分布式系統和操作多個進程了。與 Dapr 的交互并沒有什么不同，只是 Dapr 恰好在您的每個服務本地運行。Dapr 不透明地修改任何應用程序網絡規則，也不像服務網格那樣攔截到服務的所有網絡流量。Dapr 是一個技術組件，它為你的服務提供了一個可供交互的 API，并且它通過定義良好的 API 與你的應用交互。雖然這是一種新的范式，需要勇氣開始，并通過實踐來適應，但今天的開發和運維工具對運行和操作 sidecar 有很大的幫助。

# 網絡延遲

如果低延遲是一個應用的關鍵需求，那么運行在 Kubernetes 上的基于商業云基礎設施的微服務可能不是正確的起始架構。為了獲得最佳性能，最好使用在專用硬件或大型機上運行的單體應用。讓我們假設情況并非如此，但您仍然希望在 Kubernetes 上運行低延遲的分布式應用程序。由于額外的網絡跳轉而增加的網絡延遲是基于代理的技術（如 Dapr）的常見副作用。眾所周知，Dapr 將為 90% 到 99% 的請求增加大約1到2毫秒的延遲，這比其他類似的基于側車的服務網格要低。而且，由于 Dapr 不會攔截所有進出應用程序范圍的流量，所以您可以控制何時使用 Dapr 并增加額外的延遲。很有可能，并不是應用程序中的所有微服務都對延遲敏感。甚至，并不是所有的服務端點都對延遲的輕微增加敏感。您可以在應用的邊緣使用 Dapr 來與其他不可避免的額外延遲的系統集成。您可以使用 Dapr 進行大多數服務和數據源交互，并使用本機驅動程序、二進制協議等與對延遲敏感的系統交互。Dapr 是一個非侵入的、可選擇加入的工具集合，只能在有意義的地方使用。

# 資源消耗

當部署在 Kubernetes 上時，Dapr 有一個需要額外資源的控制平面。數據平面 sidecar 還需要與應用實例成比例的額外容量。但是 Dapr 是用 Go 語言編寫的，占用空間小。它使用 gRPC 協議進行更有效的 sidecar 對 sidecar?通信。而且大多數 Dapr 作業都是網絡綁定，資源消耗很少。是的，Dapr 需要額外的資源，但它的性能消耗和資源消耗都很低，而且可以持續測量和控制。

#?調試與測試成本

使用 Dapr 將把所有的外部集成移到應用程序外部，并幫助您提高業務邏輯的可測試性。但是額外的跳躍會使集成和端到端測試更加復雜，發現問題也更加困難。也就是說，調試基于容器的應用的工具和 Kubernetes 工作負載每天都在改進，包括為 VS Code 等 IDE 安裝的 Dapr 插件。

06 總結

Dapr 是一個具有多方面好處的開發框架。其開箱即用的特性幫助開發人員集成服務，并以聲明的方式與第三方系統連接。一旦引入到應用環境中，Dapr 就可以幫助運維團隊實現更好的可觀察性，提高安全性和可靠性。對于那些希望為企業中的每個團隊提供受控開發能力的平臺工程師來說，Dapr 是一個基礎。

然而，僅僅 10 倍的好處是不夠的。一個想法要實現，就必須是及時的。正如維克多·雨果曾經說過的：“Nothing is as powerful as an idea whose time has come（沒有什么比時機成熟的思想更有力量）”。微服務架構和原生云技術如此迅速地成為主流，是因為硬件創新支持廉價的云計算，同時也因為業務有了快速改變的需求以適應時代。簡而言之，偉大的技術在時機成熟時才會變得有用。Dapr 是多語言的微服務，它像 Docker 一樣便攜，它像 Kubernetes 一樣可以組合使用。Dapr 是 API 驅動和聲明式的，與云原生原則和操作實踐一致。它是及時的，并且自然地補充了其他云原生項目。它的好處與云原生生態系統的其他部分一起成倍增加。Dapr 是一個10倍好的技術，它的時代已經到來。

-> 點擊【閱讀原文】可跳轉至英文原文