2.6 服務管理者

服務管理者是對服務消費者和服務提供者以及它們之間的通信過程進行全局管理的角色，同時也擔任著整個集群的管理工作。

服務管理者關心的幾個問題及解決方案如下

1.集群容錯問題

服務是以多節點、多實例的形式進行集群化、規模化部署的。集群出現節點、實例故障在所難免，可以允許單點故障的發生，但是不能由單點故障發展成系統崩潰，所以集群中需要有類似熔斷器的組件來阻斷服務出錯的進一步擴大。

2.集群監控問題

服務提供者與服務消費者之間的調用視圖、實例之間的調用延遲、各節點的資源使用情況等，需要一個鏈路追蹤系統來跟蹤，并呈現追蹤結果。

3.集群管理問題

（1）流量控制問題

在一些高并發的系統或場景中，來自各客戶端、消費者的請求并發TPS/QPS是非常高的，所以集群需要有網關及流量控制系統來做一定的防護，包括對非法的請求、攜帶錯誤參數請求的攔截，對合理流量的分區、限速等，以保護系統不被流量洪峰沖垮。

（2）分布式調用

服務提供者與服務消費者之間的通信，可以采用HTTP協議，也可以采用成熟的RPC協議和自定義協議。調用的方式也需要提供同步調用、異步調用、并行調用等方式。在性能方面，考慮IO模型、序列化效率、線程模型等的優化。

（3）分布式事務

分布式系統因為涉及集群，所以會帶來一定的復雜性、零散性，但部分業務上的整體事務要求也是必須滿足的，這時就必須引入一些分布式事務的解決方案來滿足業務的一致性要求。

4.集群安全問題

集群安全問題包含的范圍太廣，本小節探討的是服務化相關的安全問題，數據相關的安全問題見第9章。

（1）訪問者的身份安全控制

1）Token認證

服務化是開放訪問的，對非法訪問必須加以控制防護才能保證系統的安全。常見的有Token認證機制，Token認證過程如圖2-10所示。

① 用戶攜帶密碼訪問API后端。

② 后端傳遞用戶信息到認證服務器（OWIN等），認證服務器返回Token到客戶端，服務端可選擇存儲公鑰，這個Token攜帶了用戶的私鑰。

③ 客戶端存儲Token，再次訪問時攜帶Token訪問后端。

④ 后端發送Token到認證服務器驗證（服務端未存儲公鑰的情況），通過后返回客戶端所需資源。

業界較為常用的解決方案是JSON Web Tokens（JWT），JWT與上述標準認證過程的不同在于服務端存儲公鑰，客戶端再次訪問時，不需要再到認證服務器驗證。

2）三方認證

三方認證在當前APP之間的互相認證授權中比較常見，如三方登錄業務，這種認證方式給用戶帶來良好的體驗。三方認證過程如圖2-11所示（以微信用戶登錄豆瓣網站為例）。

三方授權過程是按照OAuth 2.0規范實現的，OAuth 2.0可以理解為一種允許第三方應用程序合法獲取資源所有者對資源處理權的授權憑證，有了這個憑證，第三方程序就可以擁有對資源進行處理的合法身份。

圖2-11中4個關鍵角色的對應關系如下所示。

1）資源擁有者：微信用戶。

2）資源服務器：微信服務器。

3）客戶端：豆瓣網。

4）授權服務器：微信開放平臺。

（2）通信數據的加密控制

雙方確認身份后，可以開始建立有效的通信通道。但是在通道中的數據傳輸仍然有被竊聽的風險，在微服務之間的通信過程中，常用的保障措施就是對通道過程進行嚴格的加密，根據通信方式不同，有HTTPS、對稱加密與非對稱加密等方式。

在RPC的通信中，常見的加密算法有對稱加密AES和非對稱加密RSA。

在HTTP協議通信中，常用的是HTTPS，HTTPS即HTTP+SSL（TLS），目前的加密方式一般是客戶端與服務器互相協商，找到雙方都支持的加密算法，一般都是混合算法，混合了上述的幾種算法，這也是HTTPS通信比HTTP通信稍慢的一個原因。

（3）權限控制

有了身份證明，對通信的過程進行了加密后，那么還剩下的安全管控就是對系統資源的分類訪問控制了。

一般來說，系統建設時期所考慮的用戶都是大量的、多樣化的。而由于系統本身業務的復雜性，除了超級管理員這樣的角色需要擁有系統的完全權限以外，其他的用戶都可以分門別類地對有限的資源進行訪問控制，也就是進行權限控制。

常見的權限控制有以下幾個控制角度。

1）對業務的控制

不同的用戶只能操作對應的業務，不能訪問權限以外的業務，這也是最常見的控制類型。例如客服人員不能有財務部門的業務訪問權限。

2）對用戶的控制

每個用戶對資源的需求程度是不一樣的，那么對資源進行處理的權限也就不一樣。例如普通用戶不能觀看最新的節目資源，VIP客戶才有這個權限。

3）對數據的處理權限

數據對于各類企業來說都是非常寶貴的資產，那么對數據的控制也是要求最嚴格、精細程度最高的。例如普通用戶對報表類數據僅有只讀權限、普通管理員對日志僅有追加權限等。