Eureka是Netfix開源的服務註冊中心框架，Spring Cloud將其集成進Spring全家桶，實現了Spring Cloud的註冊中心功能。
Eureka的使用
Eureka的使用非常簡單，只要加入相關依賴，用註解開啓Eureka服務就可以了。
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
#開啓Eureka服務
@EnableEurekaServer
@SpringBootApplication
@Import(SecurityConfig.class)
public class EurekaApplication{
public static void main(String[] args) {
SpringApplication.run(EurekaApplication.class);
}
}
application.yml
spring:
application:
name: samsungeshop-eureka-server
server:
port: 7000
啓動服務後訪問對應的端口，就可以看到如下頁面
Eureka 架構
在Dubbo中使用Zookeeper實現註冊中心，那麼Zookeeper和Eureka這兩者有啥區別呢？最大的區別在於他們遵循的CPA定理不同，Zookeeper具有數據的強一致性，所以他遵循CP，而Eureka則強調可用性，所以他循序AP。多個節點的Eureka並不是一個集羣，每個服務提供者都會想所有的Eureka註冊自己，Eureka節點之間進行簡單的數據複製，服務消費者通過Eureka客戶端從Eureka Server獲取服務列表時，連接任何一個節點都可以。
上面是Netfix官方提供的Eureka架構圖，我們可以看到整個服務註冊與發現的過程分爲：
- 服務註冊
- 服務續約
- 獲取服務列表
- 取消註冊
服務提供者在啓動的時候，向每個Eureka Server註冊自己，並通過發送心跳包的方式進行服務續約；服務消費者在調用服務的時候，首先通過Eureka獲取服務列表，然後再調用相關的服務；如果服務下線，服務提供者會通知Eureka，Eureka Server不同節點之間再通過數據複製進行感知；
相關配置
eureka.client.register-with-eureka=false
這個配置表示不向註冊中心進行服務註冊，一般在Eureka Server端進行配置。
eureka.client.fetch-registry=false
這個配置表示不拉取服務列表，一般也是在Eureka Server端進行配置。
eureka.client.registry-fetch-interval-seconds=60
本地註冊列表刷新頻率，這個一般配置在服務消費端，在拉取完服務列表後，會在本地進行緩存然後定時刷新，由於Eureka遵循AP，所以可能會造成短時的服務消費者無法感知服務消費者宕機的情況，這時候就可以將刷新間隔調小，來儘早發現宕機的服務。
eureka.client.lease-renewal-interval-in-seconds=30
這個參數執行服務心跳續約包的頻率，一般配置在服務端，用來規定客戶端發送心跳包的頻率。
eureka.client.lease-expiration-duration-in-seconds=90
這個參數用來規定在接收到最後一條心跳包後過少時間內如果接收不到後續的心跳包，就表示該服務已下線，默認是90秒，也就是說，在90秒內沒有接接收到心跳包，就判定該節點不可用。但是有時候由於網絡抖動，這個時間可能超過90秒，所以Eureka引入了一種自我保護機制，在可用性上左了一種中和。
eureka.server.renewal-percent-threshold=0.85
這個參數規定了心跳續約包的接收閾值，是上一個參數的補充。默認當一個服務的心跳包在15分鐘內有15%以上都丟失的話，Eureka就會啓動自我保護機制。
eureka.server.enable-self-preservation=true
這個參數是指定是否開啓自我保護機制，一般在測試環境設置爲false，來最快感知服務提供者是否可用，避免浪費測試時間。
自我保護機制
自我保護機制是Eureka在可用性上的進一步保證，也可以說是在判定服務不可用的條件上的一種妥協，自我保護機制指的是，當服務提供者的心跳包丟包率達到了配置的閾值時，Eureka就會對服務列表進行保護，不允許刪除該服務的服務列表數據，因爲心跳丟包有可能是因爲網絡抖動造成的，如果直接剔除服務會有問題，等到心跳包恢復正常後，在解除自我保護機制。
當然，自我保護機制會造成當服務提供者真的不可用時服務消費者的感知延遲，所以在服務消費者端一定要做好服務熔斷和服務降級的處理。
這種機制也印證了Eureka是AP架構，爲了自身的可用性，不惜對服務消費者造成影響。
Eureka源碼
目前還在看，等梳理完再做記錄。