Dubbo面試題（2021最新版）

基礎知識

為什麼要用 Dubbo？

随着服務化的進一步發展，服務越來越多，服務之間的調用和依賴關系也越來越複雜，誕生了面向服務的架構體系(SOA)，也是以衍生出了一系列相應的技術，如對服務提供、服務調用、連接配接處理、通信協定、序列化方式、服務發現、服務路由、日志輸出等行為進行封裝的服務架構。就這樣為分布式系統的服務治理架構就出現了，Dubbo 也就這樣産生了。

Dubbo 是什麼？

Dubbo 是一款高性能、輕量級的開源 RPC 架構，提供服務自動注冊、自動發現等高效服務治理方案， 可以和 Spring 架構無縫內建。

Dubbo 的使用場景有哪些？

• 透明化的遠端方法調用：就像調用本地方法一樣調用遠端方法，隻需簡單配置，沒有任何API侵入。
• 軟負載均衡及容錯機制：可在内網替代 F5 等硬體負載均衡器，降低成本，減少單點。
• 服務自動注冊與發現：不再需要寫死服務提供方位址，注冊中心基于接口名查詢服務提供者的IP位址，并且能夠平滑添加或删除服務提供者。

Dubbo 核心功能有哪些？

• Remoting：網絡通信架構，提供對多種NIO架構抽象封裝，包括“同步轉異步”和“請求-響應”模式的資訊交換方式。
• Cluster：服務架構，提供基于接口方法的透明遠端過程調用，包括多協定支援，以及軟負載均衡，失敗容錯，位址路由，動态配置等叢集支援。
• Registry：服務注冊，基于注冊中心目錄服務，使服務消費方能動态的查找服務提供方，使位址透明，使服務提供方可以平滑增加或減少機器。

架構設計

Dubbo 核心元件有哪些？

• Provider：暴露服務的服務提供方
• Consumer：調用遠端服務消費方
• Registry：服務注冊與發現注冊中心
• Monitor：監控中心和通路調用統計
• Container：服務運作容器

Dubbo 伺服器注冊與發現的流程？

服務容器Container負責啟動，加載，運作服務提供者。

服務提供者Provider在啟動時，向注冊中心注冊自己提供的服務。

服務消費者Consumer在啟動時，向注冊中心訂閱自己所需的服務。

注冊中心Registry傳回服務提供者位址清單給消費者，如果有變更，注冊中心将基于長連接配接推送變更資料給消費者。

服務消費者Consumer，從提供者位址清單中，基于軟負載均衡算法，選一台提供者進行調用，如果調用失敗，再選另一台調用。

服務消費者Consumer和提供者Provider，在記憶體中累計調用次數和調用時間，定時每分鐘發送一次統計資料到監控中心Monitor。

Dubbo 的整體架構設計有哪些分層?

接口服務層（Service）：該層與業務邏輯相關，根據 provider 和 consumer 的業務設計對應的接口和實作

配置層（Config）：對外配置接口，以 ServiceConfig 和 ReferenceConfig 為中心

服務代理層（Proxy）：服務接口透明代理，生成服務的用戶端 Stub 和 服務端的 Skeleton，以 ServiceProxy 為中心，擴充接口為 ProxyFactory

服務注冊層（Registry）：封裝服務位址的注冊和發現，以服務 URL 為中心，擴充接口為 RegistryFactory、Registry、RegistryService

路由層（Cluster）：封裝多個提供者的路由和負載均衡，并橋接注冊中心，以Invoker 為中心，擴充接口為 Cluster、Directory、Router 和 LoadBlancce

監控層（Monitor）：RPC 調用次數和調用時間監控，以 Statistics 為中心，擴充接口為 MonitorFactory、Monitor 和 MonitorService

遠端調用層（Protocal）：封裝 RPC 調用，以 Invocation 和 Result 為中心，擴充接口為 Protocal、Invoker 和 Exporter

資訊交換層（Exchange）：封裝請求響應模式，同步轉異步。以 Request 和Response 為中心，擴充接口為 Exchanger、ExchangeChannel、ExchangeClient 和 ExchangeServer

網絡 傳輸 層（Transport）：抽象 mina 和 netty 為統一接口，以 Message 為中心，擴充接口為 Channel、Transporter、Client、Server 和 Codec

資料序列化層（Serialize）：可複用的一些工具，擴充接口為 Serialization、ObjectInput、ObjectOutput 和 ThreadPool

Dubbo Monitor 實作原理？

Consumer 端在發起調用之前會先走 filter 鍊；provider 端在接收到請求時也是先走 filter 鍊，然後才進行真正的業務邏輯處理。預設情況下，在 consumer 和 provider 的 filter 鍊中都會有 Monitorfilter。

1、MonitorFilter 向 DubboMonitor 發送資料

2、DubboMonitor 将資料進行聚合後（預設聚合 1min 中的統計資料）暫存到ConcurrentMap<Statistics, AtomicReference> statisticsMap，然後使用一個含有 3 個線程（線程名字：DubboMonitorSendTimer）的線程池每隔 1min 鐘，調用 SimpleMonitorService 周遊發送 statisticsMap 中的統計資料，每發送完畢一個，就重置目前的 Statistics 的 AtomicReference

3、SimpleMonitorService 将這些聚合資料塞入 BlockingQueue queue 中（隊列大寫為 100000）

4、SimpleMonitorService 使用一個背景線程（線程名為：DubboMonitorAsyncWriteLogThread）将 queue 中的資料寫入檔案（該線程以死循環的形式來寫）

5、SimpleMonitorService 還會使用一個含有 1 個線程（線程名字：DubboMonitorTimer）的線程池每隔 5min 鐘，将檔案中的統計資料畫成圖表

分布式架構

Dubbo 類似的分布式架構還有哪些？

比較著名的就是 Spring Cloud。

Dubbo 和 Spring Cloud 有什麼關系？

Dubbo 是 SOA 時代的産物，它的關注點主要在于服務的調用，流量分發、流量監控和熔斷。而 Spring Cloud 誕生于微服務架構時代，考慮的是微服務治理的方方面面，另外由于依托了 Spring、Spring Boot 的優勢之上，兩個架構在開始目标就不一緻，Dubbo 定位服務治理、Spring Cloud 是打造一個生态。

Dubbo 和 Spring Cloud 有什麼哪些差別？

Dubbo 底層是使用 Netty 這樣的 NIO 架構，是基于 TCP 協定傳輸的，配合以 Hession 序列化完成 RPC 通信。

Spring Cloud 是基于 Http 協定 Rest 接口調用遠端過程的通信，相對來說 Http 請求會有更大的封包，占的帶寬也會更多。但是 REST 相比 RPC 更為靈活，服務提供方和調用方的依賴隻依靠一紙契約，不存在代碼級别的強依賴，這在強調快速演化的微服務環境下，顯得更為合适，至于注重通信速度還是友善靈活性，具體情況具體考慮。

Dubbo 和 Dubbox 之間的差別？

Dubbox 是繼 Dubbo 停止維護後，當當網基于 Dubbo 做的一個擴充項目，如加了服務可 Restful 調用，更新了開源元件等。

注冊中心

Dubbo 有哪些注冊中心？

• Multicast 注冊中心：Multicast 注冊中心不需要任何中心節點，隻要廣播位址，就能進行服務注冊和發現,基于網絡中多點傳播傳輸實作。
• Zookeeper 注冊中心：基于分布式協調系統 Zookeeper 實作，采用 Zookeeper 的 watch 機制實作資料變更。
• Redis 注冊中心：基于 Redis 實作，采用 key/map 存儲，key 存儲服務名和類型，map 中 key 存儲服務 url，value 服務過期時間。基于 Redis 的釋出/訂閱模式通知資料變更。
• Simple 注冊中心。

推薦使用 Zookeeper 作為注冊中心

Dubbo 的注冊中心叢集挂掉，釋出者和訂閱者之間還能通信麼？

可以通訊。啟動 Dubbo 時，消費者會從 Zookeeper 拉取注冊的生産者的位址接口等資料，緩存在本地。每次調用時，按照本地存儲的位址進行調用。

叢集

Dubbo叢集提供了哪些負載均衡政策？

• Random LoadBalance: 随機選取提供者政策，有利于動态調整提供者權重。截面碰撞率高，調用次數越多，分布越均勻。
• RoundRobin LoadBalance: 輪循選取提供者政策，平均分布，但是存在請求累積的問題。
• LeastActive LoadBalance: 最少活躍調用政策，解決慢提供者接收更少的請求。
• ConstantHash LoadBalance: 一緻性 Hash 政策，使相同參數請求總是發到同一提供者，一台機器當機，可以基于虛拟節點，分攤至其他提供者，避免引起提供者的劇烈變動。

預設為 Random 随機調用。

Dubbo的叢集容錯方案有哪些？

• Failover Cluster：失敗自動切換，當出現失敗，重試其它伺服器。通常用于讀操作，但重試會帶來更長延遲。
• Failfast Cluster：快速失敗，隻發起一次調用，失敗立即報錯。通常用于非幂等性的寫操作，比如新增記錄。
• Failsafe Cluster：失敗安全，出現異常時，直接忽略。通常用于寫入審計日志等操作。
• Failback Cluster：失敗自動恢複，背景記錄失敗請求，定時重發。通常用于消息通知操作。
• Forking Cluster：并行調用多個伺服器，隻要一個成功即傳回。通常用于實時性要求較高的讀操作，但需要浪費更多服務資源。可通過 forks=”2″ 來設定最大并行數。
• Broadcast Cluster：廣播調用所有提供者，逐個調用，任意一台報錯則報錯 。通常用于通知所有提供者更新緩存或日志等本地資源資訊。

預設的容錯方案是 Failover Cluster。

配置

Dubbo 配置檔案是如何加載到 Spring 中的？

Spring 容器在啟動的時候，會讀取到 Spring 預設的一些 schema 以及 Dubbo 自定義的 schema，每個 schema 都會對應一個自己的 NamespaceHandler，NamespaceHandler 裡面通過 BeanDefinitionParser 來解析配置資訊并轉化為需要加載的 bean 對象！

說說核心的配置有哪些？

标簽	用途	解釋
dubbo:service/	服務配置	用于暴露一個服務，定義服務的元資訊，一個服務可以用多個協定暴露，一個服務也可以注冊到多個注冊中心
dubbo:reference/	引用配置	用于建立一個遠端服務代理，一個引用可以指向多個注冊中心
dubbo:protocol/	協定配置	用于配置提供服務的協定資訊，協定由提供方指定，消費方被動接受
dubbo:application/	應用配置	用于配置目前應用資訊，不管該應用是提供者還是消費者
dubbo:module/	子產品配置	用于配置目前子產品資訊，可選
dubbo:registry/	注冊中心配置	用于配置連接配接注冊中心相關資訊
dubbo:monitor/	監控中心配置	用于配置連接配接監控中心相關資訊，可選
dubbo:provider/	提供方配置	當 ProtocolConfig 和 ServiceConfig 某屬性沒有配置時，采用此預設值，可選
dubbo:consumer/	消費方配置	當 ReferenceConfig 某屬性沒有配置時，采用此預設值，可選
dubbo:method/	方法配置	用于 ServiceConfig 和 ReferenceConfig 指定方法級的配置資訊
dubbo:argument/	參數配置	用于指定方法參數配置

Dubbo 逾時設定有哪些方式？

Dubbo 逾時設定有兩種方式：

• 服務提供者端設定逾時時間，在Dubbo的使用者文檔中，推薦如果能在服務端多配置就盡量多配置，因為服務提供者比消費者更清楚自己提供的服務特性。
• 服務消費者端設定逾時時間，如果在消費者端設定了逾時時間，以消費者端為主，即優先級更高。因為服務調用方設定逾時時間控制性更靈活。如果消費方逾時，服務端線程不會定制，會産生警告。

服務調用逾時會怎麼樣？

dubbo 在調用服務不成功時，預設是會重試兩次。

通信協定

Dubbo 使用的是什麼通信架構?

預設使用 Netty 作為通訊架構。

Dubbo 支援哪些協定，它們的優缺點有哪些？

• Dubbo： 單一長連接配接和 NIO 異步通訊，适合大并發小資料量的服務調用，以及消費者遠大于提供者。傳輸協定 TCP，異步 Hessian 序列化。Dubbo推薦使用dubbo協定。
• RMI： 采用 JDK 标準的 RMI 協定實作，傳輸參數和傳回參數對象需要實作 Serializable 接口，使用 Java 标準序列化機制，使用阻塞式短連接配接，傳輸資料包大小混合，消費者和提供者個數差不多，可傳檔案，傳輸協定 TCP。 多個短連接配接 TCP 協定傳輸，同步傳輸，适用正常的遠端服務調用和 RMI 互操作。在依賴低版本的 Common-Collections 包，Java 序列化存在安全漏洞。
• WebService：基于 WebService 的遠端調用協定，內建 CXF 實作，提供和原生 WebService 的互操作。多個短連接配接，基于 HTTP 傳輸，同步傳輸，适用系統內建和跨語言調用。
• HTTP： 基于 Http 表單送出的遠端調用協定，使用 Spring 的 HttpInvoke 實作。多個短連接配接，傳輸協定 HTTP，傳入參數大小混合，提供者個數多于消費者，需要給應用程式和浏覽器 JS 調用。
• Hessian：內建 Hessian 服務，基于 HTTP 通訊，采用 Servlet 暴露服務，Dubbo 内嵌 Jetty 作為伺服器時預設實作，提供與 Hession 服務互操作。多個短連接配接，同步 HTTP 傳輸，Hessian 序列化，傳入參數較大，提供者大于消費者，提供者壓力較大，可傳檔案。
• Memcache：基于 Memcache實作的 RPC 協定。
• Redis：基于 Redis 實作的RPC協定。

設計模式

Dubbo 用到哪些設計模式？

Dubbo 架構在初始化和通信過程中使用了多種設計模式，可靈活控制類加載、權限控制等功能。

工廠模式

Provider 在 export 服務時，會調用 ServiceConfig 的 export 方法。ServiceConfig中有個字段：

private static final Protocol protocol =
ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtensi
on();
           

Dubbo 裡有很多這種代碼。這也是一種工廠模式，隻是實作類的擷取采用了 JDKSPI 的機制。這麼實作的優點是可擴充性強，想要擴充實作，隻需要在 classpath下增加個檔案就可以了，代碼零侵入。另外，像上面的 Adaptive 實作，可以做到調用時動态決定調用哪個實作，但是由于這種實作采用了動态代理，會造成代碼調試比較麻煩，需要分析出實際調用的實作類。

裝飾器模式

Dubbo 在啟動和調用階段都大量使用了裝飾器模式。以 Provider 提供的調用鍊為例，具體的調用鍊代碼是在 ProtocolFilterWrapper 的 buildInvokerChain 完成的，具體是将注解中含有 group=provider 的 Filter 實作，按照 order 排序，最後的調用順序是：

EchoFilter -> ClassLoaderFilter -> GenericFilter -> ContextFilter ->
ExecuteLimitFilter -> TraceFilter -> TimeoutFilter -> MonitorFilter ->
ExceptionFilter
           

更确切地說，這裡是裝飾器和責任鍊模式的混合使用。例如，EchoFilter 的作用是判斷是否是回聲測試請求，是的話直接傳回内容，這是一種責任鍊的展現。而像ClassLoaderFilter 則隻是在主功能上添加了功能，更改目前線程的 ClassLoader，這是典型的裝飾器模式。

觀察者模式

Dubbo 的 Provider 啟動時，需要與注冊中心互動，先注冊自己的服務，再訂閱自己的服務，訂閱時，采用了觀察者模式，開啟一個 listener。注冊中心會每 5 秒定時檢查是否有服務更新，如果有更新，向該服務的提供者發送一個 notify 消息，provider 接受到 notify 消息後，運作 NotifyListener 的 notify 方法，執行監聽器方法。

動态代理模式

Dubbo 擴充 JDK SPI 的類 ExtensionLoader 的 Adaptive 實作是典型的動态代理實作。Dubbo 需要靈活地控制實作類，即在調用階段動态地根據參數決定調用哪個實作類，是以采用先生成代理類的方法，能夠做到靈活的調用。生成代理類的代碼是 ExtensionLoader 的 createAdaptiveExtensionClassCode 方法。代理類主要邏輯是，擷取 URL 參數中指定參數的值作為擷取實作類的 key。

運維管理

服務上線怎麼相容舊版本？

可以用版本号（version）過渡，多個不同版本的服務注冊到注冊中心，版本号不同的服務互相間不引用。這個和服務分組的概念有一點類似。

Dubbo telnet 指令能做什麼？

dubbo 服務釋出之後，我們可以利用 telnet 指令進行調試、管理。Dubbo2.0.5 以上版本服務提供端口支援 telnet 指令

Dubbo 支援服務降級嗎？

以通過 dubbo:reference 中設定 mock=“return null”。mock 的值也可以修改為 true，然後再跟接口同一個路徑下實作一個 Mock 類，命名規則是 “接口名稱+Mock” 字尾。然後在 Mock 類裡實作自己的降級邏輯

Dubbo 如何優雅停機？

Dubbo 是通過 JDK 的 ShutdownHook 來完成優雅停機的，是以如果使用kill -9 PID 等強制關閉指令，是不會執行優雅停機的，隻有通過 kill PID 時，才會執行。

SPI

Dubbo SPI 和 Java SPI 差別？

JDK SPI：

JDK 标準的 SPI 會一次性加載所有的擴充實作，如果有的擴充很耗時，但也沒用上，很浪費資源。是以隻希望加載某個的實作，就不現實了

DUBBO SPI：

1、對 Dubbo 進行擴充，不需要改動 Dubbo 的源碼

2、延遲加載，可以一次隻加載自己想要加載的擴充實作。

3、增加了對擴充點 IOC 和 AOP 的支援，一個擴充點可以直接 setter 注入其

它擴充點。

4、Dubbo 的擴充機制能很好的支援第三方 IoC 容器，預設支援 Spring Bean。

其他

Dubbo 支援分布式事務嗎？

目前暫時不支援，可與通過 tcc-transaction 架構實作

介紹：tcc-transaction 是開源的 TCC 補償性分布式事務架構

TCC-Transaction 通過 Dubbo 隐式傳參的功能，避免自己對業務代碼的入侵。

Dubbo 可以對結果進行緩存嗎？

為了提高資料通路的速度。Dubbo 提供了聲明式緩存，以減少使用者加緩存的工作量<dubbo:reference cache=“true” />

其實比普通的配置檔案就多了一個标簽 cache=“true”

Dubbo 必須依賴的包有哪些？

Dubbo 必須依賴 JDK，其他為可選。

Dubbo 支援哪些序列化方式？

預設使用 Hessian 序列化，還有 Duddo、FastJson、Java 自帶序列化。

Dubbo 在安全方面有哪些措施？

• Dubbo 通過 Token 令牌防止使用者繞過注冊中心直連，然後在注冊中心上管理授權。
• Dubbo 還提供服務黑白名單，來控制服務所允許的調用方。

服務調用是阻塞的嗎？

預設是阻塞的，可以異步調用，沒有傳回值的可以這麼做。Dubbo 是基于 NIO 的非阻塞實作并行調用，用戶端不需要啟動多線程即可完成并行調用多個遠端服務，相對多線程開銷較小，異步調用會傳回一個 Future 對象。

服務提供者能實作失效踢出是什麼原理？

服務失效踢出基于 zookeeper 的臨時節點原理。

同一個服務多個注冊的情況下可以直連某一個服務嗎？

可以點對點直連，修改配置即可，也可以通過 telnet 直接某個服務。

Dubbo 服務降級，失敗重試怎麼做？

可以通過 dubbo:reference 中設定 mock=“return null”。mock 的值也可以修改為 true，然後再跟接口同一個路徑下實作一個 Mock 類，命名規則是 “接口名稱+Mock” 字尾。然後在 Mock 類裡實作自己的降級邏輯

Dubbo 使用過程中都遇到了些什麼問題？

在注冊中心找不到對應的服務,檢查 service 實作類是否添加了@service 注解無法連接配接到注冊中心,檢查配置檔案中的對應的測試 ip 是否正确

RPC

為什麼要有RPC

http接口是在接口不多、系統與系統互動較少的情況下，解決資訊孤島初期常使用的一種通信手段；優點就是簡單、直接、開發友善。利用現成的http協定進行傳輸。但是如果是一個大型的網站，内部子系統較多、接口非常多的情況下，RPC架構的好處就顯示出來了，首先就是長連結，不必每次通信都要像http一樣去3次握手什麼的，減少了網絡開銷；其次就是RPC架構一般都有注冊中心，有豐富的監控管理；釋出、下線接口、動态擴充等，對調用方來說是無感覺、統一化的操作。第三個來說就是安全性。最後就是最近流行的服務化架構、服務化治理，RPC架構是一個強力的支撐。

socket隻是一個簡單的網絡通信方式，隻是建立通信雙方的通信通道，而要實作rpc的功能，還需要對其進行封裝，以實作更多的功能。

RPC一般配合netty架構、spring自定義注解來編寫輕量級架構，其實netty内部是封裝了socket的，較新的jdk的IO一般是NIO，即非阻塞IO，在高并發網站中，RPC的優勢會很明顯

什麼是RPC

RPC（Remote Procedure Call Protocol）遠端過程調用協定，它是一種通過網絡從遠端計算機程式上請求服務，而不需要了解底層網絡技術的協定。簡言之，RPC使得程式能夠像通路本地系統資源一樣，去通路遠端系統資源。比較關鍵的一些方面包括：通訊協定、序列化、資源（接口）描述、服務架構、性能、語言支援等。

簡單的說，RPC就是從一台機器(用戶端)上通過參數傳遞的方式調用另一台機器(伺服器)上的一個函數或方法(可以統稱為服務)并得到傳回的結果。

PRC架構元件

一個基本的RPC架構裡面應該至少包含以下4個元件：

1、用戶端（Client）:服務調用方（服務消費者）

2、用戶端存根（Client Stub）:存放服務端位址資訊，将用戶端的請求參數資料資訊打包成網絡消息，再通過網絡傳輸發送給服務端

3、服務端存根（Server Stub）:接收用戶端發送過來的請求消息并進行解包，然後再調用本地服務進行處理

4、服務端（Server）:服務的真正提供者

具體調用過程：

1、服務消費者（client用戶端）通過調用本地服務的方式調用需要消費的服務；

2、用戶端存根（client stub）接收到調用請求後負責将方法、入參等資訊序列化（組裝）成能夠進行網絡傳輸的消息體；

3、用戶端存根（client stub）找到遠端的服務位址，并且将消息通過網絡發送給服務端；

4、服務端存根（server stub）收到消息後進行解碼（反序列化操作）；

5、服務端存根（server stub）根據解碼結果調用本地的服務進行相關處理；

6、本地服務執行具體業務邏輯并将處理結果傳回給服務端存根（server stub）；

7、服務端存根（server stub）将傳回結果重新打包成消息（序列化）并通過網絡發送至消費方；

8、用戶端存根（client stub）接收到消息，并進行解碼（反序列化）；

9、服務消費方得到最終結果；

而RPC架構的實作目标則是将上面的第2-10步完好地封裝起來，也就是把調用、編碼/解碼的過程給封裝起來，讓使用者感覺上像調用本地服務一樣的調用遠端服務。

RPC和SOA、SOAP、REST的差別

1、REST

可以看着是HTTP協定的一種直接應用，預設基于JSON作為傳輸格式,使用簡單,學習成本低效率高,但是安全性較低。

2、SOAP

SOAP是一種資料交換協定規範,是一種輕量的、簡單的、基于XML的協定的規範。而SOAP可以看着是一個重量級的協定，基于XML、SOAP在安全方面是通過使用XML-Security和XML-Signature兩個規範組成了WS-Security來實作安全控制的,目前已經得到了各個廠商的支援 。

它有什麼優點？簡單總結為：易用、靈活、跨語言、跨平台。

3、SOA

面向服務架構，它可以根據需求通過網絡對松散耦合的粗粒度應用元件進行分布式部署、組合和使用。服務層是SOA的基礎，可以直接被應用調用，進而有效控制系統中與軟體代理互動的人為依賴性。

SOA是一種粗粒度、松耦合服務架構，服務之間通過簡單、精确定義接口進行通訊，不涉及底層程式設計接口和通訊模型。SOA可以看作是B/S模型、XML（标準通用标記語言的子集）/Web Service技術之後的自然延伸。

4、REST 和 SOAP、RPC 有何差別呢?

沒什麼太大差別，他們的本質都是提供可支援分布式的基礎服務，最大的差別在于他們各自的的特點所帶來的不同應用場景 。

RPC架構需要解決的問題？

1、如何确定用戶端和服務端之間的通信協定？

2、如何更高效地進行網絡通信？

3、服務端提供的服務如何暴露給用戶端？

4、用戶端如何發現這些暴露的服務？

5、如何更高效地對請求對象和響應結果進行序列化和反序列化操作？

RPC的實作基礎？

1、需要有非常高效的網絡通信，比如一般選擇Netty作為網絡通信架構；

2、需要有比較高效的序列化架構，比如谷歌的Protobuf序列化架構；

3、可靠的尋址方式（主要是提供服務的發現），比如可以使用Zookeeper來注冊服務等等；

4、如果是帶會話（狀态）的RPC調用，還需要有會話和狀态保持的功能；

RPC使用了哪些關鍵技術？

1、動态代理

生成Client Stub（用戶端存根）和Server Stub（服務端存根）的時候需要用到Java動态代理技術，可以使用JDK提供的原生的動态代理機制，也可以使用開源的：CGLib代理，Javassist位元組碼生成技術。

2、序列化和反序列化

在網絡中，所有的資料都将會被轉化為位元組進行傳送，是以為了能夠使參數對象在網絡中進行傳輸，需要對這些參數進行序列化和反序列化操作。

• 序列化：把對象轉換為位元組序列的過程稱為對象的序列化，也就是編碼的過程。
• 反序列化：把位元組序列恢複為對象的過程稱為對象的反序列化，也就是解碼的過程。

目前比較高效的開源序列化架構：如Kryo、FastJson和Protobuf等。

3、NIO通信

出于并發性能的考慮，傳統的阻塞式 IO 顯然不太合适，是以我們需要異步的 IO，即 NIO。Java 提供了 NIO 的解決方案，Java 7 也提供了更優秀的 NIO.2 支援。可以選擇Netty或者MINA來解決NIO資料傳輸的問題。

4、服務注冊中心

可選：Redis、Zookeeper、Consul 、Etcd。一般使用ZooKeeper提供服務注冊與發現功能，解決單點故障以及分布式部署的問題(注冊中心)。

主流RPC架構有哪些

1、RMI

利用java.rmi包實作，基于Java遠端方法協定(Java Remote Method Protocol) 和java的原生序列化。

2、Hessian

是一個輕量級的remoting onhttp工具，使用簡單的方法提供了RMI的功能。 基于HTTP協定，采用二進制編解碼。

3、protobuf-rpc-pro

是一個Java類庫，提供了基于 Google 的 Protocol Buffers 協定的遠端方法調用的架構。基于 Netty 底層的 NIO 技術。支援 TCP 重用/ keep-alive、SSL加密、RPC 調用取消操作、嵌入式日志等功能。

4、Thrift

是一種可伸縮的跨語言服務的軟體架構。它擁有功能強大的代碼生成引擎，無縫地支援C + +，C#，Java，Python和PHP和Ruby。thrift允許你定義一個描述檔案，描述資料類型和服務接口。依據該檔案，編譯器友善地生成RPC用戶端和伺服器通信代碼。

最初由facebook開發用做系統内個語言之間的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兩種協定。

6、Dubbo

Dubbo是 阿裡巴巴公司開源的一個高性能優秀的服務架構，使得應用可通過高性能的 RPC 實作服務的輸出和輸入功能，可以和 Spring架構無縫內建。

RPC的實作原理架構圖

PS：這張圖非常重點，是PRC的基本原理，請大家一定記住！

也就是說兩台伺服器A，B，一個應用部署在A伺服器上，想要調用B伺服器上應用提供的函數/方法，由于不在一個記憶體空間，不能直接調用，需要通過網絡來表達調用的語義和傳達調用的資料。

比如說，A伺服器想調用B伺服器上的一個方法：

User getUserByName(String userName)

1、建立通信

首先要解決通訊的問題：即A機器想要調用B機器，首先得建立起通信連接配接。

主要是通過在用戶端和伺服器之間建立TCP連接配接，遠端過程調用的所有交換的資料都在這個連接配接裡傳輸。連接配接可以是按需連接配接，調用結束後就斷掉，也可以是長連接配接，多個遠端過程調用共享同一個連接配接。

通常這個連接配接可以是按需連接配接（需要調用的時候就先建立連接配接，調用結束後就立馬斷掉），也可以是長連接配接（用戶端和伺服器建立起連接配接之後保持長期持有，不管此時有無資料包的發送，可以配合心跳檢測機制定期檢測建立的連接配接是否存活有效），多個遠端過程調用共享同一個連接配接。

2、服務尋址

要解決尋址的問題，也就是說，A伺服器上的應用怎麼告訴底層的RPC架構，如何連接配接到B伺服器（如主機或IP位址）以及特定的端口，方法的名稱名稱是什麼。

通常情況下我們需要提供B機器（主機名或IP位址）以及特定的端口，然後指定調用的方法或者函數的名稱以及入參出參等資訊，這樣才能完成服務的一個調用。

可靠的尋址方式（主要是提供服務的發現）是RPC的實作基石，比如可以采用Redis或者Zookeeper來注冊服務等等。

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-mc5qSk8i-1620704763495)(https://ask.qcloudimg.com/http-save/yehe-1011815/8p90o7gg88.png?imageView2/2/w/1620)]

2.1、從服務提供者的角度看：

當服務提供者啟動的時候，需要将自己提供的服務注冊到指定的注冊中心，以便服務消費者能夠通過服務注冊中心進行查找；

當服務提供者由于各種原因緻使提供的服務停止時，需要向注冊中心登出停止的服務；

服務的提供者需要定期向服務注冊中心發送心跳檢測，服務注冊中心如果一段時間未收到來自服務提供者的心跳後，認為該服務提供者已經停止服務，則将該服務從注冊中心上去掉。

2.2、從調用者的角度看：

服務的調用者啟動的時候根據自己訂閱的服務向服務注冊中心查找服務提供者的位址等資訊；

當服務調用者消費的服務上線或者下線的時候，注冊中心會告知該服務的調用者；

服務調用者下線的時候，則取消訂閱。

3、網絡傳輸

3.1、序列化

當A機器上的應用發起一個RPC調用時，調用方法和其入參等資訊需要通過底層的網絡協定如TCP傳輸到B機器，由于網絡協定是基于二進制的，所有我們傳輸的參數資料都需要先進行序列化（Serialize）或者編組（marshal）成二進制的形式才能在網絡中進行傳輸。然後通過尋址操作和網絡傳輸将序列化或者編組之後的二進制資料發送給B機器。

3.2、反序列化

當B機器接收到A機器的應用發來的請求之後，又需要對接收到的參數等資訊進行反序列化操作（序列化的逆操作），即将二進制資訊恢複為記憶體中的表達方式，然後再找到對應的方法（尋址的一部分）進行本地調用（一般是通過生成代理Proxy去調用, 通常會有JDK動态代理、CGLIB動态代理、Javassist生成位元組碼技術等），之後得到調用的傳回值。