Nginx是著名的反向代理服務器，也被廣泛的作爲負載均衡服務器
ZooKeeper是分佈式協調服務框架，有時也被用來做負載均衡
那麼他們的區別是什麼？如何選擇呢？
下面從實際場景看下他們的關係
Nginx的負載均衡配置非常簡單，把多個web server配置到nginx中，用戶訪問Nginx時，就會自動被分配到某個web server
upstream backend {
server 192.168.1.10;
server 192.168.1.11;
當網站規模變大，通常會進行服務拆分，各個服務獨立部署，通過遠程調用方式協同工作
爲了保證穩定性，每個服務不會只使用一臺服務器，也會作爲一個集羣存在，那麼這個子集羣同樣需要一個負載均衡器，可以使用Nginx
到這裏還是沒有感覺有使用ZooKeeper的必要，因爲使用Nginx完全沒問題
但隨着整個系統的演進， 服務 的數量會 增加 、每個服務集羣中的 服務器 數量會增加
這時就會有一些小麻煩，例如
（1）配置維護的成本變高，因爲節點太多
（2）單點故障的風險增加了，因爲熱點服務的訪問量很高，如果這個服務集羣內的負載均衡服務出現問題，這個服務將失效
第一個問題，可以通過自己開發程序解決，但只是降低複雜度，並沒有實際解決
第二個問題，可以通過雙機高可用部署方案，使用另一臺nginx負載均衡服務器隨時待命，只是成本較高
爲了解決這些問題，就有人提出了使用ZooKeeper負載均衡的方案，之前就看到淘寶介紹過此類方案
ZooKeeper負載均衡的實現思路
把ZooKeeper作爲一個服務的註冊中心，在其中登記每個服務，每臺服務器知道自己是屬於哪個服務，在服務器啓動時，自己向所屬服務進行登記，這樣，一個樹形的服務結構就呈現出來了
服務的調用者到註冊中心裏面查找：能提供所需服務的服務器列表，然後自己根據負載均衡算法，從中選取一臺服務器進行連接
調用者取到服務器列表後，就可以緩存到自己內部，省得下次再取，當服務器列表發生變化，例如某臺服務器宕機下線，或者新加了服務器，ZooKeeper會自動通知調用者重新獲取服務器列表
由於ZooKeeper並沒有內置負載均衡策略，需要調用者自己實現，這個方案只是利用了ZooKeeper的樹形數據結構、watcher機制等特性，把ZooKeeper作爲服務的註冊和變更通知中心，解決了Nginx負載均衡方案帶來的問題