作者：徐磊
文章首發地址：https://smartide.cn/zh/blog/2022-0601-dapr/
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 應用的整個過程
既然是一個面向微服務的開發框架，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?而言，啟動命令如下
smartide?start?https://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>?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?工具是否存在的問題，因為這些都已經通過標準化的?開發者鏡像?提供了。你只需要在終端中執行
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個瀏覽器窗口，分別打開
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
)
)
)