Zookeeper+Dubbo安裝與搭建

（原創：黑小子-餘）

本文有借鑑：https://www.cnblogs.com/UncleYong/p/10737119.html

（一）zookeeper是什麼？（動物園）

ZooKeeper是一種分散式協調服務，用於管理大型主機。在分散式環境中協調和管理服務是一個複雜的過程。ZooKeeper通過其簡單的架構和API解決了這個問題。ZooKeeper允許開發人員專注於核心應用程式邏輯，而不必擔心應用程式的分散式特性。ZooKeeper框架最初是在“Yahoo!"上構建的，用於以簡單而穩健的方式訪問他們的應用程式。 後來，Apache ZooKeeper成為Hadoop，HBase和其他分散式框架使用的有組織服務的標準。

首先我們來了解一下什麼是分散式，順便理清幾種結構：

分散式應用的優點：

l 可靠性  - 單個或幾個系統的故障不會使整個系統出現故障。

l 可擴充套件性  - 可以在需要時增加效能，通過新增更多機器，在應用程式配置中進行微小的更改，而不會有停機時間。

l 透明性  - 隱藏系統的複雜性，並將其顯示為單個實體/應用程式。

分散式應用的挑戰：

l 競爭條件 - 兩個或多個機器嘗試執行特定任務，實際上只需在任意給定時間由單個機器完成。例如，共享資源只能在任意給定時間由單個機器修改。

l 死鎖  - 兩個或多個操作等待彼此無限期完成。

l 不一致  - 資料的部分失敗。

1、單機結構

我想大家最最最熟悉的就是單機結構，一個系統業務量很小的時候所有的程式碼都放在一個專案中就好了，然後這個專案部署在一臺伺服器上就好了。整個專案所有的服務都由這臺伺服器提供。這就是單機結構。那麼，單機結構有啥缺點呢？我想缺點是顯而易見的，單機的處理能力畢竟是有限的，當你的業務增長到一定程度的時候，單機的硬體資源將無法滿足你的業務需求。此時便出現了叢集模式，往下接著看。

2、叢集結構

叢集模式其實很簡單，雖然在程式界把它吹得牛哄哄的，來看下面，初步理解。其實也就是在單機結構上做的演變。單機結構處理到達瓶頸的時候，你就把單機複製幾份，這樣就構成了一個“叢集”。叢集中每臺伺服器就叫做這個叢集的一個“節點”，所有節點構成了一個叢集。每個節點都提供相同的服務，那麼這樣系統的處理能力就相當於提升了好幾倍（有幾個節點就相當於提升了這麼多倍）。但問題是使用者的請求究竟由哪個節點來處理呢？最好能夠讓此時此刻負載較小的節點來處理，這樣使得每個節點的壓力都比較平均。要實現這個功能，就需要在所有節點之前增加一個“排程者”的角色，使用者的所有請求都先交給它，然後它根據當前所有節點的負載情況，決定將這個請求交給哪個節點處理。這個“排程者”有個牛逼了名字——負載均衡伺服器。叢集結構的好處：就是系統擴充套件非常容易。如果隨著你們系統業務的發展，當前的系統又支撐不住了，那麼給這個叢集再增加節點就行了。但是，當你的業務發展到一定程度的時候，你會發現一個問題——無論怎麼增加節點，貌似整個叢集效能的提升效果並不明顯了。這時候，你就需要使用微服務結構了。（

負載均衡的原理：一臺伺服器的處理能力只能達到每秒幾萬個到幾十萬個請求，無法在一秒鐘內處理上百萬個甚至更多的請求。但若能將多臺這樣的伺服器組成一個系統，並通過軟體技術將所有請求平均分配給所有伺服器處理，那麼這個系統完全擁有每秒鐘處理幾百萬甚至更多請求的能力。這就是負載均衡最初的設計思想。

負載均衡：負載均衡是由多臺伺服器一對稱的方式組成一個伺服器集合，每臺伺服器都具有等價的地位，都可以單獨對外提供服務而無須其他伺服器的輔助。通過某種負載分擔的技術，將外部發送來的請求均勻分配到堆成結構中的某一臺伺服器上，而接收到請求的伺服器獨立的迴應客戶的的請求。負載均衡能夠平均奉陪客戶請求到伺服器的叢集上，來快速獲取重要的資料，解決高併發訪問服務問題。負載均衡的手段：軟/硬體負載均衡。軟負載均衡：通過在一臺或者多臺伺服器響應的作業系統上安裝一個或附加軟體來實現。硬體負載均衡：直接在伺服器的外部和外部網路間安裝負載均衡硬體裝置。

比喻列子：小飯店原來只有一個廚師，切菜洗菜備料炒菜全乾，後來客人多了，廚房一個廚師忙不過來，又請了一個廚師，兩個廚師都炒一樣的菜，這兩個廚師的關係是叢集，為了讓廚師專心炒菜，把菜做到極致，又請了個配菜師負責切菜，備菜，備料，廚師和配菜師的關係是分散式，一個配菜師也忙不過來，又請了一個配菜師，這兩個配菜師的關係是叢集。分散式講究的是協作，一個事件的發生可以觸發多個事件同時進行不同的業務運算。而叢集中的成員功能是一樣的。

ZooKeeper的好處：

以下是使用ZooKeeper的好處：

l 簡單的分散式協調過程

l 同步  - 伺服器程序之間的相互排斥和協作。此過程有助於Apache HBase進行配置管理。

l 有序的訊息

l 序列化  - 根據特定規則對資料進行編碼。確保應用程式執行一致。這種方法可以在MapReduce中用來協調佇列以執行執行的執行緒。

l 可靠性

l 原子性  - 資料轉移完全成功或完全失敗，但沒有事務是部分的。

（二）zookeeper用來做什麼？

應用場景1：統一命名服務

簡單點來說，就是偽分散式系統提供一套完整的命名規則。既能產生唯一的名稱又便於讓人識別和記住。

應用場景2：配置管理

通過zookeeper達到統一的配置檔案管理，將配置檔案儲存在zookeeper的某個目錄節點中，然後將所有需要修改的應用及其監控配置資訊的狀態（也就是用上面我們說到的watcher）。一旦配置檔案發生變化，每臺機器就會收到zookeeper的通知。然後從zookeeper獲取到最新的配置資訊應用到系統中。

應用場景3：叢集管理

如果有多臺server組成的一個服務叢集，那麼必須要一個“總管”知道當前叢集中每臺機器的服務狀態，一旦有機器不能提供服務，叢集中的其他機器必須知道，同樣當增加一臺或多臺server，同樣也必須讓“總管知道”，從而做出調整重新分配服務策略。Zookeeper不僅能維護當前叢集中機器的服務狀態，而且能夠選出一個“總管”，讓這個總管來管理叢集。

應用場景4：資料釋出/訂閱（其實也就是dubbo的註冊中心）

資料釋出/訂閱系統，就是將資料釋出到ZooKeeper的一個或一系列節點上，供訂閱者進行資料訂閱，從而達到動態獲取資料的目的。釋出/訂閱系統一般有兩種設計模式，分別是推（Push）和拉（Pull）。ZooKeeper中採用的是推拉介面的方式：客戶端向服務端註冊自己需要關注的節點，一旦該節點資料發生變更，服務端就會向相應的客戶端傳送Watcher事件通知，客戶端收到這個訊息後，需要主動到服務端獲取最新的資料。

應用場景5：負載均衡

在分散式系統中，負載均衡是一種普遍的技術。ZooKeeper作為一個叢集，負責資料的儲存以及一系列分散式協調。所有的請求，會通過ZooKeeper通過一些排程策略去協調排程哪一臺伺服器。

（三）zookeeper安裝與部署？

（一）去官網下載

（2）先說windows系統安裝，注意首先要確認java環境是否配置

1、解壓到你的磁碟，開啟目錄檔案並建立一個logs資料夾

2、進入config目錄，將zoo_sample.cfg複製一份，並重命名zoo_sample.cfg為zoo.cfg，並進到zoo.cfg裡面去修改一些東西，這要是日誌目錄和埠

3、進入bin目錄，啟動服務端

4、進入bin目錄，啟動客戶端

Dubbo

（1）Dubbo是什麼？

Dubbo是阿里巴巴公司開源的一個高效能優秀的服務框架，使得應用可通過高效能的 RPC（遠端呼叫） 實現服務的輸出和輸入功能，可以和 Spring框架無縫整合。Dubbo是一款高效能、輕量級的開源Java RPC框架，它提供了三大核心能力：面向介面的遠端方法呼叫，智慧容錯和負載均衡，以及服務自動註冊和發現。

在這裡插播一條關於RPC的簡介：

RPC(Remote Procedure Call Protocol)：遠端過程呼叫：

兩臺伺服器A、B，分別部署不同的應用a,b。當A伺服器想要呼叫B伺服器上應用b提供的函式或方法的時候，由於不在一個記憶體空間，不能直接呼叫，需要通過網路來表達呼叫的語義傳達呼叫的資料。

說白了，就是你在你的機器上寫了一個程式，我這邊是無法直接呼叫的，這個時候就出現了一個遠端服務呼叫的概念。

主要核心元件：

Remoting: 網路通訊框架，實現了 sync-over-async 和request-response 訊息機制。

RPC: 一個遠端過程呼叫的抽象，支援負載均衡、容災和叢集功能。

Registry: 服務目錄框架用於服務的註冊和服務事件釋出和訂閱。

工作原理：

Provider：暴露服務方稱之為“服務提供者”。

Consumer：呼叫遠端服務方稱之為“服務消費者”。

Registry：服務註冊與發現的中心目錄服務稱之為“服務註冊中心”。

Monitor：統計服務的呼叫次數和呼叫時間的日誌服務稱之為“服務監控中心”。

Conrainer：服務執行容器。

(1) 連通性：

註冊中心負責服務地址的註冊與查詢，相當於目錄服務，服務提供者和消費者只在啟動時與註冊中心互動，註冊中心不轉發請求，壓力較小

監控中心負責統計各服務呼叫次數，呼叫時間等，統計先在記憶體彙總後每分鐘一次傳送到監控中心伺服器，並以報表展示

服務提供者向註冊中心註冊其提供的服務，並彙報呼叫時間到監控中心，此時間不包含網路開銷

服務消費者向註冊中心獲取服務提供者地址列表，並根據負載演算法直接呼叫提供者，同時彙報呼叫時間到監控中心，此時間包含網路開銷

註冊中心，服務提供者，服務消費者三者之間均為長連線，監控中心除外

註冊中心通過長連線感知服務提供者的存在，服務提供者宕機，註冊中心將立即推送事件通知消費者

註冊中心和監控中心全部宕機，不影響已執行的提供者和消費者，消費者在本地快取了提供者列表

註冊中心和監控中心都是可選的，服務消費者可以直連服務提供者

(2) 健壯性：

監控中心宕掉不影響使用，只是丟失部分取樣資料

資料庫宕掉後，註冊中心仍能通過快取提供服務列表查詢，但不能註冊新服務

註冊中心對等叢集，任意一臺宕掉後，將自動切換到另一臺

註冊中心全部宕掉後，服務提供者和服務消費者仍能通過本地快取通訊

服務提供者無狀態，任意一臺宕掉後，不影響使用

服務提供者全部宕掉後，服務消費者應用將無法使用，並無限次重連等待服務提供者恢復

(3) 伸縮性：

註冊中心為對等叢集，可動態增加機器部署例項，所有客戶端將自動發現新的註冊中心

服務提供者無狀態，可動態增加機器部署例項，註冊中心將推送新的服務提供者資訊給消費者

（2）Dubbo部署

1、原始碼下載http://dubbo.apache.org/en-us/blog/download.html

2、下載完成後解壓，並通過Eclipse中Maven專案匯入形式導進去，然後更新專案

https://www.cnblogs.com/lionsblog/p/7767379.html

總結：文章很長，可能比較乏味，不過我都經過實踐的，看到這裡，我相信，你多少對分散式、微服務的元件有一點點了解，其實瞭解它，學習他並不難，只是一個過程，需要最初自己的理解，長久堅持。我最初寫部落格，也只是想對自己的理解做一個記錄，如果本文有不合格的地方，可以指正，三人行，必有我師！

qq：2931445528

-----------------------------------------------------------END----------------------------------------------------------------

&n