微服務治理

微服務遠程調用可能有以下問題：

• 註冊中心宕機；

• 服務提供者B有節點宕機；

• 服務消費者A和註冊中心之間的網絡不通；

• 服務提供者B和註冊中心之間的網絡不通；

• 服務消費者A和服務提供者B之間的網絡不通；

• 服務提供者B有些節點性能變慢；

• 服務提供者B短期內出現問題。

經常使用的服務治理手段：

節點管理

服務調用失敗通常是由兩類緣由引發的，一類是服務提供者自身出現問題，如服務器宕機、進程意外退出等；一類是網絡問題，如服務提供者、註冊中心、服務消費者這三者任意二者之間的網絡出現問題。

不管是服務提供者自身出現問題仍是網絡發生問題，都有兩種節點管理手段。

1. 註冊中心主動摘除機制

這種機制要求服務提供者定時的主動向註冊中心彙報心跳，註冊中心根據服務提供者節點最近一次彙報心跳的時間與上一次彙報心跳時間作比較，若是超出必定時間，就認爲服務提供者出現問題，繼而把節點從服務列表中摘除，並把最近的可用服務節點列表推送給服務消費者。

2. 服務消費者摘除機制

雖然註冊中心主動摘除機制能夠解決服務提供者節點異常的問題，但若是是由於註冊中心與服務提供者之間的網絡出現異常，最壞的狀況是註冊中心會把服務節點所有摘除，致使服務消費者沒有可用的服務節點調用，但其實這時候服務提供者自己是正常的。因此，將存活探測機制用在服務消費者這一端更合理，若是服務消費者調用服務提供者節點失敗，就將這個節點從內存中保存的可用服務提供者節點列表中移除。

負載均衡 

通常狀況下，服務提供者節點不是惟一的，可能是以集羣的方式存在，尤爲是對於大規模的服務調用來講，服務提供者節點數目可能有上百上千個。因爲機器採購批次的不一樣，不一樣服務節點自己的配置也可能存在很大差別，新採購的機器CPU和內存配置可能要高一些，同等請求量狀況下，性能要好於舊的機器。對於服務消費者而言，在從服務列表中選取可用節點時，若是能讓配置較高的新機器多承擔一些流量的話，就能充分利用新機器的性能。這就須要對負載均衡算法作一些調整。

經常使用的負載均衡算法主要包括如下幾種。

1. 隨機算法

顧名思義就是從可用的服務節點中隨機選取一個節點。通常狀況下，隨機算法是均勻的，也就是說後端服務節點不管配置好壞，最終獲得的調用量都差很少。

2. 輪詢算法 

就是按照固定的權重，對可用服務節點進行輪詢。若是全部服務節點的權重都是相同的，則每一個節點的調用量也是差很少的。但能夠給某些硬件配置較好的節點的權重調大些，這樣的話就會獲得更大的調用量，從而充分發揮其性能優點，提升總體調用的平均性能。

3. 最少活躍調用算法

這種算法是在服務消費者這一端的內存裏動態維護着同每個服務節點之間的鏈接數，當調用某個服務節點時，就給與這個服務節點之間的鏈接數加1，調用返回後，就給鏈接數減1。而後每次在選擇服務節點時，根據內存裏維護的鏈接數倒序排列，選擇鏈接數最小的節點發起調用，也就是選擇了調用量最小的服務節點，性能理論上也是最優的。

 4. 一致性Hash算法

指相同參數的請求老是發到同一服務節點。當某一個服務節點出現故障時，本來發往該節點的請求，基於虛擬節點機制，平攤到其餘節點上，不會引發劇烈變更。

這幾種算法的實現難度也是逐步提高的，因此選擇哪一種節點選取的負載均衡算法要根據實際場景而定。若是後端服務節點的配置沒有差別，同等調用量下性能也沒有差別的話，選擇隨機或者輪詢算法比較合適；若是後端服務節點存在比較明顯的配置和性能差別，選擇最少活躍調用算法比較合適。

服務路由

對於服務消費者而言，在內存中的可用服務節點列表中選擇哪一個節點不只由負載均衡算法決定，還由路由規則肯定。

所謂的路由規則，就是經過必定的規則如條件表達式或者正則表達式來限定服務節點的選擇範圍。 

爲何要制定路由規則呢？主要有兩個緣由。 

1. 業務存在灰度發佈的需求

好比，服務提供者作了功能變動，但但願先只讓部分人羣使用，而後根據這部分人羣的使用反饋，再來決定是否作全量發佈。這個時候，就能夠經過相似按尾號進行灰度的規則限定只有必定比例的人羣纔會訪問新發布的服務節點。 

2. 多機房就近訪問的需求

據我所知，大部分業務規模中等及以上的互聯網公司，爲了業務的高可用性，都會將本身的業務部署在不止一個IDC中。這個時候就存在一個問題，不一樣IDC之間的訪問因爲要跨IDC，經過專線訪問，尤爲是IDC相距比較遠時延遲就會比較大，好比北京和廣州的專線延遲通常在30ms左右，這對於某些延時敏感性的業務是不可接受的，因此就要一次服務調用盡可能選擇同一個IDC內部的節點，從而減小網絡耗時開銷，提升性能。這時通常能夠經過IP段規則來控制訪問，在選擇服務節點時，優先選擇同一IP段的節點。

那麼路由規則該如何配置呢？根據個人實際項目經驗，通常有兩種配置方式。

1. 靜態配置

就是在服務消費者本地存放服務調用的路由規則，在服務調用期間，路由規則不會發生改變，要想改變就須要修改服務消費者本地配置，上線後才能生效。

2. 動態配置

這種方式下，路由規則是存在註冊中心的，服務消費者按期去請求註冊中心來保持同步，要想改變服務消費者的路由配置，能夠經過修改註冊中心的配置，服務消費者在下一個同步週期以後，就會請求註冊中心來更新配置，從而實現動態更新。

服務容錯 

服務調用並不老是必定成功的，可能由於服務提供者節點自身宕機、進程異常退出或者服務消費者與提供者之間的網絡出現故障等緣由。對於服務調用失敗的狀況，須要有手段自動恢復，來保證調用成功。

經常使用的手段主要有如下幾種。

• FailOver：失敗自動切換。就是服務消費者發現調用失敗或者超時後，自動從可用的服務節點列表總選擇下一個節點從新發起調用，也能夠設置重試的次數。這種策略要求服務調用的操做必須是冪等的，也就是說不管調用多少次，只要是同一個調用，返回的結果都是相同的，通常適合服務調用是讀請求的場景。

• FailBack：失敗通知。就是服務消費者調用失敗或者超時後，再也不重試，而是根據失敗的詳細信息，來決定後續的執行策略。好比對於非冪等的調用場景，若是調用失敗後，不能簡單地重試，而是應該查詢服務端的狀態，看調用究竟是否實際生效，若是已經生效了就不能再重試了；若是沒有生效能夠再發起一次調用。

• FailCache：失敗緩存。就是服務消費者調用失敗或者超時後，不當即發起重試，而是隔一段時間後再次嘗試發起調用。好比後端服務可能一段時間內都有問題，若是當即發起重試，可能會加重問題，反而不利於後端服務的恢復。若是隔一段時間待後端節點恢復後，再次發起調用效果會更好。

• FailFast：快速失敗。就是服務消費者調用一次失敗後，再也不重試。實際在業務執行時，通常非核心業務的調用，會採用快速失敗策略，調用失敗後通常就記錄下失敗日誌就返回了。

對服務容錯不一樣策略的描述中，能夠看出它們的使用場景是不一樣的，通常狀況下對於冪等的調用，能夠選擇FailOver或者FailCache，非冪等的調用能夠選擇FailBack或者FailFast。