[[419843]]

前言

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

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

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

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

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

這波，這波啊我都明示了，老鐵們，點(diǎn)贊關(guān)注不迷路。

RPC和HTTP

RPC，Remote Procedure Call也就是遠(yuǎn)程過程調(diào)用，指的是計(jì)算機(jī)程序在不同的地址空間的調(diào)用，通常是不同的計(jì)算機(jī)，RPC是進(jìn)程間通信的一種形式，因?yàn)椴煌倪M(jìn)程具有不同的地址空間。

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

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

RPC和HTTP，傻傻分不清楚

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

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

HTTP的遠(yuǎn)程調(diào)用

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

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

RPC

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

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

RPC流程

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

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

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

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

Dubbo來源

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

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

1、服務(wù)越來越多，服務(wù)URL配置管理變得非常困難，單點(diǎn)壓力也越來越大

2、服務(wù)依賴關(guān)系逐漸復(fù)雜，甚至分不清哪個(gè)應(yīng)用要在哪個(gè)應(yīng)用之前啟動(dòng)

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

為了解決這由于架構(gòu)的演變所產(chǎn)生的問題幾個(gè)問題，于是，dubbo 產(chǎn)生了。當(dāng)然，解決這個(gè)問題的技術(shù)不止 dubbo。

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

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

Dubbo架構(gòu)

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

節(jié)點(diǎn)角色說明

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

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

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

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

這樣整個(gè)流程應(yīng)該就很清晰了吧！

Dubbo分層架構(gòu)

看下Dubbo的分層，來源于網(wǎng)絡(luò)，我們來看下它的架構(gòu)設(shè)計(jì)：

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

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

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

Dubbo服務(wù)暴露

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

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

Dubbo服務(wù)引用

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

Dubbo服務(wù)調(diào)用

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

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

SPI機(jī)制

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

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

這些問題我也會單獨(dú)開一篇SPI來講解，總之呢，大家讀懂這篇文章之后，關(guān)于RPC、HTTP、Dubbo這些技術(shù)點(diǎn)之間的關(guān)系，以及Dubbo的大體架構(gòu)這些，大家應(yīng)該都了解了一些了，關(guān)于上面這些沒有詳細(xì)介紹的點(diǎn)，我都會單獨(dú)拎出來說。

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