哈喽各位同學們大家好呀，小編今天帶着開發者學院中課程“Dubbo分布式Order訂單服務叢集治理實戰”幹貨總結來了~一起學習新課程吧！
課程連結以及圖譜位址小編已經為大家指路了，搭配學習效果更佳👇
課程名稱：Dubbo分布式Order訂單服務叢集治理實戰
課程位址：
https://developer.aliyun.com/learning/course/72/detail/1188圖譜名稱：Alibaba Java 技術圖譜
圖譜位址：
https://developer.aliyun.com/graph/javaDubbo分布式Order訂單服務叢集治理實戰
這節課模拟淘寶訂單服務看如何使用Dubbo，之前提到Dubbo有許多不同協定，包括核心部分注冊中心、用戶端、服務端。注冊中心要先上線，類似微服務架構，可以用zookeeper注冊服務中心注冊。
一、Dubbo分布式叢集架構
實戰開發首先安裝JAVA開發環境，Dubbo需要加部分依賴，因為Dubbo沒有快速建立的整套模闆，需要自己建構服務端、注冊中心等，用戶端需要添加依賴進行開發。
Dubbo是典型的分布式叢集架構，首先理清楚整個項目的結構關系，消費者是訂單的排程端，服務端是訂單的增、删、改、查的服務，注冊中心可以采用Zookeeper也可采用Nacos，具體項目可以繼續擴充，如加入訂單服務、支付服務、商品服務、賬号服務等相關服務叢集。目前先模拟一個服務，然後再到多個服務，單條線路跑通再做周邊的服務開發。
二、Dubbo分布式Order Service叢集架構
Dubbo模拟訂單服務，有服務的訂單就是服務端，需要host容器，可直接用自定義開發的控制台程式，需要在服務端定服務實作或服務接口，用戶端要實作排程端或有代理對象。注意，還需要Zookeeper注冊中心，可用内嵌的Zookeeper服務，也可用獨立部署的Zookeeper服務。
服務端的配置檔案和用戶端的配置檔案要配置，服務端配置檔案主要是：服務的端口、位址以及需要用哪些服務類型。用戶端配置檔案主要是：要調用的服務，注冊中心的位置使用什麼協定等關鍵參數。
三、Dubbo訂單服務叢集調用實戰
模拟整個開發工作，API端是服務接口，用戶端是用戶端程式，用戶端程式通用API代理，後面會調用後端真正的服務，真正的服務托管在Provider，是遠端服務提供方，規範服務類型托管、運作、接受請求。
如下圖所示，Provider複制了4份，參考其中一個代碼，是 main函數。
啟動後有自己的主程序去加載Bean，啟動接受請求，會模拟起用Zookeeper，Zookeeper是嵌入式模拟注冊中心。配置檔案對應的是provider，看下核心參數：
需要配置一下Zookeeper注冊中心位址，使用的協定是Dubbo原生協定。然後配置服務，服務接口暴露給用戶端使用。
之前複制了4份provider，後面多啟動幾個服務，主要用于模拟叢集，比如訂單服務要起用3台、30台、300台，是一對多的過程。同理都自己的配置檔案，因為在同一台機器上，配置不一樣，端口要變， 在同一台機器上模拟各個不同端口。如下圖所示，端口是“20893”：
模拟幾台機器一個叢集，當這幾台執行個體上線以後，都會Zookeeper進行注冊，輸入成功以後用戶端進行調用。用戶端調用訂單服務，訂單通過ID查詢訂單列印下傳回字元串。具體項目可以通過JDBC等連結資料庫。
排程端裡面是Dubbo的訂單接口，模拟死循環，不斷循環向用戶端發請求。
用戶端代理對象是proxy，proxy起用戶端代理作用，擷取配置檔案 Beanba的配置資訊，調取方法：通過建立對象調取訂單接口，根據ID模拟調用情況傳回結果。循環調用實際上隻起用了一個用戶端，隻不過每隔一秒調用一次。
四、Dubbo訂單服務叢集
模拟叢集，調用服務端一台機器的效果，調用用戶端，雖經過注冊中心，但用戶端經過注冊中心調用後端。如下圖所示，每隔一秒調後端，顯示“20890”：
說明這台伺服器隻有一台，再怎麼輪詢負載均衡都在一台機器。這時啟動第二台伺服器，逐漸上線更多服務，如下圖所示，有“20890”、“20891”，兩台機器都被調用了。
再上線第三台，用戶端本身加載最新服務清單有時間，這裡會有延遲，涉及服務上線和用戶端發現最新的服務清單的過程，這個機制跟微服務架構很像。
這裡面第二台伺服器已經出來，正常生産環境下，用戶端和服務端通過注冊中心解耦，可進行服務叢集的靈活擴容，平時隻有100台，但在雙11的時候可以加到1000台。展現了Duddo相比傳統簡單架構，往更進階别靈活性彈性叢集架構進行更新擴充，Duddo還有性能監控功能、生産環境的上線下線等功能。在當年背景下，阿裡能夠做出這種架構，并且在生産環境下大規模驗證（雙11驗證）非常牛。
分析整個Duddo架構，整個設計思想解決的問題，比目前的微服務架構協定更靈活、部署方式更靈活，架構更原生。現在Spring Cloud在全球範圍内使用更廣、生态文檔更完善，但實際上Duddo體系更單一，功能更豐富，性能更高。Duddo的并發性一定比Spring Cloud高，Duddo可以靈活的在區域網路和公網之間協定切換。
現在Duddo結合阿裡其他架構，逐漸做分布式大規模叢集治理生态的完善工作，雖然有些已經開始對接Spring Cloud微服務，但并不是重點。嚴格來說，Spring Cloud體系裡面的協定，隻是Duddo的一種，Duddo後面會做的越來越好Duddo3.0版本在做的雲原生、服務治理、安全與性能監控等模式支援都非常優秀。