為什麼Dapr是比SpringCloud和Istio更優雅的微服務架構？

兩個特性說明Dapr是比SpringCloud和Istio更有前途的微服務開發架構。

Dapr 是微軟主導的雲原生開源項目，2019年10月首次釋出，到正式釋出 V1.0 版本的不到一年的時間内，github star 數達到了 1.2萬（現在已經超過1.7萬星），超過同期的 kubernetes、istio、knative 等，發展勢頭迅猛，業界關注度非常高。

Dapr 這個詞是是 「Distributed Application runtime」的首字母縮寫，非常精煉的解釋了 dapr 是什麼：dapr 是一個為應用提供分布式能力的運作時。

Dapr官網 https://dapr.io

Dapr已經在多家大廠支撐生産環境

随着各家大廠的IT系統規模擴大，微服務架構已經成為了必需品和标準品，這也催生了 Dapr 這類非侵入式的（或者叫邊車模式SideCar）的微服務開發架構的使用。根據Dapr官方倉庫中的記錄，已經有非常多的大廠在 生産環境 中使用Dapr來支撐自己的微服務開發。這裡面不乏大家熟悉的騰訊，阿裡，丁丁等國内大廠。

參考：

• https://github.com/dapr/dapr/issues/3169
• https://github.com/dapr/community/blob/master/ADOPTERS.md

Dapr比較SpringCloud或者Istio的優勢在哪裡？

這個可能是大多數人的第一個問題，簡單總結幾點供大家參考

• 全棧多語言支援：這一點上Dapr和Istio是等同的，因為都采用了邊車模式，與應用程序之間沒有有侵入性，相比SpringCloud這種隻能支援Java語言（當然現在有很多其他語言提供SpringCloud的SDK）的侵入性架構，具備先天的跨語言優勢。微服務化給開發人員帶來的一個重要價值就是可以随意的選擇不同開發語言架構進行組裝，對于企業來說也可以避免被某一種技術架構綁定，甚至在招聘程式員的時候也可以有多的選擇。是以當微服務的理念開始在業界流行以後，采用者的團隊中必然出現多語言并存的狀況。當你面對一個Java/.Net/Python/Node/JavaScript/Golang多語言并存并且互相依賴的應用環境的時候，就會發現SpringCloud無法這種需求，變成了微服務支撐架構的瓶頸。
• 多雲/非雲環境支援：這一點上Dapr和SpringCloud是等同的。SpringCloud作為雲原生時代之前出現的架構，它本身的根基就在非雲或者虛拟機環境上，是以SpringCloud本身就具備跨雲/非雲環境支撐，因為它本身和雲環境并無綁定關系。你當然可以在容器/k8s中運作SpringCloud，但這僅僅是給SpringCloud應用換了一種打包部署方式而已。Istio 在這一點上有天然的弱勢，因為Istio從一開始就誕生于雲原生的基礎設施k8s之上，也就順其自然的利用了k8s所提供的很多基礎能力，這些對于新生類應用來說非常合适，但是對于傳統/現存應用來說就面臨改造的問題。Dapr的設計則從根基上就相容了多雲/非容器和非雲環境，同時也借鑒了雲原生環境的特點來進行設計，是以你完全可以在傳統的主機/虛拟機/非雲環境中獲得和雲原生平台類似的微服務體驗。這一點上對于已經有大量現存應用的傳統企業來說，是非常重要的一個福音。×備注：Isitio也已經開始支援與虛拟機環境的內建，這一點大家可以自行查閱資料。

這個連結中介紹了阿裡是如何引入 Dapr 以及背後的各種考量

• https://blog.dapr.io/posts/2021/03/19/how-alibaba-is-using-dapr/

簡單來說，Dapr 從設計上就借鑒并考慮了之前的2種類似架構各自的優勢，并将所有的好處融合進來，将弊端剔除掉；是目前最先進最有前途的分布式微服務開發架構。

搭建Dapr開發環境的痛點

以下視訊是展示了在容器中使用 VSCode WebIDE 開發一個 Dapr 應用的整個過程

SmartIDE快速啟動 - Dapr分布式微服務開發環境_哔哩哔哩_bilibili

既然是一個面向微服務的開發架構，Dapr 環境本身可以變得非常複雜。因為要引入各種類型的中間件，很多開發者會發現搭建一個可以運作使用Dapr的環境，可能需要先安裝一堆的各種服務。比如下面這個 Dapr 示例應用 

Dapr-Traffice-Control

代碼庫

• https://github.com/SmartIDE/sample-dapr-traffic-control

雖然應用本身并不是特别複雜，隻用到了3個服務元件，但是支撐這3個服務的中間件卻有5個之多，包括：

• 作為 

  MQTT Broker

   的 

  Mosquitto

• 常用的緩存中間件 

  Redis

• 消息隊列 

  RabbitMQ

• 電子郵件發送中間件 

  SMTP

   服務
• 密鑰服務 

  Secrets

簡單介紹一下這個示例的業務背景， 

dapr-traffice-control

 模拟了一個常見的超速攝像頭系統的實作，通過檢測車輛通過道路上2個攝像頭之間的耗時，計算車速，并發送罰單給司機。如下圖：

這裡用到的業務元件隻有3個，分别是：

• TrafficControlService

   是交通控制服務，也是主服務，其業務邏輯是根據公路上的2個固定位置攝像頭回報的資料，計算車輛通過攝像頭的車速，以便判斷是否存在超速行為。

• FineCollectionService

   是罰單處理服務，根據 

  TrafficControlService

   發送過來的車牌資料，查詢車輛注冊資料庫（

  VehicleRegistrationService

  ）擷取聯系人資訊，并發送郵件

• VehicleRegistrationService

   是車輛注冊資料庫，提供車輛資訊查詢，可以通過車牌号碼擷取車主資訊，比如郵件位址。

這其實是微服務開發中一個非常普遍的問題：基礎環境往往比應用本身還要複雜。這一點上和微服務的理念是相符的，微服務就是希望通過對不同業務元件的抽象盡量減少開發人員花在通用元件上的投入，而專注于業務本身。從這個角度來說， 

dapr-traffice-control

 非常完美的诠釋了這個理念；同時也非常直接的展示了這個困境。

從開發人員的角度來說，這帶來的一個非常麻煩的問題：單體時代隻要拿到代碼就可以開始調試，現在的應用開發環境的搭建變得越來越複雜，開發人員需要了解的知識範圍也被放大了。

實際上，以上這個問題在運維領域早就被完美解決了，方案其實就是容器和雲原生技術本身。但是開發者作為雲原生技術的使用者，自己沒有從中獲益，反而招來了更多的麻煩。

開發者不使用容器？

首先說明，這裡所說的不是使用容器進行部署，而是使用容器進行開發。雲原生的典型部署模式一定是容器化的，開發者在這個問題上并不糾結。開發者的現狀是，雖然應用最終要在容器内運作，但是在開發的時候并不希望在容器内進行開發，主要原因是不友善，操作太繁瑣以及對容器技術的不了解。這樣帶來的問題也非常顯而易見，因為開發環境和生産環境不一緻，就必須通過配置的方式，流水線自動化的方式來解決這些不一緻的問題，造成整個釋出系統變得更加複雜和難以維護。

要解決這個問題，我們必須降低容器的使用門檻，讓開發者在 不了解/不學習 容器技術的前提下使用容器進行開發。SmartIDE就是為了解決這個問題而設計的，與繁瑣的環境搭建腳本不同，SmartIDE 允許你使用一個簡單的指令 

smartide start

 來啟動 任何應用 的開發調試環境，而且這個環境從一開始就是容器化的。

對于上面這個 

dapr-traffic-control

 而言，啟動指令如下

Copy

smartide start https://github.com/SmartIDE/sample-dapr-traffic-control
           

也就是說，開發者可以使用 

smartide start

 加上代碼庫位址來啟動任何應用的開發調試；而且，如果開發者自己有一台可以運作Docker環境的雲主機，那麼就可以将這個 環境一鍵漫遊 到這個主機上，整個過程隻需要2個指令

Copy

## 添加主機到SmartIDE工具并擷取 主機ID
smartide host add <Docker主機IP位址> --username <SSH登入使用者名> --password < SSH登入用密碼>
## 一鍵漫遊環境到遠端主機
smartide start --host <主機ID> https://github.com/SmartIDE/sample-dapr-traffic-control
           

完成以上操作後開發者就可以啟動整個 

dapr-traffic-control

 的 環境進行開發調試了，效果如下

Dapr-traffic-control 開發調試過程

使用以上指令啟動環境以後，開發者首先會獲得一個類似VSCode的WebIDE界面，SmartIDE會自動啟動浏覽器并加載VSCode和應用代碼，這時開發者可以打開内置的終端工具，使用 

dapr init

 初始化 Dapr開發環境。

這時，dapr 會啟動3個docker容器，分别是 

dapr: 1.7.4

, 

zipkin

 和 

redis

。預設情況下，dapr 會利用 docker 為開發者提供必要的中間件元件。要完成 

dapr init

 動作，開發者必須首先在本地安裝 docker 環境，而在剛才的操作中，我們使用的是一個已經預裝了 docker 的容器環境，也就是在容器内提供了 docker 的支援，這樣開發者的環境完全處于容器内部，不再需要在開發機或者遠端伺服器上安裝這些服務， 這種環境我們稱之為 VM Like Container （VMLC），也就是類虛拟機容器環境，後續我們會專門針對VMLC進行更加詳細的介紹。這種方式也同時保證了無論開發者在什麼地方啟動這個環境，都可以獲得一緻的體驗。

現在，鍵入 

docker ps

 就可以看到這3個容器已經啟動完畢

現在，我們通過一個預先準備好的 

PowerShell

 腳本來啟動 

Traffice-Control

 應用的其他中間件環境，同樣，這個過程中你也不必考慮 

PowerShell

 工具是否存在的問題，因為這些都已經通過标準化的 開發者鏡像 提供了。你隻需要在終端中執行

Copy

cd src/Infrastructure/
pwsh start-all.ps1
           

你會注意到我們實際上在容器内執行了一系列的 

docker build

 和 

docker run

 的動作，完成了另外3個中間件容器的啟動，分别是：

• Maildev: 1.1.0

   - 負責模拟電子郵件發送和接受的調試工具

• Rabbitmq: 3-management-alpine

   - 消息隊列服務

• Mosquitto: 1.0

   - MQTT Broker 服務

如果再次運作 

docker ps

，你可以看到現在我們已經有了6個容器運作在環境中，構成了目前應用的完整中間件環境。現在我們就可以依次啟動3個業務元件，完成整個 

traffic-control

 應用的開發調試了。分别啟動3個終端視窗，進入 

src/TrafficControlService

, 

src/VehicleRegistrationService

, 

src/FineCollectionService

，并運作啟動指令

Copy

## 使用PowerShell腳本啟動服務
pwsh start-selfhosted.ps1
           

最後，我們來啟動模拟器。進入 

src/VisualSimulation

 目錄并運作以下指令

Copy

dotnet run 
           

現在，我們可以開啟另外2個浏覽器視窗，分别打開

• http://localhost:5000

   - 模拟器視窗，可以看到随機出現的汽車通過攝像頭的場景，同時調用以上業務服務，模拟交通流量。

• http://localhost:4000

   - 郵件模拟應用，可以持續收到郵件/超速罰單的過程

至此，我們完成了整個 

dapr-traffic-control

 示例應用的調試。在這個過程中，開發者不必了解背後的 Docker，遠端SSH隧道，容器鏡像環境的各種配置；而且，無論開發者在自己的本地開發機，還是遠端主機，或是k8s叢集中啟動這個環境，都可以使用統一的 

smartide start

 指令來完成。

SmartIDE 的設計初衷就是希望能夠最大程度的降低開發者上手一個應用的複雜度，無論這個應用是一個簡單的hello-world，還是一個複雜的微服務應用；也無論應用所需要的環境隻是簡單的SDK，還是各種複雜中間件以及繁瑣的網絡配置，都隻需要一個指令：

smartide start

SmartIDE支援跨平台，全技術棧和多種IDE工具（VSCode/JetBrains全家通/OpenSumi)；對于獨立開發者以及中小型企業使用者是完全免費并且開源的。如果你希望馬上嘗試一下這種全新的應用開發方式，請參考以下連結：

• 官網 https://SmartIDE.cn
• B 站頻道 https://space.bilibili.com/1001970523
• GitHub 開源位址 https://github.com/smartide
• Gitee 開源位址 https://gitee.com/smartide

世界上不是所有的東西都是用直接經濟契約來維系的，比如：陽光，空氣，愛情和開源軟體。