Spring Cloud系列教程第九篇-Eureka自我保護機制

Spring Cloud系列教程第九篇-Eureka自我保護機制

本文主要內容：

1：自我保護介紹

2：致使緣由分析

3：怎麼禁止自我保護

本文是由凱哥(凱哥Java:kagejava)發佈的《spring cloud系列》教程的總第九篇：

本文是幾個維度中的第一個維度：註冊與發現維度配置中心管理之Eureka相關教程第六篇。

一：Eureka的自我保護機制是什麼？

保護模式主要用於一組客戶端和Eureka Server之間存在網絡分區場景下的保護。一旦進入保護模式，Eureka Server將會嘗試保護其服務註冊表中的信息，再也不刪除服務註冊表中的數據，也就是不會註銷任何微服務。

簡單一句話：

用電視劇新三國中，劉備說的：「寧肯天下人負我，我不負天下人」。即：Eureka服務端，進入自我保護模式，就算全部的微服務真的都出問題了，也不會裏面刪除它們的。

二：爲何會出現自我保護機制？

一句話：某時刻某一個微服務不可用了，Eureka不會馬上清理，依舊會對該服務的信息進行保存。屬於CAP裏面的AP分支，也便是：保證可用性、分區容錯性。

PS：CAP原則：分佈式系統中，C:一致性；A:可用性;P:分區容錯性。

咱們來看看百度百科對CAP原則的詳細介紹，以下圖：

爲何會產生Eureka自我保護機制？

爲例防止EurekaClient能夠正常運行，可是與Eureka Server網絡不通狀況下，EurekaServer 不會馬上將EurekaClient服務剔除

默認狀況下，若是EurekaServer在必定時間內沒有收到某個微服務實例的心跳，EurekaServer將會註銷該實例(默認90s).可是當網絡分區故障發生(延時、卡頓、擁擠)時候，微服務與EurekaServer之間沒法正常通訊，以上行爲可能變得很是危險了--由於微服務自己實際上是健康的。此時本不該該註銷這個微服務的。Eureka經過"自我保護模式"來解決這個問題--當EurekaServer節點在短期內丟失過多客戶端時候(可能發生了網絡分區故障)，那麼這個節點就會進入自我保護模式了。

綜上，自我保護是一種應對網絡異常的安全保護措施。它的架構哲學是寧肯同時保留全部微服務(健康的、不健康的微服務都會保留)，也不盲目註銷任何健康的微服務。

職用自我保護模式，可讓Eureka集羣更加的健壯和穩定

三：怎麼禁止Eureka的自我保護？

出廠默認，自我保護機制是開啓的：eureka.server.enable-self-preservation=true

3.1：來看看開啓自我保護模式的時候，Eureka服務端提示：

3.2：修改服務導關閉自我保護

修改Eureka Server項目：7001項目的yml配置：

關閉自我保護機制，同時修改心跳時間爲2s.以下圖：

重啓Eureka服務項目，來看看關閉自我保護模式後提示：

咱們來修改客戶端(payment8001項目)的yml配置文件：

Eureka客戶端向服務端發送心跳的時間間隔。單位秒。默認30s。修改成1s.

Eureka服務導在收到最後一次心跳後等待時間上限，超時將剔除服務。單位秒，默認90s，修改值爲2s.以下圖：

測試關閉自我保護機制：

啓動服務端7001項目，再啓動客戶端8001項目，咱們能夠在頁面查看客戶端成功註冊到服務端了。以下圖：

咱們關閉客戶端8001項目後，間隔2秒+之後，在刷新頁面.能夠看到客戶端被移除了。以下圖：

當出現這個效果，說明，咱們測試成功了。

當eureka關閉自我保護模式後，只要檢查到客戶端沒有發送心跳檢測，就將客戶端從註冊列表中移除了。這是很危險的。

用一句話來形容，關閉自我保護模式的Eureka服務：曹孟德曰：寧肯我負天下人，不可天下人負我。

爲何說，沒有了自我保護機制很危險？

有可能由於網絡緣由，沒有發送心跳成功，可是實際上客戶端是正常運行的。若是這個時候，直接移除掉客戶端，可能形成服務大面積不能使用。是很危險的一個操做。因此，最好別關閉自我保護機制

《spring cloud系列教程》：