前言

说起来容易做起来难，一步一步都干完！！！

学习一定要自己动手搞一搞，不能只眼会。

学习笔记是跟着尚硅谷的视频学的：传送门

场景大纲

我们以这样一个场景来学习、构建我们的微服务

服务提供者的集群配置

配置actuator

在生产环境部署时，我们的微服务会部署在不同的服务器上，为了方便管理和查看，我们需要将服务的IP暴露出来，这样能清清晰的看到哪个服务是部署在哪个服务器上的。
访问localhost:7001

1. 配置不显示主机名

要想修改这两个配置，你的微服务POM中要有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>

2. 修改8001和8002工程

修改8001服务和8002服务的yml配置文件，添加如下配置：

instance:
  instance-id: payment8001

instance:
  instance-id: payment8002

3. 查看服务注册中心

检查服务状态,点击8001服务,修改最后一个参数，查看心跳

http://localhost:8001/actuator/health

up状态说明服务正常，我们的配置对服务没有产生影响。

4. 配置访问时显示IP地址

在8001和8002配置文件上添加配置（注意：yml格式需要严格的对其）

prefer-ip-address: true # 配置为true，标时访问时显示主机IP

5. 再次访问localhost:7001查看服务注册中心

服务发现Discovery的使用

Discovery类似于微服务的关于服务，通过他能够获取微服务相关的一些信息，包括注册中心提供了哪些服务、服务的地址信息等，下面我们做一下测试。

1. 改造8001工程的controller

添加DiscoveryClient

@Resource
private DiscoveryClient discoveryClient;

添加测试接口，获取服务信息

// 服务发现测试
@GetMapping("/payment/discovery")
public Object getPaymentById(){
    // 获取所有的服务名称
    List<String> services = discoveryClient.getServices();
    for (String service : services) {
        // 打印服务信息
        log.info("*********service:"+service);
    }

    // 获取CLOUD-PAYMENT-SERVICE服务下的所有实例（8001，8002）
    List<ServiceInstance> instances = discoveryClient.getInstances("CLOUD-PAYMENT-SERVICE");
    for (ServiceInstance instance : instances) {
        // 打印服务名下的所有实例信息
        log.info(instance.getServiceId()+"\t"+instance.getHost()+"\t"+instance.getPort()+"\t"+instance.getUri());
    }

    // 返回discoveryClient，看下他都具备哪些信息
    return this.discoveryClient;
}

给启动类添加注解@EnableDiscoveryClient，注意由于Eureka现在已经闭源，所以后面我们使用较多的会是@EnableDiscoveryClient注解。
@EnableDiscoveryClient和@EnableEurekaClient共同点就是：都是能够让注册中心能够发现，扫描到改服务。
不同点：@EnableEurekaClient只适用于Eureka作为注册中心，@EnableDiscoveryClient 可以是其他注册中心。

2. 启动测试

启动所有服务

访问接口

http://localhost:8001/payment/discovery

查看页面信息

查看后台日志

Eureka的自我保护机制

1. 现象

Eureka的页面上默认会有一行红字

我们谷歌翻译一下

拉几把倒，白话解释一下：就算Eureka发现了服务某个服务异常不可用了，也不会立即将他从注册表中的分支中删除，而是会保留。

这种机制署于CAP种的AP！！！！

（目前我也不懂啥意思，但视频中说记好这句话就行）

2. 原因

原因： 我们设想一下，一个微服务将自己注册到了Eureka注册中心，他过了一段时间（90秒）没有发心跳包，Eureka认为服务出现了故障把服务从注册表删除掉了，但是有一种情况是Eureka服务器的网络问题，其实微服务是正常的，但是Eureka的网不好，收不到心跳包，如果草率的将服务从注册表删除，就会出现大规模误杀，影响系统的高可用。这就好比是一个商家入驻到了万达，然后因为疫情万达封闭了一个月，商家钱物业费啥都交过了，然后一个月后解除封闭后再来万达已经把店铺撤了不让你用了，这显然是不合理的，运用到系统上是会影响系统的可用性的，因为你Eureka网络故障了，我们所有微服务都要重新注册一遍，显然不合适。

自我保护机制： Eureka为了应对以上问题，保障系统的高可用，在出现短时间内大规模丢失客户端（微服务）时，会开启自我保护机制，自我保护机制开启后将保留一段时间的注册表信息，不直接进行删除（牺牲强服务一致性，保障健康服务可用性）。

中心思想： 宁可保留错误的信息，也不让任何一个可能健康的服务删除。

3. 关闭自我保护

先把7001服务注册中心和8001服务改成单节点（为了快速测试）。


给7001添加配置信息，修改为关闭自我保护机制及修改。

server:
  #关闭自我保护机制，保证不可用服务被及时踢除
  enable-self-preservation: false
  # 心跳间隔默认30秒，修改为2秒
  eviction-interval-timer-in-ms: 2000

给8001添加配置信息，配置发送心跳包和超时提出时间小一点

#    默认的心跳间隔为30秒，为了测试改短成1秒
    lease-renewal-interval-in-seconds: 1
#    默认剔除时间90秒，改成2秒让立即剔除
    lease-expiration-duration-in-seconds: 2

4. 测试

启动程序7001
访问7001发现自我保护机制已经关闭

启动8001看是否能正常注册，成功注册

关闭8001，看是否被立即剔除（两秒左右就没了）

7001和8001上刚添加的配置注释掉，重启一下（默认开启自我保护）,重复下上面的测试步骤，发现8001关闭后不会被剔除。

证明测试成功，配置是可以生效关闭自我保护机制的。

总结

• 在生产环境部署时，我们的微服务会部署在不同的服务器上，为了方便管理和查看，我们需要将服务的IP暴露出来。

• 要想修改这两个配置，你的微服务POM中要有web和actuator依赖（我们之前已经添加过）。

• Discovery用于发现服务，可以获取注册中心上的服务相关信息。

• @EnableDiscoveryClient和@EnableEurekaClient

  共同点：都是能够让注册中心能够发现，扫描到改服务。
  不同点：@EnableEurekaClient只适用于Eureka作为注册中心，@EnableDiscoveryClient 可以是其他注册中心。

• Eureka的自我保护机制默认开启，，保障系统的高可用，在出现短时间内大规模丢失客户端（微服务）时，会开启自我保护机制，自我保护机制开启后将保留一段时间的注册表信息，不直接进行删除。

• Eureka的本质是EurekaClient将自己的信息以键值对的形式报给Server，Server将信息以服务名：地址的形式存储在注册表，调用方通过服务名获取调用地址。

• Eureka官网上可以看到，2.0已经停更（不停用），我们接下来学习zookeeper、consul、nacos等替代物，其中nacos是最优秀的，zookeeper是替代代价最小的。

服务注册中心Eureka已经告一段落了，后面我们会加快下进度，快速的学习下zookeeper和consul做服务注册中心，总体的思想大体都是一致的。

感兴趣请关注，一起学习下一篇：Zookeeper