概述

在互聯(lián)網應用開發(fā)中，隨著業(yè)務的復雜度增加，一般都會采用分布式架構。分布式架構的核心，就是利用多臺普通的計算機組成一個龐大的復雜計算網絡，提供高并發(fā)、高性能、高可用的系統(tǒng)能力支撐。在分布式架構中，原本的單體應用服務被拆分成多個獨立部署的服務，分布式在計算機網絡上，這些服務必然，需要通過網絡進行數據通信和交互。而RPC框架，就是解決在分布式架構中，各個服務之間的網絡通信問題的框架。在Java應用中，JDK 1.1版本的時候就提供了對RPC的支持框架，叫做RMI。由于RMI不能實現跨域語言的遠程調用。后面，廣發(fā)采用WebService來實現遠程調用，但是，WebService需要定義非常復雜的Scheme文件，導致無效數據內容過于臃腫。之后，就被HTTP加JSON的方案所代替了。
RPC發(fā)展到現在，實現的方式也非常多樣，但是基本都實現了跨語言的遠程調用。一般來說，RPC框架都應用于大型企業(yè)，只有在業(yè)務復雜度和用戶體量都比較大的時候，需要對服務進行解耦，從而達到擴展性強、部署靈活的目的。目前比較流行的開源RPC框架有Goole的gRPC、Facebook的Thrift、Alibaba的Dubbo。這些框架除了提供基礎的遠程通信功能以外，還會在系統(tǒng)性能、傳輸效率、服務治理等方面做出一些優(yōu)化設計。比如，阿里開源的RPC框架Dubbo就提供了非常豐富的服務治理功能。
RPC（遠程過程調用）是一種計算機通信協(xié)議，用于在不同的進程或者計算機之間實現遠程通信，使得一個進程可以調用另一個進程（通常是運行在不同機器上）的函數或方法，就像調用本地函數一樣。
rpc的主要功能目標是讓構建分布式計算（應用）更容易，在提供強大的遠程調用能力時不損失本地調用的。為實現該目標，rpc框架器提供一種透明調用機制，讓使用者不必是式的區(qū)分本地調用和遠程調用。
基本原理：

1. 客戶端調用： 客戶端調用遠程服務的方法，就像調用本地函數一樣，傳遞參數并等待結果。
2. 遠程過程執(zhí)行： 遠程過程在遠程服務器上執(zhí)行，接收客戶端發(fā)送的參數，執(zhí)行相應的計算或操作。
3. 結果返回： 執(zhí)行完成后，遠程過程將結果返回給客戶端。

rpc的優(yōu)點

分布式設計
部署靈活
解耦服務
擴展性強

組件

1. 客戶端（Client）： 發(fā)起RPC調用的應用程序部分。
2. 服務端（Server）： 提供RPC服務的應用程序部分。
3. RPC協(xié)議（Protocol）： 定義了客戶端和服務端之間通信的規(guī)則、格式和消息交換方式。
4. 序列化/反序列化（Serialization/Deserialization）： 將數據結構或對象轉換成字節(jié)流以便在網絡上傳輸，并在接收端重新構造成相應的數據結構或對象。
5. 網絡傳輸（Network Transport）： 用于在客戶端和服務端之間傳輸數據的通信機制，通常使用TCP/IP或者HTTP等協(xié)議。

工作流程&RPC的底層原理

1. 客戶端調用： 客戶端調用本地的Stub（存根）方法，傳遞參數。
2. 參數序列化： 客戶端將參數序列化成字節(jié)流。
3. 網絡傳輸： 序列化后的數據通過網絡傳輸到遠程服務端。
4. 服務端接收： 遠程服務端接收到請求，進行反序列化得到參數。
5. 服務端處理： 服務端執(zhí)行相應的方法或過程，傳入參數，執(zhí)行計算或操作。
6. 結果序列化： 服務端將執(zhí)行結果序列化成字節(jié)流。
7. 網絡傳輸： 序列化后的結果通過網絡傳輸到客戶端。
8. 客戶端接收： 客戶端接收到結果，進行反序列化得到返回值。
9. 客戶端處理： 客戶端處理返回值，完成RPC調用。

RPC的底層原理

RPC（Remote Procedure Call，遠程過程調用）是一種用于在不同的計算機之間進行通信的技術，允許一個程序調用另一個程序中的函數或方法，就像調用本地函數一樣，而無需程序員顯式地編寫通信代碼。RPC的底層原理涉及通信協(xié)議、序列化和反序列化、網絡傳輸、服務注冊與發(fā)現等方面。

下面是RPC的一般工作原理：

1. 定義接口: RPC的第一步是定義客戶端和服務端之間通信的接口。這些接口中包含需要在遠程服務器上調用的方法。
2. 序列化: 當客戶端調用遠程方法時，客戶端程序將方法的參數序列化為字節(jié)流。序列化是將對象轉換為字節(jié)流的過程，以便在網絡上傳輸。
3. 網絡傳輸: 序列化后的請求被傳輸到遠程服務器，這通常通過網絡協(xié)議（如HTTP、TCP等）實現。
4. 反序列化: 一旦請求到達遠程服務器，服務器程序將接收到的字節(jié)流反序列化為方法調用所需的參數。
5. 調用遠程方法: 遠程服務器根據反序列化后的參數調用相應的方法或函數。
6. 序列化結果: 服務器程序將方法執(zhí)行的結果序列化為字節(jié)流。
7. 網絡傳輸結果: 序列化后的結果通過網絡傳輸回客戶端。
8. 反序列化結果: 客戶端程序接收到結果后，將結果字節(jié)流反序列化為方法調用的返回值。
9. 返回結果: 最終，客戶端程序將調用遠程方法的返回值返回給調用方。
   在實際的RPC實現中，還可能涉及到一些額外的步驟，如：
   ● 服務注冊與發(fā)現: RPC框架通常會提供服務注冊與發(fā)現的功能，允許服務提供者將其提供的服務注冊到注冊中心，并允許服務消費者從注冊中心獲取可用的服務地址。
   ● 負載均衡與容錯: RPC框架通常還包括負載均衡和容錯機制，以確保請求能夠被均勻分布到不同的服務節(jié)點，并在某些節(jié)點發(fā)生故障時能夠進行故障轉移或重試。
   ● 連接管理: RPC框架通常會管理與遠程服務之間的連接，包括連接的建立、保持和釋放等。

總的來說，RPC的底層原理涉及到將方法調用的參數序列化、通過網絡傳輸、反序列化、調用遠程方法、序列化結果、再次通過網絡傳輸、反序列化結果的過程。各種RPC框架會根據具體需求和場景進行優(yōu)化和擴展。

RPC框架

RPC（Remote Procedure Call）框架是一種用于實現遠程調用的技術，它可以讓不同的進程或計算機之間通過網絡進行通信和調用遠程方法。以下是一些常見的 RPC 框架：

1. Dubbo：阿里開源的高性能 Java RPC 框架，提供了完整的服務治理功能，支持多種協(xié)議和序列化方式。 Dubbo是 阿里巴巴公司開源的一個高性能優(yōu)秀的服務框架，使得應用可通過高性能的 RPC 實現服 務的輸出和輸入功能，可以和 Spring框架無縫集成。提供了豐富的特性，包括負載均衡、服務注冊與發(fā)現、容錯處理等，廣泛應用于大型分布式系統(tǒng)中
2. gRPC：Google 開源的跨語言 RPC 框架，基于 HTTP/2 協(xié)議和 Protocol Buffers，性能高效，它支持多種編程語言，如C、C++、Java、Go、Python等，適用于跨語言的服務通信
3. Thrift：Facebook 開源的跨語言 RPC 框架，支持多種語言和數據格式，性能優(yōu)秀，包括C++、Java、Python等，適用于異構系統(tǒng)的集成
4. Spring Cloud：基于 Spring Boot 的微服務架構框架，提供了豐富的分布式系統(tǒng)解決方案，包括 RPC 調用，提供了對RPC調用的支持，通過集成Ribbon、Feign等組件實現服務之間的遠程調用
5. Apache Avro：Apache 開源的跨語言數據序列化系統(tǒng)，同時也支持 RPC 框架。
6. Apache Dubbo：原名 Apache Dubbox，是一款高性能 Java RPC 框架，提供了完善的服務治理功能。
7. Apache Thrift：Apache 開源的跨語言 RPC 框架，支持多種語言，包括 C++, Java, Python 等。
8. ZeroC ICE：一種面向對象的跨語言通信框架，適用于構建大規(guī)模分布式系統(tǒng)?；趯ο蟠淼腞PC框架，支持C++、Java、Python等多種語言，適用于大規(guī)模分布式系統(tǒng)的構建。

這些RPC框架在不同的場景和需求下有著各自的優(yōu)勢和特點，選擇適合自己業(yè)務需求的RPC框架是非常重要的。每種框架都有其獨特的特性和適用范圍，因此在選擇時需要綜合考慮技術棧、性能需求、跨語言支持等因素，這些都是比較流行的 RPC 框架，每個框架都有其獨特的特點和適用場景。選擇合適的 RPC 框架取決于具體的需求、技術棧和團隊經驗。
1、RMI
利用java.rmi包實現，基于Java遠程方法協(xié)議(Java Remote Method Protocol) 和java的原生序列 化。
2、Hessian
是一個輕量級的remoting onhttp工具，使用簡單的方法提供了RMI的功能。 基于HTTP協(xié)議，采 用二進制編解碼。
3、protobuf-rpc-pro
是一個Java類庫，提供了基于 Google 的 Protocol Buffffers 協(xié)議的遠程方法調用的框架?；?br /> Netty 底層的 NIO 技術。支持 TCP 重用/ keep-alive、SSL加密、RPC 調用取消操作、嵌入式日志 等功能。
4、Thrift
是一種可伸縮的跨語言服務的軟件框架。它擁有功能強大的代碼生成引擎，無縫地支持C + +，
C#，Java，Python和PHP和Ruby。thrift允許你定義一個描述文件，描述數據類型和服務接口。
依據該文件，編譯器方便地生成RPC客戶端和服務器通信代碼。
最初由facebook開發(fā)用做系統(tǒng)內個語言之間的RPC通信，2007年由facebook貢獻到apache基金 ，現 在是apache下的opensource之一 。支持多種語言之間的RPC方式的通信：php語言client可以構造一 個對象，調用相應的服務方法來調用java語言的服務，跨越語言的C/S RPC調用。底層通訊基于 SOCKET
5、Avro
出自Hadoop之父Doug Cutting, 在Thrift已經相當流行的情況下推出Avro的目標不僅是提供一套類 似Thrift的通訊中間件,更是要建立一個新的，標準性的云計算的數據交換和存儲的Protocol。支持 HTTP，TCP兩種協(xié)議。Apache Avro：一個數據序列化系統(tǒng)，也提供了RPC框架的支持，具有快速、緊湊的特點，支持多種編程語言。

rpc框架優(yōu)點

rpc框架一般使用長鏈接，不必每次通信都要3次握手，減少網絡開銷。
rpc框架一般都有注冊中心，有豐富的監(jiān)控管理，發(fā)布，下線接口，動態(tài)擴展等，對調用方來說是無感知，統(tǒng)一化的操作，協(xié)議私密，安全性較高
rpc協(xié)議更簡單內容更小，效率更高，服務化架構，服務化治理，rpc框架是一個強力的支撐。
rpc基于tcp實現，也可以基于http2實現

1. 簡化遠程調用：RPC 框架可以使遠程服務的調用過程像本地調用一樣簡單，隱藏了底層網絡通信細節(jié)，提供了更高層次的抽象。
2. 跨語言支持：許多 RPC 框架支持跨多種編程語言進行通信，這使得不同語言編寫的服務可以輕松地相互調用。
3. 性能高效：RPC 框架通常針對高性能進行優(yōu)化，能夠在網絡通信中提供低延遲和高吞吐量。
4. 服務治理：許多 RPC 框架提供了完善的服務注冊、發(fā)現、負載均衡、容錯處理等服務治理功能，幫助管理和監(jiān)控分布式系統(tǒng)中的服務。
5. 擴展性：RPC 框架通常具有良好的擴展性，能夠滿足不斷變化的業(yè)務需求和規(guī)模擴展。
6. 代碼生成：許多 RPC 框架支持自動生成客戶端和服務端的代碼，減少了開發(fā)人員的工作量。
7. 安全性：RPC 框架通常提供了安全機制，包括數據傳輸加密、身份認證和授權等功能。
8. 透明性：RPC 框架可以提供透明的遠程調用，使得調用方無需關心調用的具體實現細節(jié)，從而降低了系統(tǒng)的耦合度。
   總的來說，RPC 框架可以幫助開發(fā)人員構建可靠、高效、易于管理的分布式系統(tǒng)，使得不同服務之間的通信變得更加簡單和可靠。

RPC 的實現基礎

需要有非常高效的網絡通信，比如一般選擇 Netty 作為網絡通信框架；
需要有比較高效的序列化框架，比如谷歌的 Protobuf 序列化框架；
可靠的尋址方式（主要是提供服務的發(fā)現），比如可以使用 Zookeeper 來注冊服務等；
如果是帶會話（狀態(tài)）的 RPC 調用，還需要有會話和狀態(tài)保持的功能；
跨進程，可以理解為同一臺計算上的多個進程、多個JVM或者多臺計算之間的進程。
那什么是RPC呢？RPC的全稱是Remote Procedure Call，翻譯過來叫遠程過程調用。
它是一種通過網絡從遠程計算機程序上獲取服務，而不需要了解代碼網絡技術實現的一種協(xié)議。凡是符合這種協(xié)議的框架，都可以稱之為RPC框架。
通俗理解就是，A計算機提供一個服務，B計算機可以像調用本地服務一樣去調用A計算機提供的服務，這就是RPC的主要作用。
其實，RPC的應用在很早之前就出現了。在40年以前，也就是1981年的時候，由一家叫做Nelson的公司提出，并把它應用到了分布式系統(tǒng)之間的通信協(xié)議。
RPC協(xié)議
要實現RPC，需要通過網絡進行數據傳輸，并且對調用的過程進行封裝。現在比較流行的RPC框架一般都是采用TCP協(xié)議作為底層的傳輸協(xié)議。當然，其他協(xié)議也是可以的，比如UDP。
RPC協(xié)議，強調的是過程調用，調用的過程對于用戶來說是完全透明的，用戶不需要關心調用細節(jié)?？梢韵裾{用本地服務一樣去調用遠程服務。
一個完整的RPC協(xié)議包含了四個組件，分別是Client、Server、Client Stub和Sever Stub。
Client客戶端表示服務的調用方；
Sever服務端是真正的服務提供方；
Client Stub表示客戶端存根，專門用來存放服務端的地址信息，再將客戶端的請求參數打包成網絡消息，也就是序列化，然后通過網絡遠程發(fā)送給服務提供方。
Server Stub表示服務端存根，用來接收客戶端發(fā)送過來的消息，然后，解析消息內容，也就是反序列化，并且調用本地方法。

RPC的應用場景

1、分布式系統(tǒng)網絡通訊
2、分布式子系統(tǒng)之間的服務治理
3、分布式負載均衡和流控
4、服務發(fā)現與注冊
5、構建分布式調試環(huán)境

RPC使用了哪些關鍵技術

1、動態(tài)代理
生成Client Stub（客戶端存根）和Server Stub（服務端存根）的時候需要用到Java動態(tài)代理技術，可
以使用JDK提供的原生的動態(tài)代理機制，也可以使用開源的：CGLib代理，Javassist字節(jié)碼生成技術。
2、序列化和反序列化
在網絡中，所有的數據都將會被轉化為字節(jié)進行傳送，所以為了能夠使參數對象在網絡中進行傳輸，需
要對這些參數進行序列化和反序列化操作。
序列化：把對象轉換為字節(jié)序列的過程稱為對象的序列化，也就是編碼的過程。反序列化：把字節(jié)
序列恢復為對象的過程稱為對象的反序列化，也就是解碼的過程。 目前比較高效的開源序列化框架：如Kryo、FastJson和Protobuf等。
反序列化：把字節(jié)序列恢復為對象的過程稱為對象的反序列化，也就是解碼的過程。 目前比較高
效的開源序列化框架：如Kryo、FastJson和Protobuf等。
3、NIO通信
出于并發(fā)性能的考慮，傳統(tǒng)的阻塞式 IO 顯然不太合適，因此我們需要異步的 IO，即 NIO。Java 提供 了 NIO 的解決方案，Java 7 也提供了更優(yōu)秀的 NIO.2 支持?？梢赃x擇Netty或者MINA來解決NIO數據傳輸的問題。
4、服務注冊中心
可選：Redis、Zookeeper、Consul 、Etcd。一般使用ZooKeeper提供服務注冊與發(fā)現功能，解決單 點故障以及分布式部署的問題(注冊中心)。

rpc 調用異常一般怎么處理

一般超時容錯 、重試、超時處理、
處理遠程過程調用（RPC）異常的方法取決于您使用的RPC框架和編程語言。一般來說，以下是一些處理RPC調用異常的常見方法：

1. 捕獲異常：在進行RPC調用時，使用try-catch語句捕獲可能拋出的異常。這樣可以在異常發(fā)生時捕獲并處理異常情況。
2. 重試機制：對于臨時性的網絡問題或服務端問題，可以考慮實現重試機制，當RPC調用失敗時，自動嘗試再次調用，直至達到最大重試次數或成功為止。
3. 超時處理：設置合理的超時時間，并在超時發(fā)生時進行適當的處理，比如記錄日志、返回錯誤信息或者進行重試。
4. 回退策略：當發(fā)生異常時，可以考慮采用回退策略，例如切換到備用服務或者采用備用數據源。
5. 錯誤信息傳遞：在捕獲異常后，將錯誤信息傳遞給調用方，以便上層代碼能夠根據具體情況做出相應的處理。
6. 斷路器模式：引入斷路器模式，當RPC調用失敗次數達到一定閾值時，暫時關閉對該服務的訪問，避免連鎖故障。
7. 監(jiān)控和日志：建立完善的監(jiān)控和日志系統(tǒng)，及時發(fā)現RPC調用異常，從而進行故障排查和修復。
   以上方法并非孤立的，通常會結合多種方法來處理RPC調用異常，以實現系統(tǒng)的穩(wěn)定性和容錯能力。同時，針對不同的業(yè)務場景和需求，可能需要進一步細化和定制化異常處理策略。
   處理Feign RPC調用異常時，可以采取以下常見策略：
8. 使用Feign的ErrorDecoder：Feign提供了ErrorDecoder接口，可以自定義處理HTTP錯誤狀態(tài)碼和異常信息。通過實現ErrorDecoder接口，可以對Feign調用返回的異常進行統(tǒng)一處理，例如將異常信息轉換成特定格式并返回給調用方。
9. 定義Fallback方法：在Feign接口中可以定義fallback方法，當RPC調用出現異常時，可以執(zhí)行fallback方法來返回一個默認值或者進行其他補償性操作，避免將異常拋給調用方。
10. 超時處理：在Feign客戶端接口中可以設置連接和讀取超時時間，以及對應的超時處理策略，如重試、降級等。
11. 熔斷機制：對于頻繁出現異常或錯誤的RPC調用，可以引入熔斷機制，防止故障擴散，這可以通過Hystrix等框架來實現。
12. 監(jiān)控和日志：建立完善的監(jiān)控和日志系統(tǒng)，及時發(fā)現RPC調用異常，從而進行故障排查和修復。Feign本身并不提供監(jiān)控和管理功能，通常需要結合其他監(jiān)控系統(tǒng)進行監(jiān)控。
13. 全局異常處理器：在應用程序中可以編寫全局異常處理器來捕獲Feign調用產生的異常，然后進行統(tǒng)一的異常處理和記錄日志。
    綜合利用上述策略，可以有效地處理Feign RPC調用過程中可能出現的異常，提高系統(tǒng)的穩(wěn)定性和容錯能力。同時，根據具體業(yè)務需求，還可以進一步細化和定制化異常處理策略。

rpc和http的區(qū)別

傳輸協(xié)議
RPC，可以基于TCP協(xié)議，也可以基于HTTP協(xié)議
HTTP，基于HTTP協(xié)議傳輸效率
RPC，使用自定義的TCP協(xié)議，可以讓請求報文體積更小，或者使用HTTP2協(xié)議，也可以很好的減少報文的體積，提高傳輸效率
HTTP，如果是基于HTTP1.1的協(xié)議，請求中會包含很多無用的內容，如果是基于HTTP2.0，那么簡單的封裝以下是可以作為?個RPC來使用的，這時標準RPC框架更多的是服務治理
性能消耗，主要在于序列化和反序列化的耗時
RPC，可以基于thrift實現高效的二進制傳輸
HTTP，大部分是通過json來實現的，字節(jié)大小和序列化耗時都比thrift要更消耗性能
負載均衡
RPC，基本都自帶了負載均衡策略
HTTP，需要配置Nginx，HAProxy來實現
服務治理（下游服務新增，重啟，下線時如何不影響上游調用者）
RPC，能做到自動動通知，不影響上游
HTTP，需要事先通知，修改Nginx/HAProxy配 置
b. 總結：RPC主要?于公司內部的服務調用，性能消耗低，傳輸效率高，服務治理方便。HTTP主要?于對外的異構環(huán)境，瀏覽器接口調用，APP接口調用，第三方接口調用等。

為什么RPC要比HTTP更快一些

RPC（Remote Procedure Call）相比于HTTP在一些情況下可能更快，這主要是由于以下幾個原因：

1. 二進制傳輸協(xié)議：RPC框架通常使用二進制傳輸協(xié)議，如Protocol Buffers、Thrift等，而HTTP使用文本傳輸協(xié)議，如JSON、XML。二進制傳輸協(xié)議的數據體積更小，序列化和反序列化的速度更快，可以減少網絡傳輸的時間和帶寬消耗。
2. 定制化協(xié)議：RPC框架通常可以定制自己的通信協(xié)議，針對特定的場景進行優(yōu)化，如連接復用、請求批處理、壓縮等。相比之下，HTTP是通用的應用層協(xié)議，有一定的通用性，但不一定能滿足特定場景的需求。
3. 底層傳輸協(xié)議：RPC框架通常使用TCP或UDP等底層傳輸協(xié)議進行通信，而HTTP基于TCP協(xié)議。TCP相較于HTTP具有更低的開銷和更高的效率，能夠提供更快的數據傳輸速度。
4. 連接管理：RPC框架通常會維護長連接，避免頻繁地建立和關閉連接，減少了連接建立和關閉的開銷。而HTTP每次請求都需要建立連接，增加了額外的開銷。
   雖然RPC在性能上可能會比HTTP更快，但也要考慮到RPC框架的復雜性和學習成本較高，以及對網絡環(huán)境和部署的要求較高。在選擇RPC還是HTTP時，需要根據具體的應用場景和需求來權衡兩者之間的優(yōu)劣，并選擇合適的技術方案。

Dubbo和openfeign 區(qū)別

Dubbo 和 OpenFeign 是兩種常用的遠程服務調用框架，它們在實現遠程服務調用時有一些不同之處：

1. 通信協(xié)議：
   ○ Dubbo 通常使用自定義的 Dubbo 協(xié)議進行遠程調用，該協(xié)議基于 TCP 傳輸。
   ○ OpenFeign 則是基于 HTTP 協(xié)議進行遠程調用，通常使用 RESTful 風格的 API。
2. 服務注冊與發(fā)現：
   ○ Dubbo 依賴于 ZooKeeper 或其他注冊中心來進行服務的注冊和發(fā)現。
   ○ OpenFeign 在默認情況下通常與服務發(fā)現和注冊無關，需要額外集成服務發(fā)現組件（如 Eureka、Consul 等）來實現服務的注冊和發(fā)現。
3. 接口定義方式：
   ○ 在 Dubbo 中，通常需要通過 Dubbo 提供的接口定義語言（IDL）來定義服務接口，然后生成客戶端和服務器端的代理類。
   ○ OpenFeign 則通常使用接口的方式來定義遠程服務，通過注解來標識遠程服務的調用方式。
4. 負載均衡和容錯機制：
   ○ Dubbo 內置了豐富的負載均衡和容錯機制，包括輪詢、隨機、一致性哈希等負載均衡算法，以及失敗自動切換、快速失敗等容錯機制。
   ○ OpenFeign 在默認情況下通常需要結合 Ribbon 來實現負載均衡，同時也可以集成 Hystrix 等容錯機制。
5. 附加功能：
   ○ Dubbo 提供了更多的企業(yè)級功能支持，如監(jiān)控、治理、降級、熔斷等，適用于復雜的微服務架構。
   ○ OpenFeign 更側重于簡化 REST 客戶端的開發(fā)，提供了更直觀的聲明式 API 定義和使用。
   總的來說，Dubbo 更適用于企業(yè)級的微服務架構，提供了更多的功能和配置選項；而 OpenFeign 更適合于簡單的 RESTful 服務調用，提供了更便捷的聲明式 API 調用方式。選擇使用哪種框架取決于具體的業(yè)務需求和技術場景。

遠程調用

rmi
http
hessian
webservice
socket
網絡通信
負載均衡
注冊中心
遠程通訊協(xié)議的基本原理
網絡通信需要做的就是將流從一臺計算機傳輸到另外一臺計算機，基于傳輸協(xié)議和網絡 IO 來實現，其中傳輸協(xié)議比較出名的有 http 、 tcp 、 udp 等等， http 、 tcp 、 udp 都是在基于 Socket 概念上為某類應用場景而擴展出的傳輸協(xié)議，網絡 IO ，主要有 bio 、 nio 、 aio 三種方式，所有的分布式應用通訊都基于這個原理而實現，只是為了應用的易用，各種語言通常都會提供一些更為貼近應用易用的應用層協(xié)議。
應用級協(xié)議Binary-RPC
Binary-RPC(Remote Procedure Call Protocol，遠程過程調用協(xié)議)是一種和RMI(Remote Method Invocation，遠程方法調用)類似的遠程調用的協(xié)議，它和RMI 的不同之處在于它以標準的二進制格式來定義請求的信息 ( 請求的對象、方法、參數等 ) ，這樣的好處是什么呢，就是在跨語言通訊的時候也可以使用。
Binary -RPC 協(xié)議的一次遠程通信過程：
1 、客戶端發(fā)起請求，按照 Binary -RPC 協(xié)議將請求信息進行填充；
2 、填充完畢后將二進制格式文件轉化為流，通過傳輸協(xié)議進行傳輸；
3 、接收到在接收到流后轉換為二進制格式文件，按照 Binary -RPC 協(xié)議獲取請求的信息并進行處理；
4 、處理完畢后將結果按照 Binary -RPC 協(xié)議寫入二進制格式文件中并返回。
問題總結：
1 、傳輸的標準格式是：標準格式的二進制文件。
2 、怎么樣將請求轉化為傳輸的流？將二進制格式文件轉化為流。
3 、怎么接收和處理流？通過監(jiān)聽的端口獲取到請求的流，轉化為二進制文件，根據協(xié)議獲取請求的信息，進行處理并將結果寫入 XML 中返回。
4 、傳輸協(xié)議是？http

RPC框架傳輸協(xié)議傳輸速度

RMI 是 java 語言本身提供的遠程通訊協(xié)議，穩(wěn)定高效，是 EJB 的基礎。但它只能用于 JAVA 程序之間的通訊。
Hessian 和 Burlap 是 caucho 公司提供的開源協(xié)議，基于 HTTP 傳輸，服務端不用開防火墻端口。協(xié)議的規(guī)范公開，可以用于任意語言。跨平臺有點小問題。
Httpinvoker 是 SpringFramework 提供的遠程通訊協(xié)議，只能用于 JAVA 程序間的通訊，且服務端和客戶端必須使用 SpringFramework。
Web service 是連接異構系統(tǒng)或異構語言的首選協(xié)議，它使用 SOAP 形式通訊，可以用于任何語言，目前的許多開發(fā)工具對其的支持也很好。
效率相比：RMI > Httpinvoker >= Hessian >> Burlap >> web service。
RMI （Remote Method Invocation）
RMI 采用 stubs 和 skeletons 來進行遠程對象(remote object)的通訊。stub 充當
遠程對象的客戶端代理，有著和遠程對象相同的遠程接口，遠程對象的調用實際是通過調用
該對象的客戶端代理對象stub來完成的，通過該機制RMI就好比它是本地工作，采用tcp/ip
協(xié)議，客戶端直接調用服務端上的一些方法。優(yōu)點是強類型，編譯期可檢查錯誤，缺點是只
能基于 JAVA 語言，客戶機與服務器緊耦合。
JMS（Java Messaging Service）
JMS 是 Java 的消息服務，JMS 的客戶端之間可以通過 JMS 服務進行異步的消息傳輸。
JMS 支持兩種消息模型：Point-to-Point（P2P）和 Publish/Subscribe（Pub/Sub），即
點對點和發(fā)布訂閱模型。