分佈式的幾件小事（六）dubbo如何作服務治理、服務降級以及重試

1.服務治理

服務治理主要做用是改變運行時服務的行爲和選址邏輯，達到限流，權重配置等目的。
①調用鏈路自動生成
一個大型的分佈式系統，會由大量的服務組成，那麼這些服務之間的依賴關係和調用鏈路會很複雜，這就須要dubbo對多個服務之間的調用自動記錄下來，生成一張圖，顯示出來。

②服務反覆問壓力以及時長統計
須要自動統計各個接口和服務之間的調用次數以及訪問延時，並且要分紅兩個級別。一個級別是接口粒度，就是每一個服務的每一個接口天天被調用多少次，TP50，TP90，TP99，三個檔次的請求延時分別是多少；第二個級別是從源頭入口開始，一個完整的請求鏈路通過幾十個服務以後，完成一次請求，天天全鏈路走多少次，全鏈路請求延時的TP50，TP90，TP99，分別是多少。
這些東西都搞定了以後，後面才能夠來看當前系統的壓力主要在哪裏，如何來擴容和優化。

③服務分層
對服務的架構進行分層處理，好比Mapper負責接口映射，原子數據庫操做。dao層負責數據訪問，調用mapper，組裝數據。service層負責對外提供dubbo服務，webservice層暴露接口等等，防止出現循環依賴的問題。

④調用鏈路失敗的監控和報警
服務之間的調用鏈路可能會很長，那麼就會存在出現失敗的可能性很大，最好對調用鏈路進行監控，一旦出問題能保存本次調用鏈路失敗的全鏈路日誌，好作問題排查。
若是調用失敗，或者超時了最好能進行報警，能夠將報警發的郵件、釘釘羣等裏面，早點處理。

2.服務降級

好比服務A調用服務B，結果服務B掛掉了，服務A重試幾回調用服務B，仍是沒有響應，那麼就會直接走降級邏輯，即走一個備用的邏輯，給調用者返回響應。

3.服務重試

①失敗重試
consumer調用provider失敗了，好比provider出現了異常，這時候就要進行重試。

②服務超時
好比某個服務的接口，要耗費5s，你這邊不能幹等着，你這邊配置了timeout以後，我等待2s，還沒返回，我直接就撤了，不能幹等你。

若是是超時了，timeout就會設置超時時間；若是是調用失敗了自動就會重試指定的次數。

<dubbo:reference id="xxxx" interface="xx" check="true" async="false" retries="3" timeout="2000"/>

timeout，通常設置爲200ms，咱們認爲不能超過200ms還沒返回。

retries，3次，設置retries，還通常是在讀請求的時候，好比你要查詢個數據，你能夠設置個retries，若是第一次沒讀到，報錯，重試指定的次數，嘗試再次讀取2次。