為什么說要搞定微服務(wù)架構(gòu)嘱函，先搞定RPC框架甘畅？
第一章聊了【“為什么要進(jìn)行服務(wù)化，服務(wù)化究竟解決什么問題”】
第二章聊了【“微服務(wù)的服務(wù)粒度選型”】
今天開始聊一些微服務(wù)的實踐往弓，第一塊疏唾，RPC框架的原理及實踐，為什么說要搞定微服務(wù)架構(gòu)函似，先搞定RPC框架呢槐脏？
一、需求緣起
服務(wù)化的一個好處就是撇寞，不限定服務(wù)的提供方使用什么技術(shù)選型顿天，能夠?qū)崿F(xiàn)大公司跨團(tuán)隊的技術(shù)解耦，如下圖：
服務(wù)A是歐洲團(tuán)隊提供服務(wù)蔑担，歐洲團(tuán)隊的技術(shù)背景是Java牌废，可以用Java實現(xiàn)服務(wù)；
服務(wù)B是美洲團(tuán)隊提供服務(wù)啤握，可以用C++實現(xiàn)服務(wù)鸟缕；
服務(wù)C是中國團(tuán)隊提供服務(wù)，可以用Go實現(xiàn)服務(wù)恨统；
服務(wù)的上游調(diào)用方叁扫，按照接口、協(xié)議即可完成對遠(yuǎn)端服務(wù)的調(diào)用畜埋。
但實際上莫绣，99.9%的公司的團(tuán)隊規(guī)模有限，技術(shù)團(tuán)隊人數(shù)也有限悠鞍，基本是使用同一套技術(shù)體系來調(diào)用和提供服務(wù)的：
這樣的話对室，如果沒有統(tǒng)一的服務(wù)框架模燥，RPC框架，各個團(tuán)隊的服務(wù)提供方就需要各自實現(xiàn)一套序列化掩宜、反序列化蔫骂、網(wǎng)絡(luò)框架、連接池牺汤、收發(fā)線程辽旋、超時處理、狀態(tài)機(jī)等“業(yè)務(wù)之外”的重復(fù)技術(shù)勞動檐迟，造成整體的低效补胚。所以，統(tǒng)一RPC框架把上述“業(yè)務(wù)之外”的技術(shù)勞動統(tǒng)一處理追迟，是服務(wù)化首要解決的問題溶其。
在達(dá)成【“使用統(tǒng)一的RPC框架”是正確的道路】這個一致的前提下，本文期望用簡單通俗的言語簡述一下一個通用RPC框架的技術(shù)點與實現(xiàn)敦间。
二瓶逃、RPC背景與過程
什么是RPC（Remote Procedure Call Protocol），遠(yuǎn)程過程調(diào)用廓块？
先來看下什么是本地函數(shù)調(diào)用厢绝，當(dāng)我們寫下：
int result = Add(1, 2);
這段代碼的時候，我們知道剿骨，我們傳入了1代芜，2兩個入?yún)?shù)，調(diào)用了本地代碼段中的一個Add函數(shù)浓利，得到了result出參挤庇。此時，傳入數(shù)據(jù)贷掖，傳出數(shù)據(jù)嫡秕，代碼段在同一個進(jìn)程空間里，這是本地函數(shù)調(diào)用苹威。
那有沒有辦法昆咽，我們能夠調(diào)用一個跨進(jìn)程（所以叫“遠(yuǎn)程”，典型的牙甫，這個進(jìn)程部署在另一臺服務(wù)器上）的函數(shù)呢掷酗？
最容易想到的，兩個進(jìn)程約定一個協(xié)議格式窟哺，使用Socket通信泻轰，來傳輸【入?yún)ⅰ俊菊{(diào)用哪個函數(shù)】【出參】。
假設(shè)請求報文協(xié)議是一個11字節(jié)的字節(jié)流：
（1）前3個字節(jié)填入函數(shù)名
（2）中間4個字節(jié)填入第一個參數(shù)
（3）末尾4個字節(jié)填入第二個參數(shù)
同時可以設(shè)計響應(yīng)報文協(xié)議是一個4字節(jié)的字節(jié)流：
即處理結(jié)果且轨。
調(diào)用方的代碼可能變?yōu)椋?/p>
request = MakePacket(“add”, 1, 2);
SendRequest_ToService_B(request);
response = RecieveRespnse_FromService_B();
int result = unMakePacket(respnse);
簡單解釋一下：
（1）講傳入?yún)?shù)變?yōu)樽止?jié)流
（2）將字節(jié)流發(fā)給服務(wù)B
（3）從服務(wù)B接受返回字節(jié)流
（4）將返回字節(jié)流變?yōu)閭鞒鰠?shù)
服務(wù)方的代碼可能變?yōu)椋?/p>
request = RecieveRequest();
args/function = unMakePacket(request);
result = Add(1, 2);
response = MakePacket(result);
SendResponse(response);
這個過程也很好理解：
（1）服務(wù)端收到字節(jié)流
（2）將字節(jié)流轉(zhuǎn)為函數(shù)名與參數(shù)
（3）本地調(diào)用函數(shù)得到結(jié)果
（4）將結(jié)果轉(zhuǎn)變?yōu)樽止?jié)流
（5）將字節(jié)流發(fā)送給調(diào)用方
這個過程用一張圖描述如上浮声，調(diào)用方與服務(wù)方的處理步驟都是非常清晰的虚婿。這個過程存在最大的問題是什么呢？
回答：調(diào)用方太麻煩了泳挥，每次都要關(guān)注很多底層細(xì)節(jié)
（1）入?yún)⒌阶止?jié)流的轉(zhuǎn)化然痊，即序列化應(yīng)用層協(xié)議細(xì)節(jié)
（2）socket發(fā)送，即網(wǎng)絡(luò)傳輸協(xié)議細(xì)節(jié)
（3）socket接受
（4）字節(jié)流到出參的轉(zhuǎn)化屉符，即反序列化應(yīng)用層協(xié)議細(xì)節(jié)
能不能調(diào)用層不關(guān)注這個細(xì)節(jié)呢剧浸？
回答：可以，RPC框架就是解決這個問題的矗钟，它能夠讓調(diào)用方“像調(diào)用本地函數(shù)一樣調(diào)用遠(yuǎn)端的函數(shù)（服務(wù)）”辛蚊。
三、RPC框架職責(zé)
通過上面的討論真仲，RPC框架要向調(diào)用方屏蔽各種復(fù)雜性，要向服務(wù)提供方也屏蔽各類復(fù)雜性：
（1）調(diào)用方感覺就像調(diào)用本地函數(shù)一樣
（2）服務(wù)提供方感覺就像實現(xiàn)一個本地函數(shù)一樣來實現(xiàn)服務(wù)
所以整個RPC框架又分為client部分與server部分初澎，負(fù)責(zé)把整個非（1）（2）的各類復(fù)雜性屏蔽秸应，這些復(fù)雜性就是RPC框架的職責(zé)。
再細(xì)化一些碑宴，client端又包含：序列化软啼、反序列化、連接池管理延柠、負(fù)載均衡祸挪、故障轉(zhuǎn)移、隊列管理贞间，超時管理贿条、異步管理等等等等職責(zé)。
server端包含：服務(wù)端組件增热、服務(wù)端收發(fā)包隊列整以、io線程、工作線程峻仇、序列化反序列化公黑、上下文管理器、超時管理摄咆、異步回調(diào)等等等等職責(zé)凡蚜。
however，因為篇幅有限吭从，這些細(xì)節(jié)不做深入展開朝蜘。
四、結(jié)論
（1）RPC框架是架構(gòu)微服務(wù)化的首要基礎(chǔ)組件影锈，它能大大降低架構(gòu)微服務(wù)化的成本芹务，提高調(diào)用方與服務(wù)提供方的研發(fā)效率蝉绷，屏蔽跨進(jìn)程調(diào)用函數(shù)（服務(wù)）的各類復(fù)雜細(xì)節(jié)
（2）RPC框架的職責(zé)是：讓調(diào)用方感覺就像調(diào)用本地函數(shù)一樣調(diào)用遠(yuǎn)端函數(shù)、讓服務(wù)提供方感覺就像實現(xiàn)一個本地函數(shù)一樣來實現(xiàn)服務(wù)
==【完】==
回【演進(jìn)】好架構(gòu)是進(jìn)化來的枣抱，不是設(shè)計來的（58架構(gòu)演進(jìn)）
回【微信】微信為啥這么省流量
回【id】細(xì)聊分布式ID生成方法
回【晉升】晉升的為什么不是你
