Eureka原理
Region和Availability Zone均是AWS的概念。
- Region表示AWS中的地理位置，例如us-east-1、us-east-2、eu-west-1等；
- 每個Region都有多個Availability Zone，彼此內網打通；
- 各個Region之間完全隔離，彼此內網不打通；
- AWS通過這種方式實現了最大的容錯和穩定性。
Spring Cloud中，默認使用的Region是us-east-1,部分含義如下：
|
|
US East (N. Virginia) |
|
|
US East (Ohio) |
|
|
US West (N. California) |
|
|
US West (Oregon) |
。
非AWS環境下，可將將Region理解為內網沒有打通的機房，將Availability Zone理解成相同機房的不同機架（內網打通）。
Eureka架構詳解
如圖是Eureka集群的工作原理。圖中的組件非常多，概念也比較抽象，我們先來用通俗易懂的文字翻譯一下：
-
Application Service：服務提供者；
-
Application Client：服務消費者；
-
Make Remote Call調用RESTful API；
-
us-east-1c、us-east-1d等都是Availability Zone，它們都屬於us-east-1這個region。
由圖可知，Eureka包含兩個組件：Eureka Server 和 Eureka Client，它們的作用如下：
-
Eureka Server提供服務發現的能力，各個微服務啟動時，會向Eureka Server注冊自己的信息（例如IP、端口、微服務名稱等），Eureka Server會存儲這些信息；
-
Eureka Client是一個Java客戶端，用於簡化與Eureka Server的交互；
-
微服務啟動后，會周期性（默認30秒）地向Eureka Server發送心跳以續約自己的“租期”；
-
如果Eureka Server在一定時間內沒有接收到某個微服務實例的心跳，Eureka Server將會注銷該實例（默認90秒）；
-
默認情況下，Eureka Server同時也是Eureka Client。多個Eureka Server實例，互相之間通過增量復制的方式，來實現服務注冊表中數據的同步。Eureka Server默認保證在90秒內，Eureka Server集群內的所有實例中的數據達到一致（從這個架構來看，Eureka Server所有實例所處的角色都是對等的，沒有類似Zookeeper、Consul、Etcd等軟件的選舉過程，也不存在主從，所有的節點都是主節點。Eureka官方將Eureka Server集群中的所有實例稱為“對等體（peer）”）
-
Eureka Client會緩存服務注冊表中的信息。這種方式有一定的優勢——首先，微服務無需每次請求都查詢Eureka Server，從而降低了Eureka Server的壓力；其次，即使Eureka Server所有節點都宕掉，服務消費者依然可以使用緩存中的信息找到服務提供者並完成調用。
綜上，Eureka通過心跳檢查、客戶端緩存等機制，提高了系統的靈活性、可伸縮性和可用性。
TIPS
事實上，這個官方架構圖是有一點問題的：Eureka Server本身也集成了Eureka Client，彼此通過Eureka Client同步數據給其它實例又或者從其他實例同步數據