[[419843]]

前言

Docker這項技術其實大家或多或少都聽過的，或者是在你以往投簡歷的時候，劃水刷博客、刷論壇的時候，肯定也見到過這一門技術，你要是真的沒聽過也沒見過，去問百度，Dubbo這個技術應該大家都聽說過，有的公司可能項目用的也是Dubbo，這個技術面試應該也會屬于一個好手，會了Dubbo，關于RPC的調用也就懂個八九不離十了，網絡層面的很多知識點也就一并懂了不少了，總之，接下來呢，要開啟的Dubbo系列絕對會讓你受益匪淺，一起學習吧！

之前應該也寫過不少系列的文章了，我也將這些文章都已經收錄到我的https://github.com/DayuMM2021/Java文章網址中去了，這個網址中還包含不少代碼，包括設計模式示例、RocketMQ源碼解析、Dubbo源碼解析，以及后續的大數據分析等等。

這篇文章呢，主要就是帶領大家明白Dubbo的來源，作用以及架構設計，我們一般學習一個技術點首先要了解的就是該技術點的來源、做什么的，能夠解決哪些痛點問題，大致的架構和運轉流程是什么樣子的。

千萬不要上來直接死磕各種細節，各種源碼，否則直接自己把自己搞懵逼了。

你看了這篇文章之后，什么RPC調用啊，什么HTTP啊，這些都將不在話下，不過離徹底搞懂Dubbo還是差了點意思的，但是，只要你堅持的讀下去我的Dubbo系列文章，那你可就不一樣了。

這波，這波啊我都明示了，老鐵們，點贊關注不迷路。

RPC和HTTP

RPC，Remote Procedure Call也就是遠程過程調用，指的是計算機程序在不同的地址空間的調用，通常是不同的計算機，RPC是進程間通信的一種形式，因為不同的進程具有不同的地址空間。

如果在同一個主機上，即使物理地址空間是相同的，它們也具有不同的虛擬地址空間，如果位于不同的主機上，則物理地址空間肯定也會不同的，則虛擬地址空間也不會相同了。

遠程過程調用對標的是本地過程調用，本地過程調用大家應該都很熟悉的吧，你寫了一個簡單的Java程序，內部的方法的調用其實就是屬于本地過程的調用了，而遠程過程調用則指的是本地調用了遠程主機上的某個方法，這就是屬于遠程過程調用了。

RPC和HTTP，傻傻分不清楚

RPC和HTTP不是對等的概念，RPC呢，上面也解釋了，屬于一個完整的遠程調用鏈路，包括：接口規范+序列化反序列化規范+通信協議等，而HTTP只是屬于一個通信協議，屬于OSI的第七層，不是一個完整的遠程調用鏈路。

這就是屬于牛(HTTP)和馬車(RPC)的比較，要想比較，需要給牛一個工具，把它變成牛車!

HTTP的遠程調用

基于HTTP的遠程調用，HTTP+Restful，優勢比較大，可讀性好，使用這種方案會包含大量的HTTP頭信息，有用信息占比少，這種相對來說應該也是比較麻煩的，需要封裝各種參數名和參數值。

Restful屬于一種規范，就是一種動作加資源的規范，動作包含GET、POST、PUT、DELETE，資源呢，網絡中的一切都是屬于資源，這種規范就是對網絡中的資源進行各種操作，資源是Restful架構或者說是整個網絡處理的核心。

RPC

RPC呢，好處就是有用信息占比很高，效率呢也很高，調用起來也會很簡單，就像是調用本地服務一樣，沒有任何的感知，我們也不需要關心網絡傳輸或者通訊問題，HTTP其實也是屬于RPC實現的一種方式，RPC呢，就像是地區方言，只需要內部知道，雙方都需要知道方言，不然沒辦法溝通而已，HTTP就像是普通話，基本都能聽得懂。

RPC框架就是要實現小助手一樣的功能，目的就是讓我們使用遠程調用像本地調用一樣簡單方便，并且可以解決一些遠程調用會發生的各種問題，使我們開發人員可以無感知、舒服的開發，它好我也好，快樂無煩惱。

RPC流程

服務A調用服務B的過程對開發人員的感知仿佛是內部調用一樣，RPC要求在調用方中放置被調用的方法的接口，調用方只要調用了這些接口，就相當于調用了被調用方的實際方法，很簡單，調用方也可以像調用內部接口一樣調用遠程方法，不需要封裝參數名和參數值等操作。

服務A調用服首先，調用方調用的是接口，必須得為接口構造一個假的實現，顯然要使用動態代理，這樣，調用方的調用就被動態代理接受到了。

動態代理接受到調用之后，要想的就是調用遠程的實際實現，包括識別具體調用的遠程方法的IP和端口號、調用方法的入參序列化、將請求發送到遠程的方法中，遠程服務接收到調用方的請求之后的步驟，包括反序列化各個調用參數、定位到實際調用方法，然后輸入參數調用、按照調用的路徑返回調用的結果。

簡單的搞了一張圖，大家理解下：

Dubbo來源

很多時候，其實我們使用這個技術的時候，可能都是因為項目需要，所以，我們就用了，但是，至于為什么我們需要用到這個技術，可能自身并不是很了解的，但是，其實了解技術的來由及背景知識，對于理解一項技術還是有幫助的，那么，dubbo是怎么被提上日程的呢?

在互聯網的發展過程中，在以前，我們只需要一個服務器，將程序全部打包好就可以，但是，隨著流量的增大，常規的垂直應用架構已無法應對，所以，架構就發生了演變。逐漸的應用與應用之間的關系已經十分的復雜了，就會出現以下幾個問題：

1、服務越來越多，服務URL配置管理變得非常困難，單點壓力也越來越大

2、服務依賴關系逐漸復雜，甚至分不清哪個應用要在哪個應用之前啟動

3、服務調用量越來越大，服務的容量問題就會暴露，服務需要多少機器支撐，什么時候該加機器

為了解決這由于架構的演變所產生的問題幾個問題，于是，dubbo 產生了。當然，解決這個問題的技術不止 dubbo。

從上面 Dubbo 的服務治理圖我們就可以看到，Duboo 很好了解決了上面所出現的一些問題。

所以，當你的系統架構發展到了這種階段的時候，就需要考慮使用 Dubbo 了。

Dubbo架構

先來看一下官網放出的Dubbo的架構圖：

節點角色說明

上面那些是Dubbo的主要角色，接下來我們一起來說一下整體的流程，其實Dubbo的架構也是很簡單，為啥這樣說，你有沒有發現這其實很像生產者-消費者模型，只不過是在這個模型上，加上了注冊中心和監控中心而已，用于管理提供方的提供的URL，還有管理整個過程。

首先服務提供者Provider啟動然后向注冊中心注冊自己所能夠提供的服務，服務消費者Consumer啟動向注冊中心訂閱自己所需要調用的服務，然后注冊中心將提供相應的元信息給Consumer，隨后Consumer便通過負載均衡選擇一個Provider直接調用。

服務提供方的元數據如果變更的話，注冊中心會把變更信息推送給服務消費者。

服務提供者和消費者都會在內存中記錄調用的次數和時間，然后定時發送統計數據到監控中心用于監控。

這樣整個流程應該就很清晰了吧！

Dubbo分層架構

看下Dubbo的分層，來源于網絡，我們來看下它的架構設計：

大的層次呢，分為三層，分別是Business業務層、RPC傳輸和Remoting遠程，按照設計呢，又可以分為API層和SPI層，采用的是微內核設計+SPI擴展，使得有特殊需求的接入方式可以自定義擴展，做定制的二次開發。

我們一起來詳細的看下每一層的作用，千萬不要死記硬背，要適度的去理解即可。

• Service，服務接口層，和實際的邏輯業務有關，根據服務消費方和服務提供方的業務設計，實現對應的接口
• Config，對外配置層的接口，主要圍繞 ServiceConfig 和 ReferenceConfig，初始化配置信息。
• Register，服務注冊層，封裝了服務注冊和發現，以服務URL為中心，擴展接口為RegistryFactory、Registry、RegistryService，可能沒有服務注冊中心，服務提供方直接暴露服務
• Proxy，代理層，服務提供者還是消費者都會生成一個代理類，使得服務接口透明化，代理層做遠程調用和返回結果。
• Cluster，封裝多個提供者的路由和負載均衡，并且連接注冊中心，以Invoker為中心，將多個服務提供方組成為一個，實現對服務消費透明
• Monitor，監控層，負責監控統計RPC的調用時間和次數，以Statistics為中心。
• Portocol，遠程調用層，主要是封裝 RPC 調用以Invocation和Result為中心，擴展接口是Protocol、Invoker和Exporter，Protocol是服務接口，負責Invoker的生命周期管理;Invoker是實體，屬于Dubbo的核心模塊，代表一個可執行體。
• Exchange，信息交換層，用來封裝請求響應模型，同步轉異步，以Request和Response為中心。
• Transport，網絡傳輸層，以Message為中心，抽象成Mina和Netty，抽象了網絡傳輸的統一接口。
• Serialize，序列化層，將數據序列化成二進制流，當然也做反序列化，擴展接口是erialization。

Dubbo服務暴露

服務暴露就是將所要提供的服務暴露出來，你想啊，一個用戶服務模塊，需要對外提供一個注冊新用戶的功能，那你這個服務肯定要暴露出來啊，否則外部接口如何調用你這個服務啊！

大家先理解這個意思，這一塊我會單獨拎出來說，給大家看Dubbo的源碼。

Dubbo服務引用

引用呢，就是@Reference的使用了，使用過Dubbo的應該對這個注解都不陌生吧，在ReferenceConfirg中進行消息的訂閱，這個消息訂閱就是引用注冊表的invoke，并且也創建了一個netty客戶端用于交互。

Dubbo服務調用

調用這個invoker代理對象(就是自動注入的service)，在dubbo中客戶端調用的service是被多次代理后的一個對象，這其中有一個filter代理。

作用呢，就是使用dubbo的容錯，并通過負載均衡選擇使用注冊中心中的哪個服務，最終就是DubboInvoker對象中進行遠程調用，這個對象來獲取到相應的通道，通過模擬這個接口輸入的參數，通過request來進行請求，得到結果之后就會進行解析并且返回結果。

SPI機制

SPI 全稱為 (Service Provider Interface) ,是JDK內置的一種服務提供發現機制。目前有不少框架用它來做服務的擴展發現， 簡單來說，它就是一種動態替換發現的機制， 舉個例子來說， 有個接口，想運行時動態的給它添加實現，你只需要添加一個實現即可。

那為什么dubbo不用jdk的SPI呢，而是選擇自己去模仿實現一個呢！

這些問題我也會單獨開一篇SPI來講解，總之呢，大家讀懂這篇文章之后，關于RPC、HTTP、Dubbo這些技術點之間的關系，以及Dubbo的大體架構這些，大家應該都了解了一些了，關于上面這些沒有詳細介紹的點，我都會單獨拎出來說。

而且我還會帶著源碼給大家分析，你說你看完還能不會Dubbo，面試還怕問到Dubbo嗎？