## 基礎知識 ### 為什么要用 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 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 對象！ ### 說說核心的配置有哪些？ | 標簽 | 用途 | 解釋 | | --- | --- | --- | | | 服務配置 | 用于暴露一個服務，定義服務的元信息，一個服務可以用多個協議暴露，一個服務也可以注冊到多個注冊中心 | | | 引用配置 | 用于創建一個遠程服務代理，一個引用可以指向多個注冊中心 | | | 協議配置 | 用于配置提供服務的協議信息，協議由提供方指定，消費方被動接受 | | | 應用配置 | 用于配置當前應用信息，不管該應用是提供者還是消費者 | | | 模塊配置 | 用于配置當前模塊信息，可選 | | | 注冊中心配置 | 用于配置連接注冊中心相關信息 | | | 監控中心配置 | 用于配置連接監控中心相關信息，可選 | | | 提供方配置 | 當 ProtocolConfig 和 ServiceConfig 某屬性沒有配置時，采用此缺省值，可選 | | | 消費方配置 | 當 ReferenceConfig 某屬性沒有配置時，采用此缺省值，可選 | | | 方法配置 | 用于 ServiceConfig 和 ReferenceConfig 指定方法級的配置信息 | | | 參數配置 | 用于指定方法參數配置 | `如果是SpringBoot項目就只需要注解，或者開Application配置文件！！！` ### 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(); 復制代碼 ~~~ * 工廠模式 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 提供了聲明式緩存，以減少用戶加緩存的工作量 * 其實比普通的配置文件就多了一個標簽 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等。 * 反序列化：把字節序列恢復為對象的過程稱為對象的反序列化，也就是解碼的過程。 目前比較高效的開源序列化框架：如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的實現原理架構圖  也就是說兩臺服務器A，B，一個應用部署在A服務器上，想要調用B服務器上應用提供的函數/方法，由于不在一個內存空間，不能直接調用，需要通過網絡來表達調用的語義和傳達調用的數據。 比如說，A服務器想調用B服務器上的一個方法： * 1、建立通信 首先要解決通訊的問題：即A機器想要調用B機器，首先得建立起通信連接。 主要是通過在客戶端和服務器之間建立TCP連接，遠程過程調用的所有交換的數據都在這個連接里傳輸。連接可以是按需連接，調用結束后就斷掉，也可以是長連接，多個遠程過程調用共享同一個連接。 通常這個連接可以是按需連接（需要調用的時候就先建立連接，調用結束后就立馬斷掉），也可以是長連接（客戶端和服務器建立起連接之后保持長期持有，不管此時有無數據包的發送，可以配合心跳檢測機制定期檢測建立的連接是否存活有效），多個遠程過程調用共享同一個連接。 * 2、服務尋址 要解決尋址的問題，也就是說，A服務器上的應用怎么告訴底層的RPC框架，如何連接到B服務器（如主機或IP地址）以及特定的端口，方法的名稱名稱是什么。 通常情況下我們需要提供B機器（主機名或IP地址）以及特定的端口，然后指定調用的方法或者函數的名稱以及入參出參等信息，這樣才能完成服務的一個調用。 可靠的尋址方式（主要是提供服務的發現）是RPC的實現基石，比如可以采用Redis或者Zookeeper來注冊服務等等。 * 2.1、從服務提供者的角度看： 當服務提供者啟動的時候，需要將自己提供的服務注冊到指定的注冊中心，以便服務消費者能夠通過服務注冊中心進行查找； 當服務提供者由于各種原因致使提供的服務停止時，需要向注冊中心注銷停止的服務； 服務的提供者需要定期向服務注冊中心發送心跳檢測，服務注冊中心如果一段時間未收到來自服務提供者的心跳后，認為該服務提供者已經停止服務，則將該服務從注冊中心上去掉。 * 2.2、從調用者的角度看： 服務的調用者啟動的時候根據自己訂閱的服務向服務注冊中心查找服務提供者的地址等信息； 當服務調用者消費的服務上線或者下線的時候，注冊中心會告知該服務的調用者； 服務調用者下線的時候，則取消訂閱。 * 3、網絡傳輸 * 3.1、序列化 當A機器上的應用發起一個RPC調用時，調用方法和其入參等信息需要通過底層的網絡協議如TCP傳輸到B機器，由于網絡協議是基于二進制的，所有我們傳輸的參數數據都需要先進行序列化（Serialize）或者編組（marshal）成二進制的形式才能在網絡中進行傳輸。然后通過尋址操作和網絡傳輸將序列化或者編組之后的二進制數據發送給B機器。 * 3.2、反序列化 當B機器接收到A機器的應用發來的請求之后，又需要對接收到的參數等信息進行反序列化操作（序列化的逆操作），即將二進制信息恢復為內存中的表達方式，然后再找到對應的方法（尋址的一部分）進行本地調用（一般是通過生成代理Proxy去調用, 通常會有JDK動態代理、CGLIB動態代理、Javassist生成字節碼技術等），之后得到調用的返回值。 * 4、服務調用 B機器進行本地調用（通過代理Proxy和反射調用）之后得到了返回值，此時還需要再把返回值發送回A機器，同樣也需要經過序列化操作，然后再經過網絡傳輸將二進制數據發送回A機器，而當A機器接收到這些返回值之后，則再次進行反序列化操作，恢復為內存中的表達方式，最后再交給A機器上的應用進行相關處理（一般是業務邏輯處理操作）。 `通常，經過以上四個步驟之后，一次完整的RPC調用算是完成了，另外可能因為網絡抖動等原因需要重試等。`