一、介紹
eureka 和zookeeper（zk） 是我經常接觸到的兩個常見的註冊中心中間件。一般情況，springcloud 項目都會用eureka做爲註冊中心，kafka用zk做爲數據元數據管理和註冊中心。
二、對比
- 集羣結構：
zk是leader follower主從結構，leader節點纔可以進行寫操作，follower負責同步數據和讀：
eureka是peer對等架構，所有eureka節點是對等的，每個節點都可以進行數據讀寫。
2.數據一致性：
eureka 是ap架構，保證註冊中心高可用，但不保證多個節點之間數據一致性，他只能保證服務列表在多個節點的最終一致 性
zk是cp結構，cp保證保證數據一致性，leader節點寫完數據，立刻會同步到follower節點，過半數節點寫成功之後纔算寫數 據 成功。但是當leader節點掛了，整個zk集羣是不可用的，必須等到重新選舉leader節點之後纔可以提供服務。
3.時效性：
zk時效性最好，服務實例掛了之後，zk會立刻通知其他服務實例，其他服務實例會在很快的時間感知並把不可用實列剔除 調，
eureka時效性很差， 服務實例默認30秒發送一次心跳請求，eureka檢查心跳時間，超過120m,才認爲服務實例掛了，消費 者服務實例默認每30秒去eureka拉去一次服務列表，這樣從某服務實例掛了到其他服務實例感知到，時間太長了。
4.網絡通信：
zk 使用的是nio，reactor網絡模型，網絡併發能力很高
eurek使用的是http協議,相對網絡能力差一點。
5.性能問題：
服務實例達到幾千臺，zk和eureka 都會有一定性能壓力。
對於zk,有新的服務實例加入，zk就要通知到其它所有幾千臺實例（羊羣效應），這樣短時間流量很大，網絡IO壓力大。可以這樣解決： 1.部署多個zk集羣，有相互調用的服務實例可以向相同的zk集羣註冊，如果調用的服務實例在其他zk集羣，可以註冊監聽器到對於的zk集羣（複雜度較高），2.借鑑kafka，kafka使用了kafkacontroller進行集羣管理，只有持有leader controller 節點監聽服務列表，如果發現節點變更，該節點再通知其他節點主動更新服務列表
對於Eureka 也不支持大規模節點，每個eureka註冊節點，還要通知其他eureka。這個也可以採取上面第一種方式處理。