微服務架構中，服務發現元件是一個非常關鍵的元件，服務消費者、服務提供者、服務發現元件的關係大致如下：

• 各個微服務啟動時，將自己的網路地址等資訊註冊到服務發現元件中，服務發現元件會儲存這些資訊
• 服務消費者可從服務發現元件查詢服務提供者的網路地址，並使用改地址呼叫服務提供者的介面
• 各個微服務與服務發現元件使用一定機制（心跳等）通訊，服務發現元件長時間無法與某微服務例項通，就會登出該例項。

　　下面看看Eureka，它是Netflix（美國著名的線上影片租賃商）開源的服務發現元件，本身是一個基於REST的服務，它包含Server和Client兩部分，Spring Cloud將它整合在其子專案spring-cloud-netflix中，以實現Spring Cloud的服務發現功能。

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

region和zone（或者Availability Zone）均是AWS的概念。在非AWS環境下，我們可以簡單地將region理解為Eureka叢集，zone理解成機房。這樣上圖就很好理解了——一個Eureka叢集被部署在了zone1機房和zone2機房中。對region和zone感興趣的讀者可前往http://blog.csdn.net/awschina/article/details/17639191

eureka架構圖

上圖是來自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通過心跳檢測、健康檢查和客戶端快取等機制，提高了系統的靈活性、可伸縮性和可用性。