為什么說要搞定微服務架構，先搞定RPC框架？
***章聊了【“為什么要進行服務化，服務化究竟解決什么問題”】
第二章聊了【“微服務的服務粒度選型”】
今天開始聊一些微服務的實踐，***塊，RPC框架的原理及實踐，為什么說要搞定微服務架構，先搞定RPC框架呢?
一、需求緣起
服務化的一個好處就是，不限定服務的提供方使用什么技術選型，能夠實現大公司跨團隊的技術解耦，如下圖：
服務A是歐洲團隊提供服務，歐洲團隊的技術背景是Java，可以用Java實現服務;
服務B是美洲團隊提供服務，可以用C++實現服務;
服務C是中國團隊提供服務，可以用Go實現服務;
服務的上游調用方，按照接口、協議即可完成對遠端服務的調用。
但實際上，99.9%的公司的團隊規模有限，技術團隊人數也有限，基本是使用同一套技術體系來調用和提供服務的：
這樣的話，如果沒有統一的服務框架，RPC框架，各個團隊的服務提供方就需要各自實現一套序列化、反序列化、網絡框架、連接池、收發線程、超時處理、狀態機等“業務之外”的重復技術勞動，造成整體的低效。所以，統一RPC框架把上述“業務之外”的技術勞動統一處理，是服務化首要解決的問題。
在達成【“使用統一的RPC框架”是正確的道路】這個一致的前提下，本文期望用簡單通俗的言語簡述一下一個通用RPC框架的技術點與實現。
二、RPC背景與過程
什么是RPC(Remote Procedure Call Protocol)，遠程過程調用?
先來看下什么是本地函數調用，當我們寫下：
int result = Add(1, 2);
這段代碼的時候，我們知道，我們傳入了1，2兩個入參數，調用了本地代碼段中的一個Add函數，得到了result出參。此時，傳入數據，傳出數據，代碼段在同一個進程空間里，這是本地函數調用。
那有沒有辦法，我們能夠調用一個跨進程(所以叫“遠程”，典型的，這個進程部署在另一臺服務器上)的函數呢?
最容易想到的，兩個進程約定一個協議格式，使用Socket通信，來傳輸【入參】【調用哪個函數】【出參】。
假設請求報文協議是一個11字節的字節流：
(1)前3個字節填入函數名
(2)中間4個字節填入***個參數
(3)末尾4個字節填入第二個參數
同時可以設計響應報文協議是一個4字節的字節流：
即處理結果。
調用方的代碼可能變為：
- request = MakePacket(“add”, 1, 2);
- SendRequest_ToService_B(request);
- response = RecieveRespnse_FromService_B();
- int result = unMakePacket(respnse);
簡單解釋一下：
(1)講傳入參數變為字節流
(2)將字節流發給服務B
(3)從服務B接受返回字節流
(4)將返回字節流變為傳出參數
服務方的代碼可能變為：
- request = RecieveRequest();
- args/function = unMakePacket(request);
- result = Add(1, 2);
- response = MakePacket(result);
- SendResponse(response);
這個過程也很好理解：
(1)服務端收到字節流
(2)將字節流轉為函數名與參數
(3)本地調用函數得到結果
(4)將結果轉變為字節流
(5)將字節流發送給調用方
這個過程用一張圖描述如上，調用方與服務方的處理步驟都是非常清晰的。這個過程存在***的問題是什么呢?
回答：調用方太麻煩了，每次都要關注很多底層細節
(1)入參到字節流的轉化，即序列化應用層協議細節
(2)socket發送，即網絡傳輸協議細節
(3)socket接受
(4)字節流到出參的轉化，即反序列化應用層協議細節
能不能調用層不關注這個細節呢?
回答：可以，RPC框架就是解決這個問題的，它能夠讓調用方“像調用本地函數一樣調用遠端的函數(服務)”。
三、RPC框架職責
通過上面的討論，RPC框架要向調用方屏蔽各種復雜性，要向服務提供方也屏蔽各類復雜性：
(1)調用方感覺就像調用本地函數一樣
(2)服務提供方感覺就像實現一個本地函數一樣來實現服務
所以整個RPC框架又分為client部分與server部分，負責把整個非(1)(2)的各類復雜性屏蔽，這些復雜性就是RPC框架的職責。
再細化一些，client端又包含：序列化、反序列化、連接池管理、負載均衡、故障轉移、隊列管理，超時管理、異步管理等等等等職責。
server端包含：服務端組件、服務端收發包隊列、io線程、工作線程、序列化反序列化、上下文管理器、超時管理、異步回調等等等等職責。
however，因為篇幅有限，這些細節不做深入展開。
四、結論
(1)RPC框架是架構微服務化的首要基礎組件，它能大大降低架構微服務化的成本，提高調用方與服務提供方的研發效率，屏蔽跨進程調用函數(服務)的各類復雜細節
(2)RPC框架的職責是：讓調用方感覺就像調用本地函數一樣調用遠端函數、讓服務提供方感覺就像實現一個本地函數一樣來實現服務
文章轉載自微信公眾號“架構師之路”
