1 服務治理是什麼

1.1 定義

按Anne Thomas Manes的定義是：企業為了確保事情順利完成而實施的過程，包括最佳實踐、架構原則、治理規程、規律以及其他決定性的因素。服務治理指的是用來管理SOA的採用和實現的過程。

1.2 服務治理針對的問題

服務治理中一些典型的問題是：

1. 交付價值到利益相關者，這是投入與回報的問題
2. 對標準和規則的遵從（這是和審計相關的）
3. 變更管理：變更一個服務通常會引起不可預見的後果，因為服務的消費者對服務的提供者來說是不可知的。
4. 服務質量的保證：彈性新增新服務需要對這些服務給予額外的關注。

1.3 服務治理包括的行為

服務治理的一些關鍵活動包括：

1. 對開發新服務和升級現有服務的計劃
2. 管理服務的生命週期：確保升級服務不會影響目前的服務消費者
3. 制定方針來限制服務行為：制定所有服務都要遵從的規則，確保服務的一致性
4. 監控服務的效能：由於服務組合，服務停機和效能低下的後果是嚴重的。通過監控服務的效能和可用性，當問題出現的時候能馬上採取應對措施。
5. 管理由誰來呼叫服務、怎樣呼叫服務

接下來看具體服務治理手段。

2 節點管理

2.1 服務呼叫失敗原因

• 服務提供者故障
  e.g. 伺服器當機、程式意外退出
• 網路故障
  e.g. 服務提供者/註冊中心/服務消費者中任意兩者間網路故障

2.2 解決方案

2.2.1 註冊中心主動摘除機制

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

2.2.2 服務消費者摘除機制

雖然上面方案可解決服務提供者節點故障，但若因註冊中心與服務提供者間網路異常，最壞情況註冊中心會把服務節點全部摘除，導致服務消費者沒有可用服務節點呼叫，但服務提供者其實正常。
所以，將存活探測機制用在服務消費者這一端更合理，如果服務消費者呼叫服務提供者節點失敗，就將該節點從記憶體中儲存的可用服務提供者節點列表移除。

3 負載均衡

服務提供者節點一般以叢集形式存在。對於服務消費者，在從服務列表中選取可用節點時，如果能讓配置較高機器多承擔一些流量，就能充分利用機器效能。

3.1 常用的負載均衡演算法

3.1.1 隨機

從可用的服務節點中隨機選取一個節點。後端服務節點無論配置好壞，最終得到的呼叫量都差不多。

3.1.2 輪詢

按固定權重，對可用服務節點進行輪詢。如果所有服務節點的權重都是相同的，則每個節點的呼叫量也是差不多的。但可以給某些硬體配置較好的節點的權重調大些，這樣的話就會得到更大的呼叫量，從而充分發揮其效能優勢，提高整體呼叫的平均效能。

3.1.3 最少活躍呼叫

在服務消費者端記憶體動態維護同每個服務節點之間的連線數，當呼叫某個服務節點時，就給與這個服務節點之間的連線數加1，呼叫返回後，就給連線數減1。然後每次在選擇服務節點時，根據記憶體裡維護的連線數倒序排列，選擇連線數最小的節點發起呼叫，也就是選擇了呼叫量最小的服務節點，效能理論上也是最優的。

3.1.4 一致性Hash

相同引數的請求總是發到同一服務節點。當某一個服務節點出現故障時，原本發往該節點的請求，基於虛擬節點機制，平攤到其他節點上，不會引起劇烈變動。

這幾種演算法的實現難度也是逐步提升的，所以選擇哪種節點選取的負載均衡演算法要根據實際場景。如果後端服務節點的配置沒有差異，同等呼叫量下效能也沒有差異的話，選擇隨機或者輪詢演算法比較合適；如果後端服務節點存在比較明顯的配置和效能差異，選擇最少活躍呼叫演算法比較合適。

4 服務路由

對於服務消費者而言，在記憶體中的可用服務節點列表中選擇哪個節點不僅由負載均衡演算法決定，還由路由規則確定。

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

4.1 為什麼要制定路由規則

4.1.1 灰度釋出需求

比如，服務提供者做了功能變更，但希望先只讓部分人群使用，然後根據這部分人群的使用反饋，再來決定是否做全量釋出。這個時候，就可以通過類似按尾號進行灰度的規則限定只有一定比例的人群才會訪問新發布的服務節點。

4.1.2 多機房就近訪問需求

為了業務高可用，會將業務部署在不止一個IDC。不同IDC之間的訪問由於要跨IDC，通過專線訪問，尤其是IDC相距比較遠時延遲就會比較大，就要一次服務呼叫盡量選擇同一個IDC內部的節點，從而減少網路耗時開銷，提高效能。這時一般可以通過IP段規則來控制訪問，在選擇服務節點時，優先選擇同一IP段的節點。

4.2 路由規則配置

4.2.1 靜態配置

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

4.2.2 動態配置

路由規則存在註冊中心，服務消費者定期請求註冊中心來保持同步，要想改變服務消費者的路由配置，可通過修改註冊中心的配置，服務消費者在下一個同步週期之後，就會請求註冊中心來更新配置，從而實現動態更新。

5 服務容錯

服務呼叫並不總是一定成功的，前面我講過，可能因為服務提供者節點自身當機、程式異常退出或者服務消費者與提供者之間的網路出現故障等原因。對於服務呼叫失敗的情況，需要有手段自動恢復，來保證呼叫成功。

5.1 常用方案

5.1.1 FailOver

失敗自動切換。就是服務消費者發現呼叫失敗或者超時後，自動從可用的服務節點列表總選擇下一個節點重新發起呼叫，也可以設定重試的次數。這種策略要求服務呼叫的操作必須是冪等的，也就是說無論呼叫多少次，只要是同一個呼叫，返回的結果都是相同的，一般適合服務呼叫是讀請求的場景。

5.1.2 FailBack

失敗通知。就是服務消費者呼叫失敗或者超時後，不再重試，而是根據失敗的詳細資訊，來決定後續的執行策略。比如對於非冪等的呼叫場景，如果呼叫失敗後，不能簡單地重試，而是應該查詢服務端的狀態，看呼叫到底是否實際生效，如果已經生效了就不能再重試了；如果沒有生效可以再發起一次呼叫。

5.1.3 FailCache

失敗快取。就是服務消費者呼叫失敗或者超時後，不立即發起重試，而是隔一段時間後再次嘗試發起呼叫。比如後端服務可能一段時間內都有問題，如果立即發起重試，可能會加劇問題，反而不利於後端服務的恢復。如果隔一段時間待後端節點恢復後，再次發起呼叫效果會更好。

5.1.4 FailFast

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

• 冪等的呼叫，可以選擇FailOver或者FailCache
• 非冪等的呼叫可以選擇FailBack或者FailFast

6 總結

上面我講的服務治理的手段是最常用的手段，它們從不同角度來確保服務呼叫的成功率。節點管理是從服務節點健康狀態角度來考慮，負載均衡和服務路由是從服務節點訪問優先順序角度來考慮，而服務容錯是從呼叫的健康狀態角度來考慮，可謂是殊途同歸。

參考

• https://www.zhihu.com/question/56125281