帶著新人學springboot的應用12（springboot+Dubbo+Zookeeper 下）

　　上半節已經下載好了Zookeeper，以及新建了兩個應用provider和consumer，這一節我們就結合dubbo來測試一下分散式可不可以用。

　　現在就來簡單用一下，注意：這裡只是涉及最簡單的部分，新手入門用的，詳細的內容要學習的可以自己查一查資料;然後再說說用Zookeeper當作註冊中心的一個特點。

　　話說註冊中心是一個類似第三方軟體的東西，那麼我們能不能用Dubbo+其他註冊中心呢？其實也是可以的，比如redis，有興趣的可以查查資料自己試試，原理都差不多。

1.匯入依賴

      兩個模組都要匯入這兩個依賴（這兩個依賴千萬要正確，我就是因為自己匯入依賴導錯了，愣是找了好幾個小時最後才發現是依賴的問題，我匯入的組id是com.alibaba.spring.boot，太像了....細節細節！！！）

　　這裡有一些版本問題，我去官方文件截了一下圖，版本問題我也碰到了，還是官方文件靠譜！還有具體的版本對應我也截圖了，可以看看。

2.provider模組新建一個服務

　  說是建立一個服務，其實就是新建一個service層的介面，寫個實現

　　目錄結構以及介面+實現

　　配置檔案稍微配置一下，其實就是配置自己服務在哪裡，還有Zookeeper的位置及埠（Zookeeper可以是在其他電腦或者虛擬機器裡），其實還能配置很多東西，這裡列舉最簡單最實用的幾個；

　　可以嘗試啟動一下，沒報錯說明服務提供者完成！（那個Zookeeper服務端一定要開著）

3.consumer模組消費服務

　　說是消費服務，其實就是寫個controller，注入service介面，呼叫方法

　　看看consumer的目錄結構和controller內容

　　簡單配置一下配置檔案：

4.測試

　　首先保證Zookeeper服務端一直開著，然後執行服務提供者應用，然後再執行服務消費者應用，再到瀏覽器輸入url，結果如下：（應該列印服務提供者才對，訊息方面的東西看多了都打錯字了，問題不大，嘿嘿！）

5.簡要說說Zookeeper作為註冊中心的特點

　  服務註冊中心在分散式系統會大量運用，是分散式系統不可或缺的元件。

　　有需求就有利益，有利益就會有動力！正是因為服務註冊中心這麼重要，所以很多公司都注重這方面的研發，咳，比如rocketmq的NameServer，hdfs的Namenode，dubbo的Zookeeper，spring cloud的eureka，Consul等等。。

　　其中，對於這兩個：dubbo的Zookeeper，spring cloud的eureka之間，以及Dubbo和Spring Cloud之間哪種比較好的各種爭論，可謂是太多太多，各有各的說法，每個人都能舉出一大堆理論，對於我們來說，其實無所謂的，跟我們關係不大；就像問你hibernate和mybatis哪個好啊？只能說各有利弊吧！

　   不扯這麼遠了，說一個分散式系統的原理CAP：

　　絕大部分的分散式系統都會滿足一個叫做CAP理論的東西（當然也有很多爭議，暫且不提）

　　C（Consistency）：資料一致性，例如多臺伺服器中對於存的同一使用者的資料要一致

　　A（Availability）：可用性，無論怎麼了你都能訪問這個系統；例如其中一臺或幾臺伺服器掛掉了，你還是能夠正常使用，伺服器會響應成功（可能響應的是更新之前的資料），而不是一直在阻塞，這點比較關鍵

　　P（Partition Tolerance）：分割槽容錯性，就是當用戶在一臺伺服器修改了自己的資料，但是由於網路等問題，還沒有來得及同步到其他的伺服器，於是就產生了分割槽；怎樣解決分割槽問題是分散式系統不可避免的問題。

　　而我們說的Zookeeper選的是CP，而spring cloud的eureka選的是AP，那麼，到底是選CP好還是AP好呢？

　　不好說，只能是看什麼需求；

　　選P：選了這個才能支援分散式，才能進行橫向擴充套件。

　　選C：注重一致性，那就是要在多臺伺服器上資料要一致，假如伺服器同步資料的時候斷網了，那麼你就要一直等待了，直至同步成功；典型的是銀行轉賬系統，這對資料的一致性是十分苛刻的，一點都不能讓步，如果出錯，寧可停止服務；

　　選A：注重可用性，例如你更新自己的資料，然後伺服器之間同步資料的時候斷網了；那麼你再查詢，查詢的可能還是原來更新之前的資料，等待伺服器資料同步完成你才會查詢到最新資料； 網際網路公司用這個比較多，即使向用戶響應更新之前的資料也總比讓使用者一直等待要好得多。

　　可見，沒有什麼好不好，只有適不適合你的需求。

　　現在有個大概的瞭解就好，而且後面我可能會慢慢說說這兩個分散式框架Dubbo和Spring Cloud，話說這兩個分散式框架的爭論隨便查一下都有很多，千萬不要陷入其中，重要的我們學到了什麼東西！

　　Dubbo是阿里巴巴內部開發並使用，然後開源的一個很厲害的分散式框架，再加上很多阿里的人出來在其他公司工作推行了Dubbo的使用，雖然停止更新一段時間17年又恢復更新了，但是在國內估計還是基於Dubbo的分散式系統佔主流吧！（是不是主流我也不知道是不是，道聽途說而已）。

　　而Spring Cloud是Spring家族的一個分散式框架，裡面功能十分健全，可以說是一站式框架了，在國外的話估計名氣比Dubbo高。

　　要使用Dubbo還是Spring Cloud，看需要吧！孰好孰壞也不是我們該擔心的，ok，就到這裡吧！