何爲RPC？
RPC即遠程過程調用，通過名字我們就能看出RPC關注的是遠程調用而非本地調用。
爲什麼要RPC？因爲兩個不同的服務器上的服務提供的方法不在一個內存空間，所以需要網絡編程才能傳遞方法調用所需要的參數。並且方法調用的結果也需要通過網絡編程來接收。但是如果我們自己手動網絡編程來實現這個調用過程的話工作量是非常大的，因爲我們需要考慮底層傳輸方式(TCP或者UDP)，序列化方式等。
RPC能幫助我們做什麼呢？簡單來說，通過RPC可以幫助我們遠程調用計算機上某個服務的方法。這個過程就像調用本地方法一樣簡單，並且我們不需要了解底層網絡編程的具體細節。
舉個例子：A,B兩個服務部署在不同的機器上，服務A想調用服務B的某個方法就可以通過RPC來做。
一言蔽之：RPC的出現就是爲了讓你調用遠程方法像調用本地方法一樣簡單。
RPC的原理是什麼？
我們可以將整個RPC的核心功能看作是下面5個部分的實現：
- 客戶端(服務消費端)：調用遠程方法的一端。
- 客戶端Stub(樁)：這其實就是一個代理類。代理類主要做的事情很簡單，就是把你調用方法，類，方法參數等信息傳遞到服務端。
- 網絡傳輸：網絡傳輸就是你要把你調用的方法的信息比如說參數這些東西傳輸到服務端，然後服務端執行完之後再把返回結果通過網絡傳輸給你傳輸回來。網絡傳輸的實現方式有很多種，比如最基本的Socket或者性能以及封裝更加優秀的Netty.
- 服務端Stub(樁)：這個樁就不是代理類的，實際指的就是接收到客戶端執行方法的請求後，去指定對應的方法返回結果給客戶端的類。
- 服務端(服務提供端)：提供遠程方法的一端。
簡單來講:
- 客戶端以本地調用的方式調用遠程服務。
- 客戶端Stub接收到調用後負責將方法，參數等組裝成能夠進行網絡傳輸的消息體(序列化)：RpcRequest
- 客戶端找到遠程服務的地址，並將消息發送到服務端
- 服務端Stub收到消息將消息反序列化成java對象。
- 服務端Stub根據對象中的類，方法，方法參數等信息調用本地的方法
- 服務端Stub等到方法的執行結果並組裝成能夠進行網絡傳輸的消息體，序列化後發送給客戶端
- 客戶端Stub收到消息並反序列化成java對象。這樣就得到了最終的結果。
有哪些常見的RPC框架？
我們這裏說的RPC框架指可以讓客戶端直接調用服務端方法，就像調用本地方法一樣簡單的框架，比如下面說的Dubbo，Motan，gRPC這些。如果需要和HTTP協議打交道，解封和封裝HTTP請求和響應，這種框架並不能算RPC框架，比如Feign。
Dubbo
Apache Dubbo是一款微服務框架，爲大規模微服務實踐提供高性能RPC通信，流量治理，可觀測性等解決方案，涵蓋Java,Golang等多種語言SDK實現。
Motan
Motan是新浪微博開源的一款RPC框架。據說在新浪微博正支撐着千億次調用。不過好像市面上很少有公司使用。
很多人喜歡拿Dubbo和Motan作比較，但是Motan更像是一個精簡版的Dubbo，可能是借鑑了Dubbo的思想，Motan的設計更加精簡，功能更加純粹。
不過不推薦實際項目中使用Motan，因爲Dubbo的社區活躍度以及生態都要好得多。
- 從 Motan 看 RPC 框架設計：http://kriszhang.com/motan-rpc-impl/
- Motan 中文文檔：https://github.com/weibocom/motan/wiki/zh_overview
gRPC
gRPC是Google開源的一個高性能，通用的RPC框架。其主要是面向移動應用開發並基於HTTP/2協議標準而設計的。基於ProtoBuf序列化協議開發，並支持衆多開發語言。
何謂 ProtoBuf？ 它是一種更加靈活、高效的數據格式，可用於通訊協議、數據存儲等領域，基本支持所有主流編程語言且與平臺無關。不過，通過 ProtoBuf 定義接口和數據類型還挺繁瑣的，這是一個小問題。
據說Dubbo-go 3.0主要是借鑑了gRPC。
不過gRPC的設計導致其幾乎沒有服務治理功能。如果想要解決這個問題還要依賴於其它組件。
- Github：https://github.com/grpc/grpc
- 官網：https://grpc.io/
Thrift
Apache Thrift 是 Facebook 開源的跨語言的 RPC 通信框架，目前已經捐獻給 Apache 基金會管理，由於其跨語言特性和出色的性能，在很多互聯網公司得到應用，有能力的公司甚至會基於 thrift 研發一套分佈式服務框架，增加諸如服務註冊、服務發現等功能。
Thrift支持多種不同的編程語言，包括C++、Java、Python、PHP、Ruby等（相比於 gRPC 支持的語言更多 ）。
- 官網：https://thrift.apache.org/
- Thrift 簡單介紹：https://www.jianshu.com/p/8f25d057a5a9
總結
gRPC和Thrift雖然支持跨語言的RPC調用，但是他們只提供了最基本的RPC框架功能，缺乏一系列配套的服務化組件和服務化治理功能的支持。
Dubbo不論是功能完善程度，生態系統還是社區活躍度來說都是最優秀的。而且Dubbo在國能還有很多成功的案例，比如噹噹網，滴滴等，是一款成熟穩定的RPC框架。最重要的是參考資料多，學習成本相對低。
dubbo也是Spring Cloud Alibaba裏的一個組件。
但是dubbo和motan主要是給java語言使用，雖然目前能兼容部分語言，但是不太推薦，跨語言的話，可以考慮gRPC。
本篇筆記就記到這裏，如果稍微幫到你了記得點個喜歡點個關注。最近這幾章側重於一些理論和現有的輪子，其實說有用吧，工作中幾乎用不到。但是說沒用吧，我們可以藉助原理去更好的理解這個工具，而且實現的方式也可以開拓我們的思路。總之所學即所得，也祝大家工作順順利利！