分散式下的遠端通訊技術（RPC）的一些理解

前言

為什麼需要RPC，而不是簡單的HTTP介面？

剛開始還是菜鳥的時候，時常把RPC和HTTP搞混淆，本身概念還沒理解清楚，心裡就浮躁的不行，導致鬧出了不少笑話。

什麼是RPC？

RPC（Remote Promote Call） 一種程式間通訊方式。允許像呼叫本地服務一樣呼叫遠端服務。

RPC框架的主要目標就是讓遠端服務呼叫更簡單、透明。RPC框架負責遮蔽底層的傳輸方式（TCP或者UDP）、序列化方式（XML/JSON/二進位制）和通訊細節。開發人員在使用的時候只需要瞭解誰在什麼位置提供了什麼樣的遠端服務介面即可，並不需要關心底層通訊細節和呼叫過程。

什麼是HTTP？

HTTP協議是應用層的超文字傳送協議，它是Web的基礎。HTTP協議位於TCP/IP協議棧的應用層。基於HTTP協議的客戶/伺服器模式的資訊交換過程，分四個過程：建立連線、傳送請求資訊、傳送響應資訊、關閉連線。

OSI網路結構的七層模型

第七層：應用層： 定義了用於在網路中進行通訊和資料傳輸的介面 - 使用者程式；提供標準服務，比如虛擬終端、檔案以及任務的傳輸 和處理；
第六層：表示層： 掩蓋不同系統間的資料格式的不同性； 指定獨立結構的資料傳輸格式； 資料的編碼和解碼；加密和解密；壓縮和 解壓縮
第五層：會話層： 管理使用者會話和對話； 控制使用者間邏輯連線的建立和結束通話；報告上一層發生的錯誤
第四層：傳輸層： 管理網路中端到端的資訊傳送； 通過錯誤糾正和流控制機制提供可靠且有序的資料包傳送； 提供面向無連線的數 據包的傳送；
第三層：網路層： 定義網路裝置間如何傳輸資料； 根據唯一的網路裝置地址路由資料包；提供流和擁塞控制以防止網路資源的損耗
第二層：資料鏈路層： 定義操作通訊連線的程式； 封裝資料包為資料幀； 監測和糾正資料包傳輸錯誤
第一層：物理層： 定義通過網路裝置傳送資料的物理方式； 作為網路媒介和裝置間的介面；定義光學、電氣以及機械特性。

RPC是一種概念，http也是rpc實現的一種方式。論複雜度，dubbo/hessian用起來是超級簡單的。最近用dubbo和hessian比較多，http的幾乎都被廢棄了。

至於為什麼用，其實很簡單，業務場景不一樣。我最早的單位所有的程式碼都在一個工程裡，一次要釋出幾百m的程式碼。這種架構是非常有利於小程式的。但是我們為什麼要應用rpc層呢，一個功能，一套程式碼下來不就解決了麼？我覺得有幾個好處：

1. 靈活部署
2. 解耦

系統做大了，肯定是需要做微服務的。 現在我們做電商就是這樣，單獨有一個訂單系統，支付系統，商品系統，使用者系統。都是分開部署，單獨上線的。 但我們互動是用HTTP介面來互動的，我想轉用RPC，但問題是我現在還沒發現為什麼需要用RPC，我還沒能理解它的作用和意義。
用http互動其實就已經屬於rpc了。

不知道大家看到這裡有沒有解決掉文章開頭的那個問題呢？看似普普通通的一個問題，實際上暗藏了很多玄機，只有從頭到尾都完完整整的瞭解過一遍之後才能真正地得到想要的答案。大部分程式設計師應該都有在工作過程中碰到各式各樣的問題，那是否都深入去追究過問題的本質呢？如果有機會不妨去試一試，你會發現海面下隱藏的“冰山”是表面上的許多倍。

為什麼面試官問的都是同樣的問題，有的人覺得沒什麼太多能回答的點，有的人卻能滔滔不絕？我想每個人思維的深度面試官一眼就能看出來，正好就印證了那句話：架構是一種思想，技術只是外殼。技術可能淘汰，思想才能長存。

人因為有了思想，才沒有成為野獸。
在這裡推薦一個架構群895244712，除了分散式、微服務、效能優化等技術點的技術分享，更重要的是架構思想的形成。

這邊不再糾結，詳細理解一下RPC的相關問題。

廣義和狹義的RPC

廣義的遠端通訊技術包括:RPC , WebService , RMI , JMS , EJB , JNDI .

• CORBA:物件導向的程式設計體系規範,分散式系統,跨語言,對標RMI(競爭關係)。
• SOAP:簡單物件訪問協議,微軟聯合廠商對xml-rpc標準化,soap協議就是聯合標準化的結果,而且微軟搶先完善了soap協議,推出了webservice。物件訪問協議指的是使用XML描述web service的資訊(URI/類/引數/返回值),理論上SOAP就是一段xml
• WebService:屬於廣義rpc的一種(常見的廣義rpc實現還有xml-rpc和json-rpc),支援異構系統間的互動, 支援不同語言的通訊,使用http通訊,通過serlvet提供XML格式的資料,是SOAP協議的封裝,WSDL是它的描述方式。
• WSDL:webservice描述語言,描述SOAP協議的,也是段XML
• RMI:遠端呼叫物件,其實是java實現了RPC的一組介面
• JMS:MQ
• EJB:大型分散式,rmi-iiop協議

廣義RPC發展歷程

狹義RPC技術框架

由於目前跨記憶體呼叫的普遍性,RPC往往代稱更加具體的基於底層協議二進位制流的RPC框架,與WebService最大的不同就是: 狹義的RPC基於二進位制流的序列化和反序列化,故不能夠提供跨語言的服務,但是比基於文字解析的WebService更加高效。

狹義RPC框架一般需要高效能的網路框架,如Netty,Mina,高效能的序列化反序列化框架,定址方式,如果是帶會話的RPC,還要有會話和狀態保持功能。

當下XML-RPC,SOAP,WebService技術的缺陷

• 冗餘資料太多,處理速度太慢。
• RPC 風格的 Web Service 跨語言性不佳,而 Document 風格的 Web Service 又太過難用。
• Web Service 沒有解決使用者的真正問題,只是把一個問題變成了另一個問題。
• Web Service 的規範太過複雜,以至於在 .NET 和 Java 平臺以外沒有真正好用的實現,甚至沒有可用的實現。
• 跨語言跨平臺只是 Web Service 的一個口號,雖然很多人迷信這一點,但事實上它並沒有真正實現。

RPC框架實現的幾個核心技術點：

• 遠端提供者需要以某種形式提供服務呼叫相關的資訊，包括但不限於服務介面定義、資料結構、或者中間態的服務定義檔案。例如Facebook的 Thrift的IDL檔案，Web service的WSDL檔案；服務的呼叫者需要通過一定的圖景獲取遠端服務呼叫相關的資訊。
• 遠端代理物件：服務呼叫者用的服務實際是遠端服務的本地代理。說白了就是通過動態代理來實現。
• 通訊：RPC框架與具體的協議無關。
• 序列化：畢竟是遠端通訊，需要將物件轉化成二進位制流進行傳輸。不同的RPC框架應用的場景不同，在序列化上也會採取不同的技術

RPC面臨的挑戰

在大規模服務化之前，應用可能只是通過RPC框架，簡單的暴露和引用遠端服務，通過配置URL地址進行遠端服務呼叫，路由則通過F5負載均衡器等進行簡單的負載均衡。

當服務越來越多的時候，服務的URL配置管理變得更加困難。單純的使用RPC就有點吃不消。所以在大規模分散式叢集中，RPC只是作為叢集的一個方法呼叫手段。例如在Hadoop的程式間互動都是通過RPC來進行的，比如Namenode與Datanode直接，Jobtracker與Tasktracker之間等。

服務化架構的演進

• MVC架構：當業務規模很小時，將所有功能都不熟在同一個程式中，通過雙機或者負載均衡器實現負債分流；此時，分離前後臺邏輯的MVC架構是關鍵。

• PRC架構：當垂直應用越來越多，應用之間互動不可避免，將核心和公共業務抽取出來，作為獨立的服務，實現前後臺邏輯分離。此時，用於提高業務複用及拆分的RPC框架是關鍵。

• SOA架構：隨著業務發展，服務數量越來越多，服務生命週期管控和執行態的治理成為瓶頸，此時用於提升服務質量的SOA服務治理是關鍵。

• 微服務架構：通過服務的原子化拆分，以及微服務的獨立打包、部署和升級，小團隊的交付週期將縮短，運維成本也將大幅度下降。