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的配置文件中配置（暴露方和消費方都需要配置）