寫在前面
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課程的話呢 我是心情很複雜的
其實對於我們這些應用工程師
使用一些開源框架的 目的就是 爲了提升 系統的性能 穩定性
而我們學習和探究他的目的 其實是 爲了提升我們自己
你會發現 很多東西 一通百通
解決問題的思路也是可以相互借鑑的