Nginx/ZooKeeper 負載均衡的差異

Nginx是著名的反向代理伺服器，也被廣泛的作為負載均衡伺服器

ZooKeeper是分散式協調服務框架，有時也被用來做負載均衡

那麼他們的區別是什麼？如何選擇呢？

下面從實際場景看下他們的關係

Nginx是著名的反向代理伺服器，也被廣泛的作為負載均衡伺服器

ZooKeeper是分散式協調服務框架，有時也被用來做負載均衡

那麼他們的區別是什麼？如何選擇呢？

下面從實際場景看下他們的關係

Nginx的負載均衡配置非常簡單，把多個web server配置到nginx中，使用者訪問Nginx時，就會自動被分配到某個web server

upstream backend {
  server 192.168.1.101;
  server 192.168.1.111;
}



當網站規模變大，通常會進行服務拆分，各個服務獨立部署，通過遠端呼叫方式協同工作



為了保證穩定性，每個服務不會只使用一臺伺服器，也會作為一個叢集存在，那麼這個子叢集同樣需要一個負載均衡器，可以使用Nginx



到這裡還是沒有感覺有使用ZooKeeper的必要，因為使用Nginx完全沒問題

但隨著整個系統的演進，服務的數量會增加、每個服務叢集中的伺服器數量會增加



這時就會有一些小麻煩，例如

（1）配置維護的成本變高，因為節點太多

（2）單點故障的風險增加了，因為熱點服務的訪問量很高，如果這個服務叢集內的負載均衡服務出現問題，這個服務將失效

第一個問題，可以通過自己開發程式解決，但只是降低複雜度，並沒有實際解決

第二個問題，可以通過雙機高可用部署方案，使用另一臺nginx負載均衡伺服器隨時待命，只是成本較高

為了解決這些問題，就有人提出了使用ZooKeeper負載均衡的方案，之前就看到淘寶介紹過此類方案

ZooKeeper負載均衡的實現思路

把ZooKeeper作為一個服務的註冊中心，在其中登記每個服務，每臺伺服器知道自己是屬於哪個服務，在伺服器啟動時，自己向所屬服務進行登記，這樣，一個樹形的服務結構就呈現出來了




服務的呼叫者到註冊中心裡面查詢：能提供所需服務的伺服器列表，然後自己根據負載均衡演算法，從中選取一臺伺服器進行連線

呼叫者取到伺服器列表後，就可以快取到自己內部，省得下次再取，當伺服器列表發生變化，例如某臺伺服器當機下線，或者新加了伺服器，ZooKeeper會自動通知呼叫者重新獲取伺服器列表

由於ZooKeeper並沒有內建負載均衡策略，需要呼叫者自己實現，這個方案只是利用了ZooKeeper的樹形資料結構、watcher機制等特性，把ZooKeeper作為服務的註冊和變更通知中心，解決了Nginx負載均衡方案帶來的問題