《Spring Cloud Netflix》 -- 服務注冊和服務發(fā)現(xiàn)-Eureka 的使用

一、Spring Cloud Netflix

該項目是Spring Cloud的核心子項目，是對Netflix公司一系列開源產品的封裝。它為Spring Boot應用提供了自配置的整合，只需要通過一些簡單的注解，就可以快速地在Spring Cloud的應用中使用起來。

它主要提供的模塊包括：

服務發(fā)現(xiàn)注冊（Eureka）

客戶端負載均衡（Ribbon）

斷路器（Hystrix）

智能路由（Zuul）

開源地址：

http://netflix.github.io/

https://github.com/Netflix

二、服務注冊和服務發(fā)現(xiàn)

調用關系說明：

1.服務提供者在啟動時，向注冊中心注冊自己提供的服務。

2.服務消費者在啟動時，向注冊中心訂閱自己所需的服務。

3.注冊中心返回服務提供者地址給消費者。

4.服務消費者從提供者地址中調用消費者。

注意！ 下面的服務端指：注冊中心，客戶端指：提供者和消費者

  三、如何使用Eureka進行服務注冊和發(fā)現(xiàn)

1、服務端添加依賴

<dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-starter-eureka-server</artifactId>
</dependency>

2、服務端添加配置

# 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/

3、服務端添加注解

@EnableEurekaServer

4、客戶端添加依賴

<dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>

5、客戶端添加配置

提供者

# server

server.port=7777

# spring

spring.application.name=spring-cloud-provider

# eureka

eureka.client.serviceUrl.defaultZone=http://localhost:8761/eureka/

消費者

# server

server.port=8888

# spring

spring.application.name=spring-cloud-consumer

# eureka

eureka.client.serviceUrl.defaultZone=http://localhost:8761/eureka/

6、客戶端添加注解

@EnableEurekaClient

注意：

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（即服務提供者）發(fā)起us-east-1c注冊請求；

2、  Eureka Server集群中的其他兩個node（us-east-1d和us-east-1e進行Replicate復制）；

3、  圖下放的兩個client（即服務消費者）分別向三個server獲取注冊信息及Get Registry。

五、和Zookeeper的對比

1、分布式系統(tǒng)的CAP理論：

一致性（C）：所有的節(jié)點上的數(shù)據(jù)時刻保持同步。

可用性（A）：每個請求都能接受到一個響應，無論響應成功或失敗。

分區(qū)容錯性（P）：系統(tǒng)應該能持續(xù)提供服務，即使系統(tǒng)內部有消息丟失（分區(qū)）。

由于分區(qū)容錯性在是分布式系統(tǒng)中必須要保證的，因此我們只能在A和C之間進行權衡。

在此Zookeeper保證的是CP, 而Eureka則是AP。

2、Zookeeper保證CP

ZooKeeper是個 CP的，即任何時刻對ZooKeeper的訪問請求能得到一致的數(shù)據(jù)結果，同時系統(tǒng)對網絡分割具備容錯性、但是它不能保證每次服務請求的可用性(注：也就是在極端環(huán)境下，ZooKeeper可能會丟棄一些請求，消費者程序需要重新請求才能獲得結果)。

例如：當master節(jié)點因為網絡故障與其他節(jié)點失去聯(lián)系時，剩余節(jié)點會重新進行l(wèi)eader選舉。問題在于，選舉leader的時間太長，30 ~ 120s, 且選舉期間整個zk集群都是不可用的，這就導致在選舉期間注冊服務癱瘓。

3、Eureka保證AP

Eureka看明白了這一點，因此在設計時就優(yōu)先保證可用性。我們可以容忍注冊中心返回的是幾分鐘以前的注冊信息，但不能接受服務直接down掉不可用。也就是說，服務注冊功能對可用性的要求要高于一致性。

如果Eureka服務節(jié)點在短時間里丟失了大量的心跳連接(注：可能發(fā)生了網絡故障)，那么這個 Eureka節(jié)點會進入“自我保護模式”，同時保留那些“心跳死亡”的服務注冊信息不過期。此時，這個Eureka節(jié)點對于新的服務還能提供注冊服務，對于“死亡”的仍然保留，以防還有客戶端向其發(fā)起請求。當網絡故障恢復后，這個Eureka節(jié)點會退出“自我保護模式”。Eureka的哲學是，同時保留“好數(shù)據(jù)”與“壞數(shù)據(jù)”總比丟掉任何數(shù)據(jù)要更好。

4、總結

Eureka作為單純的服務注冊中心來說要比zookeeper更加“專業(yè)”，因為注冊服務更重要的是可用性，我們可以接受短期內達不到一致性的狀況。

當然，這也要看具體的使用場景。