Eureka服务治理
服務治理：
服務治理可以說是微服務架構中最為核心和基礎的模塊，主要用來實現各個微服務實例的自動化注冊與發現。 使用服務治理的原因：在服務引用并不算多的時候，可以通過靜態配置來完成服務的調用，但隨著業務的發展，系統功能越來越復雜，相應的微服務也不斷增加，此時靜態配置會變得越來越難以維護。并且面對不斷發展的業務，集群規模，服務的位置、服務的命名等都有可能發生變化，如果還是通過手工維護的方式，極易發生錯誤或是命名沖突等問題。同時，也將消耗大量的人力來維護靜態配置的內容。為了解決微服務架構中的服務實例維護問題，就產生了大量的服務治理框架和產品。這些框架和產品的實現都圍繞著服務注冊與服務發現機制來完成對微服務應用實例的自動化管理。服務注冊：
在服務治理框架中，通常都會構建一個注冊中心，每個服務單元向注冊中心登記自己提供的服務，將主機與端口號、版本號、通信協議等一些附加信息告知注冊中心，注冊中心按服務名分類組織服務清單。比如：有兩個提供服務A的進程分別運行于192.168.0.100:8000 和192.168.0.101:8000 位置上，還有三個提供服務B的進程分別運行于192.168.0.100:9000、192.168.0.101:9000、192.168.0.102:9000位置上。當這些進程都啟動，并向注冊中心注冊自己的服務之后，注冊中心就會維護類似下面的一個服務清單。另外，注冊中心還需要以心跳的方式去監測清單中的服務是否可用，若不可用需要從服務清單中剔除，達到排除故障服務的效果。
服務發現：
在服務治理框架的運作下，服務間的調用不再通過指定具體的實例地址來實現，而是通過向服務名發起請求調用實現。所以，服務調用方在調用服務提供方接口時，并不知道具體的服務實例位置。因此，調用方需要向注冊中心咨詢服務，并獲取所有服務的實例清單，以實現對具體服務實例的訪問。比如：以上述服務為例，有服務C希望調用服務A，服務C就向注冊中心發起咨詢請求，服務注冊中心就會將服務A的位置清單返回給服務C，當服務C要發起調用時，便從該清單中以某種輪詢策略取出一個位置來進行服務調用（客戶端負載均衡）。Netflix Eureka
Spring cloud Eureka ，使用 Netflix Eureka 來實現服務注冊與發現，它即包含了服務端組件，也包含了客戶端組件，并且服務端和客戶端均采用Java編寫，所以 Eureka 主要適用于通過 Java實現的分布式系統，或是與JVM兼容語言構建的系統。但是，Eureka服務端的服務治理機制提供了完備的RESTful API，所以也支持將非 Java語言構建的微服務應用納入Eureka 的服務治理體系中來。只是在使用其他語言平臺時，需要自己來實現Eureka的客戶端程序。 Eureka服務端：也稱為服務注冊中心。它和其他服務注冊中心一樣，支持高可用配置。 Eureka客戶端：主要處理服務的注冊與發現。客戶端服務通過注解和參數配置的方式，嵌入在客戶端應用程序的代碼中，在應用程序運行時，Eureka客戶端向注冊中心注冊自身提供的服務并周期性的發送心跳來更新它的服務租約。同時也能從服務端查詢當前注冊的服務信息并把它們緩存到本地并周期性的刷新服務狀態。搭建服務注冊中心
首先，創建spring boot 工程，命名為eureka-server，并在pom.xml 中引入必要的依賴內容（也可以通過spring initializer 快速構建項目）： <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><modelVersion>4.0.0</modelVersion><groupId>com.example</groupId><artifactId>eureka-server</artifactId><version>0.0.1-SNAPSHOT</version><packaging>jar</packaging><name>eureka-server</name><description>Demo project for Spring Boot</description><parent><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-parent</artifactId><version>1.5.6.RELEASE</version><relativePath/> <!-- lookup parent from repository --></parent><properties><project.build.sourceEncoding>UTF-8</project.build.sourceEncoding><project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding><java.version>1.8</java.version><spring-cloud.version>Dalston.SR2</spring-cloud.version></properties><dependencies><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-eureka-server</artifactId></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-test</artifactId><scope>test</scope></dependency></dependencies><dependencyManagement><dependencies><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-dependencies</artifactId><version>${spring-cloud.version}</version><type>pom</type><scope>import</scope></dependency></dependencies></dependencyManagement><build><plugins><plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId></plugin></plugins></build></project>
通過@EnableEurekaServer 注解啟動一個服務注冊中心提供給其他應用進行對話
package com.example.demo;import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;@EnableEurekaServer @SpringBootApplication public class EurekaServerApplication {public static void main(String[] args) {SpringApplication.run(EurekaServerApplication.class, args);} }在默認配置下，該服務注冊中心也會將自己作為客戶端來嘗試注冊它自己，所以需要禁用它的客戶端注冊行為，在application.properties文件中增加如下配置： server.port=8082eureka.instance.hostname=localhost # 向注冊中心注冊服務 eureka.client.register-with-eureka=false # 檢索服務 eureka.client.fetch-registry=false eureka.client.service-url.defaultZone=http://${eureka.instance.hostname}:${server.port}/eureka/
完成配置后，啟動應用并訪問http://localhost:8082/?？梢钥吹揭韵翬ureka信息面板，其中Instances currently registered with Eureka 欄是空的，表示該注冊中心還沒有注冊任何服務。
注冊服務提供者
完成服務注冊中心的搭建后，就可以添加一個既有的spring boot應用到Eureka的服務治理體系中去。 新建項目名為eureka-client的spring boot應用，將其作為一個微服務應用向服務注冊中心發布自己。首先在pom.xml中增加spring cloud eureka 模塊的依賴。 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><modelVersion>4.0.0</modelVersion><groupId>com.example</groupId><artifactId>eureka-client</artifactId><version>0.0.1-SNAPSHOT</version><packaging>jar</packaging><name>eureka-client</name><description>Demo project for Spring Boot</description><parent><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-parent</artifactId><version>1.5.6.RELEASE</version><relativePath/> <!-- lookup parent from repository --></parent><properties><project.build.sourceEncoding>UTF-8</project.build.sourceEncoding><project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding><java.version>1.8</java.version><spring-cloud.version>Dalston.SR2</spring-cloud.version></properties><dependencies><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-eureka</artifactId></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-test</artifactId><scope>test</scope></dependency></dependencies><dependencyManagement><dependencies><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-dependencies</artifactId><version>${spring-cloud.version}</version><type>pom</type><scope>import</scope></dependency></dependencies></dependencyManagement><build><plugins><plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId></plugin></plugins></build></project>
接著，新建RESTful API，通過注入DiscoveryClient對象，在日志中打印出服務的相關內容。
package com.example.demo.web;import org.apache.log4j.Logger; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.cloud.client.ServiceInstance; import org.springframework.cloud.client.discovery.DiscoveryClient; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController;/*** @author lxx* @version V1.0.0* @date 2017-8-9*/@RestController public class HelloController {private final Logger logger = Logger.getLogger(getClass());@Autowiredprivate DiscoveryClient client;@RequestMapping(value = "/index")public String index(){ServiceInstance instance = client.getLocalServiceInstance();logger.info("/hello：host:"+instance.getHost()+" port:"+instance.getPort()+" service_id:"+instance.getServiceId());return "hello world!";} } 然后在主類中添加 @EnableDiacoveryClient 注解，激活Eureka 中的DiscoveryClient 實現（自動化配置，創建DiscoveryClient接口針對Eureka客戶端的EurekaDiscoveryClient實例），才能實現上述對服務信息的輸出。 package com.example.demo;import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.client.discovery.EnableDiscoveryClient;@EnableDiscoveryClient @SpringBootApplication public class EurekaClientApplication {public static void main(String[] args) {SpringApplication.run(EurekaClientApplication.class, args);} }
最后修改application.properties文件，通過spring.application.name屬性為服務命名，再通過eureka.client.service-url.defaultZone 屬性來指定服務注冊中心的地址，地址和注冊中心設置的地址一致：
server.port=2222 spring.application.name=hello-serviceeureka.client.service-url.defaultZone=http://localhost:8082/eureka/下面分別啟動服務注冊中心以及服務提供方，在hello-service服務控制臺中，DiscoveryClient對象打印了該服務的注冊信息： 2017-08-09 17:17:27.635 INFO 8716 --- [ main] c.example.demo.EurekaClientApplication : Started EurekaClientApplication in 9.844 seconds (JVM running for 10.772) 2017-08-09 17:17:27.797 INFO 8716 --- [nfoReplicator-0] com.netflix.discovery.DiscoveryClient : DiscoveryClient_HELLO-SERVICE/chanpin-PC:hello-service:2222 - registration status: 204
在注冊中心控制臺可以看到hello-service的注冊信息： 2017-08-09 17:17:27.786 INFO 10396 --- [nio-8082-exec-1] c.n.e.registry.AbstractInstanceRegistry : Registered instance HELLO-SERVICE/chanpin-PC:hello-service:2222 with status UP (replication=false) 2017-08-09 17:17:47.792 INFO 10396 --- [a-EvictionTimer] c.n.e.registry.AbstractInstanceRegistry : Running the evict task with compensationTime 0ms
此處的輸出內容為HelloController中注入的DiscoveryClient接口對象，從服務注冊中心獲取的服務相關信息。
高可用注冊中心
在微服務架構這樣的分布式環境中，需要充分考慮發生故障的情況，所以在生產環境中必須對各個組件進行高可用部署，對于微服務如此，對于服務注冊中心也一樣。 Eureka Server 的設計一開始就考慮了高可用問題，在Eureka的服務治理中，所有節點既是服務提供方，也是服務消費方，服務注冊中心也一樣。 Eureka Server 的高可用實際上就是將自己作為服務向其他服務注冊中心注冊自己，這樣就可以形成一組互相注冊的服務注冊中心，以實現服務清單的相互同步，達到高可用的效果。下面嘗試搭建一個高可用服務注冊中心的集群。在之前的服務注冊中心的基礎上進行擴展，構建一個雙節點的服務注冊中心集群。- 創建 application-peer1.properties，作為peer1 服務中心的配置，并將serviceUrl指向peer2：
- 創建 application-peer2.properties，作為peer2 服務中心的配置，并將serviceUrl指向peer1：
- 在C:\Windows\System32\drivers\etc\hosts 文件中添加對peer1 和 peer2 中的轉換，讓上面配置的host形式的serviceURL能在本地正確訪問到； 127.0.0.1 peer1 127.0.0.1 peer2
- 通過spring.profiles.active 屬性來分別啟動peer1 和 peer2（打開兩個terminal進行啟動，在一個terminal中先啟動的peer1 會報錯，但不影響，是因為它所注冊的服務peer2 還未啟動，在另外個terminal中把peer2 啟動即可，不用啟動主類） ：
此時訪問peer1的注冊中心?http://localhost:1111/?可以看到，registered-replicas 中已經有 peer2 節點的eureka-server了。同樣的訪問peer2 的注冊中心?http://localhost:1112/?也可以看到registered-replicas 中有 peer1 節點， 并且這些節點在可用分片（available-replicase）之中。當關閉了peer1 節點后，刷新peer2 注冊中心，可以看到 peer1 的節點變成了不可用分片（unavailable-replicas）。
- 在設置了多節點的服務注冊中心之后，服務提供方還需要做一些簡單的配置才能將服務注冊到Eureka Server 集群中。以hello-service為例，修改配置文件如下：
主要是將eureka.client.service-url.defaultZone 的注冊中心指向之前搭建的peer1 和 peer2。 下面啟動該服務，通過訪問?http://localhost:1112/?或者?http://localhost:1111/?可以看到 hello-service 服務同時被注冊到了peer1 和 peer2 上。 若此時斷開 peer1 ，由于 hello-service 同時也向peer2 上注冊了，因此在peer2 上的其他服務依然能訪問到hello-service，從而實現了服務注冊中心的高可用。
? 如果不想使用主機名來定義注冊中心的地址，也可以使用IP地址的形式，但是需要在配置文件中增加配置參數 eureka.instance.prefer-ip-address=true，該值默認為false。
服務發現與消費
通過上面的內容介紹與實踐，已經搭建起微服務架構中的核心組件——服務注冊中心（包括單節點模式和高可用模式）。同時，還通過簡單的配置，將hello-service服務注冊到Eureka注冊中心上，成為該服務治理體系下的一個服務?，F在已經有了服務注冊中心和服務提供者，下面就構建一個服務消費者，它主要完成兩個目標，發現服務和消費服務。其中，服務發現的任務由Eureka客戶端完成，而服務消費的任務由Ribbon完成。Ribbon是一個基于HTTP和TCP的客戶端負載均衡器，它可以在通過客戶端中配置的ribbonServerList服務端列表去輪詢訪問以達到均衡負載的作用。當Ribbon與Eureka聯合使用時，Ribbon的服務實例清單RibbonServerList會被DiscoveryEnabledNIWSServerList重寫，擴展成從Eureka注冊中心獲取服務端列表。同時也會用NIWSDiscoveryPing來取代IPing，它將職責委托給Eureka來確定服務端是否已經啟動。- 準備工作：啟動之前實現的服務注冊中心eureka-server以及hello-service服務，為了實驗Ribbon的客戶端負載均衡功能，我們通過java -jar 命令行的方式來啟動兩個端口不同的hello-service，具體如下：
- 修改配置文件：
- 再將hello-service應用打包：mvn clean package
- 通過下列命令啟動應用程序：
- 成功啟動兩個服務后，可以在注冊中心看到名為HELLO-SERVICE的服務中出現兩個實例單元：
- 創建一個Spring boot項目來實現服務消費者，取名為ribbon-consumer，并在pom.xml中引入如下的依賴內容。
- 在主類中通過@EnableDiscoveryClient注解讓該應用注冊為Eureka客戶端應用，以獲取服務發現的能力，同時，在該主類中創建RestTemplate的Spring Bean實例，并通過@LoadBalanced 注解開啟客戶端負載均衡。
- 創建ConsumerController類并實現/ribbon-consumer接口。在該接口中，通過上面創建的RestTemplate 來實現對HELLO-SERVICE 服務提供的 /hello 接口進行調用。此處的訪問地址是服務名 HELLO-SERVICE ，而不是一個具體的地址，在服務治理框架中，這是一個重要特性。
- 在application.properties中配置Eureka服務注冊中心的位置，需要與之前的HELLO-SERVICE一樣，同時設置該消費者的端口為3333，不與之前啟動的應用端口沖突即可。
- 啟動ribbon-consumer應用后，可以在Eureka信息面板中看到，除了HELLO-SERVICE外，還多了實現的RIBBON-CONSUMER服務。
- 通過向?http://localhost:3333/ribbon-consumer?發起訪問， 成功返回字符串 “hello world”。在消費者控制臺中打印出服務列表情況。
- 多發送幾次請求，可以在服務提供方hello-service的控制臺中看到一些打印信息，可以看出兩個控制臺基本是交替訪問，實現了客戶端的負載均衡。
Eureka詳解
基礎架構（核心三要素）
- 服務注冊中心：Eureka提供的服務端，提供服務注冊與發現的功能，即之前的eureka-server。
- 服務提供者：提供服務的應用，可以是spring boot應用，也可以是其他技術平臺且遵循Eureka通信機制的應用。它將自己提供的服務注冊到Eureka，以供其他應用發現。即之前的HELLO-SERVICE.
- 服務消費者：消費者從服務注冊中心獲取服務列表，從而使消費者可以知道去何處調用其所需要的服務，在上一節中使用了Ribbon來實現服務消費，后續還會介紹使用Feign的消費方式
服務治理機制
體驗了Spring cloud Eureka 通過簡單的注解配置就能實現強大的服務治理功能之后，進一步了解一下Eureka基礎架構中各個元素的一些通信行為，以此來理解基于Eureka實現的服務治理體系是如何運作起來的。以上圖為例，其中有幾個重要元素：
- “服務注冊中心-1” 和 “服務注冊中心-2”，他們互相注冊組成高可用集群。
- “服務提供者” 啟動了兩個實例，一個注冊到“服務注冊中心-1” 上，另外一個注冊到 “服務注冊中心-2” 上。
- 還有兩個 “服務消費者” ，它們也都分別指向了一個注冊中心。
根據上面的結構，可以詳細了解從服務注冊開始到服務調用，及各個元素所涉及的一些重要通信行為。
服務提供者
服務注冊
“服務提供者” 在啟動的時候會通過發送REST請求的方式將自己注冊到Eureka Server 上，同時帶上了自身服務的一些元數據信息。Eureka Server 接收到這個REST請求后，將元數據信息存儲在一個雙層結構Map中，其中第一層的key是服務名，第二層的key 是具體服務的實例名。
在服務注冊時，需要確認eureka.client.register-with-eureka=true參數是否正確，若為false，將不會啟動注冊操作。
服務同步
如圖所示，這里的兩個服務提供者分別注冊到了兩個不同的服務注冊中心上，即它們的信息分別被兩個服務注冊中心維護。由于服務注冊中心之間為互相注冊，當服務提供者發送注冊請求到一個服務注冊中心時，它會將請求轉發給集群中相連的其他注冊中心，從而實現注冊中心之間的服務同步。通過服務同步，兩個服務提供者的服務信息就可以通過這兩個服務注冊中心中的任意一臺獲取到。
服務續約
在注冊完服務之后，服務提供者會維護一個心跳用來持續告訴 Eureka Server ：“我還活著”，以防止 Eureka Server 的 “剔除任務” 將該服務實例從服務列表中排除出去，我們稱該操作為服務續約。
服務消費者
獲取服務
到這里，在服務注冊中心已經注冊了一個服務，并且該服務有兩個實例。當我們啟動服務消費者時，它會發送一個REST請求給服務注冊中心，來獲取上面注冊的服務清單。為了性能考慮，Eureka Server 會維護一份只讀的服務清單來返回給客戶端，同時該緩存清單會每隔30秒更新一次。
獲取服務是服務消費者的基礎，所以要確保 eureka-client-fetch-registery=true 參數沒有被修改成false，該值默認為 true。若想修改緩存清單的更新時間，可以通過 eureka-client.registry-fetch-interval-seconds=30 參數來進行修改，該值默認為30，單位為秒。
服務調用
服務消費者在獲取服務清單后，通過服務名可以獲得具體提供服務的實例名和該實例的元數據信息。因為有這些服務實例的詳細信息，所以客戶端可以根據自己的需要決定具體需要調用的實例，在Ribbon中會默認采用輪詢的方式進行調用，從而實現客戶端的負載均衡。
服務下線
在系統運行過程中必然會面臨關閉或重啟服務的某個實例的情況，在服務關閉期間，我們自然不希望客戶端會繼續調用關閉了的實例。所以在客戶端程序中，當服務實例進行正常的關閉操作時，它會觸發一個服務下線的REST請求給 Eureka Server，告訴服務注冊中心：“我要下線了”。服務端在接收到請求之后，將該服務狀態設置為下線（DOWN），并把該下線事件傳播出去。
服務注冊中心
失效剔除
當一些外部原因如內存溢出、網絡故障等導致服務實例非正常下線，而服務注冊中心并未收到“服務下線”的請求。為了從服務列表中將這些無法提供服務的實例剔除，Eureka Server 在啟動的時候會創建一個定時任務，默認每隔一段時間（默認60秒）將當前清單中超時（默認90秒）沒有續約的服務剔除出去。
自我保護
當我們在本地調試基于 Eureka 的程序時，基本上都會在服務注冊中心的信息面板上出現類似下面的紅色警告信息：
實際上，該警告就是觸發了Eureka Server的自我保護機制。之前介紹過，服務注冊到Eureka Server之后，會維護一個心跳連接，告訴Eureka Server 自己還活著。Eureka Server 在運行期間，會統計心跳失敗的比例在15分鐘之內低于85%，如果出現低于的情況，Eureka Server 會將當前的實例信息保護起來，讓這些實例不會過期，盡可能保護這些注冊信息。但是，在保護期間內實例若出現問題，那么客戶端很容易拿到實際已經不存在的服務實例，會出現調用失敗的情況，所以客戶端必須要有容錯機制，比如可以使用請求重試、斷路器等機制。
由于在本地調試很容易觸發注冊中心的保護機制，使得注冊中心維護的服務實例不那么準確。可以在本地進行開發時，使用 eureka-server.enable-self-preservation=false 參數來關閉保護機制，確保注冊中心將不可用的實例正確剔除。
源碼分析
上面，我們對Eureka中各個核心元素的通信行為做了詳細的介紹，為了更深入的理解它的運作和配置，下面我們結合源碼來分別看看各個通信行為是如何實現的。
在看具體源碼之前，先回顧一下之前所實現的內容，從而找到一個合適的切入口去分析。首先，對于服務注冊中心、服務提供者、服務消費者這三個主要元素來說，后兩者（Eureka客戶端）在整個運行機制中是大部分通信行為的主動發動著，而注冊中心主要是處理請求的接受者。所以，我們從Eureka客戶端作為入口看看它是如何完成這些主動通信行為的。
我們將一個普通的spring boot 應用注冊到Eureka Server 或是從 Eureka Server 中獲取服務列表時，主要就做了兩件事：
- 在應用類中配置了 @EnableDiscoveryClient 注解。
- 在application.properties 中用 eureka-client.service-url.defaultZone 參數指定了注冊中心的位置。
順著上面的線索，我們看看 @EnableDiscoveryClient 的源碼，具體如下：
// // Source code recreated from a .class file by IntelliJ IDEA // (powered by Fernflower decompiler) // package org.springframework.cloud.client.discovery;import java.lang.annotation.Documented; import java.lang.annotation.ElementType; import java.lang.annotation.Inherited; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; import org.springframework.cloud.client.discovery.EnableDiscoveryClientImportSelector; import org.springframework.context.annotation.Import;@Target({ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME) @Documented @Inherited @Import({EnableDiscoveryClientImportSelector.class}) public @interface EnableDiscoveryClient {boolean autoRegister() default true; }從該注解的注釋中我們可以知道，它主要用來開啟 DiscoveryClient 的實例。通過搜索 DiscoveryClient ，我們可以發現有一個類和一個接口。通過梳理可以得到如下圖所示的關系：
其中，1 是 Spring Cloud 的接口，它定義了用來發現服務的常用抽象方法，通過該接口可以有效的屏蔽服務治理的實現細節，所以使用 Spring Cloud 構建的微服務應用可以方便的切換不同服務治理框架，而不改動程序代碼，只需要另外添加一些針對服務治理框架的配置即可。2 是對 1 接口的實現，從命名判斷。它實現的是對 Eureka 發現服務的封裝。所以 EurekaDiscoveryClient 依賴了 Netflix Eureka 的 EurekaClient 接口，EurekaClient 接口繼承了 LookupService 接口，它們都是 Netflix 開源包中的內容，主要定義了針對 Eureka 的發現服務的抽象發放，而真正實現發現服務的則Netflix包中的 DiscoveryClient （5）類。
接下來，我們就詳細看看DiscoveryClient類。先看下該類的頭部注釋，大致內容如下：
在具體研究Eureka Client 負責完成的任務之前，我們先看看在哪里對Eureka Server 的URL列表進行配置。根據配置的屬性名 eureka.client.service-url.defaultZone，通過 ServiceURL 可以找到該屬性相關的加載屬性，但是在SR5 版本中它們都被 @Deprecated 標注為不再建議使用，并 @link 到了替代類 EndpointUtils，所以可以在該類中找到下面這個函數：
public static Map<String, List<String>> getServiceUrlsMapFromConfig(EurekaClientConfig clientConfig, String instanceZone, boolean preferSameZone) {LinkedHashMap orderedUrls = new LinkedHashMap();String region = getRegion(clientConfig);String[] availZones = clientConfig.getAvailabilityZones(clientConfig.getRegion());if(availZones == null || availZones.length == 0) {availZones = new String[]{"default"};}logger.debug("The availability zone for the given region {} are {}", region, Arrays.toString(availZones));int myZoneOffset = getZoneOffset(instanceZone, preferSameZone, availZones);String zone = availZones[myZoneOffset];List serviceUrls = clientConfig.getEurekaServerServiceUrls(zone);if(serviceUrls != null) {orderedUrls.put(zone, serviceUrls);}int currentOffset = myZoneOffset == availZones.length - 1?0:myZoneOffset + 1;while(currentOffset != myZoneOffset) {zone = availZones[currentOffset];serviceUrls = clientConfig.getEurekaServerServiceUrls(zone);if(serviceUrls != null) {orderedUrls.put(zone, serviceUrls);}if(currentOffset == availZones.length - 1) {currentOffset = 0;} else {++currentOffset;}}if(orderedUrls.size() < 1) {throw new IllegalArgumentException("DiscoveryClient: invalid serviceUrl specified!");} else {return orderedUrls;}}
Region、Zone
從上面的函數中可以發現，客戶端依次加載了兩個內容，第一個是Region，第二個是Zone，從其加載邏輯上可以判斷它們之間的關系：
- 通過 getRegion 函數，我們可以看到他從配置中讀取了一個Region返回，所以一個微服務應用只可以屬于一個Region，如果不特別配置，默認為default。若要自己配置，可以通過 eureka.client.region屬性來定義。
- 通過 getAvailabilityZones 函數，可以知道當我們沒有特別為 Region 配置 Zone 的時候，默認采用defaultZone ， 這才是我們之前配置參數 eureka.client.service-url.defaultZone 的由來。若要為應用指定Zone，可以通過eureka.client.availability-zones 屬性來設置。從該函數的 return 內容，可以知道 Zone 能夠設置多個，并且通過逗號分隔來配置。由此，我們可以判斷Region與Zone 是一對多的關系。
serviceUrls
在獲取了Region 和 Zone 的信息之后，才開始真正加載 Eureka Server 的具體地址。它根據傳入的參數按一定算法確定加載位于哪一個Zone配置的serviceUrls。
int myZoneOffset = getZoneOffset(instanceZone, preferSameZone, availZones); String zone = availZones[myZoneOffset]; List serviceUrls = clientConfig.getEurekaServerServiceUrls(zone);具體獲取serviceUrls 的實現，可以詳細查看getEurekaServerServiceUrls 函數的具體實現類 EurekaClientConfigBean，用來加載配置文件中的內容，通過搜索defaultZone，我們可以很容易找到下面這個函數，它具體實現了如何解析該參數的過程，通過此內容，我們可以知道，eureka.client.service-url.defaultZone 屬性可以配置多個，并且需要通過逗號分隔。
public List<String> getEurekaServerServiceUrls(String myZone) {String serviceUrls = (String)this.serviceUrl.get(myZone);if(serviceUrls == null || serviceUrls.isEmpty()) {serviceUrls = (String)this.serviceUrl.get("defaultZone");}if(!StringUtils.isEmpty(serviceUrls)) {String[] serviceUrlsSplit = StringUtils.commaDelimitedListToStringArray(serviceUrls);ArrayList eurekaServiceUrls = new ArrayList(serviceUrlsSplit.length);String[] var5 = serviceUrlsSplit;int var6 = serviceUrlsSplit.length;for(int var7 = 0; var7 < var6; ++var7) {String eurekaServiceUrl = var5[var7];if(!this.endsWithSlash(eurekaServiceUrl)) {eurekaServiceUrl = eurekaServiceUrl + "/";}eurekaServiceUrls.add(eurekaServiceUrl);}return eurekaServiceUrls;} else {return new ArrayList();}}當我們在微服務應用中使用Ribbon來實現服務調用時，對于Zone的設置可以在負載均衡時實現區域親和特性：Ribbon的默認策略會優先訪問同客戶端處于一個Zone中的服務端實例，只有當同一個Zone 中沒有可用服務端實例的時候才會訪問其他Zone中的實例。所以通過Zone屬性的定義，配合實際部署的物理結構，我們就可以有效地設計出對區域性故障的容錯集群。
? 服務注冊
在理解了多個服務注冊中心信息的加載后，我們再回頭看看DiscoveryClient類是如何實現“服務注冊”行為的，通過查看它的構造類，可以找到調用了下面這個函數：
private void initScheduledTasks() {int renewalIntervalInSecs;int expBackOffBound;if(this.clientConfig.shouldFetchRegistry()) {renewalIntervalInSecs = this.clientConfig.getRegistryFetchIntervalSeconds();expBackOffBound = this.clientConfig.getCacheRefreshExecutorExponentialBackOffBound();this.scheduler.schedule(new TimedSupervisorTask("cacheRefresh", this.scheduler, this.cacheRefreshExecutor, renewalIntervalInSecs, TimeUnit.SECONDS, expBackOffBound, new DiscoveryClient.CacheRefreshThread()), (long)renewalIntervalInSecs, TimeUnit.SECONDS);}if(this.clientConfig.shouldRegisterWithEureka()) {renewalIntervalInSecs = this.instanceInfo.getLeaseInfo().getRenewalIntervalInSecs();expBackOffBound = this.clientConfig.getHeartbeatExecutorExponentialBackOffBound();logger.info("Starting heartbeat executor: renew interval is: " + renewalIntervalInSecs);this.scheduler.schedule(new TimedSupervisorTask("heartbeat", this.scheduler, this.heartbeatExecutor, renewalIntervalInSecs, TimeUnit.SECONDS, expBackOffBound, new DiscoveryClient.HeartbeatThread(null)), (long)renewalIntervalInSecs, TimeUnit.SECONDS);this.instanceInfoReplicator = new InstanceInfoReplicator(this, this.instanceInfo, this.clientConfig.getInstanceInfoReplicationIntervalSeconds(), 2);this.statusChangeListener = new StatusChangeListener() {public String getId() {return "statusChangeListener";}public void notify(StatusChangeEvent statusChangeEvent) {if(InstanceStatus.DOWN != statusChangeEvent.getStatus() && InstanceStatus.DOWN != statusChangeEvent.getPreviousStatus()) {DiscoveryClient.logger.info("Saw local status change event {}", statusChangeEvent);} else {DiscoveryClient.logger.warn("Saw local status change event {}", statusChangeEvent);}DiscoveryClient.this.instanceInfoReplicator.onDemandUpdate();}};if(this.clientConfig.shouldOnDemandUpdateStatusChange()) {this.applicationInfoManager.registerStatusChangeListener(this.statusChangeListener);}this.instanceInfoReplicator.start(this.clientConfig.getInitialInstanceInfoReplicationIntervalSeconds());} else {logger.info("Not registering with Eureka server per configuration");}}在上面的函數中，可以看到一個與服務注冊相關的判斷語句?if(this.clientConfig.shouldRegisterWithEureka())。在該分支內，創建了一個 InstanceInfoReplicator 類的實例，他會執行一個定時任務，而這個定時任務的具體工作可以查看該類的run() 函數，具體如下所示：
public void run() {boolean var6 = false;ScheduledFuture next2;label53: {try {var6 = true;this.discoveryClient.refreshInstanceInfo();Long next = this.instanceInfo.isDirtyWithTime();if(next != null) {this.discoveryClient.register();this.instanceInfo.unsetIsDirty(next.longValue());var6 = false;} else {var6 = false;}break label53;} catch (Throwable var7) {logger.warn("There was a problem with the instance info replicator", var7);var6 = false;} finally {if(var6) {ScheduledFuture next1 = this.scheduler.schedule(this, (long)this.replicationIntervalSeconds, TimeUnit.SECONDS);this.scheduledPeriodicRef.set(next1);}}next2 = this.scheduler.schedule(this, (long)this.replicationIntervalSeconds, TimeUnit.SECONDS);this.scheduledPeriodicRef.set(next2);return;}next2 = this.scheduler.schedule(this, (long)this.replicationIntervalSeconds, TimeUnit.SECONDS);this.scheduledPeriodicRef.set(next2);}這里有個?this.discoveryClient.register(); 這一行，真正觸發調用注冊的地方就在這里，繼續查看register() 的實現內容，如下：
boolean register() throws Throwable {logger.info("DiscoveryClient_" + this.appPathIdentifier + ": registering service...");EurekaHttpResponse httpResponse;try {httpResponse = this.eurekaTransport.registrationClient.register(this.instanceInfo);} catch (Exception var3) {logger.warn("{} - registration failed {}", new Object[]{"DiscoveryClient_" + this.appPathIdentifier, var3.getMessage(), var3});throw var3;}if(logger.isInfoEnabled()) {logger.info("{} - registration status: {}", "DiscoveryClient_" + this.appPathIdentifier, Integer.valueOf(httpResponse.getStatusCode()));}return httpResponse.getStatusCode() == 204;}可以看出，注冊操作也是通過REST請求的方式進行的。同時，我們能看到發起注冊請求的時候，傳入了一個?instanceInfo 對象，該對象就是注冊時客戶端給服務端的服務的元數據。
服務獲取與服務續約
順著上面的思路，繼續看 DiscoveryClient 的?initScheduledTasks 函數，不難發現在其中還有兩個定時任務，分別是 “服務獲取” 和 “服務續約” ：
private void initScheduledTasks() {int renewalIntervalInSecs;int expBackOffBound;if(this.clientConfig.shouldFetchRegistry()) {renewalIntervalInSecs = this.clientConfig.getRegistryFetchIntervalSeconds();expBackOffBound = this.clientConfig.getCacheRefreshExecutorExponentialBackOffBound();this.scheduler.schedule(new TimedSupervisorTask("cacheRefresh", this.scheduler, this.cacheRefreshExecutor, renewalIntervalInSecs, TimeUnit.SECONDS, expBackOffBound, new DiscoveryClient.CacheRefreshThread()), (long)renewalIntervalInSecs, TimeUnit.SECONDS);}if(this.clientConfig.shouldRegisterWithEureka()) {renewalIntervalInSecs = this.instanceInfo.getLeaseInfo().getRenewalIntervalInSecs();expBackOffBound = this.clientConfig.getHeartbeatExecutorExponentialBackOffBound();logger.info("Starting heartbeat executor: renew interval is: " + renewalIntervalInSecs);this.scheduler.schedule(new TimedSupervisorTask("heartbeat", this.scheduler, this.heartbeatExecutor, renewalIntervalInSecs, TimeUnit.SECONDS, expBackOffBound, new DiscoveryClient.HeartbeatThread(null)), (long)renewalIntervalInSecs, TimeUnit.SECONDS);…………} else {logger.info("Not registering with Eureka server per configuration");}}從源碼中可以看出，“服務獲取” 任務相對于 “服務續約” 和 “服務注冊” 任務更為獨立。“服務續約” 與 “服務注冊” 在同一個 if 邏輯中，這個不難理解，服務注冊到Eureka Server 后，需要一個心跳去續約，防止被剔除，所以它們肯定是成對出現的。
而 “服務獲取” 的邏輯在一個獨立的 if 判斷中，而且是由eureka.client.fetch-registry=true 參數控制，它默認為true，大部分情況下不需關心。
? 繼續往下可以發現 “服務獲取” 和 “服務續約” 的具體方法，其中 “服務續約” 的實現比較簡單，直接以REST請求的方式進行續約：
boolean renew() {try {EurekaHttpResponse httpResponse = this.eurekaTransport.registrationClient.sendHeartBeat(this.instanceInfo.getAppName(), this.instanceInfo.getId(), this.instanceInfo, (InstanceStatus)null);logger.debug("{} - Heartbeat status: {}", "DiscoveryClient_" + this.appPathIdentifier, Integer.valueOf(httpResponse.getStatusCode()));if(httpResponse.getStatusCode() == 404) {this.REREGISTER_COUNTER.increment();logger.info("{} - Re-registering apps/{}", "DiscoveryClient_" + this.appPathIdentifier, this.instanceInfo.getAppName());return this.register();} else {return httpResponse.getStatusCode() == 200;}} catch (Throwable var3) {logger.error("{} - was unable to send heartbeat!", "DiscoveryClient_" + this.appPathIdentifier, var3);return false;}}而 “服務獲取” 則復雜一些，會根據是否是第一次獲取發起不同的 REST 請求和相應的處理。
服務注冊中心處理
通過上面的源碼分析，可以看到所有的交互都是通過 REST 請求發起的。下面看看服務注冊中心對這些請求的處理。Eureka Server 對于各類 REST 請求的定義都位于 com.netflix.eureka.resources 包下。
以 “服務注冊” 請求為例（在ApplicationResource類中）：
@POST@Consumes({"application/json", "application/xml"})public Response addInstance(InstanceInfo info, @HeaderParam("x-netflix-discovery-replication") String isReplication) {logger.debug("Registering instance {} (replication={})", info.getId(), isReplication);if(this.isBlank(info.getId())) {return Response.status(400).entity("Missing instanceId").build();} else if(this.isBlank(info.getHostName())) {return Response.status(400).entity("Missing hostname").build();} else if(this.isBlank(info.getAppName())) {return Response.status(400).entity("Missing appName").build();} else if(!this.appName.equals(info.getAppName())) {return Response.status(400).entity("Mismatched appName, expecting " + this.appName + " but was " + info.getAppName()).build();} else if(info.getDataCenterInfo() == null) {return Response.status(400).entity("Missing dataCenterInfo").build();} else if(info.getDataCenterInfo().getName() == null) {return Response.status(400).entity("Missing dataCenterInfo Name").build();} else {DataCenterInfo dataCenterInfo = info.getDataCenterInfo();if(dataCenterInfo instanceof UniqueIdentifier) {String dataCenterInfoId = ((UniqueIdentifier)dataCenterInfo).getId();if(this.isBlank(dataCenterInfoId)) {boolean experimental = "true".equalsIgnoreCase(this.serverConfig.getExperimental("registration.validation.dataCenterInfoId"));if(experimental) {String amazonInfo1 = "DataCenterInfo of type " + dataCenterInfo.getClass() + " must contain a valid id";return Response.status(400).entity(amazonInfo1).build();}if(dataCenterInfo instanceof AmazonInfo) {AmazonInfo amazonInfo = (AmazonInfo)dataCenterInfo;String effectiveId = amazonInfo.get(MetaDataKey.instanceId);if(effectiveId == null) {amazonInfo.getMetadata().put(MetaDataKey.instanceId.getName(), info.getId());}} else {logger.warn("Registering DataCenterInfo of type {} without an appropriate id", dataCenterInfo.getClass());}}}this.registry.register(info, "true".equals(isReplication));return Response.status(204).build();}}在對注冊信息進行了一堆校驗之后，會調用 org.springframework.cloud.netflix.eureka.server.InstanceRegister 對象中的 register( InstanceInfo info, int leaseDuration, boolean isReplication) 函數來進行服務注冊：
public void register(InstanceInfo info, int leaseDuration, boolean isReplication) {this.handleRegistration(info, leaseDuration, isReplication);super.register(info, leaseDuration, isReplication);} private void handleRegistration(InstanceInfo info, int leaseDuration, boolean isReplication) {this.log("register " + info.getAppName() + ", vip " + info.getVIPAddress() + ", leaseDuration " + leaseDuration + ", isReplication " + isReplication);this.publishEvent(new EurekaInstanceRegisteredEvent(this, info, leaseDuration, isReplication));}在注冊函數中，先調用publishEvent 函數，將該新服務注冊的事件傳播出去，然后調用 com.netflix.eureka.registry.AbstractInstanceRegistry 父類中的注冊實現，將 InstanceInfo 中的元數據信息存儲在一個 ConcurrentHashMap 對象中。正如之前所說，注冊中心存儲了兩層 Map 結構，第一層的key 存儲服務名： InstanceInfo 中的APPName 屬性，第二層的 key 存儲實例名：InstanceInfo中的 instanceId 屬性。
配置詳解
在 Eureka 的服務治理體系中，主要分為服務端和客戶端兩個不同的角色，服務端為服務注冊中心，而客戶端為各個提供接口的微服務應用。當我們構建了高可用的注冊中心之后，該集群中所有的微服務應用和后續將要介紹的一些基礎類應用（如配置中心、API網關等）都可以視為該體系下的一個微服務（Eureka客戶端）。服務注冊中心也一樣，只是高可用環境下的服務注冊中心除了服務端之外，還為集群中的其他客戶端提供了服務注冊的特殊功能。所以，Eureka 客戶端的配置對象存在于所有 Eureka 服務治理體系下的應用實例中。在使用使用 Spring cloud Eureka 的過程中， 我們所做的配置內容幾乎都是對 Eureka 客戶端配置進行的操作，所以了解這部分的配置內容，對于用好 Eureka 非常有幫助。
Eureka 客戶端的配置主要分為以下兩個方面：
- 服務注冊相關的配置信息，包括服務注冊中心的地址、服務獲取的間隔時間、可用區域等。
- 服務實例相關的配置信息，包括服務實例的名稱、IP地址、端口號、健康檢查路徑等。
服務注冊類配置
關于服務注冊類的配置信息，我們可以通過查看 org.springframework.cloud.netflix.eureka.EurekaClientConfigBean 的源碼來獲得比官方文檔中更為詳盡的內容，這些配置信息都已 eureka.client 為前綴。下面針對一些常用的配置信息做進一步的介紹和說明。
指定注冊中心
在配置文件中通過?eureka.client.service-url 實現。該參數定義如下所示，它的配置值存儲在HashMap類型中，并且設置有一組默認值，默認值的key為 defaultZone、value 為 http://localhost:8761/eureka/，類名為?EurekaClientConfigBean。
private Map<String, String> serviceUrl = new HashMap();this.serviceUrl.put("defaultZone", "http://localhost:8761/eureka/");public static final String DEFAULT_URL = "http://localhost:8761/eureka/"; public static final String DEFAULT_ZONE = "defaultZone";由于之前的服務注冊中心使用了 8082 端口，所以我們做了如下配置，來講應用注冊到對應的 Eureka 服務端中。
eureka.client.service-url.defaultZone=http://localhost:8082/eureka/當構建了高可用的服務注冊中心集群時，可以為參數的value 值配置多個注冊中心的地址（逗號分隔）：
eureka.client.service-url.defaultZone=http://peer1:1111/eureka/,http://peer2:1112/eureka/另外，為了服務注冊中心的安全考慮，很多時候會為服務注冊中心加入安全校驗。這個時候，在配置serviceUrl時，需要在value 值的 URL 中加入響應的安全校驗信息，比如： http://<username>:<password>@localhost:1111/eureka。其中<username>為安全校驗信息的用戶名，<password>為該用戶的密碼。
其他配置
這些參數均以 eureka.client 為前綴。
服務實例類配置
關于服務實例類的配置信息，可以通過查看 org.springframework.cloud.netflix.eureka.EurekaInstanceConfigBean 的源碼來獲取詳細內容，這些配置均以 eureka.instance 為前綴。
元數據
在?org.springframework.cloud.netflix.eureka.EurekaInstanceConfigBean 的配置信息中，有一大部分內容都是對服務實例元數據的配置，元數據是 Eureka 客戶端在向注冊中心發送注冊請求時，用來描述自身服務信息的對象，其中包含了一些標準化的元數據，比如服務名稱、實例名稱、實例IP、實例端口等用于服務治理的重要信息；以及一些用于負載均衡策略或是其他特殊用途的自定義元數據信息。
在使用 Spring Cloud Eureka 的時候，所有的配置信息都通過?org.springframework.cloud.netflix.eureka.EurekaInstanceConfigBean 進行加載，但在真正進行服務注冊時，還是會包裝成 com.netflix.appinfo.InstanceInfo 對象發送給 Eureka 客戶端。這兩個類的定義非常相似，可以直接查看 com.netflix.appinfo.InstanceInfo 類中的詳細定義來了解原聲的 Eureka 對元數據的定義。其中，Map<String, String> metaData = new ConcurrentHashMap<String, String>(); 是自定義的元數據信息，而其他成員變量則是標準化的元數據信息。Spring Cloud 的EurekaInstanceConfigBean 對原生元數據對象做了一些配置優化處理，在后續的介紹中會提到這些內容。
我們可以通過 eureka.instance.<properties>=<value> 的格式對標準化元數據直接進行配置，<properties> 就是 EurekaInstanceConfigBean 對象中的成員變量名。對于自定義元數據，可以通過 eureka.instance.metadataMap.<key>=<value> 的格式來進行配置。
接著，針對一些常用的元數據配置做進一步的介紹和說明。
實例名配置
實例名，即 InstanceInfo 中的 instanceId 參數，它是區分同一服務中不同實例的唯一標識。在NetflixEureka 的原生實現中，實例名采用主機名作為默認值，這樣的設置使得在同一主機上無法啟動多個相同的服務實例。所以，在 Spring Cloud Eureka 的配置中，針對同一主機中啟動多實例的情況，對實例名的默認命名做了更為合理的擴展，它采用了如下默認規則：
${spring.cloud.client.hostname}:${spring.application.name}:${spring.application.instance_id}:${server.port}對于實例名的命名規則，可以通過eureka.instance.instanceId 參數來進行配置。比如，在本地進行客戶端負載均衡調試時，需要啟動同一服務的多個實例，如果我們直接啟動同一個應用必然會發生端口沖突。雖然可以在命令行中指定不同的server.port 來啟動，但這樣略顯麻煩?？梢灾苯油ㄟ^設置 server.port=0 或者使用隨機數 server.port=${random.int[10000,19999]} 來讓Tomcat 啟動的時候采用隨機端口。但是這個時候會發現注冊到 Eureka Server的實例名都是相同的，這會使得只有一個服務實例能夠正常提供服務。對于這個問題，就可以通過設置實例名規則來輕松解決：
eureka.instance.instanceId=${spring.application.name}:${random.int}通過上面的配置，利用應用名+隨機數的方式來區分不同的實例，從而實現在同一個主機上，不指定端就能輕松啟動多個實例的效果。
總結
以上是生活随笔為你收集整理的Eureka服务治理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 在Finder标题栏上显示完整路径
- 下一篇： 中文分词之HMM模型详解