Eureka大白話解析

筆記補錄：

1.Eureka 介紹

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

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

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

Eureka圖解如下：

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

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

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

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

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

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

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

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

2.1 Eureka Server

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

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

2.2 Eureka Client

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

2.2.1 服務(wù)注冊

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

2.2.2 服務(wù)續(xù)約

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

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

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

2.2.3 服務(wù)下線

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

2.2.4 獲取注冊表信息

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

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

eureka.client.fetch-registry=true

Eureka Client 上緩存的服務(wù)注冊信息，定期更新的時間間隔，默認(rèn)30秒：

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

Eureka分區(qū)策略

第一步：背景和概念介紹

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

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

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

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

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

服務(wù)注冊相關(guān):

 eureka: client: # 盡可能向同一區(qū)域的 eureka 注冊,默認(rèn)為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/

當(dāng)存在多個注冊中心時，選擇邏輯為cdn

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

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

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

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

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

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

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

最新評論