注冊中心 ZooKeeper、Eureka、Consul 、Nacos

• CAP理論 一緻性 可用性 分區容錯性 三者隻能同時兩個 不可能三個兼顧 在分布式中必須保證P 是以隻看A和P
• ZK
  • 不能保證服務可用性
    • Leader選舉 時間過長30~120s
    • Zookeeper 叢集中半數以上伺服器節點不可用
  • 資料存儲
  • 不适用淘寶的雙十一，京東的618就是緊遵AP的最好參照
• Eureka
  • Peer to Peer 互相注冊
  • Eureka Server 将會登出該執行個體(預設為90秒 可配置)
  • Eureka Server 節點在短時間内丢失過多的心跳，節點進入自我保護模式
    • Eureka不再從系統資料庫中移除長時間沒收到心跳的服務
    • Eureka仍接受新服務注冊和查詢，但是不會被同步到其它節點上（即保證目前節點依然可用）
    • 當網絡穩定時，目前執行個體新注冊的資訊會被同步到其它節點中
  • Eureka的叢集中，隻要有一台Eureka還在，就能保證注冊服務可用，隻不過查到的資訊可能不是最新的
  • 适用淘寶的雙十一，京東的618就是緊遵AP的最好參照
• Consul
  • Go語言
  • Raft算法，比zookeeper使用的Paxos算法更加簡單
  • 服務注冊相比Eureka會稍慢一些。因為Consul的raft協定要求必須過半數的節點都寫入成功才認為注冊成功
  • Leader挂掉時，重新選舉期間整個consul不可用。保證了強一緻性但犧牲了可用性
• Nacos
  • 支援動态配置服務 Nacos = Spring Cloud注冊中心 + Spring Cloud配置中心