dubbo源碼分析視頻

Ⅰ 求系統架構設計師考試的學習資料

《架構師視頻資料》網路網盤資源免費下載

鏈接:https://pan..com/s/1GbV_nl3PARKrVgMIpbnTTg

Ⅱ Java教程：bbo源碼解析-網路通信

在之前的內容中，我們探討了消費者端服務發現與提供者端服務暴露的相關內容，同時了解到消費者端通過內置的負載均衡演算法獲取合適的調用invoker進行遠程調用。接下來，我們聚焦於遠程調用過程，即網路通信的細節。

網路通信位於Remoting模塊中，支持多種通信協議，包括但不限於：bbo協議、rmi協議、hessian協議、http協議、webservice協議、thrift協議、rest協議、grpc協議、memcached協議、redis協議等。每種協議具有獨特的特點和應用場景。

其中，bbo協議採用單一長連接和 NIO 非同步通訊方式，適用於小數據量大並發的服務調用場景，以及服務消費者機器數遠大於服務提供者機器數的情況。它基於 mina1.1.7 和 hessian 3.2.1 的 tbremoting 交互實現。

rmi協議基於JDK標準的java.rmi.*實現，採用阻塞式短連接和JDK標准序列化方式。Hessian協議用於集成Hessian的服務，底層採用Http通訊，通過Servlet暴露服務，Dubbo內置Jetty作為伺服器實現。Hessian協議可以與原生Hessian服務互操作。

基於HTTP表單的遠程調用協議（http協議）採用Spring的HttpInvoker實現，可以與原生HTTP服務互操作。基於WebService的遠程調用協議（webservice協議）基於Apache CXF實現，同樣可以與原生WebService服務互操作。

thrift協議當前支持的擴展了thrift原生協議，增加了額外的頭信息，如serviceName、magic number等。rest協議基於標準的Java REST API實現，JAX-RS 2.0（Java API for RESTful Web Services的簡寫）用於支持REST調用。grpc協議自Dubbo 2.7.5版本開始支持，適合HTTP/2通信場景，利用gRPC帶來的Stream、反壓、Reactive編程能力。

memcached協議基於memcached實現的RPC協議，而redis協議基於Redis實現的RPC協議。

在序列化方面，序列化是將對象轉成位元組流以用於網路傳輸及將位元組流轉為對象的過程。序列化的優勢包括安全性更好、跨平台等。Dubbo基於netty進行網路通訊，NettyClient.doOpen()方法中可以看到Netty的相關類。序列化介麵包括但不限於：Serialization介面、Hessian2Serialization介面、Kryo介面、FST介面等。

序列化方式如Kryo和FST，性能往往優於hessian2，能夠顯著提高序列化性能。這些高效Java序列化方式的引入，可以優化Dubbo的序列化過程。

在配置Dubbo RPC時，引入Kryo和FST非常簡單，只需在RPC的XML配置中添加相應的屬性即可。

關於服務消費方發送請求，Dubbo框架定義了私有的RPC協議，消息頭和消息體分別用於存儲元信息和具體調用消息。消息頭包括魔數、數據包類型、消息體長度等。消息體包含調用消息，如方法名稱、參數列表等。請求編碼和解碼過程涉及編解碼器的使用，編碼過程包括消息頭的寫入、序列化數據的存儲以及長度的寫入。解碼過程則涉及消息頭的讀取、序列化數據的解析以及調用方法名、參數等信息的提取。

提供方接收請求後，服務調用過程包含請求解碼、調用服務以及返回結果。解碼過程在NettyHandler中完成，通過ChannelEventRunnable和DecodeHandler進一步處理請求。服務調用完成後，通過Invoker的invoke方法調用服務邏輯。響應數據的編碼與請求數據編碼過程類似，涉及數據包的構造與發送。

服務消費方接收調用結果後，首先進行響應數據解碼，獲得Response對象，並傳遞給下一個處理器NettyHandler。處理後，響應數據被派發到線程池中，此過程與服務提供方接收請求的過程類似。

在非同步通信場景中，Dubbo在通信層面為非同步操作，通信線程不會等待結果返回。默認情況下，RPC調用被視為同步操作。Dubbo通過CompletableFuture實現了非同步轉同步操作，通過設置非同步返回結果並使用CompletableFuture的get()方法等待完成。

對於非同步多線程數據一致性問題，Dubbo使用編號將響應對象與Future對象關聯，確保每個響應對象被正確傳遞到相應的Future對象。通過在創建Future時傳入Request對象，可以獲取調用編號並建立映射關系。線程池中的線程根據Response對象中的調用編號找到對應的Future對象，將響應結果設置到Future對象中，供用戶線程獲取。

為了檢測Client端與Server端的連通性，Dubbo採用雙向心跳機制。HeaderExchangeClient初始化時，開啟兩個定時任務：發送心跳請求和處理重連與斷連。心跳檢測定時任務HeartbeatTimerTask確保連接空閑時向對端發送心跳包，而ReconnectTimerTask則負責檢測連接狀態，當判定為超時後，客戶端選擇重連，服務端採取斷開連接的措施。

Ⅲ Dubbo 源碼淺析（一）—RPC 框架與 Dubbo | 京東雲技術團隊

RPC，遠程過程調用，是一種在本地調用遠程過程的技術，與之相對的是本地服務調用，即在程序內部進行的方法調用。RPC框架使得我們能像調用本地方法一樣方便地調用遠程服務，無需關心底層實現細節。它可以被認為是一種概念，實現方式可以是多種協議，如HTTP或自定義的TCP協議，例如Dubbo。

HTTP與RPC的關系並非直接包含，因為HTTP的調用方式並不直接調用遠程方法，而是通過HTTP請求進行數據傳輸。而RPC框架如Dubbo，提供了一種本地調用遠程方法的能力。因此，RPC並不局限於HTTP，還可以基於TCP協議實現。

思考RPC與HTTP的關系時，應當從定義出發，理解RPC實際上指的是遠程過程調用，其中「Procere」更多指的是程序或過程，而非方法。在理解概念時，不應忽略這一基本定義。RPC框架，如Dubbo，是為了簡化遠程服務調用的過程，提供了一套調用介面，使得開發者無需關注底層通信細節。

總體而言，RPC框架是幫助開發者在本地調用遠程服務時，如同調用本地服務一樣便捷。Dubbo是阿里巴巴開源的RPC框架，通過配置和簡單的調用，即可實現遠程服務的調用。Dubbo架構主要包含服務提供者和消費者，兩者通過注冊中心進行服務的注冊與訂閱。服務提供者啟動後向注冊中心注冊服務，消費者啟動後從注冊中心訂閱所需服務。注冊中心將服務信息推送給消費者，實現服務的調用。服務提供者與消費者會記錄調用次數與時間，並定時發送統計數據至監控中心。

相比之下，Spring Cloud作為另一大微服務框架，與Dubbo在組件配置和功能上有所不同。Spring Cloud提供了更完善的配置功能和更強的特性，更像一台品牌機，易於上手和使用。而Dubbo則更像組裝機，需要用戶自行選擇配置，提供核心計算能力，但需要用戶自行完成其他組件的裝配和調試。對於新手來說，Spring Cloud更友好，而對於熟悉架構的開發者，Dubbo的靈活性和自定義性更受歡迎。