[[419843]]

前言

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

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

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

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

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

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

RPC和HTTP

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

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

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

RPC和HTTP，傻傻分不清楚

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

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

HTTP的遠程調(diào)用

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

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

RPC

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

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

RPC流程

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

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

動態(tài)代理接受到調(diào)用之后，要想的就是調(diào)用遠程的實際實現(xiàn)，包括識別具體調(diào)用的遠程方法的IP和端口號、調(diào)用方法的入?yún)⑿蛄谢⒄埱蟀l(fā)送到遠程的方法中，遠程服務接收到調(diào)用方的請求之后的步驟，包括反序列化各個調(diào)用參數(shù)、定位到實際調(diào)用方法，然后輸入?yún)?shù)調(diào)用、按照調(diào)用的路徑返回調(diào)用的結果。

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

Dubbo來源

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

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

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

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

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

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

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

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

Dubbo架構

先來看一下官網(wǎng)放出的Dubbo的架構圖：

節(jié)點角色說明

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

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

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

服務提供者和消費者都會在內(nèi)存中記錄調(diào)用的次數(shù)和時間，然后定時發(fā)送統(tǒng)計數(shù)據(jù)到監(jiān)控中心用于監(jiān)控。

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

Dubbo分層架構

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

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

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

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

Dubbo服務暴露

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

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

Dubbo服務引用

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

Dubbo服務調(diào)用

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

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

SPI機制

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

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

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

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