Eureka的自我保護機制
前言
首先對Eureka註冊中心需要了解的是Eureka各個節點都是平等的，沒有ZK中角色的概念， 即使N-1個節點掛掉也不會影響其他節點的正常執行。
預設情況下，如果Eureka Server在一定時間內（預設90秒）沒有接收到某個微服務例項的心跳，Eureka Server將會移除該例項。但是當網路分割槽故障發生時，微服務與Eureka Server之間無法正常通訊，而微服務本身是正常執行的，此時不應該移除這個微服務，所以引入了自我保護機制。
1.1 eureka的自我保護機制
自我保護機制：長時間沒有訪問、檢測不到心跳，或者修改例項名稱，eureka啟動自我保護機制（好死不如賴活著-哈哈）
即：某一個時刻，某一個微服務不可用了，eureka不會立即清理，依舊會對該微服務的資訊進行儲存！！！
官方對於自我保護機制的定義：
自我保護模式正是一種針對網路異常波動的安全保護措施，使用自我保護模式能使Eureka叢集更加的健壯、穩定的執行。
這樣做的目的是eureka擔心這個服務註冊中心是不是死掉了，而做出的一種保護機制。但是當該微服務又重新活過來了之後，Eureka會將之前儲存的資訊還原到該微服務上。
自我保護機制的工作機制是：如果在15分鐘內超過85%的客戶端節點都沒有正常的心跳，那麼Eureka就認為客戶端與註冊中心出現了網路故障，Eureka Server自動進入自我保護機制，此時會出現以下幾種情況：
- Eureka Server不再從註冊列表中移除因為長時間沒收到心跳而應該過期的服務。
- Eureka Server仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其它節點上，保證當前節點依然可用。
- 當網路穩定時，當前Eureka Server新的註冊資訊會被同步到其它節點中。
因此Eureka Server可以很好的應對因網路故障導致部分節點失聯的情況，而不會像ZK那樣如果有一半不可用的情況會導致整個叢集不可用而變成癱瘓。
1.1.1 自我保護開關
Eureka自我保護機制，通過配置 eureka.server.enable-self-preservation 來true開啟/false禁用自我保護機制，預設開啟狀態，建議生產環境開啟此配置。
1.1.2 開發環境配置
開發環境中如果要實現服務失效能自動移除，只需要修改以下配置。
1、 註冊中心關閉自我保護機制，修改檢查失效服務的時間。
eureka:
server:
enable-self-preservation: false
eviction-interval-timer-in-ms: 3000
2、 微服務修改減短服務心跳的時間。
# 預設90秒
lease-expiration-duration-in-seconds: 10
# 預設30秒
lease-renewal-interval-in-seconds: 3
2.1 叢集搭建
一般我們都不會搭建一個微服務註冊例項，而是搭建一個叢集，這樣就算長時間內某個例項沒有相應其他例項可以接著執行，因此按照CAP定理來看，Eureka其實滿足AP的但是它不滿足CP。它可以保證高可用，但是不能保證一致性。
server:
port: 7001
eureka:
instance:
hostname: eureka7001.com #eureka服務端的例項名稱
client:
register-with-eureka: false #false表示不向註冊中心註冊自己。
fetch-registry: false #false表示自己端就是註冊中心，我的職責就是維護服務例項，並不需要去檢索服務
service-url:
#單機 defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/ #設定與Eureka Server互動的地址查詢服務和註冊服務都需要依賴這個地址（單機）。
defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/