總結
聊一聊最近了解的公司服務治理平台，主要是思想，理念，而不是一種技術或框架。整個平台設計，融入了oauth2認證，融入了微服務思想，幫助公司各系統在複雜的it架構下，實現一種便捷統一的呼叫方案，同時完成呼叫的管理（監控、註冊、鑑權等）。問題
一種思想或理念的出現，是否有價值，我認為主要在於它實際解決了哪些問題。基於這個價值觀，我們先看看，當乙個公司有成百上千個系統時，會有哪些問題？
pi如：
1. 介面訪問有沒有鑑權？如何鑑權？這個話題很大，歸根揭底就是，要讓提供方知道呼叫方是誰（身份），並且同意呼叫（授權）。
2. 想看看系統間呼叫關係，得查**或文件
3. 某個系統異常，怎麼評估影響範圍？誰調了它，它調了誰？
4. 某系統呼叫量如何？負載均衡之前需不需要流量控制？
解決問題
服務治理平台，目標就是把所有系統的所有介面，管理起來，對呼叫方進行鑑權，對提供方開放介面註冊，運營來統一管理授權。最終，解決許可權問題，監控系統間呼叫關係，實現公司級的服務治理。
鑑權開放平台，很重要的乙個點，就是對訪問進行許可權控制。比較老的basic auth認證方式，在請求中加入使用者名稱和密碼，由服務端來進行鑑權。目前較通用的oauth認證，通過access token完成授權與認證，具體不在詳述，目前我們使用oauth2。
其實，抽象來看，鑑權主要圍繞兩個問題，1，你是誰，2，同意不同意你調。
圍繞這兩個問題，我們來捋一捋怎麼設計，來完成這兩個事：
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。時效設定多久合適，大家可以另行分析。我們系統是金融領域=。=
以上，感謝**，點個贊，我覺得不過分。
微信公眾平台服務框架
其他有些是除錯和測試檔案。本框架的使用很簡單，主要進行如下步驟 1.匯入資料庫檔案db.sql 具體來說可以使用一下命令 mysql u p 輸入密碼 source db.sql take care of path of file2.修改 中的配置 開啟config.php，將其中的 usernam...
zabbix後台服務與前台服務的分離
zabbix安裝 將zabbixserver mysql端與php apache分離 在usr路徑下建立了software資料夾，放入net snmp msyql zabbix 三個tar檔案 1.安裝net snmp包 為zabbix提供snmp支援，建議直接安裝，不要指定路徑，好處在後面安裝za...
微服務概覽與治理
微服務設計 grpc 服務發現 通過微服務架構，軟體開發過程能夠得到改善，開發效率能夠得到提高，從而創造更為優秀的產品和使用者滿意度。所謂微服務 microservice 就是一些具有足夠小的粒度 能夠相互協作且自治的服務體系。治理去中心化技術去中心化跨橫切面的功能，需要協調更新框架公升級發版 路由...