分佈式下的遠程通訊技術（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服務治理是關鍵。
• 微服務架構：經過服務的原子化拆分，以及微服務的獨立打包、部署和升級，小團隊的交付週期將縮短，運維成本也將大幅度降低。