1.前言
上一章描述了現有系統架構的模式和改造方向，本章節主要描述改造的基本方案和相關問題描述。
2.改造方案
基本流程:
1) 服務提供者B啓動到Zookeeper服務器處進行註冊;
2) 服務消費者A啓動時，請求Zookeeper服務器獲取最新的B服務存活列表，並保存到本地緩存中;
3)A請求B服務器時，根據緩存中的B服務器列表，隨機選取一個進行請求。
服務變動:
1) 當B出現異常或人工關閉不能提供服務時，Zookeeper服務器某個節點會探測到B節點的變化，更新本節點B服務器列表；
2) Zookeeper內部節點進行數據同步；
3) 服務消費者A監聽到B服務列表的變化，更新本地緩存。
自動重發機制:
B服務掛掉到A緩存更新大約需要3-5s的時間（根據網絡環境不同還需仔細測試）。爲了保證服務的實時可用，A請求B發生異常時，需要根據服務消費報錯信息，處理特定異常進行自動重發。
3. 存在風險和問題
1) 服務發現速度慢的問題，上述描述服務延遲問題。
2) Zookeeper 作爲服務發現存在的問題
在分佈式系統領域有個著名的CAP定理（C-數據一致性；A-服務可用性；P-服務對網絡分區故障的容錯性，這三個特性在任何分佈式系統中不能同時滿足，最多同時滿足兩個）。
ZooKeeper是個CP的，即任何時刻對ZooKeeper的訪問請求能得到一致的數據結果，同時系統對網絡分割具備容錯性；但是它不能保證每次服務請求的可用性（注：也就是在極端環境下，ZooKeeper可能會丟棄一些請求，消費者程序需要重新請求才能獲得結果）。但是別忘了，ZooKeeper是分佈式協調服務，它的職責是保證數據（注：配置數據，狀態數據）在其管轄下的所有服務之間保持同步、一致；所以就不難理解爲什麼ZooKeeper被設計成CP而不是AP特性的了，如果是AP的，那麼將會帶來恐怖的後果（注：ZooKeeper就像交叉路口的信號燈一樣，你能想象在交通要道突然信號燈失靈的情況嗎？）。而且，作爲ZooKeeper的核心實現算法Zab，就是解決了分佈式系統下數據如何在多個服務之間保持同步問題的。
參考:
爲什麼不應該使用Zookeeper做服務發現 http://dockone.io/article/78
Ribbon和Eureka的集成使用 http://blog.csdn.net/defonds/article/details/38016301
3) Zookeeper不是爲高可用性設計的
4) Zookeeper的選舉過程速度很慢
5) Zookeeper的性能是有限的
4 制定回滾方案
初步使用Zookeeper時，要考慮Zookeeper使用和現在架構的切換。實現更改程序配置進行 使用Zookeeper和F5之間的切換。
Q&A
1) 中心化B-Proxy存在的意義
中心化的B-Proxy使用代理模式實現，B模塊的改變對於上層服務是不可見的，降低了系統的耦合度。
模塊的增加、刪除無需修改上層服務請求者。但交易量過大時需要考慮B-Proxy的負載問題。
2) 當Zookeeper服務和B之間通訊全部異常，Zookeeper監聽到的可用服務爲零的時候，服務請求端如何容錯。
服務請求者需要配置除Zookeeper之外特定的一個服務提供者地址，該服務不受Zookeeper監控。
當Zookeeper監控的服務列表由於某種情況全部掛掉之後，服務請求者判斷可用列表爲空時自動請求該固定的服務提供者（backup）。
要求服務提供者需要配置開關，開關開啓請求Zookeeper，開關關閉不請求Zookeeper。
