前言

首先本文不討論為什么要服務(wù)化沛贪，包括服務(wù)化的優(yōu)點(diǎn)缺點(diǎn)耘纱。
其次本文也不討論什么是微服務(wù)殴玛，也不討論微服務(wù)和SOA的區(qū)別。
最后本文也不討論哪個(gè)技術(shù)最優(yōu)翘地。

服務(wù)化框架構(gòu)成

最基本的服務(wù)框架

基本的服務(wù)化框架包括如下模塊：統(tǒng)一的RPC框架申尤，服務(wù)注冊(cè)中心，管理平臺(tái)衙耕。
有了這三個(gè)模塊昧穿，就能實(shí)現(xiàn)基本的服務(wù)化。
下面對(duì)三個(gè)模塊進(jìn)行具體分析橙喘。

RPC框架選型

為什么一定要是統(tǒng)一的RPC框架时鸵，而不是隨便啥框架，這里主要是為了技術(shù)對(duì)齊，減少開發(fā)人員的學(xué)習(xí)成本饰潜，減少團(tuán)隊(duì)間溝通成本初坠。
好，那么選擇一個(gè)RPC框架彭雾，我們都需要考量什么東西呢碟刺？

這里我總結(jié)下：

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

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

• 成熟度：包括學(xué)習(xí)成本幔托，社區(qū)熱度，文檔數(shù)蜂挪，是否有團(tuán)隊(duì)維護(hù)重挑，穩(wěn)定性（盲目追求的不一定是最適合）
• 可擴(kuò)展性：是否有SPI支持?jǐn)U展，是否支持上下兼容
• 跨語言：是否支持跨語言
• 性能：要想作為RPC框架棠涮，性能一般都不會(huì)太差

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

Ps：SOAP史煎，RMI，Hessian驳糯，ICE就不列舉了篇梭。

選型小結(jié)：

• 如果需要與前端交互的，適合短鏈接酝枢、跨語言的RPC框架恬偷，例如RESTful、gRPC等
• 如果純粹后臺(tái)交互的帘睦，適合長鏈接袍患、序列化為二進(jìn)制的RPC框架，例如thrift竣付、dubbo等更高效
• 如果是小公司诡延，新公司從頭開始推廣服務(wù)化框架的，可以選擇規(guī)范化的RPC框架古胆，例如thrift孕暇、RESTful、gRPC
• 如果是已有大量業(yè)務(wù)代碼的再推廣服務(wù)框架的，那么最好選擇無代碼入侵的RPC框架妖滔，例如dubbo隧哮、RESTful

注冊(cè)中心選型

注冊(cè)中心相當(dāng)于是服務(wù)提供者和服務(wù)調(diào)用者之間的引路人，在服務(wù)治理中的作用極為重要座舍。

選擇注冊(cè)中心基本要考量：

• 服務(wù)注冊(cè)：接收注冊(cè)信息的方式
• 服務(wù)訂閱：返回訂閱信息的方式沮翔，推還是拉
• 狀態(tài)檢測：檢測服務(wù)端存活狀態(tài)
  重點(diǎn)提一下這個(gè)狀態(tài)檢測，因?yàn)檫@個(gè)要是檢測不準(zhǔn)確會(huì)誤判曲秉，導(dǎo)致嚴(yán)重后果采蚀，
  例如Zookeeper根據(jù)服務(wù)端注冊(cè)的臨時(shí)節(jié)點(diǎn)進(jìn)行狀態(tài)檢測，如果服務(wù)端和Zookeeper之間的網(wǎng)絡(luò)閃斷承二，導(dǎo)致Zookeeper認(rèn)為服務(wù)端已經(jīng)死了榆鼠，從而摘掉這個(gè)節(jié)點(diǎn)。
  但是其實(shí)客戶端和服務(wù)端直接的網(wǎng)絡(luò)是好的亥鸠，這樣就有可能把節(jié)點(diǎn)全部摘掉妆够，導(dǎo)致無可用節(jié)點(diǎn)。

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

• 成熟度：包括學(xué)習(xí)成本神妹，社區(qū)熱度，文檔數(shù)（盲目追求的不一定是最適合）
• 維護(hù)成本：注冊(cè)中心維護(hù)
• 數(shù)據(jù)解構(gòu)：是否能快速定位結(jié)果家妆，是否能遍歷
• 性能和穩(wěn)定性：
• CAP原則：CP（關(guān)注一致性）還是AP（關(guān)注可用性）

下面是常見的一些使用開源項(xiàng)目做注冊(cè)中心的比較鸵荠，大家可以看一下。

Ps：Redis和MySQL沒有列舉。

選型小結(jié)：

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

簡易管理端

管理端沒啥特殊要求齿税，最起碼能看到服務(wù)提供者和調(diào)用者即可。

完善的服務(wù)化框架

如果需要一個(gè)完善的服務(wù)化框架炊豪，那么必須增加外部模塊凌箕，常見的模塊如下圖：

完善的服務(wù)化框架

接口文檔管理

提供一個(gè)接口文檔管理以及接口查詢的入口，可以是一個(gè)公共的WIKI词渤，也可以是獨(dú)立的系統(tǒng)牵舱，等等。
這里可以定義接口的文檔缺虐，包括接口描述芜壁，方法定義，字段定義
可以定義接口的SLA，包括支持的并發(fā)數(shù)慧妄，tp99多少顷牌，建議配置是什么
還有就是接口的負(fù)責(zé)人等一些查詢的入口。

配置中心

提供一個(gè)配置管理的地方塞淹，這里說的配置主要指的是服務(wù)相關(guān)的一些配置窟蓝。
配置包括分組配置、路由策略饱普、黑白名單运挫、降級(jí)開關(guān)、限流信息套耕、超時(shí)時(shí)間谁帕、重試次數(shù)等等，任何可以動(dòng)態(tài)變更的所有數(shù)據(jù)冯袍。
這樣服務(wù)提供者和服務(wù)調(diào)用者可以不需要重啟自己的應(yīng)用匈挖，直接進(jìn)行配置的變更。
配置中心可以獨(dú)立于注冊(cè)中心颠猴，也可以和注冊(cè)中心合并关划。

監(jiān)控中心

監(jiān)控服務(wù)關(guān)注接口維度，實(shí)例（例如所在JVM實(shí)例）維度的數(shù)據(jù)翘瓮。
RPC框架可以定時(shí)上報(bào)調(diào)用次數(shù)贮折，耗時(shí)，異常等信息资盅。
監(jiān)控中心可以統(tǒng)計(jì)出服務(wù)質(zhì)量信息调榄，也可以進(jìn)行監(jiān)控報(bào)警。

分布式跟蹤

區(qū)別于監(jiān)控中心呵扛，以調(diào)用鏈的模式對(duì)服務(wù)進(jìn)行每庆。
RPC框架作為分布式跟蹤系統(tǒng)的一個(gè)天然埋點(diǎn)，可以很好的進(jìn)行一個(gè)數(shù)據(jù)輸出今穿。

服務(wù)治理（重點(diǎn)）

我這邊列了常見的服務(wù)治理功能缤灵，例如：

• 服務(wù)路由：

  1. 權(quán)重：例如機(jī)器配置高的權(quán)重高，機(jī)器配置低的權(quán)重低
  2. IP路由：例如某幾臺(tái)機(jī)器只能調(diào)某幾臺(tái)機(jī)器
  3. 分組路由：例如自動(dòng)根據(jù)配置調(diào)某個(gè)分組
  4. 參數(shù)路由：例如根據(jù)方法名進(jìn)行讀寫分類蓝晒，或者根據(jù)參數(shù)走不同的節(jié)點(diǎn)
  5. 機(jī)房路由：例如只走同機(jī)房腮出，或者同機(jī)房優(yōu)先

• 調(diào)用授權(quán)：

  1. 應(yīng)用授權(quán)：只有授權(quán)后的應(yīng)用才能調(diào)這組服務(wù)
  2. token：只有token對(duì)的調(diào)這組服務(wù)
  3. 黑白名單：只有名單允許的才能調(diào)這組服務(wù)

• 動(dòng)態(tài)分組：

  1. 服務(wù)端切分組：可以根據(jù)分組的情況，對(duì)服務(wù)提供者進(jìn)行一個(gè)動(dòng)態(tài)的分組調(diào)度
  2. 客戶端切分組：可以對(duì)調(diào)用者進(jìn)行一個(gè)分組調(diào)度

• 調(diào)用限流：

  1. 服務(wù)端限流：服務(wù)端基于令牌桶或者漏桶模型進(jìn)行限流
  2. 客戶端限流：根據(jù)客戶端的標(biāo)識(shí)芝薇，進(jìn)行調(diào)用次數(shù)限流

• 灰度部署：

  1. 灰度上線：先啟動(dòng)胚嘲，驗(yàn)證后在提供服務(wù)
  2. 預(yù)發(fā)標(biāo)識(shí)：表示該服務(wù)為預(yù)發(fā)布服務(wù)
  3. 接口測試：方便的提供接口自動(dòng)化功能測試功能

• 配置下發(fā)：

1. 服務(wù)配置
2. 全局配置

• 服務(wù)降級(jí)：

1. Mock：出現(xiàn)異常或者測試情況下洛二，返回Mock數(shù)據(jù)
2. 熔斷：客戶端超時(shí)或者服務(wù)端超時(shí)
3. 拒絕服務(wù)：服務(wù)端壓力大時(shí)馋劈，自動(dòng)拒絕服務(wù)攻锰，保護(hù)自己

網(wǎng)關(guān)

RPC框架大部分場景都是P2P的，什么時(shí)候會(huì)需要一個(gè)網(wǎng)關(guān)呢妓雾？

網(wǎng)關(guān)可以提供如下功能：

• 通訊鏈路打通（例如跨機(jī)房網(wǎng)絡(luò)不通）
• 統(tǒng)一的鑒權(quán)服務(wù)
• 限流服務(wù)
• 協(xié)議轉(zhuǎn)換：外部協(xié)議轉(zhuǎn)統(tǒng)一內(nèi)部協(xié)議
• Mock：服務(wù)測試娶吞，降級(jí)等
• 其它一些統(tǒng)一處理邏輯（例如請(qǐng)求解析，響應(yīng)包裝）

服務(wù)注冊(cè)中心Plus

需要邏輯處理能力君珠，例如對(duì)數(shù)據(jù)進(jìn)行篩選過濾整合寝志，計(jì)算服務(wù)路由等功能。

同時(shí)還需要有與RPC框架交互的功能策添。

管理端Plus

管理端除了之前的簡單服務(wù)管理功能外材部，還需要提供配置信息展示，監(jiān)控信息展示唯竹，各種維度的數(shù)據(jù)展示乐导。也就是上面提到的服務(wù)治理功能路狮，都可以在管理端進(jìn)行管理后添。

另外，常見的服務(wù)治理功能嫉鲸，我們都可以作為開放服務(wù)供開發(fā)人員進(jìn)行一個(gè)調(diào)用产上。

京東實(shí)踐

第一代SAF背景

2012年初棵磷，京東從.NET轉(zhuǎn)Java。各個(gè)部門晋涣，各個(gè)業(yè)務(wù)線都沒有一個(gè)統(tǒng)一的服務(wù)化框架仪媒，有的是dubbo，有的是WebService谢鹊，有的是Hessian等等算吩。

同時(shí)各個(gè)業(yè)務(wù)系統(tǒng)自己有非常多的業(yè)務(wù)代碼。通過統(tǒng)計(jì)接口規(guī)模在1K左右佃扼，服務(wù)節(jié)點(diǎn)在50K左右偎巢，機(jī)器規(guī)模在8K左右，機(jī)房比較少拓?fù)浜唵巍?/p>

所以當(dāng)時(shí)的愿景和目標(biāo)比較明確：

• 京東系統(tǒng)服務(wù)化兼耀、API化的從無到有
• 統(tǒng)一京東的RPC調(diào)用框架
• 穩(wěn)定可靠
• 提供簡單的服務(wù)治理功能

第一代SAF選擇

OK压昼，結(jié)合我們的情況和上面的一些選型小結(jié)，我們當(dāng)時(shí)的選擇如下：

• RPC框架：基于dubbo2.3.2做配置擴(kuò)展瘤运，以及功能擴(kuò)展包括rest（resteasy）窍霞、webservice（cxf）、kryo/thrift序列化尽超、調(diào)用壓縮等
• 注冊(cè)中心：Zookeeper官撼，RPC框架直接接入
• 監(jiān)控中心：監(jiān)控服務(wù)+HBase
• 管理平臺(tái)：讀取Zookeeper做管理平臺(tái)梧躺，提供基本的上下線似谁、黑白名單等功能

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

第二代JSF背景

隨著京東業(yè)務(wù)的不斷快速增長，接口塞琼、機(jī)器數(shù)也呈數(shù)量級(jí)增長菠净。
同時(shí)京東成立子公司，在全國各地新建機(jī)房彪杉，部署結(jié)構(gòu)也變得比較復(fù)雜毅往。
加上SAF遺留的一些問題，大概面臨如下幾點(diǎn)：

• RPC框架較重派近，性能有提高的空間
• 注冊(cè)中心無業(yè)務(wù)邏輯攀唯，直接對(duì)外暴露
• 京東復(fù)雜的部署架構(gòu)需要更強(qiáng)大靈活的服務(wù)治理功能
• 監(jiān)控?cái)?shù)據(jù)不完整，維度不夠
• 無應(yīng)用依賴關(guān)系
• 跨語言調(diào)用需求

第二代JSF選擇

所以在2014年初渴丸，我們進(jìn)行了第二代JSF的一個(gè)全部自研過程侯嘀。
我們主要做了如下技術(shù)選型：（全部自研）

• RPC框架：輕量級(jí)，更佳的性能谱轨，兼容舊版本協(xié)議
• 注冊(cè)中心：基于DB作為數(shù)據(jù)源戒幔，前置Index服務(wù)；支持十倍接入量土童；部分邏輯放在注冊(cè)中心減少客戶端負(fù)擔(dān)
• 監(jiān)控中心：監(jiān)控Proxy服務(wù)+InfluxDB（2015后改為ElasticSearch）
• 管理端：基于DB诗茎，功能更強(qiáng)大，提供完善的服務(wù)治理管理功能娜扇；打通京東應(yīng)用管理平臺(tái)错沃，提供應(yīng)用依賴關(guān)系梳理；
• HTTP網(wǎng)關(guān)：基于Netty雀瓢，支持跨語言調(diào)用

開發(fā)周期：7人/年(2014.1-2015.1)枢析。包括開發(fā)、測試刃麸、預(yù)發(fā)醒叁、上線、推廣泊业。

JSF架構(gòu)簡圖

JSF架構(gòu)簡圖

JSF注冊(cè)中心

京東的注冊(cè)中心是自研的把沼，基于DB做的數(shù)據(jù)最終一致，也就是上面說的AP系統(tǒng)吁伺。

注冊(cè)中心主要實(shí)現(xiàn)的就是服務(wù)列表的注冊(cè)訂閱推送饮睬，服務(wù)配置的獲取下發(fā)，服務(wù)狀態(tài)的實(shí)時(shí)查看等功能篮奄。

注冊(cè)中心節(jié)點(diǎn)是無狀態(tài)的捆愁，可水平擴(kuò)展的割去。整個(gè)注冊(cè)中心集群下的所有注冊(cè)中心幾點(diǎn)都是等價(jià)的。

每個(gè)機(jī)房部署多個(gè)注冊(cè)中心節(jié)點(diǎn)昼丑。同機(jī)房的RPC框架會(huì)優(yōu)先連本機(jī)房的注冊(cè)中心節(jié)點(diǎn)呻逆。

主要亮點(diǎn)如下：

• 引入Index服務(wù)概念
  該服務(wù)就是一個(gè)最簡單HTTP的服務(wù)，用于找注冊(cè)中心節(jié)點(diǎn)（同機(jī)房或者壓力最小或者其它特定場景）菩帝，可以認(rèn)為是不會(huì)掛的服務(wù)咖城，
  RPC框架會(huì)優(yōu)先連該服務(wù)拿注冊(cè)中心地址，這樣子的好處是注冊(cè)中心地址變化后呼奢，RPC框架不用修改任何設(shè)置宜雀。
• 注冊(cè)中心內(nèi)存有服務(wù)列表全量緩存，連不上數(shù)據(jù)庫也保證可讀
• 數(shù)據(jù)庫的數(shù)據(jù)結(jié)構(gòu)更適合各種維度展示握础、過濾州袒、分析等
  例如根據(jù)分組，IP弓候，應(yīng)用郎哭，機(jī)房等不同維度
• 注冊(cè)中心就是個(gè)JSF服務(wù)，監(jiān)控到壓力大即可進(jìn)行動(dòng)態(tài)水平擴(kuò)展
  dogfooding菇存，注冊(cè)中心其實(shí)是第一個(gè)JSF接口
• 服務(wù)列表推送邏輯改進(jìn)
  例如原來100個(gè)Provider夸研，現(xiàn)在加1個(gè)節(jié)點(diǎn)，之前的SAF是需要下發(fā)101個(gè)節(jié)點(diǎn)依鸥，自己判斷加了哪個(gè)節(jié)點(diǎn)亥至，進(jìn)行長鏈接建立；
  現(xiàn)在的改進(jìn)是：修改為下發(fā)一個(gè)add事件贱迟，告知RPC框架加了1個(gè)節(jié)點(diǎn)姐扮，RPC框架進(jìn)行長鏈接建立；
  這樣做大大減少了推送的數(shù)據(jù)量衣吠。
• 注冊(cè)中心與RPC框架可各種交互
  注冊(cè)中心和RPC框架是長鏈接茶敏，而且JSF是支持Callback的，注冊(cè)中心可以調(diào)用RPC框架進(jìn)行服務(wù)列表變化之外的操作缚俏；
  例如查看狀態(tài)惊搏，查看配置，配置下發(fā)等

JSF RPC框架

RPC框架作為服務(wù)化里面的最基本的組件忧换，其實(shí)都大同小異恬惯，因?yàn)镽PC調(diào)用都繞不開代理、網(wǎng)絡(luò)亚茬、序列化這些操作酪耳。

JSF的RPC框架也類似，主要分為圖中的幾個(gè)模塊：

RPC模塊圖

下面大概列下一些功能特性：

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

JSF管理平臺(tái)

提供強(qiáng)大管理功能，包括服務(wù)管理沾凄，監(jiān)控管理梗醇，注冊(cè)中心管理等功能。

管理端服務(wù)管理

管理端服務(wù)詳情

管理端監(jiān)控界面

我們針對(duì)服務(wù)治理的功能撒蟀，提供了很多API叙谨，可以授權(quán)給開發(fā)人員或者外部系統(tǒng)使用。

例如單元測試調(diào)用保屯，限流配置/開關(guān)手负，動(dòng)態(tài)分組，上下線等都提供了開放API姑尺。

JSF HTTP網(wǎng)關(guān)

網(wǎng)關(guān)是為了方便跨語言通過HTTP+JSON調(diào)用JSF服務(wù)竟终，而不需要使用JSF的RPC框架。

特性如下：

• 基于Netty4.0實(shí)現(xiàn)HTTP網(wǎng)關(guān)切蟋，沒有使用Servlet容器统捶，輕量高效。
• 支持服務(wù)自動(dòng)發(fā)現(xiàn)
  一般的HTTP服務(wù)柄粹，外面為了解決單點(diǎn)問題喘鸟，都會(huì)用域名+VIP等實(shí)現(xiàn)高可用，故障轉(zhuǎn)移等驻右；
  現(xiàn)在網(wǎng)關(guān)同時(shí)原生接入了JSF的注冊(cè)中心什黑，知道了服務(wù)的提供者信息（JSF協(xié)議支持HTTP調(diào)用）。
  服務(wù)提供者也不用關(guān)系擴(kuò)容縮容導(dǎo)致服務(wù)的IP端口發(fā)生變化堪夭，網(wǎng)關(guān)會(huì)自動(dòng)維護(hù)服務(wù)列表兑凿。
• 服務(wù)限流
  針對(duì)方法級(jí)+應(yīng)用進(jìn)行授權(quán)，固定時(shí)間只能調(diào)用指定次數(shù)茵瘾。
  同一個(gè)方法也只能占用網(wǎng)關(guān)內(nèi)的部分線程
• 結(jié)果統(tǒng)一包裝
  對(duì)異常等響應(yīng)進(jìn)行包裝

JSF遇到京東彈性云

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

例如：

• 硬件指標(biāo)：例如使用JDK獲取的Docker的指標(biāo)有些是物理機(jī)的圣絮，我們需要特殊處理
• 網(wǎng)絡(luò)：結(jié)合京東的“胖”容器，每個(gè)容器其實(shí)有實(shí)際IP雕旨，對(duì)外提供服務(wù)
• 輕量：提高啟動(dòng)速度
• 開放服務(wù)：在容器銷毀或者非優(yōu)雅停機(jī)的情況下扮匠，提供API進(jìn)行服務(wù)治理

JSF規(guī)模

• 接口數(shù)：萬級(jí)
• 服務(wù)節(jié)點(diǎn)數(shù)：百萬級(jí)
• 接入實(shí)例數(shù)：十萬級(jí)
• 框架調(diào)用量：每天千億級(jí)別
• 監(jiān)控?cái)?shù)據(jù)：每天120億條數(shù)據(jù)捧请， 1.2T數(shù)據(jù)量
• HTTP網(wǎng)關(guān)：每天百億級(jí)別

總結(jié)

• 沒有最好，只有最適合棒搜！
  意思就是不要人云亦云疹蛉，盲目看大公司用什么，現(xiàn)在什么最新力麸，或者什么性能最好可款。
  因?yàn)榧軜?gòu)不是讓你一下子設(shè)計(jì)出來使用一輩子，好的架構(gòu)都是慢慢演化而來的克蚂。
  不同的架構(gòu)會(huì)做出不同的技術(shù)選型闺鲸。所以無論什么時(shí)候都要結(jié)合自己的現(xiàn)狀以及未來幾年的規(guī)劃，來進(jìn)行技術(shù)選型埃叭。
• It’s just the beginning摸恍！
  其實(shí)服務(wù)化框架的選擇只是開始，真正的變革是選擇一個(gè)統(tǒng)一的服務(wù)化框架后赤屋，公司整體業(yè)務(wù)和開發(fā)的變革立镶。建議大家有空可以看看康威定律。