概述

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

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

rpc的優(yōu)點

分布式設(shè)計
部署靈活
解耦服務(wù)
擴展性強

組件

1. 客戶端（Client）： 發(fā)起RPC調(diào)用的應(yīng)用程序部分。
2. 服務(wù)端（Server）： 提供RPC服務(wù)的應(yīng)用程序部分。
3. RPC協(xié)議（Protocol）： 定義了客戶端和服務(wù)端之間通信的規(guī)則、格式和消息交換方式。
4. 序列化/反序列化（Serialization/Deserialization）： 將數(shù)據(jù)結(jié)構(gòu)或?qū)ο筠D(zhuǎn)換成字節(jié)流以便在網(wǎng)絡(luò)上傳輸，并在接收端重新構(gòu)造成相應(yīng)的數(shù)據(jù)結(jié)構(gòu)或?qū)ο蟆?/li>
5. 網(wǎng)絡(luò)傳輸（Network Transport）： 用于在客戶端和服務(wù)端之間傳輸數(shù)據(jù)的通信機制，通常使用TCP/IP或者HTTP等協(xié)議。

工作流程&RPC的底層原理

1. 客戶端調(diào)用： 客戶端調(diào)用本地的Stub（存根）方法，傳遞參數(shù)。
2. 參數(shù)序列化： 客戶端將參數(shù)序列化成字節(jié)流。
3. 網(wǎng)絡(luò)傳輸： 序列化后的數(shù)據(jù)通過網(wǎng)絡(luò)傳輸?shù)竭h程服務(wù)端。
4. 服務(wù)端接收： 遠程服務(wù)端接收到請求，進行反序列化得到參數(shù)。
5. 服務(wù)端處理： 服務(wù)端執(zhí)行相應(yīng)的方法或過程，傳入?yún)?shù)，執(zhí)行計算或操作。
6. 結(jié)果序列化： 服務(wù)端將執(zhí)行結(jié)果序列化成字節(jié)流。
7. 網(wǎng)絡(luò)傳輸： 序列化后的結(jié)果通過網(wǎng)絡(luò)傳輸?shù)娇蛻舳恕?/li>
8. 客戶端接收： 客戶端接收到結(jié)果，進行反序列化得到返回值。
9. 客戶端處理： 客戶端處理返回值，完成RPC調(diào)用。

RPC的底層原理

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

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

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

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

RPC框架

RPC（Remote Procedure Call）框架是一種用于實現(xiàn)遠程調(diào)用的技術(shù)，它可以讓不同的進程或計算機之間通過網(wǎng)絡(luò)進行通信和調(diào)用遠程方法。以下是一些常見的 RPC 框架：

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

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

rpc框架優(yōu)點

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

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

RPC 的實現(xiàn)基礎(chǔ)

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

RPC的應(yīng)用場景

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

RPC使用了哪些關(guān)鍵技術(shù)

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

rpc 調(diào)用異常一般怎么處理

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

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

rpc和http的區(qū)別

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

為什么RPC要比HTTP更快一些

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

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

Dubbo和openfeign 區(qū)別

Dubbo 和 OpenFeign 是兩種常用的遠程服務(wù)調(diào)用框架，它們在實現(xiàn)遠程服務(wù)調(diào)用時有一些不同之處：

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

遠程調(diào)用

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

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

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