RPC框架
RPC（Remote Promote Call） 一種進程間通信方式。允許像調用本地服務一樣調用遠程服務。

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

RPC框架實現的幾個核心技術點：
（1）遠程提供者需要以某種形式提供服務調用相關的信息，包括但不限于服務接口定義、數據結構、或者中間態的服務定義文件。例如Facebook的 Thrift的IDL文件，Web service的WSDL文件；服務的調用者需要通過一定的圖景獲取遠程服務調用相關的信息。

（2）遠程代理對象：服務調用者用的服務實際是遠程服務的本地代理。說白了就是通過動態代理來實現。

（3）通信：RPC框架與具體的協議無關。

（4）序列化：畢竟是遠程通信，需要將對象轉化成二進制流進行傳輸。不同的RPC框架應用的場景不同，在序列化上也會采取不同的技術

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

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

RPC與WebServie
講道理，我覺得RPC與WebService很像.可以說WebService是在RPC發展的基礎之上。WebService是運行在web上的一個服務

RPC使用C/S方式，發送請求到服務器，等待服務器返回結果。

Web Service提供的服務是基于web容器的，底層使用http協議，類似一個遠程的服務提供者，比如天氣預報服務，對各地客戶端提供天氣預報，是一種請求應答的機制，是跨系統跨平臺的。就是通過一個servlet，提供服務出去。

RPC與JMS
在RPC中，當一個請求到達RPC服務器時，這個請求就包含了一個參數集和一個文本值，通常形成“classname.methodname”的形式。這就向RPC服務器表明，被請求的方法在為“classname”的類中，名叫“methodname”。然后RPC服務器就去搜索與之相匹配的類和方法，并把它作為那種方法參數類型的輸入。這里的參數類型是與RPC請求中的類型是匹配的。一旦匹配成功，這個方法就被調用了，其結果被編碼后返回客戶方。

JMS 一般只是一個點發出一個Message到Message Server,發出之后一般不會關心誰用了這個message。JMS可以做到異步調用完全隔離了客戶端和服務提供者，能夠抵御流量洪峰；JMS獲得消息可以進行延遲處理，而RPC一般是進行實時調用。

相比較其他的通信而言，RPC的側重點在于方法。并且是C/S架構方式

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

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

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

微服務架構：通過服務的原子化拆分，以及微服務的獨立打包、部署和升級，小團隊的交付周期將縮短，運維成本也將大幅度下降。
---------------------?
作者：heqianqiann?
來源：CSDN?
原文：https://blog.csdn.net/Thousa_Ho/article/details/78401158?
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的分布式 RPC架构简单理解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。