1.什麼是Eureka保護機制
官方解釋： 自我保護模式正是一種針對網絡異常波動的安全保護措施，使用自我保護模式能使Eureka集羣更加的健壯、穩定的運行。
默認情況下，Eureka Client會定時的向 Eureka Server端發送心跳包，默認是30s發送一次，目的是告訴 Eureka Server當前客戶端實例還處於存活狀態，如果Eureka server在一定時間內沒有收到實例的心跳，便會把該實例從註冊表中刪除（默認是90秒）,但是，如果短時間內丟失大量的實例心跳，便會觸發Eureka server的自我保護機制的 ,默認自我保護機制處於開啓狀態，比如在開發測試時，需要頻繁地重啓微服務實例客戶端，但是我們很少會把eureka server一起重啓（因爲在開發過程中不會修改eureka註冊中心），當一分鐘內收到的心跳數大量減少時，會觸發該保護機制。可以在eureka管理界面看到Renews threshold和Renews(last min)，當Renews(last min)（最後一分鐘收到的心跳數）小於Renews threshold（心跳閾值）的時候，如果某個服務實例宕機掉，觸發保護機制，會出現紅色的警告：
2.爲什麼要自我保護
因爲同時保留"好數據"與"壞數據"總比丟掉任何數據要更好，當網絡故障恢復後，這個 Eureka 節點會退出"自我保護模式"。
當一個服務未按時進行心跳續約時，在生產環境下，因爲網絡延遲等原因，心跳失敗實例的比例很有可能超標，但是此時就把服務剔除列表並不妥當，因爲服務可能沒有宕機。Eureka就會把當前實例的註冊信息保護起來，不予剔除。生產環境下這很有效，保證了大多數服務依然可用。
爲了防止在一定時間內，Eureka Client與Eureka Server在網絡不同的情況下，Eureka Server誤將Eureka Client服務剔除，這個機制是爲了對服務進行保護；
3.如何關閉Eureka自我保護機制
Eureka自我保護機制默認是開啓的，如果如果需要關閉自我保護機制，按照下述方式： enable-self-preservation: false 開關關閉掉，然後修改客戶端和服務端相關參數，保證異常服務能及時剔除；
3.1.Eureka Server配置
註冊中心關閉自我保護機制，修改檢查失效服務的時間，以確保註冊中心將不可用的實例及時正確剔除
yml:
#Eureka自我保護機制
server:
#關閉eureka自我保護機制false（默認爲true）
enable-self-preservation: false
# 配置Eureka Server清理無效節點的時間間隔（單位毫秒，默認60*1000毫秒,即60秒）
eviction-interval-timer-in-ms: 2000
#關閉自我保護:true 爲開啓自我保護，false 爲關閉自我保護
eureka.server.enableSelfPreservation=false
#清理間隔(單位:毫秒，默認是 60*1000)
eureka.server.eviction.interval-timer-in-ms=2000
然後啓動server和服務，觀察關閉服務前後的變化
3.2.Eureka Client配置
減短客戶端服務發送服務心跳給服務端的時間， 在開發測試時，將值設置設置小些，保證服務關閉後註冊中心能及時踢出服務
eureka:
instance:
#eureka服務端在接受到實例的最後一次發出的心跳後，需要等待多久纔可以將此刪除，單位爲秒（默認爲90s），超過時間則剔除（客戶端會按照此規則向Eureka服務端發送心跳檢測包）
lease-expiration-duration-in-seconds: 90
#eureka客戶端需要多長時間發送心跳給eureka服務端，單位爲秒（默認爲30s）,（客戶端會按照此規則向Eureka服務端發送心跳檢測包）
lease-renewal-interval-in-seconds: 2
- lease-renewal-interval-in-seconds：服務續約(renew)的間隔，默認爲30秒
- lease-expiration-duration-in-seconds：服務失效時間，默認值90秒
獲取服務列表
當服務消費者啓動是，會檢測eureka.client.fetch-registry=true參數的值，如果爲true，則會從Eureka Server服務的列表只讀備份，然後緩存在本地。並且每隔30秒會重新獲取並更新數據。我們可以通過下面的參數來修改：
eureka:
client:
#表示eureka client間隔多久去拉取服務器註冊信息,默認爲30秒
registry-fetch-interval-seconds: 5
生產環境中，我們不需要修改這個值。
但是爲了開發環境下，能夠快速得到服務的最新狀態，我們可以將其設置小一點。
4.開啓和關閉Eureka保護機制的場景
4.1.開發環境關閉
當我們在使用微服務框架做項目開發的時候，如果註冊中心是Eureka，因爲會頻繁的重啓本地開發環境，調試和修改代碼，但是不會頻繁的重啓Eureka Server，所以建議在測試環境、本地開發環境時關閉Eureka的自我保護機制，，如果觸發了保護機制，則舊的服務實例沒有被刪除，這時請求有可能跑到舊的實例中，而該實例已經關閉了，這就導致請求錯誤，影響開發測試效率；
4.2.生產環境開啓
Linux—>Docker容器化部署—>K8S
在微服務各個節點部署到生產環境了之後，建議開啓Eureka自我保護環境，這一點還是比較重要的，因爲在生產環境，並不會頻繁的重啓，而且有時在短時間內可能會發生服務與服務之間網絡故障、重啓Eureka Client客戶端服務實例等其他原因導致通訊中斷，所以一定要把自我保護機制打開，否則網絡一旦終端，就無法恢復，導致誤刪除服務節點，造成生產故障；