Eureka

负责服务的注册与发现

采用C-S架构设计，EurekaServer作为服务注册功能的服务器，系统中的其他微服务使用Eureka客户端并维持心跳连接，这样可以通过EurekaServer监控各个微服务是否正常

三大角色

Eureka Server：提供服务的注册与发现
Service Provider：将自身服务注册到Eureka
Service Consumer：服务消费从Eureka中获取注册列表，找到服务

两大组件

Eureka Server：提供服务注册，各个节点启动后，会在Eureka Server进行注册
Eureka Client：提供服务的客户端，使用轮询负载算法，在启动后会向Eureka Server发送心跳（默认30秒），Eureka Server在多个心跳周期内没有接收到某个节点的心跳，会从服务注册列表中移除（默认90秒）

服务端

导入依赖

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka-server</artifactId>
</dependency>

配置

server:
  port: 8000

# Eureka配置
eureka:
  instance:
    # 服务端实例名称
    hostname: localhost
  client:
    # 是否注册自己，默认true
    register-with-eureka: false
    # false表示自己为注册中心
    fetch-registry: false
    # 监控页码地址，动态配置
    service-url:
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka

开启服务

@SpringBootApplication
// 开启服务
@EnableEurekaServer
public class Eureka_8000 {
    public static void main(String[] args) {
        SpringApplication.run(Eureka_8000.class, args);
    }
}

访问localhost:8000即可看到监控页面

客户端

同理客户端配置，该客户端为提供服务者

添加依赖

<!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-eureka -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka</artifactId>
    <version>1.4.7.RELEASE</version>
</dependency>

配置

# Eureka
eureka:
  client:
    service-url:
      defaultZone: http://localhost:8000/eureka

开启服务：在主启动类上加@EnableEurekaClient

保护机制

当监控页面出现EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE红色字样，是Eureka进入了保护模式，重启即可，稍等一下其他服务就会注册进来

某一个时刻微服务不可用了，Eureka不会立即清理，依旧会对该微服务的信息进行保存

默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务的心跳，EurekaServer将会注销实例（90秒），但是当网络出现故障等情况导致EurekaServer无法与微服务正常通信，这时清除该服务就危险了，因为微服务本身是健康的，此时不应该注销这个服务。Eureka通过自我保护机制来解决这样的问题，当EurekaServer短时间内丢失过多客户端时，那么这个节点就会进入自我保护模式，将保护服务注册表中的信息，不再删除服务注册表中的数据（也就是不注销任何服务），当节点恢复后，EurekaServer会自动退出自我保护模式

该架构哲学为宁可同时保留所有微服务（健康和不健康的），也不盲目注销任何微服务

可以通过配置关闭，但不建议

集群

单台注册中的容错率太低了，一旦宕机，整个服务都会瘫痪，还是要集群部署

示例

# Eureka配置
eureka:
  instance:
    # 服务端实例名称，集群注意不要一样
    hostname: localhost
  client:
    # 是否注册自己，默认true
    register-with-eureka: false
    # false表示自己为注册中心
    fetch-registry: false
    # 监控页面地址
    service-url:
      # 单机可用，动态配置
      #defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka
      # 集群配置，配置其他Eureka，相互绑定，多个用,分隔
      defaultZone: http://localhost:8000/eureka/

客户端连接多个

# Eureka
eureka:
  client:
    service-url:
      defaultZone: http://localhost:8000/eureka,http://localhost:8000/eureka/

CAP原则

C：一致性（Consistency）
A：可用性（Availability）
P：分区容错性（Partition tolerance）

CAP原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾

注意：由于分区容错性在分布式系统中是必须要保证的，因此只能在一致性和可用性之间权衡

Zookeeper保证的是CP
- 当向注册中心查询服务列表时，可以容忍注册中心返回几分钟前的信息，但是不能接收服务直接宕掉不可用。也就是服务注册功能对可用性的要求高于一致性，但是Zookeeper会出现这样一种情况，当主机节点因为网络故障与其他节点失联，剩余节点就会重新进行主机选举，而且选举时间较长（30~120s），整个选举期间Zookeeper集群是不可用的，这期间处于瘫痪状态，可用性较差
Eureka保证的是AP
- Eureka的设计优先保证可用性，Eureka各个节点都是平等的，宕掉节点不影响使用，剩余节点继续提供服务，只不过插到的信息不是最新的，当网络稳定时，当前实例新的注册信息会被同步到其他节点