Zookeeper+Dubbo安裝與搭建
（一）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項目導入形式導進去，然後更新項目