背景
大體從2015年開始，我與團隊對所負責的一個電商系統啟動架構改造大手術。當時改造的第一初衷其實是在全球分布式團隊協作模式下，如何實作各地團隊自治性問題。首先提一句這個電商系統主要聚焦在公司XaaS軟體産品的線上試用、報價、訂單、服務開通、計量、計費、賬單、發票等業務領域，并非我們所熟悉的亞馬遜、京東、淘寶等實體商品電子商務交易。提到現代化改造相信大家腦海中閃現的一定是類似微服務、容器化、上雲、Kubernetes，服務網格、無伺服器化、基礎設施即代碼、gitOps等詞彙。我們也毫不意外的經曆了這麼一個過程：從單體架構使用領域驅動方法進行微服務化改造，上雲（最初還主要是CloudFoundry），到後來持續的演進到容器化以及使用Kubernetes、服務網格、函數計算等等。
在這樣的一個演進過程中，有采納新技術後看到實際業務價值的興奮，也有對技術碎片化發展的迷茫。于是乎想把自己在這個過程中的一些感受寫下來。從哪裡開始呢，既然分布式架構現在已成主流架構風格，那就從分布式（不考慮過去的SOA架構，故這裡特指微服務架構）開始吧。
雖然說從分布式架構開始，但我不想花筆墨去普及它的基礎知識。隻想提下分布式架構給我們帶來很多價值的同時也讓我們經曆了不少的挑戰。比方說在服務治理方面尤其對于大規模系統，我們不得不投入大量精力去解決服務注冊/發現、服務負載均衡、服務配置管理、服務灰階釋出、服務容錯（逾時、重試、熔斷）、服務可觀測性、服務安全等諸多課題。在這個過程中也誕生了優秀的解決方案比如Netflix開源的系列微服務治理方案，到後來的SpringCloud全家桶、以及這兩年堪稱當紅炸子雞的服務網格。
機緣巧合之下在2021年時了解到了Dapr這個項目。當時就被它的思想所深深吸引，後來一直持續在關注它的發展至今。今天這篇文章就作為介紹Dapr系列的引子，給大家介紹下這個項目的整體架構。
初識Dapr
Dapr全稱是Distributed Application Runtime，即分布式應用運作時。它是由微軟在2019年發起的一個開源項目，2021年11月被CNCF接納目前處于孵化階段。目前發展到v1.9版本，在GitHub上有20k star，受歡迎程度可見一斑。
Dapr的官方定義是一個可移植的、事件驅動的運作時，它使開發人員能夠輕松建構出彈性的、無狀态和有狀态的應用程式，并可運作在雲平台或邊緣計算中，它支援多種程式設計語言和開發架構。
去掉一系列繁瑣的定語，我們可以看到Dapr的核心是一個應用運作時。那作為應用運作時，它都提供什麼方面的能力呢？我們又為什麼需要這樣的運作時環境？這還要回到分布式架構帶來的挑戰說起。
Multi-Runtime理念
Multi-Runtime是由RedHat的架構師Bilgin Ibryam提出。他總結了一個分布式應用存在四大類需求：生命周期、網絡、狀态、綁定。平時我們大都把這些需求統稱為服務治理。
（圖檔引用自InfoQ）
其中生命周期類需求主要包括應用建構打包、部署、健康檢查、擴縮容、配置管理等。
網絡類需求包括服務注冊/發現、灰階釋出、服務容錯、服務調用、釋出/訂閱、服務安全、服務可觀測性等方面能力。
狀态類需求包括服務幂等性、緩存、工作流管理等方面。
綁定類需求則聚焦與連結器、協定轉換、消息路由等。
在傳統模式下這些能力與業務邏輯基本都是打包在一起，侵入性較大。
（圖檔來自InfoQ）
為簡化業務應用開發，把這些能力外移到各種運作時中去，就基本形成了現代化應用的大體模樣：以業務邏輯為核心，各項治理能力下沉形成類似外挂形式發揮作用。
（圖檔來自InfoQ）
繼續将這些多個運作時進行歸并整合，便形成被業界稱為Mecha-Runtime（來源于阿凡達1中AMP機甲）模式。從形态上來看它跟一些服務網格的Sidecar模式幾乎一樣，事實上這也一直延伸到了Dapr架構中。
（圖檔來自InfoQ）
Multi-Runtime可以了解為針對分布式架構下服務治理能力的一個組合。如果我們能夠将這些分布式能力進一步泛化形成一個抽象層，比方說将各種能力抽象為API，為不同能力提供多種實作，在開發時面向能力（接口）程式設計而在運作時通過配置選擇不同實作，這個聽上去是不是有點炫酷？這就是Dapr的思想，而且Dapr也是業界第一個Multi-Runtime實踐項目。
解構Dapr
首先我們來看下Dapr的整體架構，大體分為三層：業務邏輯層、Dapr建構塊層、基礎設施層。
（圖檔來自Dapr官方網站）
我們可以看到Dapr 将建構分布式應用的最佳實踐設計成開放、獨立和子產品化的方式，讓開發者能夠使用任意開發語言和架構建構可移植的應用程式。 每個建構塊都是完全獨立，可以采用其中一個、多個或全部來建構應用。它是平台無關的，可以運作在本地、Kubernetes以及各種主流雲平台中。從架構設計的角度看，如下圖所示Dapr 的精髓在于：通過抽象/隔離/可替換，解耦能力和實作，進而實作可移植性。
Dapr倡導面向能力程式設計即：
- Dapr API 提供了對分布式能力的抽象，并提取為标準API
- Dapr 的 Runtime 隔離 應用和底層元件的具體實作
（圖檔來自網絡）
進一步打開來看Dapr的核心，也就是它的建構塊層。一個建構塊是在我們代碼中可以通過HTTP或gRPC調用的一組API，一個建構塊由若幹元件組成實作它的能力。
（圖檔來自Dapr官方網站）
下表詳細介紹了Dapr原生提供的9大建構塊：
| 建構塊 | 端點 | 說明 |
| 服務調用 | /v1.0/invoke | 服務調用使應用程式能夠通過 Http 或 gRPC 消息形式互相通信。 Dapr 提供了一個端點，它充當反向代理與内置服務發現的組合，同時内置分布式跟蹤和錯誤處理。 |
| 狀态管理 | /v1.0/state | 獨立的狀态管理，使用鍵/值對作為存儲機制，可以輕松的使長時運作、高可用的有狀态服務和無狀态服務共同運作在應用程式中。 狀态存儲是可插拔的，目前支援使用Azure CosmosDB、 Azure SQL Server、 PostgreSQL,、AWS DynamoDB、Redis 作為狀态存儲媒體。 |
| 釋出訂閱 | /v1.0/publish /v1.0/subscribe | 釋出/預訂是松散耦合的消息傳遞模式，發送方 (或釋出者) 将消息推送到訂閱者預訂的主題。 Dapr 支援應用程式之間的釋出/訂閱模式。 |
| 資源綁定 | /v1.0/bindings | Dapr的Bindings是建立在事件驅動架構的基礎之上的。通過建立觸發器與資源的綁定，可以從任何外部源（例如資料庫，隊列，檔案系統等）接收和發送事件，而無需借助消息隊列，即可實作靈活的業務場景。 |
| Actors | /v1.0/actors | Actor模型 = 狀态 + 行為 + 消息。一個應用/服務由多個Actor組成，每個Actor都是一個獨立的運作單元，擁有隔離的運作空間，在隔離的空間内，其有獨立的狀态和行為，不被外界幹預，Actor之間通過消息進行互動，而同一時刻，每個Actor隻能被單個線程執行，這樣既有效避免了資料共享和并發問題，又確定了應用的伸縮性。 |
| 可觀測性 | N/A | Dapr記錄名額，日志，鍊路以調試和監視Dapr和使用者應用的運作狀況。 Dapr支援分布式跟蹤，其使用W3C跟蹤上下文标準和開放式遙測技術，可以輕松地診斷在生産環境中服務間的網絡調用，并發送到不同的監視工具。 |
| 密鑰 | /v1.0/secrets | Dapr 提供一個密鑰建構塊 API ，并與 Azure Key Vault 和 Kubernetes 等密鑰商店內建，以存儲密鑰。 服務代碼可以調用密鑰 API 從 Dapr 支援的密鑰存儲中檢索密鑰。 |
| 配置 | /v1.0-alpha1/configuration | 配置API提供應用從支援的倉儲中擷取、訂閱配置項的能力。 |
| 分布式鎖 | /v1.0-alpha1/lock | 提供分布式鎖能力。 |
Dapr采用元件化設計，每個建構塊的能力都是由元件來承載實作。每個元件有接口定義， 所有元件都是可插拔的，是以可以将元件換為另一個具有相同接口的元件。比方說狀态建構塊中，Dapr提供了面向Redis的元件、面向MemCache的元件。這些元件對外接口使用統一化緩存接口，這也就賦予了開發者無縫遷移緩存實作方案的能力。在需要時也可以通過 components contrib repo 為元件接口貢獻實作并擴充 Dapr 功能。而Dapr 可移植性的基石就在于标準API + 可拔插可替換的元件。
（圖檔來自Dapr官方網站）
下圖展示了Dapr目前支援的元件：
（圖檔來自Dapr官方網站）
每一個元件定義都需要遵從如下格式規範：
（圖檔來自Dapr官方網站）
在調用Dapr API時可以通過下發政策方式配置服務容錯、檢查檢查、可觀測性能力，比如逾時、重試、熔斷、鍊路跟蹤等。
（圖檔來自Dapr官方網站）
在運作态，Dapr表現為一個被命名為daprd的獨立程序，它對外暴露了三組API：
建構塊API：被業務邏輯代碼調用來使用各種分布式能力。
中繼資料API：通過此類API可以擷取加載的元件、類型、支援的特性等。
健康檢查API：檢測sidecar健康、liveness、readiness狀态等
（圖檔來自Dapr官方網站）
Dapr采用sidecar模式暴露能力，這使得它成為一種對應用無侵入的解決方案，注意看以下幾個示例調用中的端點。
（圖檔來自Dapr官方網站）
在Kubernetes環境下，Dapr以附屬容器形式和應用容器運作在同一pod中，熟悉服務網格的同學對這種模式應該不會陌生。Dapr提供了對各種建構塊能力的抽象和屏蔽。
（圖檔來自Dapr官方網站）
Dapr與服務網格
從架構形态上來看，Dapr與Istio等服務網格方案極為類似。而且事實上Dapr與服務網格存在一定的能力交集，但Dapr并不是一種服務網格實作。服務網格在定位上是處理服務間通訊的基礎設施層，它聚焦在網絡層面，在大部分情況是由系統運維人員管理。而Dapr是面向開發者的，目标是通過建構塊的方式簡化微服務開發。從下圖可以清晰看到兩者在能力方面的不同定位：
（圖檔來自Dapr官方網站）
後續
到這裡我們隻是簡單認識了Dapr的整體架構，但大都是圖文描述偏于理論介紹。Dapr 通過抽象API+建構塊的方式，實作了能力和實作的解耦，并給出了一個美好的願景：在有一個業界普遍認可并遵循的标準化API的基礎上，使用者可以自由選擇程式設計語言開發雲原生，這些雲原生可以在不同的平台上運作，不被廠商和平台限制——終極目标是使得雲原生應用真正具備跨雲跨平台的可移植性。
下一篇讓我們從代碼出發來看下如果實際使用Dapr！