Zookeeper分佈式服務架構是谷歌的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個爲分佈式應用提供一致性服務的軟件，提供的功能包括：配置維護、域名服務、分佈式同步、組服務等。
提出的問題:
-
是否可控(是排查，知道原因之後要能修復或規避)，出問題能夠快速解決。
-
是否可伸縮，加減服務實例的時候，不需要去配置。
-
能不能多個服務實例使用同一ID的時候，用於服務更新場景，能夠無縫切換。
-
這個服務本身不能成爲瓶頸，或者說它本身可以快速擴容。
-
能夠將對同一設備的請求，轉發到同一服務實例，這個是最重要也是這次討論的初衷。
實際上一般是用於 用於分佈式中一致性處理的框架 由於分佈式系統中一致性處理較爲困難，其他的分佈式系統沒有必要費勁重複造輪子，故隨後的分佈式系統中大量應用了zookeeper，以至於zookeeper成爲了各種分佈式系統的基礎組件(比如著名的分佈式架構: hadoop、kafka、dubbo 都是基於zookeeper而構建) 所以回答第一個問題:用戶使用的多,相應的資料與生態也想對的成熟,穩定性也是相對於其他分佈式比較穩定,發展與版本的迭代也很迅速。
問題二：加減服務實例是需要配置的serverID，去看paxos算法或者zab就知道需要配置！當前zk集羣是3臺，那麼選舉的大多數是2；如果加一臺，選舉的大多數就是3，如果是掛了一臺，當前zk集羣並不知道是掛了一臺 還是 集羣下掉一個節點，所以需要進行配置變更；
問題三：對於多個服務實例使用同一ID的時候，用於服務更新場景，能夠無縫切換這個是不可以的，ID是不可以重複的！
問題四：擴容問題：一般就3-7臺，就行了，太多的話強一致性，可用性會降低而且zk啓動後集羣就固定了，除非你、改配置文件後重啓纔行；
問題五:也是最關鍵zk能不能,將對同一設備的請求，轉發到同一服務實例，轉發是自己做的，比如dubbo的話應該是對應負載均衡這塊吧，invokers是當前註冊中心服務的服務實例，你就看怎麼挑或者乾脆用默認策略也行。
應用的場景：
1. 配置管理：在分佈式中很常見，同一個應用系統的多個服務由zk來修改配置等等；
2. 集羣管理：作爲“主管”知道當前集羣中每臺機器的服務狀態，一旦有機器不能提供服務，就做從新調整分配服務
3. 分佈式鎖，主要是因爲zk保證數據的強一致性，zookeeper的znode節點創建的唯一性和遞增性能保證所有來搶鎖的worker的原子性
結論：最簡單的方法就是第一次獲取到服務實例ID用個map存起來!
需求描述：
以上是討論的方案，實現的需求是實現一個動態的路由列表，讓兩個服務通信並且檢測服務是否在線實現無縫切換服務，現在有很多種服務（比如A和B），每種服務都有多個實例（比如A1，A2，B1，B2，B3）。服務間互相調用，現在要做的是提供一張可用的服務列表，A1獲取到這張列表就知道要去調用B2的接口，其中路由的選擇是由使用者決定。
引申出來的討論：
方案有兩種一：由使用者決定 ，路由管理只需要提供使用者所需的，在線服務信息即可但是中間如果服務掛了，再用另外一個一樣的服務信息來手動銜接；
二：路由的選擇是由路由決定就是動態分配和動態匹配，使用者只提供需要的服務即可，所以還是需要做到路由控制分配最佳；
後面決定使用方案一，不由使用者決定也是可以的，但這樣就是中心結點會特別複雜。比如，LOG是使用NS+KEY（log系統的）來決定這條日誌該分發到哪臺服務器去執行寫入；客戶端和會話其實最終是用它id來決定把會話和客戶端的數據給到哪臺broadcaster進行數據分發。
這類問題都是與具體業務相關的，作爲中間這個服務，它是無法爲那麼多的業務去訂製相應的分發算法的，每修改一個業務或增加，就得改一次，中心結點就是指分發的這個服務，如果只是要將請求分發到不同服務器，而不需要根據業務來指定，直接用阿里雲的SLB就可以了；
另外一種就是，把每一次請求對業務產生的變化都記到數據庫（或公共緩存），每一次新到請求時候都去從數據庫加載最新的狀態來執行後續操作，這種也可以。數據庫狀態拿到的狀態什麼的是需要重新計算；優點時挺好實現，缺點是會增加大量IO；
如果在服務實例內緩存，使用SLB，因爲SLB分發時候會有隨機性，那可能會造成在所有服務實例上都會有這個客戶端的數據緩存,那麼緩存也就失效了。所以就有了現在的方式，提供服務實例列表，由使用者決定（通常是約定，打包到庫裏）分發到哪裏，比如會話->播發或客戶端->播發，都使用station的Id來決定：services.getService(id)；
services.getService()這個方法提供一種或幾種分配的方式就可以了，由中心結點來分配，可以避免，但每個請求都要調用中心節點的接口來確定使用哪個服務實例，會增加IO；使用緩存+定期更新，也可以一定程度上優化，前提也是要知道約定是哪些信息作爲關鍵信息纔行，比如得知道下一步的服務使用id作爲分發關鍵字，才能去建這個緩存。所以又矛盾了，避免不了大量IO!