Dubbo教程-01-簡單介紹和springboot整合
寫在前面
hello 大家好
我是御風
歡迎大家收看御風大世界
今天我們迎來了Dubbo系列教程第1課
本次課我大家介紹分散式系統、dubbo框架
以及 演示一個 dubbo 的helloworld程式
看視訊演示請去 B站 https://www.bilibili.com/video/av36468178/
清晰無廣告 ！！！
本課原始碼 ： https://github.com/ibywind/dubbo-learn
分散式系統？
分散式系統是若干個獨立計算機的集合，這些計算機對於使用者來說就像單個相關係統
隨著網際網路的發展
單體應用已經不能支撐瞬間暴漲的使用者湧入
因此 分散式系統 流式計算框架 勢在必行
我們急需一個 分散式服務 治理框架 確保系統的 穩定有條不紊
dubbo 是什麼？
dubbo 最初由 阿里開源 現在是 Apache 頂級專案
主要作為一個 RPC框架 高效能
擁有很多高階特性 被業界普遍接受
基於什麼背景?
背景
隨著網際網路的發展，網站應用的規模不斷擴大，常規的垂直應用架構已無法應對，分散式服務架構以及流動計算架構勢在必行，亟需一個治理系統確保架構有條不紊的演進。
單一應用架構
當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。此時，用於簡化增刪改查工作量的資料訪問框架(ORM)是關鍵。
垂直應用架構
當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率。此時，用於加速前端頁面開發的Web框架(MVC)是關鍵。
分散式服務架構
當垂直應用越來越多，應用之間互動不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。此時，用於提高業務複用及整合的分散式服務框架(RPC)是關鍵。
流動計算架構
當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個排程中心基於訪問壓力實時管理叢集容量，提高叢集利用率。此時，用於提高機器利用率的資源排程和治理中心(SOA)是關鍵。
我們的需求
需求
在大規模服務化之前，應用可能只是通過 RMI 或 Hessian 等工具，簡單的暴露和引用遠端服務，通過配置服務的URL地址進行呼叫，通過 F5 等硬體進行負載均衡。
當服務越來越多時，服務 URL 配置管理變得非常困難，F5 硬體負載均衡器的單點壓力也越來越大。 此時需要一個服務註冊中心，動態的註冊和發現服務，使服務的位置透明。並通過在消費方獲取服務提供方地址列表，實現軟負載均衡和 Failover，降低對 F5 硬體負載均衡器的依賴，也能減少部分成本。
當進一步發展，服務間依賴關係變得錯蹤複雜，甚至分不清哪個應用要在哪個應用之前啟動，架構師都不能完整的描述應用的架構關係。 這時，需要自動畫出應用間的依賴關係圖，以幫助架構師理清理關係。
接著，服務的呼叫量越來越大，服務的容量問題就暴露出來，這個服務需要多少機器支撐？什麼時候該加機器？ 為了解決這些問題，第一步，要將服務現在每天的呼叫量，響應時間，都統計出來，作為容量規劃的參考指標。其次，要可以動態調整權重，在線上，將某臺機器的權重一直加大，並在加大的過程中記錄響應時間的變化，直到響應時間到達閾值，記錄此時的訪問量，再以此訪問量乘以機器數反推總容量。
以上是 Dubbo 最基本的幾個需求。
Dubbo架構
架構
節點角色說明
| 節點 | 角色說明 |
|---|---|
Provider |
暴露服務的服務提供方 |
Consumer |
呼叫遠端服務的服務消費方 |
Registry |
服務註冊與發現的註冊中心 |
Monitor |
統計服務的呼叫次數和呼叫時間的監控中心 |
Container |
服務執行容器 |
呼叫關係說明
-
服務容器負責啟動，載入，執行服務提供者。
-
服務提供者在啟動時，向註冊中心註冊自己提供的服務。
-
服務消費者在啟動時，向註冊中心訂閱自己所需的服務。
-
註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。
-
服務消費者，從提供者地址列表中，基於軟負載均衡演算法，選一臺提供者進行呼叫，如果呼叫失敗，再選另一臺呼叫。
-
服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘傳送一次統計資料到監控中心。
Dubbo 架構具有以下幾個特點，分別是連通性、健壯性、伸縮性、以及向未來架構的升級性。
連通性
-
註冊中心負責服務地址的註冊與查詢，相當於目錄服務，服務提供者和消費者只在啟動時與註冊中心互動，註冊中心不轉發請求，壓力較小
-
監控中心負責統計各服務呼叫次數，呼叫時間等，統計先在記憶體彙總後每分鐘一次傳送到監控中心伺服器，並以報表展示
-
服務提供者向註冊中心註冊其提供的服務，並彙報呼叫時間到監控中心，此時間不包含網路開銷
-
服務消費者向註冊中心獲取服務提供者地址列表，並根據負載演算法直接呼叫提供者，同時彙報呼叫時間到監控中心，此時間包含網路開銷
-
註冊中心，服務提供者，服務消費者三者之間均為長連線，監控中心除外
-
註冊中心通過長連線感知服務提供者的存在，服務提供者宕機，註冊中心將立即推送事件通知消費者
-
註冊中心和監控中心全部宕機，不影響已執行的提供者和消費者，消費者在本地快取了提供者列表
-
註冊中心和監控中心都是可選的，服務消費者可以直連服務提供者
健壯性
-
監控中心宕掉不影響使用，只是丟失部分取樣資料
-
資料庫宕掉後，註冊中心仍能通過快取提供服務列表查詢，但不能註冊新服務
-
註冊中心對等叢集，任意一臺宕掉後，將自動切換到另一臺
-
註冊中心全部宕掉後，服務提供者和服務消費者仍能通過本地快取通訊
-
服務提供者無狀態，任意一臺宕掉後，不影響使用
-
服務提供者全部宕掉後，服務消費者應用將無法使用，並無限次重連等待服務提供者恢復
伸縮性
-
註冊中心為對等叢集，可動態增加機器部署例項，所有客戶端將自動發現新的註冊中心
-
服務提供者無狀態，可動態增加機器部署例項，註冊中心將推送新的服務提供者資訊給消費者
升級性
當服務叢集規模進一步擴大，帶動IT治理結構進一步升級，需要實現動態部署，進行流動計算，現有分散式服務架構不會帶來阻力。下圖是未來可能的一種架構：
節點角色說明
| 節點 | 角色說明 |
|---|---|
Deployer |
自動部署服務的本地代理 |
Repository |
倉庫用於儲存服務應用釋出包 |
Scheduler |
排程中心基於訪問壓力自動增減服務提供者 |
Admin |
統一管理控制檯 |
Registry |
服務註冊與發現的註冊中心 |
Monitor |
統計服務的呼叫次數和呼叫時間的監控中心 |
開始寫程式碼
我們利用springboot作為專案的基礎
然後利用 阿里開源的 dubbo starter 來嘗試整合dubbo
dubbo springboot starter
大家可以去這個地址檢視詳細內容
我們使用 spring initializer 外掛 建立三個 springboot專案
當你有兩個以上springboot專案的時候，IDEA會出現一個 run dashboard提示
如下圖
run dashboard 就是下面的樣子
接著我們 開始寫程式碼
這一塊大家可以看我的視訊演示
首先我們啟動我們的 服務提供者
我們發現我們的 服務提供者 已經 開始 正常運行了
接著我們來到我們的 服務消費者 專案
我們寫了一個測試用例
在這裡 我們 不是 像以前一樣 寫 @autowired 註解了
而是換成了 dubbo自己的 reference 註解
並且 我們使用的也是 介面
當我們開始執行我們的 測試方法的時候
我們斷點檢視下 userService
大家可以看到 userService其實在這個時候是一種代理 。
而整個 Rpc的呼叫 也就是 代理 來實現的
總結
最開始用dubbo的時候大概是 2年前了
那個時候我還在一家外包公司
在那段時間
我交到了很多好朋友 （知道今天都是）
也正是從那個 使用dubbo的專案開始
我走上了技術學習的不歸路
所以這次做dubbo課程的話呢 我是心情很複雜的
其實對於我們這些應用工程師
使用一些開源框架的 目的就是 為了提升 系統的效能 穩定性
而我們學習和探究他的目的 其實是 為了提升我們自己
你會發現 很多東西 一通百通
解決問題的思路也是可以相互借鑑的