文章目錄
1.dubbo產生的背景
單一應用架構（ORM）–>垂直應用架構（MVC）–>分佈式服務架構(RPC)–>流動計算架構（SOA）
關注點在一直變化：
- 簡化增刪改查工作量的數據訪問框架ORM是關鍵
- 應用拆分，加速前端頁面開發的Web框架MVC是關鍵
- 核心業務抽離，作爲獨立服務，業務複用及整合的分佈式服務RPC框架是關鍵
- 服務越來越多，增加調度中心基於訪問壓力管理集羣，提高機器利用率的資源調度和治理中心SOA是關鍵
2.dubbo可以滿足的需求
- 遠程服務調用（最基本的）
- 註冊中心：地址維護，服務註冊和上下線感知，
- 服務調用之間鏈路監控，
- 服務熔斷限流，
- 服務負載均衡問題，
3.dubbo架構圖
3.1 dubbo各節點之間調用關係
- 0.服務容器負責啓動, 加載，運行服務提供者
- 1.服務提供者啓動時會將服務註冊到註冊中心
- 2.消費者啓動時從註冊中心訂閱服務
- 3.註冊中心返回給消費者服務端的地址列表，如有變更，註冊中心將基於長連接將變更數據給消費者
- 4.消費者基於負載均衡算法從註冊中心返回的地址列表中選擇一臺提供者進行調用，如果調用失敗，換另一臺重試
- 5.服務消費者和服務提供者從內存中累計調用次數和調用時間，定時每分鐘發送一次數據到監控中心；
3.2 dubbo各個節點角色
| 節點 | 角色說明 |
|---|---|
Provider |
暴露服務的服務提供方 |
Consumer |
調用遠程服務的服務消費方 |
Registry |
服務註冊與發現的註冊中心 |
Monitor |
統計服務的調用次數和調用時間的監控中心 |
Container |
服務運行容器 |
3.3 dubbo架構特點
連通性：註冊中心，提供者，消費者之間都是長連接
健壯性：
- 註冊中心任一臺宕機不影響使用，自動切換至其他機器；全部宕機，提供者和消費者可根據本地緩存繼續通信；
- 提供者任一臺宕機，不影響使用；全部宕機消費端無法使用可無限次重連等待提供者恢復；
- 數據庫宕機，不能註冊新服務
- 監控中心宕機，不影響使用，只丟失部分採樣數據；
可伸縮性：
- 註冊中心可以加集羣，動態擴容
- 服務端可以動態擴容，註冊中心會推送新的服務提供者信息給消費者
升級性
** 升級後節點角色說明**
| 節點 | 角色說明 |
|---|---|
Deployer |
自動部署服務的本地代理 |
Repository |
倉庫用於存儲服務應用發佈包 |
Scheduler |
調度中心基於訪問壓力自動增減服務提供者 |
Admin |
統一管理控制檯 |
Registry |
服務註冊與發現的註冊中心 |
Monitor |
統計服務的調用次數和調用時間的監控中心 |
4.dubbo所支持的協議：
| Feature | Maturity(成熟度) | Strength | Problem | Advise | User |
| Dubbo協議 （默認的） |
Stable | 單連接，長連接，TCP，NIO異步傳輸，Hessian 二進制序列化 | 在大文件傳輸時，單一連接會成爲瓶頸 | 可用於生產環境， 適合大併發小數據量的服務調用，消費者遠大於提供者的，不能傳輸大數據量 適用:常規遠程服務方法調用 |
|
|---|---|---|---|---|---|
| Rmi協議 | Stable | 多連接，短鏈接，TCP，同步傳輸，java標準二進制序列化 | 偶爾會連接失敗，需重建Stub | 可用於生產環境。適合消費者與提供者個數差不多，可傳文件 適用：常規遠程服務方法調用，與原生RMI服務互操作 |
|
| Hessian協議 | Stable | 多連接，短鏈接，HTTP，同步傳輸，Hessian二進制序列化 | 需hessian.jar支持，http短連接的開銷大 | 可用於生產環境 入參，出參數據包較大，提供者大於消費者，提供者壓力較大，可傳文件 適用：頁面傳輸，文件傳輸，或與原生hessian服務互操作 |
|
| http | 多連接，短鏈接，http, 同步傳輸，表單序列化 | 適用於入參出參大小混合，提供者多，消費者少，可用瀏覽器查看，可用表單url傳參，不支持傳文件 適用：需同時給應用程序和瀏覽器 JS 使用的服務 |
|||
| webservice | 多連接，短鏈接，http，同步傳輸，soap文本序列化 | - 適用場景：系統集成，跨語言調用 |
|||
| thrift | |||||
| memcached |
5. Dubbo核心的配置：
| 標籤 | 用途 | 解釋 |
|---|---|---|
<dubbo:service/> |
服務配置 | 用於暴露一個服務，定義服務的元信息，一個服務可以用多個協議暴露，一個服務也可以註冊到多個註冊中心 |
<dubbo:reference/>[2] |
引用配置 | 用於創建一個遠程服務代理，一個引用可以指向多個註冊中心 |
<dubbo:protocol/> |
協議配置 | 用於配置提供服務的協議信息，協議由提供方指定，消費方被動接受 |
<dubbo:application/> |
應用配置 | 用於配置當前應用信息，不管該應用是提供者還是消費者 |
<dubbo:module/> |
模塊配置 | 用於配置當前模塊信息，可選 |
<dubbo:registry/> |
註冊中心配置 | 用於配置連接註冊中心相關信息 |
<dubbo:monitor/> |
監控中心配置 | 用於配置連接監控中心相關信息，可選 |
<dubbo:provider/> |
提供方配置 | 當 ProtocolConfig 和 ServiceConfig 某屬性沒有配置時，採用此缺省值，可選 |
<dubbo:consumer/> |
消費方配置 | 當 ReferenceConfig 某屬性沒有配置時，採用此缺省值，可選 |
<dubbo:method/> |
方法配置 | 用於 ServiceConfig 和 ReferenceConfig 指定方法級的配置信息 |
<dubbo:argument/> |
參數配置 | 用於指定方法參數配置 |
5.2 配置之間的關係：
5.3 配置優先級
方法級優先，接口級次之，全局配置再次之；
如果級別一樣，則消費方優先，提供方次之；
提供者的配置會通過url經由註冊中心傳遞給消費方；
6.服務調用時阻塞的嗎？調用流程圖？
默認是同步等待結果阻塞的，支持異步調用。
Dubbo 是基於 NIO 的非阻塞實現並行調用，客戶端不需要啓動多線程即可完成並行調用多個遠程服務，相對多線程開銷較小，異步調用會返回一個 Future 對象。
7.容錯機制
在集羣的某些情況加，可包容範圍內，允許某些錯誤發生。
eg:程序當前無法響應，可選擇等待響應。
分佈式中，鏈路調用，調用鏈路中某節點網絡延遲故障，可能會導致雪崩，爲減少某個節點故障的影響範圍，需要構建容錯服務，優雅處理終端的相應結果；
cloud的容錯機制–熔斷機制對該服務做熔斷，提供該節點的備份服務。
7.1 dubbo提供了哪些容錯機制？
- failsafe：當請求調用失敗後，記錄失敗請求，屏蔽掉錯誤，定時重發。
- failover: 調用失敗後會重試其他服務器 ,可設置默認次數 retries （默認情況,默認重試2次，不包含首次，即3次
- failfast: 快速失敗，失敗以後立馬報錯
- failback: 失敗會自動恢復，失敗後記錄請求，然後重發(考慮冪等問題)
- forking: 併發請求，forks設置並行數
- broadcast：廣播，任意一臺報錯，則是執行方法報錯。
7.2 如何配置？
事務請求建議使用 failfast,failover；
配置cluster方式配置指定容錯方案
8.服務降級？
降級是爲了保證核心服務可用。
8.1 服務降級分類和應用場景？
降級有分類：自動降級，人工降級
人工降級：
對非核心服務進行人工降級，關閉對主流程沒有影響的功能；（比如雙11來臨時，暫時關閉推薦，評價模塊內容）
出現異常後我們做的其他處理
- 異常降級：
- 降低數據的實時性要求，提供默認數據給客戶端（電商推薦信息）
- 限流降級：
- 達到最大併發數之後是繼續處理還是選擇丟棄
- 類似線程池的拒絕策略
- 熔斷降級：
8.2 dubbo的降級方式
8.3 實現步驟？
提供了mock機制，放在客戶端來處理
創建一個Mock類實現對應接口，類名必須以Mock結尾；
註解方式配置：
xml方式配置：
9.Dubbo 集羣的負載均衡算法和特點?
在消費端和服務端都可以配置此算法，爲什麼可以配置在服務端呢？
客戶端拿到註冊中心返回給url列表後可以解析所有的配置，可以解析url裏面配置的負載均衡算法
在調用端做負載均衡處理
配置方式：loadbalance:
- 隨機-random 權重 隨機 （默認）
- 最小活躍-：
- 某個服務處理的請求越高，堆積的請求較少，活躍數越低，負載數量就越高，是最均衡的算法
- 權重輪詢-roundrobin
- 按A、B、C 順序來輪詢，同時根據權重調整輪詢次數
- 一致性hash
- hash算法，根據請求的方法和參數生成一個hash值，客戶端調用同一個方法時候會輪詢到同一臺機器上