zookeeper和dubbo安裝與搭建

• 2019 年 10 月 3 日
• 筆記

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—————————————————————-