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註冊中心搭建
在Project中建立module
image-20210109160624673 匯入依賴
<!-- 引入SpringCloud Eureka server的依賴-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
</dependencies>啟動類上加註解
配置檔案
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啟動註冊中心 訪問註冊中心的監控頁面
http://localhost:8800
image-20210109160155304
客戶端搭建—使用者服務
以使用者服務為例
建立專案
匯入相關依賴
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>啟動類上加註解
image-20200420165233554 配置檔案
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叢集搭建
註冊中心叢集，防止註冊中心單機故障。
建立一個新的註冊中心 eureka-server-8801
建立專案
image-20210109160323741 匯入依賴
啟動類加註解
寫配置檔案
image-20210109160336831
修改註冊中心 Eureka-server-8800的配置檔案
image-20210109160350052 修改所有的客戶端的配置，讓客戶端能夠同時向兩個註冊中心註冊
image-20210109160405439 啟動所有的客戶端和註冊中心 看看能不能正常註冊
如果你覺得這篇內容對你挺有有幫助的話：
點贊支援下吧，讓更多的人也能看到這篇內容（收藏不點贊，都是耍流氓 -_-）
歡迎在留言區與我分享你的想法，也歡迎你在留言區記錄你的思考過程。
覺得不錯的話，也可以關注 程式設計鹿 的個人公眾號看更多文章和講解視訊（感謝大家的鼓勵與支援