單體架構到分布式集群架構帶來各種服務之間的呼叫，有直接http呼叫與rpc呼叫等
1.雖然現在服務間的呼叫越來越多地使用了 rpc 和訊息佇列，但是 http 依然有適合它的場景。
rpc 的優勢在於高效的網路傳輸模型（常使用 nio 來實現 netty等），以及針對服務呼叫場景專門設計協議和高效的序列化術。
2.http 的優勢在於它的成熟穩定、使用實現簡單、被廣泛支援、相容性良好、防火牆友好、訊息的可讀性高。所以 http 協議在開放 api、跨平台的服務間呼叫、對效能要求不苛刻的場景中有著廣泛的使用。
1-目標服務肯定會做擴容，擴容以後，客戶端會帶來一些變化
2-客戶端對於目標服務如何進行負載均衡
3-客戶端如何維護目標服務的位址資訊
4-服務端的服務狀態變化，如何讓客戶端盡心感知
服務註冊中心主要用於實現服務的註冊和服務的發現功能，在微服務架構中，它起到了非常大的作用。
註冊中心的實現：
dubbo 體系中的 zookeeper、 spring cloud 中的 eureka 和 consul
apache zookeeper 是乙個高可靠的分布式協調中介軟體。
zookeeper 的設計目標是將那些複雜且容易出錯的分布式一致性服務封裝起來，構成乙個高效可靠的原語集，並以一系列簡單易用的介面提供給使用者使用。
摘自《從paxos到zookeeper 》第四章第一節的某段內容：
在雅虎內部很多大型系統基本都需要依賴乙個類似的系統來進行分布式協調，但是這些系統往往都存在分布式單點問題。所以，雅虎的開發人員就試圖開發乙個通用的無單點問題的分布式協調框架，以便讓開發人員將精力集中在處理業務邏輯上。
zookeeper 是乙個典型的分布式資料一致性解決方案，分布式應用程式可以基於 zookeeper 實現諸如資料發布/訂閱、負載均衡、命名服務、分布式協調/通知、集群管理、master 選舉、分布式鎖和分布式佇列等功能。
zookeeper 乙個最常用的使用場景就是用於擔任服務生產者和服務消費者的註冊中心。服務生產者將自己提供的服務註冊到zookeeper中心，服務的消費者在進行服務呼叫的時候先到zookeeper中查詢服務，獲取到服務生產者的詳細資訊之後，再去呼叫服務生產者的內容與資料。
在分布式架構中，任何的節點都不能以單點的方式存在，因此我們需要解決單點的問題。常見的解決單點問題的方式就是集群
這個集群需要滿足：
-1. 集群中要有主節點和從節點（也就是集群要有角色）
-2. 集群要能做到資料同步，當主節點出現故障時，從節點能夠頂替主節點繼續工作，但是繼續工作的前提是資料必須要主節點保持一致
-3. 主節點掛了以後，從節點接替成為主節點
leader 伺服器是整個 zookeeper 集群的核心，主要的工作任務有兩項
-1. 事物請求的唯一排程和處理者，保證集群事物處理的順序性
-2. 集群內部各伺服器的排程者
follower 角色的主要職責是
-1. 處理客戶端非事物請求、**事物請求給 leader 伺服器
-2. 參與事物請求 proposal 的投票（需要半數以上伺服器通過才能通知 leader commit 資料;
leader 發起的提案，要求 follower 投票）
-3. 參與 leader 選舉的投票
observer 是 zookeeper3.3 開始引入的乙個全新的伺服器角色，
不參與任何形式的投票，包括事物請求 proposal 的投票和 leader 選舉的投票 ，
observer 伺服器只提供非事物請求服務，通常在於不影響集群事物處理能力的前提下提公升集群非事物處理的能力
當 leader 掛了，需要從其他 follower 節點中選擇乙個新的節點進行處理， 這個時候就需要涉及到 leader 選舉
zookeeper 是由 2n+1 臺 server 組成，每個 server 都知道彼此的存在。 每個 server 都維護的記憶體狀態映象以及持久化儲存的事務日誌和快照。
對於 2n+1 臺 server，因為只要有 n+1臺（過半數形成有效投票） server 可用，就整個系統保持可用 ，允許n臺掛掉
要滿足這樣的乙個高效能集群，應該每個節點都能接收到請求，並且每個節點的資料都必須要保持一致。要實現各個節點的資料一致性，就勢必要乙個 leader 節點負責協調和資料同步操作。
如果在這樣乙個集群中沒有 leader 節點，每個節點都可以接收所有請求，那麼這個集群的資料同步的複雜度是非常大
leader 節點要和其他節點保證資料一致性，並且要求是強一致的。
在分布式系統中，每乙個機器節點雖然都能夠明確知道自己進行的事務操作過程是成功和失敗，但是卻無法直接獲
取其他分布式節點的操作結果。
所以當乙個事務操作涉及到跨節點的時候，就需要用到分布式事務，分布式事務的資料一致性協議有 2pc 協議和 3pc 協議
2pc顧名思義分為兩個階段，其實施思路可概括為：
（1）投票階段（voting phase）：參與者（各節點）將操作結果通知協調者（leader）；
（2）提交階段（commit phase）：協調者（leader）收到參與者的通知後，協調者再根據各參與者（各節點）反饋情況決定各參與者是否要提交還是回滾；
-1. 啟動 zk 服務:
bin/zkserver.sh start
-2. 檢視 zk 服務狀態:
bin/zkserver.sh status
-3. 停止 zk 服務:
bin/zkserver.sh stop
-4. 重啟 zk 服務:
bin/zkserver.sh restart
-5. 連線伺服器
zkcli.sh -timeout 0 -r -server ip:port
一般情況下，在開發測試環境，沒有這麼多資源的情況下，而且也不需要特別好的穩定性的
前提下，我們可以使用單機部署；
初次使用 zookeeper，需要將 conf目錄下的zoo_sample.cfg 檔案 copy 乙份重新命名為 zoo.cfg修改 datadir 目錄， datadir 表示日誌檔案存放的路徑， 在新建的datadir目錄下，新建乙個myid檔案，就填寫為1
然後 bin/zkserver.sh start
在 zookeeper 集群中，各個節點總共有三種角色，分別是： leader， follower， observer
集群模式我們採用模擬 3 臺機器來搭建 zookeeper 集群。分別複製安裝包到三颱機器上並解
壓，同時 copy 乙份 zoo.cfg。
修改埠（知道彼此 1是誰 2是誰）
server.1=ip1:2888:3888 【2888：訪問 zookeeper 的埠； 3888：重新選舉 leader 的埠】
server.2=ip2.2888:3888
server.3=ip3.2888:2888
解釋：server.a=b:c:d
其中 a 是乙個數字，表示這個是第幾號伺服器；
b 是這個伺服器的 ip 位址；
c 表示的是這個伺服器與集群中的 leader 伺服器交換資訊的埠；
d 表示的是萬一集群中的 leader 伺服器掛了，需要乙個埠來重新進行選舉，選出乙個新的 leader，而這個埠就是用來執行選舉時伺服器相互通訊的埠。
在datadir所指定的目錄下建立乙個檔名為myid的檔案，檔案中的內容只有一行，為本主機對應的id值，也就是上步中的序號id
啟動：bin/zkserver.sh start
zookeeper知識整理
zookeeper 是什麼？zookeeper 是乙個分布式的，開放原始碼的分布式應用程式協調服務，是 google chubby 的開源實現，是 hadoop 和 hbase 的重要元件。它是乙個為分布式應用提供一致性服務的軟體，提供的功能包括 配置維護 網域名稱服務 分布式同步 組服務等。158...
zookeeper學習筆記一
源自google的chubby yahoo的實現，注就了我們有機會看到如此優秀的協作工具 zk.當我在看分布式系統的書籍時，同時在學習zk，可以進行比較分析，很好！感覺這東西的原理或多或少已經在早前某些專案上接觸到，只是沒有那麼具體和靈活。比如開發中遇到的索引同步問題,loadbalance切換se...
zookeeper學習筆記
zookeeper簡介 zookeeper是乙個為分布式應用程式提供高效能協調服務的工具集合，是著名的開源框架 hadoop的子專案，它可以應用在一些需要提供統一協調服務的任務中，例如命名 配置管理 同步和組服務等，而在分布式快取設計中，它被作為乙個協調分布式環境中各快取伺服器之間共享狀態資料的基礎...