Zookeeper+Dubbo安裝與搭建（1）
（原創：黑小子-余）
（一）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安裝與部署？
鏈接跳轉 ：>點擊<-
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部署
鏈接跳轉： ->點擊<-
總結：文章很長，可能比較乏味，不過我都經過實踐的，看到這里，我相信，你多少對分布式、微服務的組件有一點點了解，其實了解它，學習他並不難，只是一個過程，需要最初自己的理解，長久堅持。我最初寫博客，也只是想對自己的理解做一個記錄，如果本文有不合格的地方，可以指正，三人行，必有我師！
qq：2931445528
-----------------------------------------------------------END----------------------------------------------------------------