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

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

默認文件1610014380163

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

image-20210107185205249

Eureka服務注冊和發現

本文要點：

• 什么是服務注冊和發現
• Eureka的使用
• CAP
• Eureka集群搭建

什么是服務注冊和發現

1593934895413

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

以上都可以通過 Eureka 可以實現

Eureka基本使用

基本概念

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

image-20200420161934202

在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

   

   image-20210109160624673

2. 導入依賴

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

3. 啟動類上加注解

1593935968864

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

   

   image-20210109160155304

客戶端搭建—用戶服務

以用戶服務為例

1. 創建項目

   

2. 導入相關依賴

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

3. 啟動類上加注解

   

   image-20200420165233554

4. 配置文件

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

通過以上四步 就完成了一個 Eureka客戶端的搭建 直接啟動項目 通過Eureka的注冊中心可以看到

image-20210109160221422

按照上述步驟，將商品服務和訂單服務改造為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首頁輸出警告如圖：

image-20210109160302395

默認情況下，如果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. 創建項目

      

      image-20210109160323741

   2. 導入依賴

   3. 啟動類加注解

   4. 寫配置文件

      

      image-20210109160336831

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

   

   image-20210109160350052

3. 修改所有的客戶端的配置，讓客戶端能夠同時向兩個注冊中心注冊

   

   image-20210109160405439

4. 啟動所有的客戶端和注冊中心 看看能不能正常注冊

如果你覺得這篇內容對你挺有有幫助的話：

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

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

3. 覺得不錯的話，也可以關注 編程鹿 的個人公眾號看更多文章和講解視頻（感謝大家的鼓勵與支持🌹🌹🌹）