一、使用方法:

1、添加maven依賴

org.springframework.cloud

spring-cloud-starter-netflix-eureka-server

版本一般交由spring-cloud-dependencies管理。注意這個依賴的artifactId在Edgware以前是spring-cloud-starter-eureka-server，而在之后變成了spring-cloud-starter-netflix-eureka-server。其他組件也是類似。

2、在啟動類中加入注解@EnableEurekaServer

@SpringBootApplication

@EnableEurekaServer

public class EurekaCenter {

public static void main(String[] args) {

SpringApplication.run(EurekaCenter.class, args);

}

}

二、屬性優化：

1. 關于eureka的配置

大致分為eureka.instance, eureka.clinet,eureka.server三大類。大部分的參數都可以不管，有默認值。需要時查一下就可以了。下面列出幾個比較有用的參數

eureka.client.registerWithEureka

表示是否將自己注冊到Eureka Server，默認為true。由于當前應用就是Eureka Server，所以不需要注冊，修改為false。

eureka.client.fetchRegistry

表示是否從Eureak Server獲取注冊信息，默認為true。由于示例中是單點的Eureka Server，不需要同步其他的Eureka Server節點的數據，所以修改為false。

eureka.client.serviceUrl.defaultZone

設置與Eureka Server交互的地址，查詢服務和注冊服務都需要依賴這個地址。

另外，可以給eureka的監控頁面增加簡單的權限驗證security.basic.enabled=true

security.user.name=admin

security.user.password=123

Eureka的其他配置屬性可在spring-cloud-netflix-eureka-client的jar包中META-INF目錄下尋找spring-configuration-metadata.json文件中有詳細描述。這是starter組件的開發流程，其他組件的配置信息也有類似的描述文件。

2. 關于eureka注冊中心的自我保護模式

關于自我保護模式，最直觀的體現是進入eureka的監控頁面時，頁面上出現紅色的警告信息

默認情況下，Eureka Server在一定時間內沒有接收到某個微服務的心跳，Eureka Server就會注銷該實例(默認90秒，可以通過參數自行配置)。這本是正常的微服務治理機制，但是如果問題的原因只是因為網絡分區故障而發生時，就會出現比較不好的結果。即服務本身其實是健康的，但是Eureka Server卻把他注銷掉了。

為了防止這種情況，Eureka Server采用了自我保護模式。即當服務失聯后，會繼續保存該服務的注冊信息-不會分配請求。而當網絡故障恢復后，該服務就會退出自我保護模式，重新分配請求。

而在SpringCloud中，可以通過配置參數

eureka.server.enable-self-preservation= false

來禁用自我保護模式

另外，對于自我保護模式下的服務，可以通過手動訪問接口方式進行管理，即手動下線已經失效的微服務。具體方式可以訪問Eureka Server的REST接口，例如下線服務只需要給如下地址發送DELETE請求(可以用POSTMAN等工具發送)

http://${Eureka_URL}:${Eureka_port}/eureka/apps/${AppName}/${instance}

其中，AppName和{AppName}和AppName和{instance}就是在頁面上看到的服務節點。

3. Eureka的高可用配置

Eureka通過多個節點相互注冊的方式來實現集群高可用。

為了在單機模擬HA配置方式，可以采用在單機監聽兩個不同端口的方式啟動更多個實例。

使用yml文件配置方式如下：

---

server:

port: 8001

spring:

profiles: server1

application:

name: eureka-ha

eureka:

instance:

hostname: server1

client:

serviceUrl:

defaultZone: http://server2:8002/eureka/

---

server:

port: 8002

spring:

profiles: server2

application:

name: eureka-ha

eureka:

instance:

hostname: server2

client:

serviceUrl:

defaultZone: http://server1:8001/eureka/

然后使用指令啟動兩個實例：

java -jar ./eurekaCenter-0.0.1-SNAPSHOT.jar --spring.profiles.active=server1

java -jar ./eurekaCenter-0.0.1-SNAPSHOT.jar --spring.profiles.active=server2

啟動兩個實例后可以訪問server1:8001和server2:8002頁面，可以看到兩個實例完成了相互注冊。

4.Eureka跨機房災備

Eureka通過增加region和zone的定義可以快速時間跨機房災備(region和zone的概念均來自于亞馬遜的AWS)

一般region概念指代區域，如亞洲地區、華北地區、北京等。而zone概念指代具體機房。

災備原則是一個機房內的Consumer優先調用同機房的Service，當同一機房的service或者eureka不可用時，再去調用其他機房的服務。

1、Eureka分區服務配置

eureka.client.prefer-same-zone-eureka=true

eureka.client.region=beijing

eureka.client.availability-zones.beijing=zone1,zone2

eureka.client.serviceUrl.zone1=http://localhost:9002/eureka

eureka.client.serviceUrl.zone2=http://localhost:9003/eureka

注冊中心選擇邏輯：

如果prefer-same-zone-eureka為false，按照service-url下的 list取第一個注冊中心來注冊，并和其維持心跳檢測。不會再向list內的其它的注冊中心注冊和維持心跳。只有在第一個注冊失敗的情況下，才會依次向其它的注冊中心注冊，總共重試3次，如果3個service-url都沒有注冊成功，則注冊失敗。每隔一個心跳時間，會再次嘗試。

如果prefer-same-zone-eureka為true，先通過region取availability-zones內的第一個zone，然后通過這個zone取service-url下的list，并向list內的第一個注冊中心進行注冊和維持心跳，不會再向list內的其它的注冊中心注冊和維持心跳。只有在第一個注冊失敗的情況下，才會依次向其它的注冊中心注冊，總共重試3次，如果3個service-url都沒有注冊成功，則注冊失敗。每隔一個心跳時間，會再次嘗試。

所以說，為了保證服務注冊到同一個zone的注冊中心，一定要注意availability-zones的順序，必須把同一zone寫在前面

2、對于服務調用者和服務提供者，都是通過eureka.instance.metadata-map.zone來設置屬于哪個zone

服務消費者會先通過ribbon去注冊中心拉取一份服務提供者的列表，然后通過eureka.instance.metadata-map.zone指定的zone進行過濾，過濾之后如果同一個zone內的服務提供者有多個實例，則會輪流調用。

只有在同一個zone內的所有服務提供者都不可用時，才會調用其它zone內的服務提供者。

3、擴展配置

eureka.instance.lease-renewal-interval-in-seconds: 30

服務和注冊中心的心跳間隔時間，默認為30s

eureka.instance.lease-expiration-duration-in-seconds: 90

服務和注冊中心的心跳超時時間，默認為90s

三、Eureka與Zookeeper

Dubbo使用Zookeeper作為注冊中心，而SpringCloud使用Eureka作為注冊中心。兩者作為服務中心，在單點使用時差別不大，但是在作為集群服務時有些區別。

1、以CAP理論，zookeeper是保證CP的，而Eureka是保證AP的。即在集群面臨各種宕機、網絡波動等分布式問題時，前者更偏向保證數據一致，而后者更偏向保證服務可用。

2、集群方式：zookeeper集群需要以選舉算法保證集群中有一個唯一的leader，這樣，集群在選舉過程中，容易導致短暫服務不可用。而Eureka集群的方式則是簡單的互相注冊，即把當前Eureka節點也作為一個服務，向其他Eureka節點進行注冊。這樣當有節點宕機后，直接用另外一些節點提供服務即可。但是這時，就存在節點之間數據同步沒有完成的問題。這個集群方式也是兩者CP與AP之爭的根本。

3、Eureka的自我保護機制也是別人說Eureka更適合做服務中心的特點之一。

個人觀點，如果不是云環境，用哪個隨緣把。