Dapr - 大廠都用的這個微服務框架好在哪裡?

微軟技術棧 發表於 2022-06-13
框架 微服務

(轉載自:SmartIDE部落格)

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 - 大廠都用的這個微服務框架好在哪裡?

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

隨著各家大廠的IT系統規模擴大,微服務架構已經成為了必需品和標準品,這也催生了 Dapr 這類非侵入式的(或者叫邊車模式SideCar)的微服務開發框架的使用。根據Dapr官方倉庫中的記錄,已經有非常多的大廠在生產環境中使用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 從設計上就借鑑並考慮了之前的2種類似框架各自的優勢,並將所有的好處融合進來,將弊端剔除掉;是當前最先進最有前途的分散式微服務開發框架。
Dapr - 大廠都用的這個微服務框架好在哪裡?

搭建Dapr開發環境的痛點

以下視訊是展示了在容器中使用 VSCode WebIDE 開發一個 Dapr 應用的整個過程
https://www.bilibili.com/vide...

既然是一個面向微服務的開發框架,Dapr 環境本身可以變得非常複雜。因為要引入各種型別的中介軟體,很多開發者會發現要學習或者自己搭建一個可以執行使用Dapr的應用,可能需要先安裝一堆的各種服務。比如下面這個 Dapr 示例應用 Dapr-Traffice-Control

雖然應用本身並不是特別複雜,只用到了3個服務元件,但是支撐這3個服務的中介軟體卻有5個之多,包括:

  • 作為 MQTT Broker 的 Mosquitto
  • 常用的快取中介軟體 Redis
  • 訊息佇列 RabbitMQ
  • 電子郵件傳送中介軟體 SMTP 服務
  • 金鑰服務Secrets

簡單介紹一下這個示例的業務背景, dapr-traffice-control 模擬了一個常見的超速攝像頭系統的實現,通過檢測車輛通過道路上2個攝像頭之間的耗時,計算車速,併傳送罰單給司機。如下圖:
Dapr - 大廠都用的這個微服務框架好在哪裡?

這裡用到的業務元件只有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 的 環境進行開發除錯了,效果如下
image.png

Dapr-traffic-control 開發除錯過程

使用以上指令啟動環境以後,開發者首先會獲得一個類似VSCode的WebIDE介面,SmartIDE會自動啟動瀏覽器並載入VSCode和應用程式碼,這時開發者可以開啟內建的終端工具,使用 dapr init 初始化 Dapr開發環境。
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個容器已經啟動完畢

Dapr - 大廠都用的這個微服務框架好在哪裡?

現在,我們通過一個預先準備好的 PowerShell 指令碼來啟動 Traffice-Control 應用的其他中介軟體環境,同樣,這個過程中你也不必考慮 PowerShell 工具是否存在的問題,因為這些都已經通過標準化的 開發者映象 提供了。你只需要在終端中執行

cd src/Infrastructure/
pwsh start-all.ps1

Dapr - 大廠都用的這個微服務框架好在哪裡?
你會注意到我們實際上在容器內執行了一系列的 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

Dapr - 大廠都用的這個微服務框架好在哪裡?

最後,我們來啟動模擬器。進入 src/VisualSimulation 目錄並執行以下指令

dotnet run

現在,我們可以開啟另外2個瀏覽器視窗,分別開啟

  • http://localhost:5000 - 模擬器視窗,可以看到隨機出現的汽車通過攝像頭的場景,同時呼叫以上業務服務,模擬交通流量。
  • http://localhost:4000 - 郵件模擬應用,可以持續收到郵件/超速罰單的過程

Dapr - 大廠都用的這個微服務框架好在哪裡?
至此,我們完成了整個 dapr-traffic-control 示例應用的除錯。在這個過程中,開發者不必瞭解背後的 Docker,遠端SSH隧道,容器映象環境的各種配置;而且,無論開發者在自己的本地開發機,還是遠端主機,或是k8s叢集中啟動這個環境,都可以使用統一的 smartide start 指令來完成。

SmartIDE 的設計初衷就是希望能夠最大程度的降低開發者上手一個應用的複雜度,無論這個應用是一個簡單的hello-world,還是一個複雜的微服務應用;也無論應用所需要的環境只是簡單的SDK,還是各種複雜中介軟體以及繁瑣的網路配置,都只需要一個指令:smartide start

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


Dapr - 大廠都用的這個微服務框架好在哪裡?

長按識別二維碼

關注微軟中國MSDN

相關文章