推薦學習

• 消息中間件合集：MQ(ActiveMQ/RabbitMQ/RocketMQ)+Kafka+筆記
• 肝了30天，整出這份[分布式寶典：限流+緩存+通訊]，秋招跳槽有望
• 一箭雙雕！Alibaba架構師，純手打Cloud+Boot微服務架構筆記

Dubbo

簡單的介紹一下Dubbo？(Dubbo是什么)

dubbo就是個服務調用的東東。

為什么怎么說呢？

因為Dubbo是由阿里開源的一個RPC分布式框架

那么RPC是什么呢？

就是不同的應用部署到不同的服務器上，應用之間想要調用沒有辦法直接調用，因為不在一個內存空間，需要通過網絡通訊來調用，或者傳達調用的數據。而且RPC會將遠程調用的細節隱藏起來，讓調用遠程服務像調用本地服務一樣簡單。

dubbo有哪些組件？

紫色虛線:在Dubbo啟動時完成的功能　　藍青色的線：都是程序運行過程中執行的功能，虛線是異步操作，實線是同步操作

• Provider：提供者，服務發布方。如果是采用SOA開發的模式，這個就是和數據庫交互的接口，也就是service主要放在生產者這邊
• Consumer：消費者，調用服務方。面向前端的Controller主要是在這邊，可以遠程調用生產者中的方法，生產者發生變化時也會實時更新消費者的調用列表。具體的看下面介紹
• Container：主要負責啟動、加載、運行服務提供者。Dubbo容器，依賴于Spring容器。這里比較注意的就是Dubbo是依賴與Spring容器的。所以必須要和Spring配合著使用
• Registry：注冊中心.當Container啟動時把所有可以提供的服務列表上Registry中進行注冊。作用：告訴Consumer提供了什么服務和服務方在哪里.
• Monitor:監控中心：監控中心負責統計各服務調用次數、調用時間

運行原理？

• 0.Start： 啟動容器,相當于在啟動Dubbo的Provider，并且會創建對應的目錄結構，例如代碼中的共用接口名為com.learnDubbo.demo.DemoService，就會創建 /dubbo/com.learnDubbo.demo.DemoService目錄，然后在創建providers目錄，再在providers目錄下寫入自己的 URL 地址。
• 1.Register：啟動后會去注冊中心進行注冊，注冊所有可以提供的服務列表。即訂閱/dubbo/com.learnDubbo.demo.DemoService 目錄下的所有提供者和消費者 URL 地址。
• 2.Subscribe：Consumer在啟動時，不僅僅會注冊自身到 …/consumers/目錄下，同時還會訂閱…/providers目錄，實時獲取其上Provider的URL字符串信息。當服務消費者啟動時：會在/dubbo/com.learnDubbo.demo.DemoService目錄創建/consumers目錄，并在/consumers目錄寫入自己的 URL 地址。
• 3.notify：當Provider有修改后，注冊中心會把消息推送給Consummer。也就是注冊中心會對Provider進行觀察，這里就是使用設計模式中的觀察者模式。以Zookeeper注冊中心為例，Dubbo中有ZookeeperRegistry中的doSubscribe方法也就是進行生產者訂閱和監聽。
• 4、invoke：根據獲取到的Provider地址，真實調用Provider中功能。這里就是唯一一個同步的方法，因為消費者要得到生產者傳來的數據才能進行下一步操作，但是Dubbo是一個RPC框架，RPC的核心就在于只能知道接口不能知道內部具體實現。所以在Consumer方使用了代理設計模式，創建一個Provider方類的一個代理對象，通過代理對象獲取Provider中真實功能，起到保護Provider真實功能的作用。
• 5、Monitor：Consumer和Provider每隔1分鐘向Monitor發送統計信息,統計信息包含,訪問次數,頻率等

Dubbo與SpringCould相比它為什么效率要高一些

首先看一下Dubbo支持什么協議？dubbo各種協議的性能對比：

thrift協議：

thrift原生協議性能表現卓越，是dubbo原生性能的6倍

dubbo協議：

定義：缺省協議、采用了單一長連接和NIO異步通訊、使用線程池并發處理請求，能減少握手和加大并發效率

適用范圍：傳入傳出參數數據包較小(建議小于100K)，消費者比提供者個數多，單一消費者無法壓滿提供者，盡量不要用dubbo協議傳輸大文件或超大字符串。適用場景：常規遠程服務方法調用

hession協議：定義：用于集成Hessian的服務，Hessian底層采用Http通訊，采用Servlet暴露服務，Dubbo缺省內嵌Jetty作為服務器實現適用范圍：傳入傳出參數數據包較大，提供者比消費者個數多，提供者壓力較大，可傳文件。適用場景：頁面傳輸，文件傳輸，或與原生hessian服務互操作。

案例測試：

可以看出dubbo通信的效率上高于SpringCould，那為什么會高于呢？

SpringCloud 服務間的通信方式有兩種

• RestTemplate 方式
• Feign 的方式

不管是什么方式，它都是通過REST接口調用服務的http接口，參數和結果默認都是通過jackson序列化和反序列化。

也就是說SpringCould是Http請求。

dubbo我們都知道是RPC分布式框架，默認是基于dubbo自定義的二進制協議進行傳輸，消息體比較簡單，傳輸數據要小很多。

案例測試：

結論：RPC請求的效率是HTTP請求的1.6倍左右，性能明顯比HTTP請求要高很多，因為HTTP協議包含大量的請求頭、響應頭信息。

Zookeeper

Zookeeper的實現原理？(工作原理)

Zookeeper會維護一個類似于標準的文件系統的具有層次關系的數據結構。這個文件系統中每個子目錄項都被稱為znode節點，這個znode節點也可以有子節點，每個節點都可以存儲數據，客戶端也可以對這些node節點進行getChildren，getData,exists方法，同時也可以在znode tree路徑上設置watch(類似于監聽)，當watch路徑上發生節點create、delete、update的時候，會通知到client。client可以得到通知后，再獲取數據，執行業務邏輯操作。Zookeeper 的作用主要是用來維護和監控存儲的node節點上這些數據的狀態變化，通過監控這些數據狀態的變化，從而達到基于數據的集群管理。

為什么要用zookeeper作為dubbo的注冊中心？能選擇其他的嗎？

Zookeeper的數據模型是由一系列的Znode數據節點組成，和文件系統類似。zookeeper的數據全部存儲在內存中，性能高；zookeeper也支持集群，實現了高可用；同時基于zookeeper的特性，也支持事件監聽(服務的暴露方發生變化，可以進行推送)，所以zookeeper適合作為dubbo的注冊中心區使用。redis、Simple也可以作為dubbo的注冊中心來使用。

項目中主要用zookeeper做了什么？(作用)

作為注冊中心用；主要是在服務器上搭建zookeeper，其次在spring管理的dubbo的配置文件中配置(暴露方和消費方都需要配置)

作者：java小丑

原文鏈接：https://blog.csdn.net/java_wxid/article/details/107029848

總結

以上是生活随笔為你收集整理的dubbo provider异步_Dubbo支持什么协议？与SpringCould相比它为什么效率要高一些？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。