微服務治理

微服務遠端調用可能有如下問題：

注冊中心當機；

服務提供者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。