為什麼Dapr是比SpringCloud和Istio更優雅的微服務框架？
Dapr 是微軟主導的雲原生開源項目，2019年10月首次發布，到正式發布 V1.0 版本的不到一年的時間內，github star 數達到了 1.2萬（現在已經超過1.7萬星），超過同期的 kubernetes、istio、knative 等，發展勢頭迅猛，業界關注度非常高。
Dapr 這個詞是是 「Distributed Application runtime」的首字母縮寫，非常精鍊的解釋了 dapr 是什麼：dapr 是一個為應用提供分散式能力的運行時。
Dapr官網 //dapr.io
Dapr已經在多家大廠支撐生產環境
隨著各家大廠的IT系統規模擴大，微服務架構已經成為了必需品和標準品，這也催生了 Dapr 這類非侵入式的（或者叫邊車模式SideCar）的微服務開發框架的使用。根據Dapr官方倉庫中的記錄，已經有非常多的大廠在 生產環境 中使用Dapr來支撐自己的微服務開發。這裡面不乏大家熟悉的騰訊，阿里，丁丁等中國大廠。
參考：
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 以及背後的各種考量
簡單來說，Dapr 從設計上就借鑒並考慮了之前的2種類似框架各自的優勢，並將所有的好處融合進來，將弊端剔除掉；是當前最先進最有前途的分散式微服務開發框架。
搭建Dapr開發環境的痛點
以下影片是展示了在容器中使用 VSCode WebIDE 開發一個 Dapr 應用的整個過程
既然是一個面向微服務的開發框架，Dapr 環境本身可以變得非常複雜。因為要引入各種類型的中間件，很多開發者會發現搭建一個可以運行使用Dapr的環境，可能需要先安裝一堆的各種服務。比如下面這個 Dapr 示例應用 Dapr-Traffice-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 而言，啟動命令如下
smartide start //github.com/SmartIDE/sample-dapr-traffic-control
也就是說，開發者可以使用 smartide start 加上程式碼庫地址來啟動任何應用的開發調試；而且，如果開發者自己有一台可以運行Docker環境的雲主機，那麼就可以將這個 環境一鍵漫遊 到這個主機上，整個過程只需要2個指令
## 添加主機到SmartIDE工具並獲取 主機ID
smartide host add <Docker主機IP地址> --username <SSH登錄用戶名> --password < SSH登錄用密碼>
## 一鍵漫遊環境到遠程主機
smartide start --host <主機ID> //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 工具是否存在的問題，因為這些都已經通過標準化的 開發者鏡像 提供了。你只需要在終端中執行
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，並運行啟動指令
## 使用PowerShell腳本啟動服務
pwsh start-selfhosted.ps1
最後，我們來啟動模擬器。進入 src/VisualSimulation 目錄並運行以下指令
dotnet run
現在，我們可以開啟另外2個瀏覽器窗口，分別打開
//localhost:5000– 模擬器窗口，可以看到隨機出現的汽車通過攝影機的場景，同時調用以上業務服務，模擬交通流量。//localhost:4000– 郵件模擬應用，可以持續收到郵件/超速罰單的過程
至此，我們完成了整個 dapr-traffic-control 示例應用的調試。在這個過程中，開發者不必了解背後的 Docker，遠程SSH隧道，容器鏡像環境的各種配置；而且，無論開發者在自己的本地開發機，還是遠程主機，或是k8s集群中啟動這個環境，都可以使用統一的 smartide start 指令來完成。
SmartIDE 的設計初衷就是希望能夠最大程度的降低開發者上手一個應用的複雜度，無論這個應用是一個簡單的hello-world，還是一個複雜的微服務應用；也無論應用所需要的環境只是簡單的SDK，還是各種複雜中間件以及繁瑣的網路配置，都只需要一個指令：smartide start
SmartIDE支援跨平台，全技術棧和多種IDE工具（VSCode/JetBrains全家通/OpenSumi)；對於獨立開發者以及中小型企業用戶是完全免費並且開源的。如果你希望馬上嘗試一下這種全新的應用開發方式，請參考以下鏈接：
- 官網 //SmartIDE.cn
- B 站頻道 //space.bilibili.com/1001970523
- GitHub 開源地址 //github.com/smartide
- Gitee 開源地址 //gitee.com/smartide
