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源码
目前还在看，等梳理完再做记录。