RPC框架（一）RPC简介
- 一、概述
- 二、RPC
- 2.1、RPC定義
- 2.2、RPC主要組成部分
- 三、影響RPC框架性能的因素
- 四、工業界的 RPC 框架一覽
- 4.1、國內
- 4.2、國外
- 五、如何選擇RPC框架
?
一、概述
隨著公司規模的擴大，以及業務量的激增，單體應用逐步演化為服務/微服務的架構模式， 服務之間的調用大多采用rpc的方式調用，或者消息隊列的方式進行解耦。幾乎每個大廠都會創建自己的rpc框架，或者基于知名的rpc框架進行改造。
目前, rpc框架主要沿著兩條路線發展，一個是目標為了跨語言，服務端可以用不同的語言實現，客戶端也可以用不同的語言實現，不同的語言實現的客戶端和服務器端可以互相調用。很顯然，要支持不同的語言，需要基于那種語言實現相同協議的框架，并且協議設計應該也是跨語言的，其中比較典型的是 grpc,基于同一個IDL，可以生成不同語言的代碼，并且語言的支持也非常的多。
另一個rpc框架發展的目標是支持服務治理，主要的精力放在服務發現、路由、容錯處理等方面，主要圍繞一個語言開發，可能也有一些第三方曲折的實現服務的調用和服務的實現，這其中的代表，也是比較早的開源的框架就是阿里巴巴的dubbo。
有些rpc框架協議的涉及一開始就沒有考慮的跨語言，其中使用了語言的一些特有的屬性，比如Java的ObjectInputStream/ObjectOutputStream, Golang的Gob等，有些在協議的設計上就考慮了通用性， 使用JSON或者Protobuffer作為數據序列化。
有些框架是基于TCP的二進制流的數據傳輸，有些基于http的request/response模型進行請求，也有基于http2的流式傳輸，更有一些支持可信賴的UDP進行數據傳入，比如quic、kcp等。
有些提供了生態圈的一些框架，比如gateway、agent等，有些restful風格的rpc框架天然支持API gateway進行負載均衡。
二、RPC
2.1、RPC定義
RPC（Remote Procedure Call Protocol）遠程過程調用協議。一個通俗的描述是：客戶端在不知道調用細節的情況下，調用存在于遠程計算機上的某個對象，就像調用本地應用程序中的對象一樣。比較正式的描述是：一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議。那么我們至少從這樣的描述中挖掘出幾個要點：
-
RPC是協議：既然是協議就只是一套規范，那么就需要有人遵循這套規范來進行實現。目前典型的RPC實現包括：Dubbo、Thrift、GRPC、Hetty等。這里要說明一下，目前技術的發展趨勢來看，實現了RPC協議的應用工具往往都會附加其他重要功能，例如Dubbo還包括了服務治等功能。
-
網絡協議和網絡IO模型對其透明：既然RPC的客戶端認為自己是在調用本地對象。那么傳輸層使用的是TCP/UDP還是HTTP協議，又或者是一些其他的網絡協議它就不需要關心了。既然網絡協議對其透明，那么調用過程中，使用的是哪一種網絡IO模型調用者也不需要關心。
-
信息格式對其透明：我們知道在本地應用程序中，對于某個對象的調用需要傳遞一些參數，并且會返回一個調用結果。至于被調用的對象內部是如何使用這些參數，并計算出處理結果的，調用方是不需要關心的。那么對于遠程調用來說，這些參數會以某種信息格式傳遞給網絡上的另外一臺計算機，這個信息格式是怎樣構成的，調用方是不需要關心的。
-
應該有跨語言能力：為什么這樣說呢？因為調用方實際上也不清楚遠程服務器的應用程序是使用什么語言運行的。那么對于調用方來說，無論服務器方使用的是什么語言，本次調用都應該成功，并且返回值也應該按照調用方程序語言所能理解的形式進行描述。
那么上面的描述情況可以用下圖表示：
2.2、RPC主要組成部分
當然，上圖是作為RPC的調用者所觀察到的現象（而實際情況是客戶端或多或少的還是需要知道一些調用RPC的細節）。但是我們是要講解RPC的基本概念，所以RPC協議內部是怎么回事就要說清楚：
-
Client：RPC協議的調用方。就像上文所描述的那樣，最理想的情況是RPC Client在完全不知道有RPC框架存在的情況下發起對遠程服務的調用。但實際情況來說Client或多或少的都需要指定RPC框架的一些細節。
-
Server：在RPC規范中，這個Server并不是提供RPC服務器IP、端口監聽的模塊。而是遠程服務方法的具體實現（在JAVA中就是RPC服務接口的具體實現）。其中的代碼是最普通的和業務相關的代碼，甚至其接口實現類本身都不知道將被某一個RPC遠程客戶端調用。
-
Stub/Proxy：RPC代理存在于客戶端，因為要實現客戶端對RPC框架“透明”調用，那么客戶端不可能自行去管理消息格式、不可能自己去管理網絡傳輸協議，也不可能自己去判斷調用過程是否有異常。這一切工作在客戶端都是交給RPC框架中的“代理”層來處理的。
-
Message Protocol：在上文我們已經說到，一次完整的client-server的交互肯定是攜帶某種兩端都能識別的，共同約定的消息格式。RPC的消息管理層專門對網絡傳輸所承載的消息信息進行編碼和解碼操作。目前流行的技術趨勢是不同的RPC實現，為了加強自身框架的效率都有一套（或者幾套）私有的消息格式。
-
Transfer/Network Protocol：傳輸協議層負責管理RPC框架所使用的網絡協議、網絡IO模型。例如Hessian的傳輸協議基于HTTP（應用層協議）；而Thrift的傳輸協議基于TCP（傳輸層協議）。傳輸層還需要統一RPC客戶端和RPC服務端所使用的IO模型；
-
Selector/Processor：存在于RPC服務端，用于服務器端某一個RPC接口的實現的特性（它并不知道自己是一個將要被RPC提供給第三方系統調用的服務）。所以在RPC框架中應該有一種“負責執行RPC接口實現”的角色。包括：管理RPC接口的注冊、判斷客戶端的請求權限、控制接口實現類的執行在內的各種工作。
-
IDL：實際上IDL（接口定義語言）并不是RPC實現中所必須的。但是需要跨語言的RPC框架一定會有IDL部分的存在。這是因為要找到一個各種語言能夠理解的消息結構、接口定義的描述形式。如果您的RPC實現沒有考慮跨語言性，那么IDL部分就不需要包括，例如JAVA RMI因為就是為了在JAVA語言間進行使用，所以JAVA RMI就沒有相應的IDL。
一定要說明一點，不同的RPC框架實現都有一定設計差異。例如生成Stub的方式不一樣，IDL描述語言不一樣、服務注冊的管理方式不一樣、運行服務實現的方式不一樣、采用的消息格式封裝不一樣、采用的網絡協議不一樣。但是基本的思路都是一樣的，上圖中的所列出的要素也都是具有的。
三、影響RPC框架性能的因素
在物理服務器性能相同的情況下，以下幾個因素會對一款RPC框架的性能產生直接影響：
-
使用的網絡IO模型：RPC服務器可以只支持傳統的阻塞式同步IO，也可以做一些改進讓RPC服務器支持非阻塞式同步IO，或者在服務器上實現對多路IO模型的支持。這樣的RPC服務器的性能在高并發狀態下，會有很大的差別。特別是單位處理性能下對內存、CPU資源的使用率。
-
基于的網絡協議：一般來說您可以選擇讓您的RPC使用應用層協議，例如HTTP或者HTTP/2協議，或者使用TCP協議，讓您的RPC框架工作在傳輸層。工作在哪一層網絡上會對RPC框架的工作性能產生一定的影響，但是對RPC最終的性能影響并不大。但是至少從各種主流的RPC實現來看，沒有采用UDP協議做為主要的傳輸協議的。
-
消息封裝格式：選擇或者定義一種消息格式的封裝，要考慮的問題包括：消息的易讀性、描述單位內容時的消息體大小、編碼難度、解碼難度、解決半包/粘包問題的難易度。當然如果您只是想定義一種RPC專用的消息格式，那么消息的易讀性可能不是最需要考慮的。消息封裝格式的設計是目前各種RPC框架性能差異的最重要原因，這就是為什么幾乎所有主流的RPC框架都會設計私有的消息封裝格式的原因。dubbo中消息體數據包含dubbo版本號、接口名稱、接口版本、方法名稱、參數類型列表、參數、附加信息
-
Schema 和序列化（Schema & Data Serialization）：序列化和反序列化，是對象到二進制數據的轉換，程序是可以理解對象的，對象一般含有 schema 或者結構，基于這些語義來做特定的業務邏輯處理。考察一個序列化框架一般會關注以下幾點：
Encoding format?。是 human readable（是否能直觀看懂 json） 還是 binary(二進制)。
Schema declaration?。也叫作契約聲明，基于 IDL，比如 Protocol Buffers/Thrift，還是自描述的，比如 JSON、XML。另外還需要看是否是強類型的。
語言平臺的中立性?。比如 Java 的 Native Serialization 就只能自己玩，而 Protocol Buffers 可以跨各種語言和平臺。
新老契約的兼容性?。比如 IDL 加了一個字段，老數據是否還可以反序列化成功。
和壓縮算法的契合度?。跑 benchmark (基準)和實際應用都會結合各種壓縮算法，例如 gzip、snappy。
性能?。這是最重要的，序列化、反序列化的時間，序列化后數據的字節大小是考察重點。
序列化方式非常多，常見的有 Protocol Buffers， Avro，Thrift，XML，JSON，MessagePack，Kyro，Hessian，Protostuff，Java Native Serialize，FST 。 -
實現的服務處理管理方式：在高并發請求下，如何管理注冊的服務也是一個性能影響點。您可以讓RPC的Selector/Processor使用單個線程運行服務的具體實現（這意味著上一個客戶端的請求沒有處理完，下一個客戶端的請求就需要等待）、您也可以為每一個RPC具體服務的實現開啟一個獨立的線程運行（可以一次處理多個請求，但是操作系統對于“可運行的最大線程數”是有限制的）、您也可以線程池來運行RPC具體的服務實現（目前看來，在單個服務節點的情況下，這種方式是比較好的）、您還可以通過注冊代理的方式讓多個服務節點來運行具體的RPC服務實現。
四、工業界的 RPC 框架一覽
4.1、國內
Dubbo 。來自阿里巴巴?http://dubbo.I/O/
Motan 。新浪微博自用?https://github.com/weibocom/motan
Dubbox 。當當基于 dubbo 的?https://github.com/dangdangdotcom/dubbox
rpcx 。基于 Golang 的?https://github.com/smallnest/rpcx
4.2、國外
Thrift from facebook?https://thrift.apache.org
Avro from hadoop?https://avro.apache.org
Finagle by twitter?https://twitter.github.I/O/finagle
gRPC by Google?http://www.grpc.I/O?(Google inside use Stuppy)
Hessian from cuacho?http://hessian.caucho.com
Coral Service inside amazon (not open sourced)
上述列出來的都是現在互聯網企業常用的解決方案，暫時不考慮傳統的 SOAP，XML-RPC 等。這些是有網絡資料的，實際上很多公司內部都會針對自己的業務場景，以及和公司內的平臺相融合（比如監控平臺等），自研一套框架，但是殊途同歸，都逃不掉剛剛上面所列舉的 RPC 的要考慮的各個部分。
五、如何選擇RPC框架
選擇一個rpc框架會基于多方面的考慮： 框架特性、性能、成熟度、技術支持、社區活躍度等多個方面。最重要一點，這也是往往很多技術人員進入的誤區，“對于技術，不要為了使用而使用，用最簡單合適的技術實現解決問題才是正道”。架構是服務于業務的，能快速方便的滿足業務需求的架構才是好的架構。沒有最好的，只有適合自己的。
來源：https://blog.csdn.net/yjp198713/article/details/79410521
總結
以上是生活随笔為你收集整理的RPC框架（一）RPC简介的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： REST是什么？如何实现RESTful？
- 下一篇： JAVA中System.out.prin