1.概述
爲了解決公司系統單點壓力過載的問題，經過多次分析和借鑑當前主流的架構思想，決定使用分佈式協調應用框架Zookeeper進行現有系統代碼優化。
2.當前現狀分析
架構1.0– 線性模式：
存在問題：
1)中心節點過載:基於 B-Proxy 爲中心化的通訊轉發導致 B-Proxy 壓力過大
2) 單點故障：B-Proxy 存在單點故障，各個B模塊存在單點故障
架構2.0– 使用F5實現負載均衡
1)單點故障
2) 多路轉發 -- 負載均衡
存在問題:
1)仍然存在中心，F5作爲主中心, B-Proxy 作爲副中心。F5 性能比較可靠，B-Proxy的轉發工作量也被1分爲4,1分爲5.但依然是性能瓶頸。中心即爲瓶頸，並會存在潛在問題。
2)運維和升級操作複雜，擴展成本高，不可持續。增加處理性能需要擴展 B-Proxy和B模塊，性能提升依賴於硬件堆積，擴展成本高；模塊增多導致運維和升級操作成本和風險成倍提高。靠擴展硬件提升性能成本太高，並且模塊成倍增多，若不借助自動化運維工具，系統將變得不可維護。每次擴展和升級均需要配置F5服務器，也存在潛在風險。
3)現在缺乏依賴F5的心跳探測
現在系統監控依賴於 Negios , 服務轉發依賴於 F5，兩者沒有結合起來。
3.當前現狀分析
Ø 去中心化
去掉以 B-Proxy 爲中心的請求轉發，A 直接請求B模塊。服務請求者直接請求服務提供者。
Ø 動態擴展和高可用 (依賴於 Zookeeper 的監控(心跳檢測)結果作爲服務發現)
服務(提供者)啓動時實時被發現，動態擴展。服務Lost( 正常關閉、服務異常)時，實時更改可用服務列表，保持服務高可用。
Ø 配置共享
多服務分佈式集羣部署時，減少升級和日常運維的工作量。單點故障問題也會解決，負載均衡功能也會實現。
總結：
爲此我們選用了Zookeeper這種技術，除了如上特性Zookeeper自身可集羣部署，可通過內部機制保證各個節點內部狀態的一致性。保證了Zookeeper自身的穩定性。