一、spring cloud netflix
它主要提供的子產品包括：
服務發現注冊（eureka）
用戶端負載均衡（ribbon）
斷路器（hystrix）
智能路由（zuul）
開源位址：
http://netflix.github.io/
https://github.com/netflix
二、服務注冊和服務發現
調用關系說明：
1.服務提供者在啟動時，向注冊中心注冊自己提供的服務。
2.服務消費者在啟動時，向注冊中心訂閱自己所需的服務。
3.注冊中心傳回服務提供者位址給消費者。
4.服務消費者從提供者位址中調用消費者。
注意！ 下面的服務端指：注冊中心，用戶端指：提供者和消費者
三、如何使用eureka進行服務注冊和發現
1、服務端添加依賴
2、服務端添加配置
# server (eureka 預設端口為：8761)
# spring
# eureka
# 是否注冊到eureka
# 是否從eureka擷取注冊資訊
# eureka伺服器的位址（注意：位址最後面的 /eureka/ 這個是固定值）
3、服務端添加注解
4、用戶端添加依賴
5、用戶端添加配置
提供者
# server
消費者
6、用戶端添加注解
注意：
emergency! eureka may be incorrectly claiming instances are up when they're not. renewals are lesser than threshold and hence the instances are not being expired just to be safe.
分析：是由于eureka進入了保護模式。
在保護模式下，eureka server将會嘗試保護其服務系統資料庫中的資訊，暫時不會登出服務系統資料庫中的服務。
四、基本流程：
1、 最左邊的client（即服務提供者）發起us-east-1c注冊請求；
2、 eureka server叢集中的其他兩個node（us-east-1d和us-east-1e進行replicate複制）；
3、 圖下放的兩個client（即服務消費者）分别向三個server擷取注冊資訊及get registry。
五、和zookeeper的對比
1、分布式系統的cap理論：
一緻性（c）：所有的節點上的資料時刻保持同步。
可用性（a）：每個請求都能接受到一個響應，無論響應成功或失敗。
分區容錯性（p）：系統應該能持續提供服務，即使系統内部有消息丢失（分區）。
由于分區容錯性在是分布式系統中必須要保證的，是以我們隻能在a和c之間進行權衡。
在此zookeeper保證的是cp, 而eureka則是ap。
2、zookeeper保證cp
zookeeper是個 cp的，即任何時刻對zookeeper的通路請求能得到一緻的資料結果，同時系統對網絡分割具備容錯性、但是它不能保證每次服務請求的可用性(注：也就是在極端環境下，zookeeper可能會丢棄一些請求，消費者程式需要重新請求才能獲得結果)。
例如：當master節點因為網絡故障與其他節點失去聯系時，剩餘節點會重新進行leader選舉。問題在于，選舉leader的時間太長，30 ~ 120s, 且選舉期間整個zk叢集都是不可用的，這就導緻在選舉期間注冊服務癱瘓。
3、eureka保證ap
eureka看明白了這一點，是以在設計時就優先保證可用性。我們可以容忍注冊中心傳回的是幾分鐘以前的注冊資訊，但不能接受服務直接down掉不可用。也就是說，服務注冊功能對可用性的要求要高于一緻性。
如果eureka服務節點在短時間裡丢失了大量的心跳連接配接(注：可能發生了網絡故障)，那麼這個 eureka節點會進入“自我保護模式”，同時保留那些“心跳死亡”的服務注冊資訊不過期。此時，這個eureka節點對于新的服務還能提供注冊服務，對于“死亡”的仍然保留，以防還有用戶端向其發起請求。當網絡故障恢複後，這個eureka節點會退出“自我保護模式”。eureka的哲學是，同時保留“好資料”與“壞資料”總比丢掉任何資料要更好。
4、總結
eureka作為單純的服務注冊中心來說要比zookeeper更加“專業”，因為注冊服務更重要的是可用性，我們可以接受短期内達不到一緻性的狀況。
當然，這也要看具體的使用場景。