還有就是接口的負責人等一些查詢的入口。
配置中心
提供一個配置管理的地方，這里說的配置主要指的是服務相關的一些配置。
配置包括分組配置、路由策略、黑白名單、降級開關、限流信息、超時時間、重試次數等等，任何可以動態(tài)變更的所有數據。
這樣服務提供者和服務調用者可以不需要重啟自己的應用，直接進行配置的變更。
配置中心可以獨立于注冊中心，也可以和注冊中心合并。
監(jiān)控中心
監(jiān)控服務關注接口維度，實例（例如所在JVM實例）維度的數據。
RPC框架可以定時上報調用次數，耗時，異常等信息。
監(jiān)控中心可以統(tǒng)計出服務質量信息，也可以進行監(jiān)控報警。
分布式跟蹤
區(qū)別于監(jiān)控中心，以調用鏈的模式對服務進行。
RPC框架作為分布式跟蹤系統(tǒng)的一個天然埋點，可以很好的進行一個數據輸出。
服務治理（重點）
我這邊列了常見的服務治理功能，例如：
服務路由：
- 權重：例如機器配置高的權重高，機器配置低的權重低
IP路由：例如某幾臺機器只能調某幾臺機器 - 分組路由：例如自動根據配置調某個分組
- 參數路由：例如根據方法名進行讀寫分類，或者根據參數走不同的節(jié)點
- 機房路由：例如只走同機房，或者同機房優(yōu)先
- 權重：例如機器配置高的權重高，機器配置低的權重低
調用授權：
- 應用授權：只有授權后的應用才能調這組服務
- token：只有token對的調這組服務
- 黑白名單：只有名單允許的才能調這組服務
動態(tài)分組：
- 服務端切分組：可以根據分組的情況，對服務提供者進行一個動態(tài)的分組調度
- 客戶端切分組：可以對調用者進行一個分組調度
調用限流：
- 服務端限流：服務端基于令牌桶或者漏桶模型進行限流
- 客戶端限流：根據客戶端的標識，進行調用次數限流
灰度部署：
- 灰度上線：先啟動，驗證后在提供服務
- 預發(fā)標識：表示該服務為預發(fā)布服務
- 接口測試：方便的提供接口自動化功能測試功能
配置下發(fā)：
- 服務配置
- 全局配置
服務降級：
- Mock：出現異常或者測試情況下，返回Mock數據
- 熔斷：客戶端超時或者服務端超時
- 拒絕服務：服務端壓力大時，自動拒絕服務，保護自己
網關
RPC框架大部分場景都是自己調用的，什么時候會需要一個網關呢？
網關可以提供如下功能：
- 統(tǒng)一的鑒權服務
- 限流服務
- 協(xié)議轉換：外部協(xié)議轉統(tǒng)一內部協(xié)議
- Mock：服務測試，降級等
其它一些統(tǒng)一處理邏輯（例如請求解析，響應包裝）
服務注冊中心Plus
需要邏輯處理能力，例如對數據進行篩選過濾整合，計算服務路由等功能
同時還需要有與RPC框架交互的功能。
管理端Plus
管理端除了之前的簡單服務管理功能外，還需要提供配置信息展示，監(jiān)控信息展示，各種維度的數據展示。
也就是下面提到的服務治理功能，都可以在管理端進行管理。
另外，常見的服務治理功能，我們都可以作為開放服務供開發(fā)人員進行一個調用。
京東實踐
第一代SAF背景
2012年初，京東從.NET轉Java。各個部門，各個業(yè)務線都沒有一個統(tǒng)一的服務化框架，有的是dubbo，有的是WebService，有的是Hessian等等。
同時各個業(yè)務系統(tǒng)自己有非常多的業(yè)務代碼。通過統(tǒng)計接口規(guī)模在1K左右，服務節(jié)點在50K左右，機器規(guī)模在8K左右，機房比較少拓撲簡單。
所以當時的愿景和目標比較明確：
- 京東系統(tǒng)服務化、API化的從無到有
- 統(tǒng)一京東的RPC調用框架
- 穩(wěn)定可靠
- 提供簡單的服務治理功能
第一代SAF選擇
OK，結合我們的情況和上面的一些選型小結，我們當時的選擇如下：
- RPC框架：基于dubbo2.3.2做配置擴展，以及功能擴展包括rest（resteasy）、webservice（cxf）、kryo/thrift序列化、調用壓縮等
- 注冊中心：Zookeeper，RPC框架直接接入數據源
- 監(jiān)控中心：監(jiān)控服務+HBase
- 管理平臺：讀取Zookeeper做管理平臺，提供基本的上下線、黑白名單等功能
于2012年4月上線，最大規(guī)模時，接口數3K，接入最大IP數20K。
第二代JSF背景
隨著京東業(yè)務的不斷快速增長，接口、機器數也呈數量級增長。