架構---什麼是RPC框架
RPC，即 Remote Procedure Call（遠端過程呼叫），呼叫遠端計算機上的服務，就像呼叫本地服務一樣。RPC可以很好的解耦系統，如WebService就是一種基於Http協議的RPC。
RPC 可基於 HTTP 或 TCP 協議，Web Service 就是基於 HTTP 協議的 RPC，它具有良好的跨平臺性，但其效能卻不如基於 TCP 協議的 RPC。會兩方面會直接影響 RPC 的效能，一是傳輸方式，二是序列化。
眾所周知，TCP 是傳輸層協議，HTTP 是應用層協議，而傳輸層較應用層更加底層，在資料傳輸方面，越底層越快，因此，在一般情況下，TCP 一定比 HTTP 快。就序列化而言，Java 提供了預設的序列化方式，但在高併發的情況下，這種方式將會帶來一些效能上的瓶頸，於是市面上出現了一系列優秀的序列化框架，比如：Protobuf、Kryo、Hessian、Jackson 等，它們可以取代 Java 預設的序列化，從而提供更高效的效能。
為了支援高併發，傳統的阻塞式 IO 顯然不太合適，因此我們需要非同步的 IO，即 NIO。Java 提供了 NIO 的解決方案，Java 7 也提供了更優秀的 NIO.2 支援，用 Java 實現 NIO 並不是遙不可及的事情，只是需要我們熟悉 NIO 的技術細節。
我們需要將服務部署在分散式環境下的不同節點上，通過服務註冊的方式，讓客戶端來自動發現當前可用的服務，並呼叫這些服務。這需要一種服務登錄檔（Service Registry）的元件，讓它來註冊分散式環境下所有的服務地址（包括：主機名與埠號）。
這個RPC整體框架如下：
這個RPC框架使用的一些技術所解決的問題：
服務釋出與訂閱：服務端使用Zookeeper註冊服務地址，客戶端從Zookeeper獲取可用的服務地址。
通訊：使用Netty作為通訊框架。
Spring：使用Spring配置服務，載入Bean，掃描註解。
動態代理：客戶端使用代理模式透明化服務呼叫。
訊息編解碼：使用Protostuff序列化和反序列化訊息。
關於上面的Zookeeper知識可參考 https://blog.csdn.net/qq_18416057/article/details/54927189 或者
https://blog.csdn.net/WeiJiFeng_/article/details/79775738
關於Spring知識可參考 https://blog.csdn.net/qq_22583741/article/details/79589910
關於Netty可參考 https://blog.csdn.net/bjweimengshu/article/details/78786315 或者 https://blog.csdn.net/javadhh/article/details/66477423
關於 Protostuff可參考 https://blog.csdn.net/canot/article/details/53750443
OSI網路七層模型
在說RPC和HTTP的區別之前，我覺的有必要了解一下OSI的七層網路結構模型（雖然實際應用中基本上都是五層），它可以分為以下幾層： （從上到下）
- 第一層：應用層。定義了用於在網路中進行通訊和傳輸資料的介面；
- 第二層：表示層。定義不同的系統中資料的傳輸格式，編碼和解碼規範等；
- 第三層：會話層。管理使用者的會話，控制使用者間邏輯連線的建立和中斷；
- 第四層：傳輸層。管理著網路中的端到端的資料傳輸；
- 第五層：網路層。定義網路裝置間如何傳輸資料；
- 第六層：鏈路層。將上面的網路層的資料包封裝成資料幀，便於物理層傳輸；
- 第七層：物理層。這一層主要就是傳輸這些二進位制資料。
實際應用過程中，五層協議結構裡面是沒有表示層和會話層的。應該說它們和應用層合併了。我們應該將重點放在應用層和傳輸層這兩個層面。因為HTTP是應用層協議，而TCP是傳輸層協議。好，知道了網路的分層模型以後我們可以更好地理解為什麼RPC服務相比HTTP服務要Nice一些！
RPC服務
從三個角度來介紹RPC服務：分別是RPC架構，同步非同步呼叫以及流行的RPC框架。
RPC架構
先說說RPC服務的基本架構吧。允許我可恥地盜一幅圖哈~我們可以很清楚地看到，一個完整的RPC架構裡面包含了四個核心的元件，分別是Client ,Server,Client Stub以及Server Stub，這個Stub大家可以理解為存根。分別說說這幾個元件：
- 客戶端（Client），服務的呼叫方。
- 服務端（Server），真正的服務提供者。
- 客戶端存根，存放服務端的地址訊息，再將客戶端的請求引數打包成網路訊息，然後通過網路遠端傳送給服務方。
- 服務端存根，接收客戶端傳送過來的訊息，將訊息解包，並呼叫本地的方法。
RPC主要是用在大型企業裡面，因為大型企業裡面系統繁多，業務線複雜，而且效率優勢非常重要的一塊，這個時候RPC的優勢就比較明顯了。實際的開發當中是這麼做的，專案一般使用maven來管理。比如我們有一個處理訂單的系統服務，先宣告它的所有的介面（這裡就是具體指Java中的interface），然後將整個專案打包為一個jar包，服務端這邊引入這個二方庫，然後實現相應的功能，客戶端這邊也只需要引入這個二方庫即可呼叫了。為什麼這麼做？主要是為了減少客戶端這邊的jar包大小，因為每一次打包釋出的時候，jar包太多總是會影響效率。另外也是將客戶端和服務端解耦，提高程式碼的可移植性。
同步呼叫與非同步呼叫
什麼是同步呼叫？什麼是非同步呼叫？同步呼叫就是客戶端等待呼叫執行完成並返回結果。非同步呼叫就是客戶端不等待呼叫執行完成返回結果，不過依然可以通過回撥函式等接收到返回結果的通知。如果客戶端並不關心結果，則可以變成一個單向的呼叫。這個過程有點類似於Java中的callable和runnable介面，我們進行非同步執行的時候，如果需要知道執行的結果，就可以使用callable介面，並且可以通過Future類獲取到非同步執行的結果資訊。如果不關心執行的結果，直接使用runnable介面就可以了，因為它不返回結果，當然啦，callable也是可以的，我們不去獲取Future就可以了。
流行的RPC框架
目前流行的開源RPC框架還是比較多的。下面重點介紹三種：
- gRPC是Google最近公佈的開源軟體，基於最新的HTTP2.0協議，並支援常見的眾多程式語言。 我們知道HTTP2.0是基於二進位制的HTTP協議升級版本，目前各大瀏覽器都在快馬加鞭的加以支援。 這個RPC框架是基於HTTP協議實現的，底層使用到了Netty框架的支援。
- Thrift是Facebook的一個開源專案，主要是一個跨語言的服務開發框架。它有一個程式碼生成器來對它所定義的IDL定義檔案自動生成服務程式碼框架。使用者只要在其之前進行二次開發就行，對於底層的RPC通訊等都是透明的。不過這個對於使用者來說的話需要學習特定領域語言這個特性，還是有一定成本的。
- Dubbo是阿里集團開源的一個極為出名的RPC框架，在很多網際網路公司和企業應用中廣泛使用。協議和序列化框架都可以插拔是及其鮮明的特色。同樣 的遠端介面是基於Java Interface，並且依託於spring框架方便開發。可以方便的打包成單一檔案，獨立程序執行，和現在的微服務概念一致。
偷偷告訴你集團內部已經不怎麼使用dubbo啦，現在用的比較多的叫HSF，又名“好舒服”。後面有可能會開源，大家拭目以待。
HTTP服務
其實在很久以前，我對於企業開發的模式一直定性為HTTP介面開發，也就是我們常說的RESTful風格的服務介面。的確，對於在介面不多、系統與系統互動較少的情況下，解決資訊孤島初期常使用的一種通訊手段；優點就是簡單、直接、開發方便。利用現成的http協議進行傳輸。我們記得之前本科實習在公司做後臺開發的時候，主要就是進行介面的開發，還要寫一大份介面文件，嚴格地標明輸入輸出是什麼？說清楚每一個介面的請求方法，以及請求引數需要注意的事項等。比如下面這個例子：POST http://www.httpexample.com/restful/buyer/info/share
介面可能返回一個JSON字串或者是XML文件。然後客戶端再去處理這個返回的資訊，從而可以比較快速地進行開發。但是對於大型企業來說，內部子系統較多、介面非常多的情況下，RPC框架的好處就顯示出來了，首先就是長連結，不必每次通訊都要像http一樣去3次握手什麼的，減少了網路開銷；其次就是RPC框架一般都有註冊中心，有豐富的監控管理；釋出、下線介面、動態擴充套件等，對呼叫方來說是無感知、統一化的操作。
最後這裡有一個RPC搭建的例子,可以研究一下:
https://my.oschina.net/huangyong/blog/361751