1. Spring Cloud Netflix
Spring Cloud Netflix 是Spring Cloud 的核心子項目，是對Netflix公司一系列開源產品的封裝。它為Spring Boot應用提供了自動配置的整合，只需要通過一些簡單的注解，就可以快速的在Spring Cloud應用中使用。
它主要提供以下模塊：
服務發現和注冊（Eureka）
客戶端負載均衡（Ribbon)
斷路由（Hystrix)
只能路由（Zuul)
2. 服務注冊和發現（Eureka）
調用關系圖：
服務注冊和發現的具體實現：
新建一個服務端（注冊中心）工程，引入依賴。
pom文件：
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId> </dependency>
在工程啟動類上加上@EnableEurekaServer注解，配置application.properties文件
# server (eureka 默認端口為：8761)
server.port=8761 # spring spring.application.name=spring-cloud-server # eureka # 是否注冊到eureka eureka.client.register-with-eureka=false # 是否從eureka獲取注冊信息 eureka.client.fetch-registry=false # eureka服務器的地址（注意：地址最后面的 /eureka/ 這個是固定值） eureka.client.serviceUrl.defaultZone=http://localhost:${server.port}/eureka/
訪問http://localhost:8761/如下
注冊到本注冊中心的服務可能由於剛啟動，需要校驗一下服務，所以會出現保護模式。
接下來注冊一個服務提供者，其實它是一個Eureka客戶端，實現方式如下：
先新建一個服務，引入如下pom文件
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
在該服務的啟動類中添加注解@EnableEurekaClient，配置端口及服務名稱信息等
server.port=8762
spring.application.name=spring-cloud-provider # 要注冊到的注冊中心地址 eureka.client.serviceUrl.defaultZoon=http://localhost:8761/eureka/
啟動該工程，訪問http://localhost:8761/，會發現在Instances currently registered with Eureka中存在該服務的信息，表示該服務提供者已經被注冊成功了。
再創建一個工程，同樣引入客戶端以來和添加@EnableEurekaClient，修改配置文件的服務名稱和端口，注冊中心地址與提供者保持一致，如下：
server.port=8888
spring.application.name=spring-cloud-consumer # 要注冊到的注冊中心地址 eureka.client.server-url.defaultZoon=http://localhost:8761/eureka/
啟動該工程，訪問http://localhost:8761/，會發現在Instances currently registered with Eureka中存在該服務的信息，表示該服務消費者已經被注冊成功了。
注意：由於spring-cloud-starter-netflix-eureka-client沒有依賴tomcat，所以在創建客戶端的時候，需要加入以下依賴
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency>
否則會報無法創建bean的錯誤。
3. Eureka和zookeeper的對比
3.1 分布式系統的CAP理論
一致性（C）:所有節點上的數據時刻保持同步。
可用性（A）:每個請求都能接收到一個響應，無論響應失敗還是成功。
分區容錯性（P）: 系統應該能持續提供服務，即使系統內部有消息丟失。
由於分區容錯性在分布式系統中必須要保證，所以我們只能在A和C之間進行權衡，Zookeeper保證的是CP,而Eureka保證的是AP
3.2 Zookeeper保證CP
Zookeeper是個cp的，即任何時刻對Zookeeper的請求訪問都能得到一致的數據結果，同時系統對網絡分割具有容錯性，但是它不能保證每次服務請求都可用，也就是說zookeeper可能會在極端情況下丟棄一些請求。
3.3 Eureka保證AP
Eureka在設計時就優先保證了可用性，我們可以容忍注冊中心返回的是幾分鍾以前的注冊信息，但是不能夠接受服務直接down掉 不可用，也就是說，服務注冊功能對可用性的要求高於一致性。
如果Eureka服務節點在短時間內失去了大量的心跳連接，那么這個節點將進入”自我保護模式“，同時保留那些”心跳死亡”的服務注冊信息不過期，此時，這個Eureka節點對於新的服務還能提供注冊服務，對於死亡的仍然保留，以防還有客戶端向其發送請求，當故障恢復后，這個節點會推出自我保護模式，Eureka的哲學是，同時保存好數據和壞數據，總比丟失數據要更好。
至於運用中使用什么為注冊中心更具業務和需求來定，沒有最好的架構，只有最合適的架構。