服務框架dubbo(一):基礎篇

學習博文：https://www.imooc.com/t/6300745

dubbo是一個分佈式服務框架，致力於提供高性能透明化RPC遠程調用方案，提供SOA服務治理解決方案。

• 因爲dubbo各個分層都是不少擴展，
  • 註冊中心有redis、zookeeper選項，
  • 通訊模塊有netty、mina，
  • 序列化有hession、hession二、java序列化等，
  • 本文不能面面俱到，重點闡述主線流程，
    • 註冊中心選擇zookeeper(client選擇curator)，
    • 通訊選擇netty，
    • 協議選擇dubbo，
    • 序列化選擇hession2,
    • 容器選擇Spring。
• 將應用拆分，並抽取出核心服務來解決上述問題，
• 還要考慮負載均衡、服務監控、高可用性、服務隔離與降級、路由策略、完善的容錯機制、序列化方案的選擇、通訊框架的選擇、開發人員對底層細節無感知、服務升級兼容性等問題。

分佈式服務調用時，每每會用到dubbo的負載均衡，dubbo提供多種可選的負載均衡策略進行配置，

• 但如何在調用的時候動態的指定某臺機器直接調用呢，負載均衡策略並不能知足這個需求，解決這個問題，則須要經過動態配置路由策略來實現。

節點角色說明：

• Consumer：服務消費者，即服務調用方；
• Provider：服務提供者，即被調用方；
• Registry：註冊中心，服務註冊與服務發現，dubbo支持4種註冊中心（multicast zookeeper redis simple），dubbo推薦使用zookeeper註冊中心；
• Monitor：服務監控中心，提供服務調用次數和調用時間統計；
• Container：服務運行容器；

調用關係說明：

• 0. 服務容器負責啓動，加載，運行服務提供者；
• 1. 服務提供者在啓動時，向註冊中心註冊本身提供的服務；
• 2. 服務消費者在啓動時，向註冊中心訂閱本身所需的服務；
• 3. 註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者；
• 4. 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選另外一臺調用；
• 5. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

Dubbo負載均衡

在集羣負載均衡時，dubbo提供了4種均衡策略，缺省爲random隨機調用，具體策略以下：

• Random LoadBalance
  • 隨機，按權重設置隨機機率。
  • 在一個截面上碰撞的機率高，但調用量越大分佈越均勻，並且按機率使用權重後也比較均勻，有利於動態調整提供者權重。

• RoundRobin LoadBalance

  • 輪循，按公約後的權重設置輪循比率。

  • 存在慢的提供者累積請求問題，好比：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，長此以往，全部請求都卡在調到第二臺上。

• LeastActive LoadBalance

  • 最少活躍調用數，相同活躍數的隨機，活躍數指調用先後計數差。

  • 使慢的提供者收到更少請求，由於越慢的提供者的調用先後計數差會越大。

• ConsistentHash LoadBalance

  • 一致性Hash，相同參數的請求老是發到同一提供者。

  • 當某一臺提供者掛時，本來發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引發劇烈變更。

直連提供者

• dubbo自己也會提供直連指定服務提供者的方式，繞過註冊中心，點對點鏈接到提供者。

動態配置路由規則

• dubbo服務的調用都是經過zookeeper註冊中心完成，咱們是否能夠向註冊中心寫入必定的路由規則，達到動態調用指定提供者的需求

• 以上代碼的規則，歸納就是：
  • 對於全部調用com.foo.BarService接口的消費者，
  • 若是消費者的ip是"10.20.153.10"，那麼這個消費者將調用ip爲"10.20.153.11"的提供者，
  • 這樣，經過動態配置註冊中心的路由規則，就實現了動態指定某個提供者的需求。

管理端

監控中心：

dubbo幾大核心組件：按照角色來劃分分爲：

• provider(服務提供方，對應前文的服務方)
• consumer(服務消費方，對應前文的調用方)
• monitor center(監控中心)
• registry center(註冊中心，接下來咱們以zookeeper爲例子說明)
• admin web console(管理端，用於修改路由、修改配置，最終做用於註冊中心)

更細緻的組件關係圖：按功能來劃分：

• directory (負責從zookeeper中心生成的provider列表)
• router (路由)
• fault-tolerantStrategy（容錯策略）
• loadBalance(負載均衡)
• monitorFilter(監控攔截)
• zookeeperClient(Zoookeeper客戶端，咱們使用zookeeper作例子)
• proxy(代理對象)
• nettyClient(咱們以netty做爲通訊框架)
• nettyServer(咱們以netty做爲通訊框架)
• Hession2Serialization(咱們選hession2做爲序列化方案)

集羣容錯

• 什麼是容錯機制？ 容錯機制指的是某種系統控制在必定範圍內的一種容許或包容犯錯狀況的發生
• 在分佈式架構下，網絡、硬件、應用均可能發生故障，因爲各個服務之間可能存在依賴關係，若是一條鏈路中的其中一個節點出現故障，將會致使雪崩效應。

• 爲了減小某一個節點故障的影響範圍，因此咱們才須要去構建容錯服務，來優雅的處理這種中斷的響應結果

Dubbo提供了6種容錯機制，分別以下：

• failsafe 失敗安全，能夠認爲是把錯誤吞掉（記錄日誌）
• failover(默認)   重試其餘服務器； retries（2）--重試兩次
• failfast 快速失敗， 失敗之後立馬報錯
• failback  失敗後自動恢復。
• forking  forks. 設置並行數
• broadcast  廣播，任意一臺報錯，則執行的方法報錯

  • 配置方式以下，經過cluster方式，配置指定的容錯方案：

服務降級

• 降級的目的是爲了保證核心服務可用。
• 降級能夠有幾個層面的分類： 自動降級和人工降級；
  • 按照功能能夠分爲：讀服務降級和寫服務降級；
    1. 對一些非核心服務進行人工降級，在大促以前經過降級開關關閉哪些推薦內容、評價等對主流程沒有影響的功能
    2. 故障降級，好比調用的遠程服務掛了，網絡故障、或者RPC服務返回異常。 那麼能夠直接降級，降級的方案好比設置默認值、採用兜底數據（系統推薦的行爲廣告掛了，能夠提早準備靜態頁面作返回）等等
    3. 限流降級，在秒殺這種流量比較集中而且流量特別大的狀況下，由於突發訪問量特別大可能會致使系統支撐不了。這個時候能夠採用限流來限制訪問量。當達到閥值時，後續的請求被降級，好比進入排隊頁面，好比跳轉到錯誤頁（活動太火爆，稍後重試等）
• dubbo的降級方式： Mock
  • 實現步驟
    1. 在client端建立一個TestMock類，實現對應IGpHello的接口（須要對哪一個接口進行mock，就實現哪一個），名稱必須以Mock結尾
    2. 在client端的xml配置文件中，添加以下配置，增長一個mock屬性指向建立的TestMock
    3. 模擬錯誤（設置timeout），模擬超時異常，運行測試代碼便可訪問到TestMock這個類。當服務端故障解除之後，調用過程將恢復正常

配置的優先級別

• 以timeout爲例，顯示了配置的查找順序，其它retries, loadbalance等相似
  • 方法級優先，接口級次之，全局配置再次之。
  • 若是級別同樣，則消費方優先，提供方次之。

  • 其中，服務提供方配置，經過URL經由註冊中心傳遞給消費方。

  • 建議由服務提供方設置超時，由於一個方法須要執行多長時間，服務提供方更清楚，

    • 若是一個消費方同時引用多個服務，就不須要關心每一個服務的超時設置