Eureka大白話解析

筆記補錄：

1.Eureka 介紹

Spring Cloud Eureka 是 Spring Cloud Netflix 微服務套件的一部分，基于 Netflix Eureka 做了二次封裝，主要負責實現(xiàn)微服務架構中的服務治理功能。

服務治理是微服務架構中必不可少的一部分，阿里開源的 Dubbo 框架就是針對服務治理的。服務治理必須要有一個注冊中心，除了用 Eureka 作為注冊中心外，我們還可以使用 Consul、Etcd、Zookeeper 等來作為服務的注冊中心。

Eureka 由兩部分組成：服務端和客戶端，服務端就是注冊中心，用來接收其它的服務注冊，客戶端是一個java客戶端，用來注冊，并可以實現(xiàn)負載均衡等功能。 Eureka 的搭建和集群請點擊查看這篇文章。

Eureka圖解如下：

從圖中可以看出Eureka有三個角色：

• Eureka Server：注冊中心
• Eureka Provider：服務提供者
• Eureka Consumer：服務消費者

注冊中心就是管理所有服務的信息和狀態(tài)，12306 就好比一個注冊中心，顧客就好比調用的客戶端，當他們需要坐火車時，就會在 12306 網站上查詢余票，有票就可以購買，然后獲取火車的車次、時間等，最后出發(fā)。程序也是一樣，當你需要調用某一個服務的時候，你會先去 Eureka 中去拉取服務列表，查看你調用的服務在不在其中，在的話就拿到服務地址、端口等信息，然后調用。

注冊中心帶來的好處就是，不需要知道有多少提供方，你只需要關注注冊中心即可，就像顧客不必關心有多少火車在開行，只需要去 12306 網站上看有沒有票就可以了。

為什么 Eureka 比 Zookeeper 更適合作為注冊中心呢？主要是因為 Eureka 是基于 AP 原則構建的，而 ZooKeeper 是基于 CP 原則構建的。在分布式系統(tǒng)領域有個著名的 CAP 定理，即 C 為數(shù)據一致性；A 為服務可用性；P 為服務對網絡分區(qū)故障的容錯性。這三個特性在任何分布式系統(tǒng)中都不能同時滿足，最多同時滿足兩個。Zookeeper 有一個 Leader，而且在這個 Leader 無法使用的時候通過 Paxos（ZAB）算法選舉出一個新的 Leader。這個 Leader 的任務就是保證寫數(shù)據的時候只向這個 Leader 寫入，Leader 會同步信息到其他節(jié)點。通過這個操作就可以保證數(shù)據的一致性。 

想要保證 AP 就要用 Eureka，想要保證 CP 就要用 Zookeeper。 

Dubbo 中大部分都是基于 Zookeeper 作為注冊中心的。Spring Cloud 中當然首選 Eureka。

2. Eureka 的工作細節(jié)

2.1 Eureka Server

 Eureka Server主要對外提供了三個功能：

• 服務注冊，所有的服務都注冊到Eureka Server上面來
• 提供注冊表，注冊表就是所有注冊上來服務的一個列表，Eureka Client在調用服務時，需要獲取這個注冊表，一般來說，這個注冊表會緩存下來，如果緩存失效，則直接獲取最新的注冊表
• 同步狀態(tài)，Eureka Client 通過注冊、心跳等機制，和Eureka Server同步當前客戶端的狀態(tài)

2.2 Eureka Client

Eureka Client 主要是來簡化每一個服務和Eureka Server 之間的交互。Eureka Client 會自動拉取、更新以及緩存Eureka Server 中的信息，這樣，即便Eureka Server 所有節(jié)點都宕機，Eureka Client 依然能夠獲取到想要調服務的地址（但是地址可能不準確）。

2.2.1 服務注冊

 服務提供者將自己注冊到服務注冊中心(Eureka Server)，需要注意，所渭的服務提供者，只是一個業(yè)務上的劃分，本質上他就是一個 Eureka Client 。當 Eureka Client 向 Eureka Server 注冊時，他需要提供自身的一些元數(shù)據信息，例如IP地址、端囗、名稱、運行狀態(tài)等等。

2.2.2 服務續(xù)約

Eureka Client 注冊到 Eureka Server 上之后，事情還沒有結束，剛剛開始而已。注冊成功后，默認情況下，Eureka Client 每隔30秒就要向 Eureka Server 發(fā)送一條心跳消息，來告訴Eureka Server 我還在運行。如果 Eureka Server 連續(xù)90秒有沿有收到Eureka Client 的續(xù)約消息（連續(xù)三次沒發(fā)送），它會認為Eureka Client已經線了，會將掉線的Eureka Client從當前的服務注冊列表中剔除。

服務續(xù)約，有兩個相關的屬性（一般不建議修改）：

# 表示服務的續(xù)約時間，默認是30秒
eureka.instance.lease-renewal-intetval-in-seconds=30 
# 服務失效時間，默認是90秒
eureka.instance.lease-expiration-duration-in-seconds=90

2.2.3 服務下線

當 Eureka Client 下線時，它會主動發(fā)送一條消息，告訴Eureka Server，我下線了。

2.2.4 獲取注冊表信息

Eureka Client 從Eureka Server 上獲取服務的注冊信息，將其緩存在本地。本地客戶端在需要調用遠程服務時，會從該信息中查找遠程服務所對應的IP地址、端囗等信息。Eureka Client 上緩存的服務注冊信息會定期更新（30秒)，如果 Eureka Server 返回的注冊表信息與本地緩存的注冊表信息不同的話，Eureka Client 會自動處理。

這里，也涉及至兩個屬性，一個是是否允許獲取注冊表信息：

eureka.client.fetch-registry=true

Eureka Client 上緩存的服務注冊信息，定期更新的時間間隔，默認30秒：

eureka.client.registry-fetch-interval-seconds=30

Eureka分區(qū)策略

第一步：背景和概念介紹

背景：用戶量比較大或者用戶地理位置分布范圍很廣的項目，一般都會有多個機房。這個時候如果上線springCloud服務的話，我們希望一個機房內的服務優(yōu)先調用同一個機房內的服務，當同一個機房的服務不可用的時候，再去調用其它機房的服務，以達到減少延時的作用。

概念：region：能夠簡單理解為地理上的分區(qū)。好比亞洲地區(qū)，或者華北地區(qū)，再或者北京地區(qū)等等，沒有具體大小的限制，根據項目具體的狀況，能夠自行劃分region。 zone：能夠簡單理解為 region 內的具體機房，好比說 region 劃分為華北地區(qū)，而后華北地區(qū)有兩個機房，就能夠在此 region 之下劃分出 zone1、zone2 兩個 zone eureka 也借用了 region 和 zone 的概念架構 

如圖所示，有一個 region:華北地區(qū)，下面有兩個機房，機房A 和機房Burl

• 每一個機房內有一個 Eureka Server 集群 和兩個服務提供者 ServiceA 和 ServerB
• 如今假設 serverA 須要調用 ServerB 服務，按照就近原則，serverA 會優(yōu)先調用同一個 zone 內的 ServiceB，當 ServiceB 不可用時，才會去調用另外一個 zone 內的 ServiceBcode

第二步：相關參數(shù)介紹

服務注冊相關:

 eureka: client: # 盡可能向同一區(qū)域的 eureka 注冊,默認為true prefer-same-zone-eureka: true #地區(qū) region: huabei availability-zones: huabei: zone-1,zone-2 service-url: zone-1: http://Eureka的Ip地址:8761/eureka/ zone-2: http://Eureka的Ip地址:8761/eureka/

當存在多個注冊中心時，選擇邏輯為cdn

• 若是 prefer-same-zone-eureka 為 false，按照 service-url 下的 list 取第一個注冊中心來注冊，并和其維持心跳檢測，再也不向list內的其它的注冊中心注冊和維持心跳。server只有在第一個注冊失敗的狀況下，才會依次向其它的注冊中心注冊，總共重試3次，若是3個service-url都沒有注冊成功，則注冊失敗。blog

注冊失敗后每隔一個心跳時間，會再次嘗試。it

• 若是 prefer-same-zone-eureka 為true，先經過 region 取 availability-zones 內的第一個zone，而后經過這個zone取 service-url 下的list，并向list內的第一個注冊中心進行注冊和維持心跳，再也不向list內的其它的注冊中心注冊和維持心跳。只有在第一個注冊失敗的狀況下，才會依次向其它的注冊中心注冊，總共重試3次，若是3個service-url都沒有注冊成功，則注冊失敗。注冊失敗后每隔一個心跳時間，會再次嘗試。

為了保證服務注冊到同一個 zone 的注冊中心，必定要注意 availability-zones 的順序，必須把同一 zone 寫在最前面

eureka: instance: # 服務和注冊中心的心跳間隔時間，默認為30s lease-renewal-interval-in-seconds: 30 # 服務和注冊中心的心跳超時時間，默認為90s lease-expiration-duration-in-seconds: 90 metadata-map: # 當前服務所屬的 zone zone: zone1

• 服務消費者和服務提供者分別屬于哪一個zone，均是經過 eureka.instance.metadata-map.zone 來斷定的。
• 服務消費者會先經過 ribbon 去注冊中心拉取一份服務提供者的列表，而后經過 eureka.instance.metadata-map.zone 指定的 zone 進行過濾，過濾以后若是同一個 zone 內的服務提供者有多個實例，則會輪流調用。
• 只有在同一個 zone 內的全部服務提供者都不可用時，才會調用其它zone內的服務提供者。

以上為個人經驗，希望能給大家一個參考，也希望大家多多支持腳本之家。