我们以这样一个场景来学习、构建我们的微服务
配置actuator
在生产环境部署时，我们的微服务会部署在不同的服务器上，为了方便管理和查看，我们需要将服务的IP暴露出来，这样能清清晰的看到哪个服务是部署在哪个服务器上的。
访问localhost:7001
要想修改这两个配置，你的微服务POM中要有web和actuator依赖（我们之前已经添加过）。
2. 修改8001和8002工程org.springframework.boot spring-boot-starter-web org.springframework.boot spring-boot-starter-actuator
修改8001服务和8002服务的yml配置文件，添加如下配置：
instance: instance-id: payment8001
instance: instance-id: payment80023. 查看服务注册中心
检查服务状态,点击8001服务,修改最后一个参数，查看心跳
http://localhost:8001/actuator/health
up状态说明服务正常，我们的配置对服务没有产生影响。
在8001和8002配置文件上添加配置（注意：yml格式需要严格的对其）
prefer-ip-address: true # 配置为true，标时访问时显示主机IP5. 再次访问localhost:7001查看服务注册中心
服务发现Discovery的使用
Discovery类似于微服务的关于服务，通过他能够获取微服务相关的一些信息，包括注册中心提供了哪些服务、服务的地址信息等，下面我们做一下测试。
1. 改造8001工程的controller添加DiscoveryClient
@Resource private DiscoveryClient discoveryClient;
添加测试接口，获取服务信息
// 服务发现测试
@GetMapping("/payment/discovery")
public Object getPaymentById(){
// 获取所有的服务名称
List services = discoveryClient.getServices();
for (String service : services) {
// 打印服务信息
log.info("*********service:"+service);
}
// 获取CLOUD-PAYMENT-SERVICE服务下的所有实例（8001，8002）
List 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 可以是其他注册中心。
启动所有服务
访问接口
http://localhost:8001/payment/discovery
查看页面信息
查看后台日志
Eureka的自我保护机制 1. 现象
Eureka的页面上默认会有一行红字
我们谷歌翻译一下
拉几把倒，白话解释一下：就算Eureka发现了服务某个服务异常不可用了，也不会立即将他从注册表中的分支中删除，而是会保留。
（目前我也不懂啥意思，但视频中说记好这句话就行）
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是替代代价最小的。
感兴趣请关注，一起学习下一篇：Zookeeper
