![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/1c53ee49144940e38f0b5ccb762a8f69.png)

作者 | 敖小劍
來源 | [阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/Dsb7rwu5tRAizJ7Wdr23Fw)

Dapr 是 2019 年 10 月微軟開源的可移植、事件驅動分散式執行時，它使開發人員能夠輕鬆地構建執行在雲平臺和邊緣的彈性而微服務化的無狀態和有狀態的應用程式，從而降低基於微服務架構構建現代雲原生應用的准入門檻。

在今年 2 月份剛剛釋出了 v1.0 正式版本。雖然推出至今不過一年半時間，但 Dapr 發展勢頭十分迅猛，目前已經在 GitHub 上收穫了 1.2w 星。阿里是 Dapr 開源專案的深度參與者和早期採用者，率先進行了生產落地，集團內部有十幾個應用在使用 Dapr；目前已有 2 位 Dapr成員，是 Dapr 專案中除微軟之外程式碼貢獻最多的公司。

**拉到文末可以瞭解 Dapr 入門教程體驗方式**

# 為什麼阿里會選擇Dapr？
在阿里巴巴，Java 使用非常廣泛，不僅僅業務應用大量使用 Java，大量中介軟體和基礎能力的伺服器端也是使用 Java 開發。在過去十幾年間，我們圍繞 Java 建立了非常完備的生態體系，經歷過各種嚴酷的考驗。

而隨著業務形態的日漸豐富，**多語言**的需求在不斷的增加，如 nodejs / golang / c / c++ / rust 等。特別是在微服務流行之後，根據實際情況而選擇使用不同的程式語言開發微服務成為趨勢。但效仿 Java ，為每一種程式語言都打造一套功能完備的生態體系在成本上是不現實的。因此，需要一個成本可控的方案來解決多語言問題，讓微服務開發能真正的實現“語言自由”。

隨著雲的採用，業務應用的形態也開始朝雲原生方向發展，越來越多的業務應用（尤其是前臺業務）開始擁抱 FaaS 和 Serverless  作為應用託管和資源排程的解決方案。而在 FaaS 和 Serverless 場景下，需要更輕量化的解決方案以滿足快速啟動和伸縮的需求 —— 傳統類庫模式下由於需要整合大量的 SDK，業務應用變得非常的臃腫。而在 Function 形態下更加的不協調，以 nodejs 為例：幾百行的 nodejs Function 程式碼依然需要依賴多達幾十兆的 node module。同時 FaaS 和 Serverless 也對多語言的支援提供了更高的要求。因此，在 FaaS 和 Serverless 這種新型形態下有必要提供有別於傳統類庫方式的、更輕量化的、支援多語言的解決方案。

顯然，Servicemesh 倡導的 Sidecar 模式是解決上述問題的絕佳方案。在過去幾年間，隨著 Servicemesh 的發展和採用， Sidecar 模式已經得到充分驗證：Sidecar 模式非常符合雲原生的理念，特別是在多語言支援和應用輕量化方面具備天然優勢。

我們非常認可 Bilgin Ibryam 在["Multi-Runtime Microservices Architecture"](https://www.infoq.com/articles/multi-runtime-microservice-architecture/) 一文中提出的 Multiple Runtime / Mecha Runtime 的理念，尤其是他對分散式應用需求的分析，很符合我們的實際情況：

![1.png](https://ucc.alicdn.com/pic/developer-ecology/80d05e530d674d939dc3c5594fbfe48d.png)

而 Dapr 是第一個實踐 Multiple Runtime 理念的開源專案，我們從這個專案釋出開始就密切關注它，因為 Dapr 可以很好的解決我們面臨的問題：Sidecar 模式天然提供了對多語言的支援，各種客戶端 SDK 被 Dapr Runtime 替代之後應用也得以輕量化。

此外，從長期戰略的角度考慮，我們在 2020 年提出了"三位一體"的理念，即將“自研技術”、“開源專案”、“商業產品”形成統一的技術體系，最大化技術的價值。而當前的實際情況是三者有完全不同的產品和技術方案，導致當我們需要將某個產品在阿里內部、公有云、客戶私有云等不同的平臺上進行遷移時，或者是跨多個平臺部署時，就會遇到非常大的挑戰。Dapr 面向能力程式設計的理念，強調可移植性和可擴充套件性的標準 API，平臺中立、無供應商鎖定的設計，深深的吸引了我們。

> “在阿里雲，我們相信 Dapr 將引領微服務的發展。透過採用 Dapr，我們的客戶現在可以以更快的速度來構建可移植和健壯的分散式系統。”

—— 阿里雲資深技術專家 李響

在 2020 年年中，我們開始基於 Dapr 專案進行了內部小規模的試點，在實際的落地過程中探索和驗證 Dapr 的理念。我們也積極參與到 Dapr 開源專案的建設中，提交了大量的改進建議和程式碼。

下面我們將以 Dapr 在阿里的實際落地場景來具體說明 Dapr 是如何幫助我們解決上述問題的。

# Dapr 在阿里的實踐
## 1. 概況
**目前 Dapr 在阿里巴巴內部還處於實驗階段**。

我們的首要工作是為內部的中介軟體開發 Dapr 元件，使業務應用程式可以與這些中介軟體和實現它們的 Java 語言/ Java Client SDK 解耦。然後透過小規模的業務應用落地，在各種場景下的對 Dapr 進行驗證，在驗證完成之後計劃繼續部署較大規模的業務應用。

截止到 2021 年 3 月，Dapr 在阿里內部落地的場景主要集中在 2 個方面：多語言支援和雲間遷移。

## 2. 多語言支援
### **1）Faas / Serverless 場景**
> 背景：在阿里的電商系統中，存在大量活動和導購需求。

這些需求的特點是"短平快"：需要快速開發、快速迭代、生命週期相對比較短。因此這類需求非常適合透過採用 FaaS 的方式來落地。

Faas 對多語言支援有強烈的訴求，肯定不會侷限於 Java。而阿里內部大部分應用都是 Java 體系，對多語言的支援比較弱，尤其是新興語言（如 Dart）或者小眾語言（如 Rust）。

而從需求上說，採用 FaaS 的應用也同樣需要和內部執行的服務以及各種中介軟體/基礎設施進行通訊，因此 FaaS 平臺迫切的需要解決多語言支援問題。

透過 Dapr ，我們很好的解決了 FaaS 的多語言問題，從而使得客戶透過 FaaS 實現了開發效率的大幅提升。

### **2）多語言應用的接入**
> 背景：阿里收購有大量的公司。

這些收購的公司有大量的應用，而這些應用中很多不是 Java 體系，在接入阿里的技術體系時，對多語言支援有明確的需求。

另外，由於業務創新的需要，有些應用對 nodejs 和 golang 有強烈訴求，還有一些應用則需要使用到 Dart 和 C++。

但目前這些語言的生態系統並沒有像 Java 那麼完善，尤其部分中介軟體和基礎設施已經發展的非常成熟，進入維護狀態，不太可能在現在重新開發所有語言的客戶端：成本上代價很高，時間上也來不及。

透過 Dapr ，我們可以為這些應用提供多語言解決方案。

### **3）複雜的 Java 遺留系統**
> 背景：基於 Java ClassLoader 機制而設計的複雜系統。

為了解決類衝突問題，隔絕不同的業務模組，阿里針對  Java 系統設計了基於 ClassLoader 機制的複雜系統，這些系統的設計往往非常複雜，應用也非常臃腫。

此外，部分業務團隊為了能和現有的中介軟體進行互通，自行維護了一套多語言的中介軟體 SDK，而這些 SDK 本來應該由中介軟體團隊維護並保持同步更新。這也帶來了穩定性方面的隱患和風險。

我們期望將這些遺留的系統遷移到 Dapr 中，統一實現中介軟體 SDK 的維護和更新。比較特殊的是這裡存在一個需求：最好能讓業務開發團隊儘量不做程式碼層面的調整，以減少遷移時對業務應用的衝擊。

所以針對 Java 遺留系統，在遷往 Dapr 時，我們額外設計了一個 Java 適配層：將原來的 Java 呼叫適配到 Dapr 的客戶端 API 上。

以上三種多語言的落地實踐場景，如下圖所示：

![2.png](https://ucc.alicdn.com/pic/developer-ecology/860df5656bd348e683578f4290ddb9dc.png)

## 3. 雲間遷移
> 背景：業務應用對外輸出時有跨平臺需求。

阿里的部分業務，如釘釘文件，原本是提供給阿里內部和外部使用者直接使用的，此時釘釘文件只需要部署在阿里內部的業務叢集裡，直接訪問阿里內部的生態體系。

但是隨著 SaaS 業務的發展，以及部分資訊保安敏感的使用者對於資料安全的強烈訴求， 需要將釘釘文件部署到使用者 VPC 下或者公有云下。

為此，我們需要將釘釘文件的系統從阿里內部遷移到公有云上進行部署，而釘釘文件使用的底層技術需要從阿里內部的技術體系遷移到使用開源技術或阿里雲的商業化產品上。

藉助 Dapr 的標準 API 和可擴充套件的組建模型，我們採取的策略是讓使用者不需要修改任何程式碼，直接透過 Dapr Runtime 遮蔽底層使用的中介軟體：部署在不同平臺時，透過啟用 Dapr 中的不同的 Component 來提供一致的能力。

以訊息通訊威力，當應用需要訪問訊息系統時：

- 在阿里內部：透過 Rocketmq.yaml 啟用 Rocketmq 元件。
- 在公有云上：透過 Kafka.yaml 啟用 kafka 元件。

透過 Dapr 的可移植性，上層的釘釘文件應用現在可以和底層的基礎設施（如訊息系統）解耦，從而實現在不同的雲平臺之間平滑遷移：

![3.png](https://ucc.alicdn.com/pic/developer-ecology/0f27f4f1713346b38cf33a56fec8fbc0.png)

最終幫助我們的業務團隊實現了他們的**業務目標**：使 Dingtalk 在任何地方部署成為可能。

# 阿里的 Dapr 未來規劃
未來我們將繼續透過應用試點的方式對 Dapr 進行驗證，包括：

- 適用場景
- 效能
- 穩定性
- 可移植性

同時我們將繼續開發 Dapr 的元件，以整合更多的中介軟體和基礎設施，包括內部產品和阿里雲上支援的商業產品。其中對阿里雲商業產品的整合程式碼，我們將在驗證透過之後貢獻給 Dapr 專案，從而為 Dapr 提供阿里雲支援。這些專案預計將包括：

- Apache Dubbo 的 RPC 支援
- Apache RocketMQ 的訊息傳遞支援
- Nacos 的動態配置支援
- 阿里雲 RDS 的 MySQL 支援
- 阿里雲快取服務的 Redis 支援

作為 Multiple Runtime 架構的先驅者和 Dapr 專案的早期採用者，我們將繼續和 Dapr 社群合作，在落地的過程中努力完善 Dapr 的功能、效能、穩定性等關鍵指標，和社群一起聯手打造雲原生時代的**D**istributed**AP**plication**R**untime！

開源 1 年半 star 破 1.2 萬的 Dapr 是如何在阿里落地的？

相關文章