Eureka是Netflix開發的服務發現元件，本身是一個基於REST的服務。Spring Cloud將它整合在其子專案spring-cloud-netflix中，以實現Spring Cloud的服務發現功能。目前Eureka 專案相當活躍，程式碼更新相當頻繁，目前最新的版本是1.5.5。Eureka 2.0也在緊鑼密鼓地開發中，2.0將會帶來更強的功能和更好的擴充套件性，但是由於還沒有Release，故而不作討論。

本文講解的Spring Cloud Camden SR1所使用的Eureka版本是1.4.11，還是比較新的。同時有了Eureka 1.x的基礎，未來上手Eureka 2.x也會比較容易。

Region、Zone解析

Eureka的官方文件對regin、zone幾乎沒有提及，由於概念抽象，新手很難理解。因此，在分析Eureka原理之前，我們先來了解一下region、zone、Eureka叢集三者的關係，如圖4-2。

圖4-2 region、zone、Eureka叢集之間的關係

region和zone（或者Availability Zone）均是AWS的概念。在非AWS環境下，我們可以簡單地將region理解為Eureka叢集，zone理解成機房。這樣圖4-2就很好理解了——一個Eureka叢集被部署在了zone1機房和zone2機房中。

Eureka架構

圖4-3 Eureka架構圖

圖4-3是來自Eureka官方的架構圖，大致描述了Eureka叢集的工作過程。圖中包含的元件非常多，可能比較難以理解，我們用通俗易懂的語言解釋一下：

• Application Service 相當於本書中的服務提供者，Application Client相當於本書中的服務消費者；
• Make Remote Call，可以簡單理解為呼叫RESTful API；
• us-east-1c、us-east-1d等都是zone，它們都屬於us-east-1這個region；

由圖可知，Eureka包含兩個元件：Eureka Server 和 Eureka Client，它們的作用如下：

• Eureka Client是一個Java客戶端，用於簡化與Eureka Server的互動；

• Eureka Server提供服務發現的能力，各個微服務啟動時，會通過Eureka Client向Eureka Server進行註冊自己的資訊（例如網路資訊），Eureka Server會儲存該服務的資訊；
• 微服務啟動後，會週期性地向Eureka Server傳送心跳（預設週期為30秒）以續約自己的資訊。如果Eureka Server在一定時間內沒有接收到某個微服務節點的心跳，Eureka Server將會登出該微服務節點（預設90秒）；
• 每個Eureka Server同時也是Eureka Client，多個Eureka Server之間通過複製的方式完成服務登錄檔的同步；
• Eureka Client會快取Eureka Server中的資訊。即使所有的Eureka Server節點都宕掉，服務消費者依然可以使用快取中的資訊找到服務提供者。

綜上，Eureka通過心跳檢測、健康檢查和客戶端快取等機制，提高了系統的靈活性、可伸縮性和可用性。