[Java知识库]【SpringCloud】——Eureka服务注册与发现

• 什么是服务治理？
  Spring Cloud封装了Netflix公司开发的Euraka模块来实现服务治理
  在传统的rpc远程调用框架中，管理每个服务与服务之间依赖关系比较复杂，管理比较复杂，所以需要使用服务治理，管理服务与服务之间依赖关系，可以实现服务调用、负载均衡、容错等，实现服务发现与注册
• 什么是服务注册与发现？
  Eureka采用了CS的设计架构，Eureka Server作为服务注册功能的服务器，它是服务注册中心，而系统中的其他微服务，使用Euraka的客户端连接到Euraka Server并维持心跳连接。这样系统的维护人员就可以通过Euraka Server来监控系统中各个微服务是否正常运行
  在服务注册与发现中，有一个注册中心，当服务器启动的时候，会把当前自己服务器的信息比如服务地址通讯地址等以别名方式注册到注册中心上。另一方（消费者|服务提供者），以该别名的方式去注册中心上获取到实际的服务通讯地址，然后再实现本地RPC调用

RPC远程调用框架核心设计思想：在于注册中心，因为使用注册中心管理每个服务与服务之间的一个依赖关系 （服务治理概念）。在任何rpc远程框架中，都会有一个注册中心（存放服务地址相关信息（接口地址））

Eureka包含两个组件：Eureka Server和Eureka Client

Eureka Server提供服务注册服务

各个微服务节点通过配置启动后，会在EurakaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观看到

EurekaClient通过注册中心进行访问

是一个Java客户端，用于简化Euraka Server的交互，客户端同时也具备一个内置的、使用轮询（round-robin）负载算法的负载均衡器。在应用启动后，将会向Euraka Server发送心跳（默认周期30秒）。如果Euraka Server在多个心跳周期内没有接收到某个节点的心跳，EurakaServer将会从服务注册表中把这个服务节点移除（默认90秒）

单机Eureka构建步骤

IDEA生成eurakaServer端服务注册中心类似物业公司
?建module
?改POM

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

 <dependencies>
        <!-- eureka-server -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
        </dependency>
        <!-- 引入自定义的api通用包，可以使用Payment支付Entity -->
        <dependency>
            <groupId>org.example.springcloud</groupId>
            <artifactId>cloud-api-commons</artifactId>
            <version>1.0-SNAPSHOT</version>
        </dependency>
        <!-- boot web actuator -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>   <!-- 图形监控-->
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

写YML

主启动

测试http://localhost:7001/

EurakaClient端cloud-provider-payment8001将注册进EurekaServer成为服务提供者provider

EurakaClient端cloud-consumer-order80将注册进EurakaServer成为服务消费者consumer

测试:

• 先要启动EurekaServer，7001服务
• 再要启动服务提供者provider，8001服务
• eureka服务器
  http://localhost/consumer/payment/get31

集群Eureka构建步骤

• Eureka集群原理说明
  服务注册：将服务信息注册进注册中心
  服务发现：从注册中心上获取服务信息

实质：存key服务，取value调用地址

1、先启动eureka注册中心
2、启动服务提供者payment支付服务
3、支付服务启动后会把自身信息（比如服务地址以别名方式注册进eureka）
4、消费者order服务在需要调用接口时，使用服务别名去注册中心获取实际的RPC远程调用地址
5、消费者获得调用地址后，底层实际是利用HttpClient技术实现远程调用
6、消费者获得服务地址后会缓存在本地jvm内存中，默认每间隔30秒更新一次服务调用地址

问题：微服务RPC远程服务调用最核心的是什么
? 高可用，若注册中心只有一个，会导致整个为服务环境不可用
? 解决办法：搭建Eureka注册中心集群，实现负载均衡+故障容错

• EurekaServer集群环境构建步骤
  参考cloud-eureka-server7001
  新建cloud-eureka-server7002
  改POM
  修改配置映射
  ? 找到C:\Windows\System32\drivers\etc路径下的host文件
  ? 修改映射配置添加进hosts文件
  ? 127.0.0.1 eureka7001.com
  ? 127.0.0.1 eureka7002.com
  ? 不同的端口号映射同一个地址

写YML（以前单机）


主启动

• 将支付服务8001微服务发布到上面2台Eureka集群配置中

• 将订单服务80微服务发布到上面2台Eureka集群配置中
  

• 测试01

• 支付服务提供者8001集群环境构建

  • 参考cloud-provider-payment8001
  • 新建cloud-provider-payment8002
  • 改POM
  • 写YML
  • 主启动
  • 业务类
  • 修改8001/8002的Controller

• 负载均衡
  订单服务访问地址不能写死
  
  使用@LoadBalanced注解赋予RestTemplate负载均衡的能力
  
• 测试02

负载均衡效果达到
8001/8002端口交替出现
Ribbon和Eureka整合后Consumer可以直接调用服务而不用再关心地址和端口号，且该服务还具备负载均衡功能
actuator微服务信息完善
主机名称：服务名称修改
修改cloud-provider-payment8001
YML：修改部分

? 访问信息有IP显示

服务发现Discovery
对于注册进euraka里面的微服务，可以通过服务发现来获得该服务的信息
修改cloud-provider-payment8001的Controller

@GetMapping(value = "/payment/discovery")
public Object discovery() {
    List<String> services = discoveryClient.getServices();
    for (String element : services) {
        log.info("******element:" + element);
    }
    List<ServiceInstance> instances = discoveryClient.getInstances("CLOUD-PAYMENT-SERVICES");
    for (ServiceInstance instance : instances) {
    	log.info(instance.getServiceId()+"\t"+instance.getHost()+"\t"+instance.getPort()+"\t"+instance.getUri());
}
	return this.discoveryClient;
}

8001主启动类 @EnableDiscoveryClient

? 自测http://localhost:8001/payment/discovery

eureka自我保护

• 故障现象
  保护模式主要用于一组客户端和Eureka Server之间存在网络分区场景下的保护。一旦进入保护模式，Eureka Server将会尝试保护其服务注册表中的信息，不再删除服务注册表中的数据，也就是不会注销任何微服务

如果在Eureka Server的首页看到以下这段信息，则说明Eureka进入了保护模式：
EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE

• 导致原因

  • 某时刻某一个微服务不可用了，Eureka不会立刻清理，依旧会对该微服务的信息进行保存
  • 属于CAP里面的AP分支
  • 为什么会产生Eureka自我保护机制？
    • 为了防止EurekaClient可以正常运行，但是与EurekaServer网络不通情况下，EurekaServer不会立刻将EurekaClient服务剔除
  • 什么是自我保护模式？
    • 默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例（默认90秒）。但是当网络分区故障发生（延时、卡顿、拥挤）时，微服务与EurekaServer之间无法正常通信，以上行为可能变得非常危险了——因为微服务本身其实是健康的，此时本不应该注销这个微服务。Eureka通过“自我保护模式”来解决这个问题——当EurekaServer节点在短时间内丢失过多客户端时（可能发生了网络分区故障），那么这个节点就会进入自我保护模式
  • 自我保护机制：默认情况下EurekaClient定时向EurekaServer端发送心跳包，如果Eureka在server端在一定时间内（默认90秒）没有收到EurekaClient发送心跳包，便会直接从服务注册列表中剔除该服务，但是在短时间内（90秒中）内丢失了大量的服务实例心跳，这时候EurekaServer会开启自我保护机制，不会剔除该服务（该现象可能出现在如果网络不通，但是EurekaClient出现宕机，此时如果换做别的注册中心如果一定时间内没有收到心跳会将剔除该服务，这样就出现了严重失误，因为客户端还能正常发送心跳，只是网络延迟问题，而保护机制是为了解决此问题而产生的）
  • 在自我保护模式中，Eureka Server会保护服务注册表中的信息，不会注销任何服务实例，它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。一句话讲解：好死不如赖活着
  • 综上，自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留）也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮、稳定

• 怎么禁止自我保护

  • 注册中心eurekaServer端7001

    • 出厂默认，自我保护机制是开启的

    • 使用eureka.server.enable-self-preservation=false可以禁用自我保护模式
      

    • 关闭效果
      

    • 在eurekaServer端7001处设置关闭自我保护机制

  • 生产客户端eurekaClient端8001
    

马上消失！！！！