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

dubbo是一個分散式服務框架，致力於提供高效能透明化RPC遠端呼叫方案，提供SOA服務治理解決方案。

• 由於dubbo各個分層都是很多擴充套件，
  • 註冊中心有redis、zookeeper選項，
  • 通訊模組有netty、mina，
  • 序列化有hession、hession2、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經由註冊中心傳遞給消費方。

  • 建議由服務提供方設定超時，因為一個方法需要執行多長時間，服務提供方更清楚，

    • 如果一個消費方同時引用多個服務，就不需要關心每個服務的超時設定