前言

首先本文不討論為什么要服務化，包括服務化的優(yōu)點缺點。

其次本文也不討論什么是微服務，也不討論微服務和SOA的區(qū)別。

最后本文也不討論哪個技術最優(yōu)。

服務化框架構成

最基本的服務框架

基本的服務化框架包括如下模塊：統(tǒng)一的RPC框架，服務注冊中心，管理平臺。

有了這三個模塊，就能實現(xiàn)基本的服務化。下面對三個模塊進行具體分析。

RPC框架選型

為什么一定要是統(tǒng)一的RPC框架，而不是隨便啥框架，這里主要是為了技術對齊，減少開發(fā)人員的學習成本，減少團隊間溝通成本。

好，那么選擇一個RPC框架，我們都需要考量什么東西呢?

這里我總結下：

• 代碼規(guī)范：例如是對已有代碼透明，還是代碼生成;
• 通訊協(xié)議：例如是TCP還是HTTP;
• 序列化協(xié)議：例如是二進制還是文本，是否需要跨語言，性能;
• IO模型：異步/同步，阻塞/非阻塞;
• 負載均衡：客戶端軟負載，代理模式，服務端負載。

另外如果是從開源里面選擇，那么我們還需要考量：

• 成熟度：包括學習成本，社區(qū)熱度，文檔數(shù)，是否有團隊維護，穩(wěn)定性(盲目追求的不一定是最適合);
• 可擴展性：是否有SPI支持擴展，是否支持上下兼容;
• 跨語言：是否支持跨語言;
• 性能：要想作為RPC框架，性能一般都不會太差 [滑稽臉]。

下面是常見的一些開源框架的比較，大家可以看一下。

Ps：SOAP，RMI，Hessian，ICE就不列舉了。

選型小結：

• 如果需要與前端交互的，適合短鏈接、跨語言的RPC框架，例如RESTful、gRPC等;
• 如果純粹后臺交互的，適合長鏈接、序列化為二進制的RPC框架，例如thrift、dubbo等更高效;
• 如果是小公司，新公司從頭開始推廣服務化框架的，可以選擇規(guī)范化的RPC框架，例如thrift、RESTful、gRPC;
• 如果是已有大量業(yè)務代碼的再推廣服務框架的，那么最好選擇無代碼入侵的RPC框架，例如dubbo、RESTful。

注冊中心選型

注冊中心相當于是服務提供者和服務調用者之間的引路人，在服務治理中的作用極為重要。

選擇注冊中心基本要考量：

• 服務注冊：接收注冊信息的方式;
• 服務訂閱：返回訂閱信息的方式，推還是拉;
• 狀態(tài)檢測：檢測服務端存活狀態(tài)。

重點提一下這個狀態(tài)檢測，因為這個要是檢測不準確會誤判，導致嚴重后果，例如Zookeeper根據服務端注冊的臨時節(jié)點進行狀態(tài)檢測，如果服務端和Zookeeper之間的網絡閃斷，導致Zookeeper認為服務端已經死了，從而摘掉這個節(jié)點;但是其實客戶端和服務端直接的網絡是好的，這樣就有可能把節(jié)點全部摘掉，導致無可用節(jié)點。

如果是從開源里面選擇，那么還需要考量：

• 成熟度：包括學習成本，社區(qū)熱度，文檔數(shù)(盲目追求的不一定是最適合);
• 維護成本：注冊中心維護;
• 數(shù)據解構：是否能快速定位結果，是否能遍歷;
• 性能和穩(wěn)定性;
• CAP原則：CP(關注一致性)還是AP(關注可用性)。

下面是常見的一些使用開源項目做注冊中心的比較，大家可以看一下。

Ps：Redis和MySQL沒有列舉。

選型小結：

• 規(guī)模小選擇CP，RPC框架可以直接接入數(shù)據源;
• 規(guī)模大選擇AP， RPC框架不可以直接接入數(shù)據源;
• 存在跨機房，跨地域的盡量不要選有強一致性協(xié)議的注冊中心;
• RPC框架必須要有注冊中心不可用的容災策略;
• 服務狀態(tài)檢測十分重要。

簡易管理端

管理端沒啥特殊要求，最起碼能看到服務提供者和調用者即可。

完善的服務化框架

如果需要一個完善的服務化框架，那么必須增加外部模塊，常見的模塊如下圖：

接口文檔管理

提供一個接口文檔管理以及接口查詢的入口，可以是一個公共的WIKI，也可以是獨立的系統(tǒng)，等等。

這里可以定義接口的文檔，包括接口描述，方法定義，字段定義。可以定義接口的SLA，包括支持的并發(fā)數(shù)，tp99多少，建議配置是什么。還有就是接口的負責人等一些查詢的入口。

配置中心

提供一個配置管理的地方，這里說的配置主要指的是服務相關的一些配置。

配置包括分組配置、路由策略、黑白名單、降級開關、限流信息、超時時間、重試次數(shù)等等，任何可以動態(tài)變更的所有數(shù)據。

這樣服務提供者和服務調用者可以不需要重啟自己的應用，直接進行配置的變更。

配置中心可以獨立于注冊中心，也可以和注冊中心合并。

監(jiān)控中心

監(jiān)控服務關注接口維度，實例(例如所在JVM實例)維度的數(shù)據。RPC框架可以定時上報調用次數(shù)，耗時，異常等信息。監(jiān)控中心可以統(tǒng)計出服務質量信息，也可以進行監(jiān)控報警。

分布式跟蹤

區(qū)別于監(jiān)控中心，以調用鏈的模式對服務進行。RPC框架作為分布式跟蹤系統(tǒng)的一個天然埋點，可以很好的進行一個數(shù)據輸出。

服務治理(重點)

我這邊列了常見的服務治理功能，例如：

• 服務路由：

1. 權重：例如機器配置高的權重高，機器配置低的權重低;
2. IP路由：例如某幾臺機器只能調某幾臺機器;
3. 分組路由：例如自動根據配置調某個分組;
4. 參數(shù)路由：例如根據方法名進行讀寫分類，或者根據參數(shù)走不同的節(jié)點;
5. 機房路由：例如只走同機房，或者同機房優(yōu)先。

• 調用授權：

1. 應用授權：只有授權后的應用才能調這組服務
2. token：只有token對的調這組服務
3. 黑白名單：只有名單允許的才能調這組服務

• 動態(tài)分組：

1. 服務端切分組：可以根據分組的情況，對服務提供者進行一個動態(tài)的分組調度;
2. 客戶端切分組：可以對調用者進行一個分組調度。

• 調用限流：

1. 服務端限流：服務端基于令牌桶或者漏桶模型進行限流;
2. 客戶端限流：根據客戶端的標識，進行調用次數(shù)限流。

• 灰度部署：

1. 灰度上線：先啟動，驗證后在提供服務;
2. 預發(fā)標識：表示該服務為預發(fā)布服務;
3. 接口測試：方便的提供接口自動化功能測試功能。

• 配置下發(fā)：

1. 服務配置;
2. 全局配置。

• 服務降級：

1. Mock：出現(xiàn)異常或者測試情況下，返回Mock數(shù)據;
2. 熔斷：客戶端超時或者服務端超時;
3. 拒絕服務：服務端壓力大時，自動拒絕服務，保護自己。

網關

RPC框架大部分場景都是自己調用的，什么時候會需要一個網關呢?

網關可以提供如下功能：

• 統(tǒng)一的鑒權服務;
• 限流服務;
• 協(xié)議轉換：外部協(xié)議轉統(tǒng)一內部協(xié)議;
• Mock：服務測試，降級等;
• 其它一些統(tǒng)一處理邏輯(例如請求解析，響應包裝)。

服務注冊中心Plus

需要邏輯處理能力，例如對數(shù)據進行篩選過濾整合，計算服務路由等功能

同時還需要有與RPC框架交互的功能。

管理端Plus

管理端除了之前的簡單服務管理功能外，還需要提供配置信息展示，監(jiān)控信息展示，各種維度的數(shù)據展示。也就是下面提到的服務治理功能，都可以在管理端進行管理。另外，常見的服務治理功能，我們都可以作為開放服務供開發(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框架直接接入數(shù)據源;
• 監(jiān)控中心：監(jiān)控服務+HBase;
• 管理平臺：讀取Zookeeper做管理平臺，提供基本的上下線、黑白名單等功能。

于2012年4月上線，最大規(guī)模時，接口數(shù)3K，接入最大IP數(shù)20K。

第二代JSF背景

隨著京東業(yè)務的不斷快速增長，接口、機器數(shù)也呈數(shù)量級增長。同時京東成立子公司，在全國各地新建機房，部署結構也變得比較復雜。

加上SAF遺留的一些問題，大概面臨如下幾點：

RPC框架較重，性能有提高的空間;

注冊中心無業(yè)務邏輯，直接對外暴露;

京東復雜的部署架構需要更強大靈活的服務治理功能;

監(jiān)控數(shù)據不完整，維度不夠;

無應用依賴關系;

跨語言調用需求。

第二代JSF選擇

所以在2014年初，我們進行了第二代JSF的一個全部自研過程。

我們主要做了如下技術選型：(全部自研)

• RPC框架：輕量級，更佳的性能，兼容舊版本協(xié)議;
• 注冊中心：基于DB作為數(shù)據源，前置Index服務;支持十倍接入量;部分邏輯放在注冊中心減少客戶端負擔;
• 監(jiān)控中心：監(jiān)控Proxy服務+InfluxDB(2015后改為ElasticSearch);
• 管理端：基于DB，功能更強大，提供完善的服務治理管理功能;打通京東應用管理平臺，提供應用依賴關系梳理;
• HTTP網關：基于Netty，支持跨語言調用。

開發(fā)周期：7人/年(2014.1-2015.1)。包括開發(fā)、測試、預發(fā)、上線、推廣。

JSF架構簡圖

JSF注冊中心

京東的注冊中心是自研的，基于DB做的數(shù)據最終一致，也就是上面說的AP系統(tǒng)。注冊中心主要實現(xiàn)的就是服務列表的注冊訂閱推送，服務配置的獲取下發(fā)，服務狀態(tài)的實時查看等功能。注冊中心節(jié)點是無狀態(tài)的，可水平擴展的。整個注冊中心集群下的所有注冊中心幾點都是等價的。

每個機房部署多個注冊中心節(jié)點。同機房的RPC框架會優(yōu)先連本機房的注冊中心節(jié)點。

主要亮點如下：

• 引入Index服務概念：該服務就是一個最簡單HTTP的服務，用于找注冊中心節(jié)點(同機房或者壓力最小或者其它特定場景)，可以認為是不會掛的服務，RPC框架會優(yōu)先連該服務拿注冊中心地址，這樣子的好處是注冊中心地址變化后，RPC框架不用修改任何設置;
• 注冊中心內存有服務列表全量緩存，連不上數(shù)據庫也保證可讀;
• 數(shù)據庫的數(shù)據結構更適合各種維度展示、過濾、分析等，例如根據分組/IP/應用/機房等不同維度;
• 注冊中心就是個JSF服務，監(jiān)控到壓力大即可進行動態(tài)水平擴展，dogfooding，注冊中心其實是第一個JSF接口;
• 服務列表推送邏輯改進：例如原來100個Provider，現(xiàn)在加1個節(jié)點，之前的SAF是需要下發(fā)101個節(jié)點，自己判斷加了哪個節(jié)點，進行長鏈接建立;現(xiàn)在的改進是：修改為下發(fā)一個add事件，告知RPC框架加了1個節(jié)點，RPC框架進行長鏈接建立;這樣做大大減少了推送的數(shù)據量;
• 注冊中心與RPC框架可各種交互：注冊中心和RPC框架是長鏈接，而且JSF是支持Callback的，注冊中心可以調用RPC框架進行服務列表變化之外的操作;例如查看狀態(tài)，查看配置，配置下發(fā)等。

JSF RPC框架

RPC框架作為服務化里面的最基本的組件，其實都大同小異，因為RPC調用都繞不開代理、網絡、序列化這些操作。

JSF的RPC框架也類似，主要分為圖中的幾個模塊，下面大概列下一些功能特性：

• Config：Spring/API/Annotation
• Proxy: Javassist/JDK
• Invoker/Filter：內置+自定義，F(xiàn)ilter可擴展
• Client：Failover(默認)/FailFast/TransportPinpoint/MultiClientProxy
• 調用方式：同步(默認)/異步并行/異步回調/Callback/泛化
• Loadbalance：Random(默認)/Roundrobin/ConsistentHash/ LocalPreference/LeastActiveCall
• 路由：參數(shù)路由，分組路由，(IP級別路由邏輯在注冊中心做)
• 長連接維護：可用/死亡/亞健康
• 協(xié)議：JSF(默認)/SAF(dubbo)/HTTP/Telnet/HTTP2
• 第三方：REST/Webservice
• 序列化：MsgPack(默認)/Hessian/Json/Java/protobuf(c++)
• 壓縮：Snappy/LZMA
• 網絡：基于Netty4.0，長連接復用
• 線程模型：BOSS+WORKER+BIZ
• 容災：本地文件
• 請求上下文：IP，參數(shù)，隱式傳參
• 事件監(jiān)聽：響應事件，連接事件，狀態(tài)事件
• 分布式跟蹤支持：進行數(shù)據埋點

JSF管理平臺

提供強大管理功能，包括服務管理，監(jiān)控管理，注冊中心管理等功能。

我們針對服務治理的功能，提供了很多API，可以授權給開發(fā)人員或者外部系統(tǒng)使用。例如單元測試調用，限流配置/開關，動態(tài)分組，上下線等都提供了開放API。

JSF HTTP網關

網關是為了方便跨語言通過HTTP+JSON調用JSF服務，而不需要使用JSF的RPC框架。

特性如下：

• 基于Netty4.0實現(xiàn)HTTP網關，沒有使用Servlet容器，輕量高效;
• 支持服務自動發(fā)現(xiàn)：一般的HTTP服務，外面為了解決單點問題，都會用域名+VIP等實現(xiàn)高可用，故障轉移等;現(xiàn)在網關同時原生接入了JSF的注冊中心，知道了服務的提供者信息(JSF協(xié)議支持HTTP調用);服務提供者也不用關系擴容縮容導致服務的IP端口發(fā)生變化，網關會自動維護服務列表;
• 服務限流：針對方法級+應用進行授權，固定時間只能調用指定次數(shù);同一個方法也只能占用網關內的部分線程;
• 結果統(tǒng)一包裝：對異常等響應進行包裝。

JSF遇到京東彈性云

京東的JSF服務開發(fā)在京東彈性云的研發(fā)推廣之前完成，自從京東彈性云落地以來，也遇到不少問題。例如：

• 硬件指標：例如使用JDK獲取的Docker的指標有些是物理機的，我們需要特殊處理;
• 網絡：結合京東的“胖”容器，每個容器其實有實際IP，對外提供服務;
• 輕量：提高啟動速度;
• 開放服務：在容器銷毀或者非優(yōu)雅停機的情況下，提供API進行服務治理。

JSF規(guī)模

• 接口數(shù)：萬級
• 服務節(jié)點數(shù)：百萬級
• 接入實例數(shù)：十萬級
• 框架調用量：每天千億級別
• 監(jiān)控數(shù)據：每天120億條數(shù)據， 1.2T數(shù)據量
• HTTP網關：每天百億級別

總結

沒有最好，只有最適合!意思就是不要人云亦云，盲目看大公司用什么，現(xiàn)在什么最新，或者什么性能最好。

因為架構不是讓你一下子設計出來使用一輩子，好的架構都是慢慢演化而來的。不同的架構會做出不同的技術選型。所以無論什么時候都要結合自己的現(xiàn)狀以及未來幾年的規(guī)劃，來進行技術選型。

It’s just the beginning!

服務化框架的選擇只是開始，真正的變革是選擇后，公司整體業(yè)務和開發(fā)的變革。這個大家有空可以看看康威定律。

作者：章耿，原京東資深架構師，曾負責京東服務框架，配置中心等基礎平臺。近十年工作經驗，專注于基礎中間件等底層技術架構，對分布式系統(tǒng)/服務化/DevOps建設有一定經驗。

【本文來自51CTO專欄作者張開濤的微信公眾號(開濤的博客)，公眾號id: kaitao-1234567】

戳這里，看該作者更多好文