第3章
Eureka注冊中心
注冊中心在微服務架構中是必不可少的一部分，主要用來實作服務治理功能，本章我們将學習如何用 Netflix 提供的 Eureka 作為注冊中心，來實作服務治理的功能。
3.1 Eureka
Spring Cloud Eureka 是 Spring Cloud Netflix 微服務套件的一部分，基于 Netflix Eureka 做了二次封裝，主要負責實作微服務架構中的服務治理功能。Spring Cloud Eureka 是一個基于 REST 的服務，并且提供了基于 Java 的用戶端元件，能夠非常友善地将服務注冊到Spring Cloud Eureka 中進行統一管理。
服務治理是微服務架構中必不可少的一部分，阿裡開源的 Dubbo 架構就是針對服務治理的。服務治理必須要有一個注冊中心，除了用 Eureka 作為注冊中心外，我們還可以使用 Consul、Etcd、Zookeeper等來作為服務的注冊中心。
用過 Dubbo 的讀者應該清楚，Dubbo中也有幾種注冊中心，比如基于Zookeeper、基于 Redis 等，不過用得最多的還是 Zookeeper方式。至于使用哪種方式都是可以的，注冊中心無非就是管理所有服務的資訊和狀态。若用我們生活中的例子來說明的話，筆者覺得12306 網站比較合适。
首先，12306網站就好比一個注冊中心，顧客就好比調用的用戶端，當他們需要坐火車時，就會登入12306 網站上查詢餘票，有票就可以購買，然後擷取火車的車次、時間等，最後出發。
程式也是一樣，當你需要調用某一個服務的時候，你會先去 Eureka 中去拉取服務清單，檢視你調用的服務在不在其中，在的話就拿到服務位址、端口等資訊，然後調用。
注冊中心帶來的好處就是，不需要知道有多少提供方，你隻需要關注注冊中心即可，就像顧客不必關心有多少火車在開行，隻需要去12306網站上看有沒有票就可以了。
為什麼Eureka 比 Zookeeper 更适合作為注冊中心呢？主要是因為 Eureka 是基于 AP 原則建構的，而 ZooKeeper 是基于 CP 原則建構的。在分布式系統領域有個著名的 CAP 定理， 即 C 為資料一緻性；A 為服務可用性；P 為服務對網絡分區故障的容錯性。這三個特性在任何分布式系統中都不能同時滿足，最多同時滿足兩個。
Zookeeper 有一個 Leader，而且在這個Leader 無法使用的時候通過 Paxos（ZAB）算法選舉出一個新的 Leader。這個 Leader 的任務就是保證寫資料的時候隻向這個 Leader 寫入， Leader 會同步資訊到其他節點。通過這個操作就可以保證資料的一緻性。
總而言之，想要保證 AP 就要用 Eureka，想要保證 CP 就要用 Zookeeper。Dubbo 中大部分都是基于 Zookeeper 作為注冊中心的。Spring Cloud 中當然首選 Eureka。
3.2 使用 Eureka 編寫注冊中心服務
首先建立一個 Maven 項目，取名為 eureka-server，在 pom.xml 中配置 Eureka 的依賴資訊，如代碼清單 3-1 所示。
建立一個啟動類 EurekaServerApplication，如代碼清單 3-2 所示。
這裡所說的啟動類，跟我們之前講的 Spring Boot 幾乎完全一樣，隻是多了一個 @EnableEurekaServer 注解，表示開啟 Eureka Server。
接下來在 src/main/resources 下面建立一個 application.properties 屬性檔案，增加下面的配置：
eureka.client.register-with- eureka 一定要配置為 false，不然啟動時會把自己當作用戶端向自己注冊，會報錯。
接下來直接運作EurekaServerApplication 就可以啟動我們的注冊中心服務了。我們在 application.properties 配置的端口是 8761，則可以直接通過
http://localhost:8761/去浏覽器中通路，然後便會看到Eureka 提供的 Web 控制台，如圖3-1 所示。
3.3 編寫服務提供者
3.3.1 建立項目注冊到Eureka
注冊中心已經建立并且啟動好了，接下來我們實作将一個服務提供者eureka-client-user-service 注冊到 Eureka 中，并提供一個接口給其他服務調用。
首先還是建立一個 Maven 項目，然後在 pom.xml 中增加相關依賴，如代碼清單 3-3
所示。
建立一個啟動類App，代碼如代碼清單 3-4 所示。
啟動類的方法與之前沒有多大差別，隻是注解換成@EnableDiscoveryClient，表示目前服務是一個 Eureka 的用戶端。
接下來在src/main/resources下面建立一個 application.properties屬性檔案，增加下面的配置：
eureka.client.serviceUrl.defaultZone 的位址就是我們之前啟動的 Eureka 服務的位址，在啟動的時候需要将自身的資訊注冊到 Eureka 中去。
執行 App 啟動服務，我們可以看到控制台中有輸出注冊資訊的日志：
DiscoveryClient_EUREKA-CLIENT-USER-SERVICE/eureka-client-user-service:192.168.31.245:8081 - registration status: 204
我們可以進一步檢查服務是否注冊成功。回到之前打開的Eureka 的 Web 控制台，重新整理頁面，就可以看到新注冊的服務資訊了，如圖3-2 所示。
3.3.2 編寫提供接口
建立一個 Controller，提供一個接口給其他服務查詢，如代碼清單 3-5 所示。
重新開機服務，通路
http://localhost:8081/user/hello，如果能看到我們傳回的 Hello 字元串，就證明接口提供成功了。
3.4 編寫服務消費者
3.4.1 直接調用接口
建立服務消費者，消費我們剛剛編寫的 user/hello 接口，同樣需要先建立一個 Maven 項目eureka-client-article-service，然後添加依賴，依賴和服務提供者的一樣，這裡就不貼代碼了。
建立啟動類App，啟動代碼與前面所講也是一樣的。唯一不同的就是 application.properties 檔案中的配置資訊：
spring.application.name=eureka-client-article-service
server.port=8082
RestTemplate 是Spring提供的用于通路 Rest 服務的用戶端，RestTemplate 提供了多種便捷通路遠端 Http 服務的方法，能夠大大提高用戶端的編寫效率。我們通過配置RestTemplate 來調用接口，如代碼清單 3-6 所示。
建立接口，在接口中調用 user/hello 接口，代碼如代碼清單 3-7 所示。
執行App啟動消費者服務，通路/article/callHello 接口來看看有沒有傳回 Hello 字元串，如果傳回了就證明調用成功。通路位址為
http://localhost:8082/article/callHello。
3.4.2 通過Eureka來消費接口
上面提到的方法是直接通過服務接口的位址來調用的，和我們之前的做法一樣，完全沒有用到 Eureka 帶給我們的便利。既然用了注冊中心，那麼用戶端調用的時候肯定是不需要關心有多少個服務提供接口，下面我們來改造之前的調用代碼。
首先改造 RestTemplate 的配置，添加一個 @LoadBalanced 注解，這個注解會自動構造LoadBalancerClient 接口的實作類并注冊到 Spring 容器中，如代碼清單 3-8 所示。
接下來就是改造調用代碼，我們不再直接寫固定位址，而是寫成服務的名稱，這個名稱就是我們注冊到 Eureka 中的名稱，是屬性檔案中的 spring.application.name，相關代碼如代碼清單 3-9 所示。
3.5 開啟 Eureka 認證
Eureka 自帶了一個 Web 的管理頁面，友善我們查詢注冊到上面的執行個體資訊，但是有一個問題：如果在實際使用中，注冊中心位址有公網 IP 的話，必然能直接通路到，這樣是不安全的。是以我們需要對 Eureka 進行改造，加上權限認證來保證安全性。
改造我們的 eureka-server，通過內建 Spring-Security 來進行安全認證。
在 pom.xml 中添加 Spring-Security 的依賴包，如代碼清單 3-10 所示。
然後在 application.properties 中加上認證的配置資訊：
spring.security.user.name=yinjihuan #使用者名
spring.security.user.password=123456 #密碼
增加Security配置類：
重新啟動注冊中心，通路
，此時浏覽器會提示你輸入使用者名和密碼，輸入正确後才能繼續通路 Eureka 提供的管理頁面。
在 Eureka 開啟認證後，用戶端注冊的配置也要加上認證的使用者名和密碼資訊：
eureka.client.serviceUrl.defaultZone=
http://yinjihuan:123456@localhost:8761/eureka/ 3.6 Eureka高可用搭建
3.6.1 高可用原理
前面我們搭建的注冊中心隻适合本地開發使用，在生産環境中必須搭建一個叢集來保證高可用。Eureka 的叢集搭建方法很簡單：每一台 Eureka 隻需要在配置中指定另外多個Eureka 的位址就可以實作一個叢集的搭建了。
下面我們以 2 個節點為例來說明搭建方式。假設我們有 master 和 slaveone 兩台機器， 需要做的就是：
- 将 master 注冊到 slaveone 上面。
- 将 slaveone 注冊到 master 上面。
如果是 3 台機器，以此類推：
- 将 master 注冊到 slaveone 和 slavetwo 上面。
- 将 slaveone 注冊到 master 和 slavetwo 上面。
- 将 slavetwo 注冊到 master 和 slaveone 上面。
3.6.2 搭建步驟
建立一個新的項目eureka-server-cluster，配置跟eureka-server一樣。
首先，我們需要增加 2 個屬性檔案，在不同的環境下啟動不同的執行個體。增加 application-master.properties：
在A機器上預設用 master啟動，然後在B機器上加上 --spring.profiles.active= slaveone 啟動即可。
這樣就将master注冊到了slaveone中，将slaveone 注冊到了master中，無論誰出現問題，應用都能繼續使用存活的注冊中心。
之前在用戶端中我們通過配置eureka.client.serviceUrl.defaultZone來指定對應的注冊中心，當我們的注冊中心有多個節點後，就需要修改eureka.client.serviceUrl.defaultZone的配置為多個節點的位址，多個位址用英文逗号隔開即可：
http://yinjihuan:123456@localhost:8761/eureka/,http://yinjihuan:123456@localhost:8762/eureka/ 3.7 常用配置講解
3.7.1 關閉自我保護
保護模式主要在一組用戶端和 Eureka Server 之間存在網絡分區場景時使用。一旦進入保護模式，Eureka Server 将會嘗試保護其服務的系統資料庫中的資訊，不再删除服務系統資料庫中的資料。當網絡故障恢複後，該 Eureka Server 節點會自動退出保護模式。
如果在 Eureka 的 Web 控制台看到圖3-3 所示的内容，就證明Eureka Server進入保護模式了。
可以通過下面的配置将自我保護模式關閉，這個配置是在eureka-server 中：
eureka.server.enableSelfPreservation=false
3.7.2 自定義Eureka的InstanceID
用戶端在注冊時，服務的 Instance ID 的預設值的格式如下：
${spring.cloud.client.hostname}:${spring.application.name}:${spring.application. instance_id:${server.port}}
翻譯過來就是“主機名：服務名稱：服務端口”。當我們在 Eureka 的 Web 控制台檢視服務注冊資訊的時候，就是這樣的一個格式：user-PC:eureka-client-user-service:8081。
很多時候我們想把 IP 顯示在上述格式中，此時，隻要把主機名替換成 IP 就可以了，或者調整順序也可以。可以改成下面的樣子，用“服務名稱：服務所在IP：服務端口”的格式來定義：
eureka.instance.instance-id=${spring.application.name}:${spring.cloud.client.ip-address}:${server.port}
定義之後我們看到的就是 eureka-client-user-service:192.168.31.245:8081，一看就知道是哪個服務，在哪台機器上，端口是多少。
我們還可以點選服務的 Instance ID 進行跳轉，這個時候顯示的名稱雖然變成了 IP，但是跳轉的連結卻還是主機名，請看圖3-4 所示界面的左下角。
是以還需要加一個配置才能讓跳轉的連結變成我們想要的樣子，使用 IP 進行注冊，如圖3-5 所示：
eureka.instance.preferIpAddress=true
3.7.3 自定義執行個體跳轉連結
在3.7.2中，我們通過配置實作了用 IP 進行注冊，當點選 Instance ID 進行跳轉的時候，就可以用 IP 跳轉了，跳轉的位址預設是 IP+Port/info。我們可以自定義這個跳轉的位址：
eureka.instance.status-page-url=
http://cxytiandi.com效果如圖3-6 所示。
3.7.4 快速移除已經失效的服務資訊
在實際開發過程中，我們可能會不停地重新開機服務，由于 Eureka 有自己的保護機制，故節點下線後，服務資訊還會一直存在于 Eureka 中。我們可以通過增加一些配置讓移除的速度更快一點，當然隻在開發環境下使用，生産環境下不推薦使用。
首先在我們的eureka-server中增加兩個配置，分别是關閉自我保護和清理間隔：
eureka.client.healthcheck.enabled 用于開啟健康檢查，需要在 pom.xml 中引入 actuator
的依賴，如代碼清單 3-12 所示。
其中：
- eureka.instance.lease-renewal-interval-in-seconds表示Eureka Client發送心跳給server端的頻率。
- eureka.instance.lease-expiration-duration-in-seconds 表示 Eureka Server 至上一次收到client 的心跳之後，等待下一次心跳的逾時時間，在這個時間内若沒收到下一次心跳，則移除該 Instance。
更多的Instance 配置資訊可參考源碼中的配置類：org.springframework.cloud.netflix. eureka.
EurekaInstanceConfigBean。
更多的Server配置資訊可參考源碼中的配置類：org.springframework.cloud.netflix. eureka. server.EurekaServerConfigBean。
3.8 擴充使用
3.8.1 Eureka REST API
Eureka 作為注冊中心，其本質是存儲了每個用戶端的注冊資訊，Ribbon 在轉發的時候會擷取注冊中心的服務清單，然後根據對應的路由規則來選擇一個服務給 Feign 來進行調用。如果我們不是 Spring Cloud 技術選型，也想用 Eureka，可以嗎？完全可以。
如果不是 Spring Cloud 技術棧，筆者推薦用 Zookeeper，這樣會友善些，當然用 Eureka 也是可以的，這樣的話就會涉及如何注冊資訊、如何擷取注冊資訊等操作。其實 Eureka 也考慮到了這點，提供了很多 REST 接口來給我們調用。
我們舉一個比較有用的案例來說明，比如對 Nginx 動态進行 upstream 的配置。
在架構變成微服務之後，微服務是沒有依賴的，可以獨立部署，端口也可以随機配置設定， 反正會注冊到注冊中心裡面，調用方也無須關心提供方的 IP和Port，這些都可以從注冊中心拿到。但是有一個問題：API 網關的部署能這樣嗎？API網關大部分會用 Nginx 作為負載，那麼Nginx就必須知道API網關有哪幾個節點，這樣網關服務就不能随便啟動了，需要固定。
當然網關是不會經常變動的，也不會經常釋出，這樣其實也沒什麼大問題，唯一不好的就是不能自動擴容了。
其實利用 Eureka 提供的 API 我們可以擷取某個服務的執行個體資訊，也就是說我們可以根據 Eureka 中的資料來動态配置 Nginx 的 upstream。
這樣就可以做到網關的自動部署和擴容了。網上也有很多的方案，結合 Lua 腳本來做， 或者自己寫 Sheel 腳本都可以。
下面舉例說明如何擷取 Eureka 中注冊的資訊。具體的接口資訊請檢視官方文檔：
https://github.com/Netflix/eureka/wiki/Eureka-REST-operations擷取某個服務的注冊資訊，可以直接 GET 請求：
http://localhost:8761/eureka/apps/eureka-client-user-service。其中，eureka-client-user-service 是應用名稱，也就是 spring.application.name。
在浏覽器中，資料的顯示格式預設是 XML 格式的，如圖3-7 所示。
如果想傳回 Json 資料的格式，可以用一些接口測試工具來請求，比如 Postman，在請求頭中添加下面兩行代碼即可，具體如圖3-8 所示。
Content-Type:application/json Accept:application/json
如果 Eureka 開啟了認證，記得添加認證資訊，使用者名和密碼必須是 Base64 編碼過的 Authorization:Basic 使用者名：密碼，其餘的接口就不做過多講解了，大家可以自己去嘗試。Postman 直接支援了 Basic 認證，将選項從 Headers 切換到 Authorization，選擇認證方式為 Basic Auth 就可以填寫使用者資訊了，如圖3-9 所示。
填寫完之後，直接發起請求就可以了。我們切換到 Headers 選項中，就可以看到請求頭中已經多了一個 Authorization 頭。
3.8.2 中繼資料使用
Eureka 的中繼資料有兩種類型，分别是架構定好了的标準中繼資料和使用者自定義中繼資料。标準中繼資料指的是主機名、IP 位址、端口号、狀态頁和健康檢查等資訊，這些資訊都會被釋出在服務系統資料庫中，用于服務之間的調用。自定義中繼資料可以使用 eureka.instance. metadataMap 進行配置。
自定義中繼資料說得通俗點就是自定義配置，我們可以為每個 Eureka Client 定義一些屬于自己的配置，這個配置不會影響 Eureka 的功能。自定義中繼資料可以用來做一些擴充資訊，比如灰階釋出之類的功能，可以用中繼資料來存儲灰階釋出的狀态資料，Ribbon 轉發的時候就可以根據服務的中繼資料來做一些處理。當不需要灰階釋出的時候可以調用 Eureka 提供的 REST API 将中繼資料清除掉。
下面我們來自定義一個簡單的中繼資料，在屬性檔案中配置如下：
eureka.instance.metadataMap.yuantiandi=yinjihuan
上述代碼定義了一個 key 為 yuantiandi 的配置，value 是 yinjihuan。重新開機服務，然後通過 Eureka 提供的 REST API 來檢視剛剛配置的中繼資料是否已經存在于 Eureka 中，如圖3-10 所示。
3.8.3 EurekaClient使用
當我們的項目中內建了 Eureka 之後，可以通過 EurekaClient 來擷取一些我們想要的資料，比如上節講的中繼資料。我們就可以直接通過 EurekaClient 來擷取（見代碼清單 3-13），不用再去調用 Eureka 提供的 REST API。
通過 PostMan 來調用接口看看有沒有傳回我們想要的資料，如圖3-11 所示。
可以看到，通過 EurekaClient 擷取的資料跟我們自己去掉 API 擷取的資料是一樣的， 從使用角度來說前者比較友善。
除了使用 EurekaClient，還可以使用 DiscoveryClient（見代碼清單 3-14），這個不是 Feign 自帶的，是 Spring Cloud 重新封裝的，類的路徑為 org.springframework.cloud.client. discovery.DiscoveryClient。
3.8.4 健康檢查
預設情況下，Eureka 用戶端是使用心跳和服務端通信來判斷用戶端是否存活，在某些場景下，比如MongoDB出現了異常，但你的應用程序還是存在的，這就意味着應用可以繼續通過心跳上報，保持應用自己的資訊在Eureka中不被剔除掉。
Spring Boot Actuator 提供了 /actuator/health 端點，該端點可展示應用程式的健康資訊，當MongoDB異常時，/actuator/health 端點的狀态會變成DOWN，由于應用本身确實處于存活狀态，但是MongoDB的異常會影響某些功能，當請求到達應用之後會發生操作失敗的
情況。
在這種情況下，我們希望可以将健康資訊傳遞給 Eureka 服務端。這樣Eureka中就能及時将應用的執行個體資訊下線，隔離正常請求，防止出錯。通過配置如下内容開啟健康檢查：
eureka.client.healthcheck.enabled=true
我們可以通過擴充健康檢查的端點來模拟異常情況，定義一個擴充端點，将狀态設定為DOWN，如代碼清單 3-15 所示。
擴充好後我們通路/actuator/health可以看到目前的狀态是DOWN，如圖3-12所示。
Eureka中的狀态是UP，如圖3-13所示。
這種情況下請求還是能轉發到這個服務中，下面我們開啟監控檢查，再次檢視Eureka中的狀态，如圖3-14所示。
3.8.5 服務上下線監控
在某些特定的需求下，我們需要對服務的上下線進行監控，上線或下線都進行郵件通知，Eureka 中提供了事件監聽的方式來擴充。
目前支援的事件如下：
- EurekaInstanceCanceledEvent 服務下線事件。
- EurekaInstanceRegisteredEvent 服務注冊事件。
- EurekaInstanceRenewedEvent 服務續約事件。
- EurekaRegistryAvailableEvent Eureka 注冊中心啟動事件。
- EurekaServerStartedEvent Eureka Server 啟動事件。
基于 Eureka 提供的事件機制，可以監控服務的上下線過程，在過程發生中可以發送郵件來進行通知。代碼清單3-16隻是示範了監控的過程，并未發送郵件。
注意:在Eureka叢集環境下，每個節點都會觸發事件，這個時候需要控制下發送通知的行為，不控制的話每個節點都會發送通知。
3.9 本章小結
通過本章的學習，我們已經能夠獨立搭建一個高可用的 Eureka 注冊中心，通過服務提供者和服務消費者的案例我們也對 Eureka 進行了實際的運用。本章最後講解了一些經常用到的配置資訊及 Eureka 的 REST API，通過 API 可以做一些擴充。