2021升級版微服務教程3—Eureka徹底使用指南

2021升級版SpringCloud教程從入門到實戰精通「H版&alibaba&鏈路追蹤&日誌&事務&鎖」

教程全目錄「含視頻」：https://gitee.com/bingqilinpeishenme/Java-Wiki

Eureka服務註冊和發現

本文要點：

• 什麼是服務註冊和發現
• Eureka的使用
• CAP
• Eureka集羣搭建

什麼是服務註冊和發現

• 治理中心
• 服務註冊
• 服務發現
• 心跳機制

以上均可以經過 Eureka 能夠實現

Eureka基本使用

基本概念

Spring Cloud 封裝了 Netflix 公司開發的 Eureka 組件來實現服務註冊和發現。

在Eureka的架構中有兩個角色：服務註冊中心 Eureka Server 和 服務客戶端 Eureka Client

• Eureka註冊中心 Eureka Server

  Eureka Server 做爲服務註冊功能的服務器，是服務註冊中心。系統中的其餘微服務，使用 Eureka 的客戶端鏈接到 Eureka Server並維持心跳鏈接。這樣系統的維護人員就能夠經過 Eureka Server 來監控系統中各個微服務是否正常運行。

• Eureka客戶端 Eureka Client

  EurekaClient是一個Java客戶端，用於簡化Eureka Server的交互

  • 在應用啓動後，將會向Eureka Server發送心跳(默認週期爲30秒)。若是Eureka Server在多個心跳週期內沒有接收到某個節點的心跳，EurekaServer將會從服務註冊表中把這個服務節點移除（默認90秒）
  • Eureka Client會緩存服務註冊表中的信息。這種方式有必定的優點首先能夠下降Eureka Server的壓力，其次當全部的Eureka Server宕機，服務調用方依然能夠完成調用

Eureka註冊中心搭建

1. 在Project中建立module

2. 導入依賴

   <!--        引入SpringCloud Eureka server的依賴-->
           <dependency>
               <groupId>org.springframework.cloud</groupId>
               <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
           </dependency>
       </dependencies>

3. 啓動類上加註解

4. 配置文件

   server:
     port: 8800
   
   eureka:
     client:
       #    eureka.client. register-with-eureka:因爲該應用爲註冊中心，因此設置爲false，表明不向註冊中心註冊本身
       registerWithEureka: false
       #      不主動發現別人
       fetchRegistry: false
       #    聲明註冊中心的地址
       serviceUrl:
         defaultZone: http://localhost:8800/eureka/
   
   #給當前應用起個服務名稱 不能經過路徑訪問的  這個服務名稱 在微服務中使用表明當前服務
   spring:
     application:
       name: eureka-server

5. 啓動註冊中心 訪問註冊中心的監控頁面 http://localhost:8800

客戶端搭建—用戶服務

以用戶服務爲例

1. 建立項目

   

2. 導入相關依賴

   <dependency>
               <groupId>org.springframework.cloud</groupId>
               <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
           </dependency>

3. 啓動類上加註解

4. 配置文件

   server:
     port: 8804
   
   #指定當前服務的名稱  這個名稱會註冊到註冊中心
   spring:
     application:
       name: cloud-user-8804
   
   #  指定 服務註冊中心的地址
   eureka:
     client:
       serviceUrl:
         defaultZone: http://localhost:8800/eureka

經過以上四步 就完成了一個 Eureka客戶端的搭建 直接啓動項目 經過Eureka的註冊中心能夠看到

按照上述步驟，將商品服務和訂單服務改造爲Eureka客戶端。

Eureka進階使用

CAP理論

目前，大型網站幾乎都是分佈式的，分佈式系統的最大難點，就是各個節點的狀態如何同步。CAP 定理是這方面的基本定理，也是理解分佈式系統的起點。

1998年，加州大學的計算機科學家 Eric Brewer 提出，分佈式系統有三個指標。

• Consistency 一致性
• Availability 可用性
• Partition tolerance 分區容錯性

它們的第一個字母分別是 C、A、P。

Eric Brewer 說，這三個指標不可能同時作到。這個結論就叫作 CAP 定理。

• 分區容錯性

  大多數分佈式系統都分佈在多個子網絡。每一個子網絡就叫作一個區（partition）。分區容錯的意思是，區間通訊可能失敗。好比，一臺服務器放在中國，另外一臺服務器放在美國，這就是兩個區，它們之間可能沒法通訊。

  Node1 和 Node2 是兩臺跨區的服務器。Node1 向 Node2 發送一條消息，Node2可能沒法收到。系統設計的時候，必須考慮到這種狀況。

  通常來講，分區容錯沒法避免，所以能夠認爲 CAP 的 P 老是成立。CAP 定理告訴咱們，剩下的 C 和 A 沒法同時作到。

• 數據一致性

  因爲系統問題，Node1 的數據不能即時同步給Node2，此時若是獲取數據，會獲取到不一致的數據，全部爲了保證分佈式系統對外的數據一致性，選擇不返回任何數據【或者全部節點不響應任何請求】。

• 可用性

  要求系統內的節點在接受到請求的時候可以即時給出響應，具體來講就是：一方面須要在合理的時間內給出響應，另外一方面即使是部分節點宕機，那麼其餘未宕機的節點也須要可以正常處理請求，即時返回的數據有問題。

一致性和可用性，爲何不可能同時成立？

答案很簡單，由於可能通訊失敗（即出現分區容錯），因此，對於分佈式系統，咱們只能能考慮當發生分區錯誤時，如何選擇一致性和可用性。

須要強調的是：C 和 A 的抉擇是發生在有分區問題的時候，正常狀況下系統就應該有完美的數據一致性和可用性

例子：

好比，咱們有個分佈式系統，由三個節點 a、b、c 組成。其中節點 a 存放了 A 表的數據，b 存放了 B 表的數據，c 存放了 C 表的數據。

若是有一個業務，它的意圖是想往 A 表插入一條新數據，在 B 表刪除一條已有數據，在 C 表更新一條老數據，這個分佈式系統該怎麼處理這種業務？

技術上咱們對這種一個意圖想作多件事的狀況每每會包裝成一個事務。當咱們包裝成一個事務之後，咱們可能會經過先在 a 節點執行，而後去 b 節點執行，最後去 c 節點執行，等到都成功了，纔會返回成功。

可是，發生了分區之後怎麼辦？當在 a、b 節點都成功了，到 c 發現發生了通訊故障？

此時，根據 CAP 定理，你有兩個選擇，要麼就直接返回一個部分紅功的結果給客戶端，要麼直接卡死等客戶端超時或者返回失敗給客戶端。當返回部分紅功的時候，這就是選擇了可用性（A），當卡死或者返回失敗給客戶端的時候，就是選擇了一致性（C）。

而根據一致性和可用性的選擇不一樣，開源的分佈式系統每每又被分爲 CP 系統和 AP 系統。

• 當一套系統在發生分區故障後，客戶端的任何請求都被卡死或者超時，可是，系統的每一個節點老是會返回一致的數據，則這套系統就是 CP 系統，經典的好比 Zookeeper。

• 若是一套系統發生分區故障後，客戶端依然能夠訪問系統，可是獲取的數據有的是新的數據，有的仍是老數據，那麼這套系統就是 AP 系統，經典的好比 Eureka。

不少時候一致性和可用性並非二選一的問題，大部分的時候，系統設計會盡量的實現兩點，在兩者之間作出妥協，當強調一致性的時候，並不表示可用性是徹底不可用的狀態，好比，Zookeeper 只是在 master 出現問題的時候，纔可能出現幾十秒的不可用狀態，而別的時候，都會以各類方式保證系統的可用性。而強調可用性的時候，也每每會採用一些技術手段，去保證數據最終是一致的。

自我保護機制

Eureka首頁輸出警告如圖：

默認狀況下，若是Eureka Server在必定時間內沒有接受到服務實例的心跳，Eureka將會註銷該實例(默認90秒).可是當網絡分區發生故障時，微服務客戶端和Eureka Server 沒法正常通訊。以上行爲可能變得特別危險了，由於微服務自己是健康的，此時不能註銷該服務實例。

Eureka經過自我保護機制來解決這個問題，當Eureka Server在短期丟失過多的服務實例（可能發生了網絡分區的故障），那麼Eureka Server進入自我保護模式，一旦進入此模式，Eureka Server將會保護服務註冊表中的信息，再也不刪除服務註冊表中的數據（也就是再也不註銷任何的服務實例），當網絡故障恢復後，Eureka Server會自動退出自我保護模式。

綜上，自我保護模式是一種應對網絡故障的安全保護措施，它的架構哲學是寧肯同時保留全部的微服務，也不盲目註銷任何健康的微服務，使用自我保護模式可讓Eureka，更加健壯，穩定。

一句話：大面積出現客戶端失聯的時候，Eureka 註冊中心進入自我保護模式，不註銷任何實例

自我保護機制的配置【瞭解】

在Eureka Server中配置關閉自我保護機制

#關閉自我保護機制  默認開啓
eureka.server.enable-self-preservation=false

若是想及時剔除失效的eureka服務除了關閉自我保護機制外，能夠調低eureka的心跳值

eureka-server服務端
配置文件中咱們添加以下配置

#關閉保護機制，以確保註冊中心將不可用的實例正確剔除
eureka.server.enable-self-preservation=false
#（表明是5秒，單位是毫秒,清理失效服務的間隔 ）
eureka.server.eviction-interval-timer-in-ms=5000

客戶端
配置文件中咱們添加以下配置

# 心跳檢測檢測與續約時間
# 測試時將值設置設置小些，保證服務關閉後註冊中心能及時踢出服務
# 配置說明
#　　lease-renewal-interval-in-seconds 每間隔10s，向服務端發送一次心跳，證實本身依然」存活「
#　　lease-expiration-duration-in-seconds  告訴服務端，若是我20s以內沒有給你發心跳，就表明我「死」了，將我踢出掉。
eureka.instance.lease-renewal-interval-in-seconds=10
eureka.instance.lease-expiration-duration-in-seconds=20

Eureka集羣搭建

註冊中心集羣，防止註冊中心單機故障。

1. 建立一個新的註冊中心 eureka-server-8801

   1. 建立項目

   2. 導入依賴

   3. 啓動類加註解

   4. 寫配置文件

2. 修改註冊中心 Eureka-server-8800的配置文件

3. 修改全部的客戶端的配置，讓客戶端可以同時向兩個註冊中心註冊

4. 啓動全部的客戶端和註冊中心 看看能不能正常註冊

若是你以爲這篇內容對你挺有有幫助的話：

1. 點贊支持下吧，讓更多的人也能看到這篇內容（收藏不點贊，都是耍流氓 -_-）

2. 歡迎在留言區與我分享你的想法，也歡迎你在留言區記錄你的思考過程。

3. 以爲不錯的話，也能夠關注 編程鹿 的我的公衆號看更多文章和講解視頻（感謝你們的鼓勵與支持🌹🌹🌹）