前言
首先本文不討論為什么要服務(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ì)齊，減少開(kāi)發(fā)人員的學(xué)習(xí)成本，減少團(tuán)隊(duì)間溝通成本。
好，那么選擇一個(gè)RPC框架，我們都需要考量什么東西呢？這里我總結(jié)下：
- 代碼規(guī)范：例如是對(duì)已有代碼透明，還是代碼生成。
- 通訊協(xié)議：例如是TCP還是HTTP
- 序列化協(xié)議：例如是二進(jìn)制還是文本，是否需要跨語(yǔ)言，性能
- IO模型：異步/同步，阻塞/非阻塞
- 負(fù)載均衡：客戶端軟負(fù)載，代理模式，服務(wù)端負(fù)載
另外如果是從開(kāi)源里面選擇，那么我們還需要考量：
- 成熟度：包括學(xué)習(xí)成本，社區(qū)熱度，文檔數(shù)，是否有團(tuán)隊(duì)維護(hù)，穩(wěn)定性（盲目追求的不一定是最適合）
- 可擴(kuò)展性：是否有SPI支持?jǐn)U展，是否支持上下兼容
- 跨語(yǔ)言：是否支持跨語(yǔ)言
- 性能：要想作為RPC框架，性能一般都不會(huì)太差 [滑稽臉]
下面是常見(jiàn)的一些開(kāi)源框架的比較，大家可以看一下。
Ps：SOAP，RMI，Hessian，ICE就不列舉了。
選型小結(jié)：
- 如果需要與前端交互的，適合短鏈接、跨語(yǔ)言的RPC框架，例如RESTful、gRPC等
- 如果純粹后臺(tái)交互的，適合長(zhǎng)鏈接、序列化為二進(jìn)制的RPC框架，例如thrift、dubbo等更高效
- 如果是小公司，新公司從頭開(kāi)始推廣服務(wù)化框架的，可以選擇規(guī)范化的RPC框架，例如thrift、RESTful、gRPC
- 如果是已有大量業(yè)務(wù)代碼的再推廣服務(wù)框架的，那么最好選擇無(wú)代碼入侵的RPC框架，例如dubbo、RESTful
注冊(cè)中心選型
注冊(cè)中心相當(dāng)于是服務(wù)提供者和服務(wù)調(diào)用者之間的引路人，在服務(wù)治理中的作用極為重要。
選擇注冊(cè)中心基本要考量：
- 服務(wù)注冊(cè)：接收注冊(cè)信息的方式
- 服務(wù)訂閱：返回訂閱信息的方式，推還是拉
- 狀態(tài)檢測(cè)：檢測(cè)服務(wù)端存活狀態(tài)
重點(diǎn)提一下這個(gè)狀態(tài)檢測(cè)，因?yàn)檫@個(gè)要是檢測(cè)不準(zhǔn)確會(huì)誤判，導(dǎo)致嚴(yán)重后果，
例如Zookeeper根據(jù)服務(wù)端注冊(cè)的臨時(shí)節(jié)點(diǎn)進(jìn)行狀態(tài)檢測(cè)，如果服務(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)致無(wú)可用節(jié)點(diǎn)。
如果是從開(kāi)源里面選擇，那么還需要考量：
- 成熟度：包括學(xué)習(xí)成本，社區(qū)熱度，文檔數(shù)（盲目追求的不一定是最適合）
- 維護(hù)成本：注冊(cè)中心維護(hù)
- 數(shù)據(jù)解構(gòu)：是否能快速定位結(jié)果，是否能遍歷
- 性能和穩(wěn)定性：
- CAP原則：CP（關(guān)注一致性）還是AP（關(guān)注可用性）
下面是常見(jiàn)的一些使用開(kāi)源項(xiàng)目做注冊(cè)中心的比較，大家可以看一下。
Ps：Redis和MySQL沒(méi)有列舉。
選型小結(jié)：
- 規(guī)模小選擇CP，RPC框架可以直接接入數(shù)據(jù)源
- 規(guī)模大選擇AP， RPC框架不可以直接接入數(shù)據(jù)源
- 存在跨機(jī)房，跨地域的盡量不要選有強(qiáng)一致性協(xié)議的注冊(cè)中心
- RPC框架必須要有注冊(cè)中心不可用的容災(zāi)策略
- 服務(wù)狀態(tài)檢測(cè)十分重要
簡(jiǎn)易管理端
管理端沒(méi)啥特殊要求，最起碼能看到服務(wù)提供者和調(diào)用者即可。
完善的服務(wù)化框架
如果需要一個(gè)完善的服務(wù)化框架，那么必須增加外部模塊，常見(jiàn)的模塊如下圖：
接口文檔管理
提供一個(gè)接口文檔管理以及接口查詢的入口，可以是一個(gè)公共的WIKI，也可以是獨(dú)立的系統(tǒng)，等等。
這里可以定義接口的文檔，包括接口描述，方法定義，字段定義
可以定義接口的SLA，包括支持的并發(fā)數(shù)，tp99多少，建議配置是什么