建站
咨詢
售后
建站咨詢
新聞中心
前言
Docker這項技術(shù)其實大家或多或少都聽過的，或者是在你以往投簡歷的時候，劃水刷博客、刷論壇的時候，肯定也見到過這一門技術(shù)，你要是真的沒聽過也沒見過，去問百度，Dubbo這個技術(shù)應該大家都聽說過，有的公司可能項目用的也是Dubbo，這個技術(shù)面試應該也會屬于一個好手，會了Dubbo，關(guān)于RPC的調(diào)用也就懂個八九不離十了，網(wǎng)絡層面的很多知識點也就一并懂了不少了，總之，接下來呢，要開啟的Dubbo系列絕對會讓你受益匪淺，一起學習吧！
青白江網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)建站！從網(wǎng)頁設計、網(wǎng)站建設、微信開發(fā)、APP開發(fā)、成都響應式網(wǎng)站建設等網(wǎng)站項目制作，到程序開發(fā)，運營維護。創(chuàng)新互聯(lián)建站成立與2013年到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設就選創(chuàng)新互聯(lián)建站。
之前應該也寫過不少系列的文章了，我也將這些文章都已經(jīng)收錄到我的https://github.com/DayuMM2021/Java文章網(wǎng)址中去了，這個網(wǎng)址中還包含不少代碼，包括設計模式示例、RocketMQ源碼解析、Dubbo源碼解析，以及后續(xù)的大數(shù)據(jù)分析等等。
這篇文章呢，主要就是帶領(lǐng)大家明白Dubbo的來源，作用以及架構(gòu)設計，我們一般學習一個技術(shù)點首先要了解的就是該技術(shù)點的來源、做什么的，能夠解決哪些痛點問題，大致的架構(gòu)和運轉(zhuǎn)流程是什么樣子的。
千萬不要上來直接死磕各種細節(jié)，各種源碼，否則直接自己把自己搞懵逼了。
你看了這篇文章之后，什么RPC調(diào)用啊，什么HTTP啊，這些都將不在話下，不過離徹底搞懂Dubbo還是差了點意思的，但是，只要你堅持的讀下去我的Dubbo系列文章，那你可就不一樣了。
這波，這波啊我都明示了，老鐵們，點贊關(guān)注不迷路。
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架構(gòu)或者說是整個網(wǎng)絡處理的核心。
RPC
RPC呢，好處就是有用信息占比很高，效率呢也很高，調(diào)用起來也會很簡單，就像是調(diào)用本地服務一樣，沒有任何的感知，我們也不需要關(guān)心網(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)用的是接口，必須得為接口構(gòu)造一個假的實現(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)用的結(jié)果。
簡單的搞了一張圖，大家理解下：
Dubbo來源
很多時候，其實我們使用這個技術(shù)的時候，可能都是因為項目需要，所以，我們就用了，但是，至于為什么我們需要用到這個技術(shù)，可能自身并不是很了解的，但是，其實了解技術(shù)的來由及背景知識，對于理解一項技術(shù)還是有幫助的，那么，dubbo是怎么被提上日程的呢?
在互聯(lián)網(wǎng)的發(fā)展過程中，在以前，我們只需要一個服務器，將程序全部打包好就可以，但是，隨著流量的增大，常規(guī)的垂直應用架構(gòu)已無法應對，所以，架構(gòu)就發(fā)生了演變。逐漸的應用與應用之間的關(guān)系已經(jīng)十分的復雜了，就會出現(xiàn)以下幾個問題：
1、服務越來越多，服務URL配置管理變得非常困難，單點壓力也越來越大
2、服務依賴關(guān)系逐漸復雜，甚至分不清哪個應用要在哪個應用之前啟動
3、服務調(diào)用量越來越大，服務的容量問題就會暴露，服務需要多少機器支撐，什么時候該加機器
為了解決這由于架構(gòu)的演變所產(chǎn)生的問題幾個問題，于是，dubbo 產(chǎn)生了。當然，解決這個問題的技術(shù)不止 dubbo。
從上面 Dubbo 的服務治理圖我們就可以看到，Duboo 很好了解決了上面所出現(xiàn)的一些問題。
所以，當你的系統(tǒng)架構(gòu)發(fā)展到了這種階段的時候，就需要考慮使用 Dubbo 了。
Dubbo架構(gòu)
先來看一下官網(wǎng)放出的Dubbo的架構(gòu)圖：
節(jié)點角色說明
| 節(jié)點 | 角色說明 |
|---|---|
| Provider | 暴露服務的服務提供方 |
| Consumer | 調(diào)用遠程服務的服務消費方 |
| Registry | 服務注冊與發(fā)現(xiàn)的注冊中心 |
| Monitor | 統(tǒng)計服務的調(diào)用次數(shù)和調(diào)用時間的監(jiān)控中心 |
| Container | 服務運行容器 |
上面那些是Dubbo的主要角色，接下來我們一起來說一下整體的流程，其實Dubbo的架構(gòu)也是很簡單，為啥這樣說，你有沒有發(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分層架構(gòu)
看下Dubbo的分層，來源于網(wǎng)絡，我們來看下它的架構(gòu)設計：
大的層次呢，分為三層，分別是Business業(yè)務層、RPC傳輸和Remoting遠程，按照設計呢，又可以分為API層和SPI層，采用的是微內(nèi)核設計+SPI擴展，使得有特殊需求的接入方式可以自定義擴展，做定制的二次開發(fā)。
我們一起來詳細的看下每一層的作用，千萬不要死記硬背，要適度的去理解即可。
- Service，服務接口層，和實際的邏輯業(yè)務有關(guān)，根據(jù)服務消費方和服務提供方的業(yè)務設計，實現(xiàn)對應的接口
- Config，對外配置層的接口，主要圍繞 ServiceConfig 和 ReferenceConfig，初始化配置信息。
- Register，服務注冊層，封裝了服務注冊和發(fā)現(xiàn)，以服務URL為中心，擴展接口為RegistryFactory、Registry、RegistryService，可能沒有服務注冊中心，服務提供方直接暴露服務
- Proxy，代理層，服務提供者還是消費者都會生成一個代理類，使得服務接口透明化，代理層做遠程調(diào)用和返回結(jié)果。
- 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)用你這個服務?。?/p>
大家先理解這個意思，這一塊我會單獨拎出來說，給大家看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來進行請求，得到結(jié)果之后就會進行解析并且返回結(jié)果。
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來講解，總之呢，大家讀懂這篇文章之后，關(guān)于RPC、HTTP、Dubbo這些技術(shù)點之間的關(guān)系，以及Dubbo的大體架構(gòu)這些，大家應該都了解了一些了，關(guān)于上面這些沒有詳細介紹的點，我都會單獨拎出來說。
而且我還會帶著源碼給大家分析，你說你看完還能不會Dubbo，面試還怕問到Dubbo嗎？
新聞標題：我們一起跟著Dubbo起飛
轉(zhuǎn)載來源：http://www.5511xx.com/article/cdidsoe.html
