公共平臺服務治理與鑒權

• 問題
• 解決問題
  • 鑒權
  • 注冊
  • 管理
• 總結

聊一聊最近了解的公司服務治理平臺，主要是思想，理念，而不是一種技術或框架。整個平臺設計，融入了OAUTH2認證，融入了微服務思想，幫助公司各系統在復雜的IT架構下，實現一種便捷統一的調用方案，同時完成調用的管理（監控、注冊、鑒權等）。

問題

一種思想或理念的出現，是否有價值，我認為主要在于它實際解決了哪些問題。基于這個價值觀，我們先看看，當一個公司有成百上千個系統時，會有哪些問題？
pi如：

1. 接口訪問有沒有鑒權？如何鑒權？這個話題很大，歸根揭底就是，要讓提供方知道調用方是誰（身份），并且同意調用（授權）。
2. 想看看系統間調用關系，得查代碼或文檔
3. 某個系統異常，怎么評估影響范圍？誰調了它，它調了誰？
4. 某系統調用量如何？負載均衡之前需不需要流量控制？

解決問題

服務治理平臺，目標就是把所有系統的所有接口，管理起來，對調用方進行鑒權，對提供方開放接口注冊，運營來統一管理授權。最終，解決權限問題，監控系統間調用關系，實現公司級的服務治理。

鑒權

開放平臺，很重要的一個點，就是對訪問進行權限控制。比較老的Basic Auth認證方式，在請求中加入用戶名和密碼，由服務端來進行鑒權。目前較通用的OAuth認證，通過Access Token完成授權與認證，具體不在詳述，目前我們使用OAUTH2。
其實，抽象來看，鑒權主要圍繞兩個問題，1，你是誰，2，同意不同意你調。
圍繞這兩個問題，我們來捋一捋怎么設計，來完成這兩個事：

1. 首先，得有個系統，讓調用方注冊用戶，申請訪問接口等，暫且命名為portal
2. 其次，提供方可以在平臺注冊自己的接口
3. 平臺管理人員，一般是運營同事，得有個系統可以查看注冊接口、訪問申請、注冊用戶、發布到公共平臺等等，并完成對各種訪問的授權，暫且命名為admin
4. 另，既然使用了oauth2，就得有個取token的系統，暫且命名為oauth
5. 最后，得有個對外的統一入口吧（即公共平臺），暫且名為open

整個調用鑒權流程，如下：

1. 調用方注冊用戶
2. protal返回用戶id和secret
3. 管理員，審核用戶（你是誰？）
4. 用戶id通過審核
5. 通過審核的用戶id申請相關訪問資源
6. 管理員，授權資源訪問（同不同意你調？）
7. 資源申請通過
8. 根據用戶id和secret到oauth取token
9. 到公共平臺（open）訪問你申請的資源，需要帶上token
10. open對token進行鑒權

注冊

提供方系統注冊接口到公共平臺，有很多種方式，目前，我們主要使用兩種方式：

1. 系統內置平臺注冊SDK，在代碼中實現接口注冊
2. 系統調用平臺開放注冊接口，通過HTTP請求完成注冊。這種方式，提供方本身又成了公共平臺的調用方，需要走一遍上面的鑒權過程=。=

整個注冊流程比較簡單，如下：

管理

基于以上分析，有個提供方并在平臺注冊了接口，有了調用方并在平臺獲得了授權，那么整個管理平臺的基本職能就可以推斷出來：

1. 服務注冊、維護
2. 消費維護、授權
3. 應用申請授權、接口發布
4. 系統運行態數據監控

總結

以上，僅僅是一個梗概，認識一個東西，我喜歡先看輪廓，在扣細節。
扣個細節，比如，授權單位如果是個接口的話，我們公司將近2w個openAPI接口，授權起來比較瑣碎，此時可以用分組來進行管理。如某個小系統的所有接口放到一個組里面，調用方通過申請組資源的訪問，來完成對組內接口的訪問。
在比如，授權時可以設置用戶token的時效，過期token失效，需要重新取token。時效設置多久合適，大家可以另行分析。我們系統是金融領域=。=

以上，感謝觀看，點個贊，我覺得不過分。