SpringCloud—Eureka服务注册与发现
1. Eureka基础知识
- 前面我们没有服务注册中心,也可以服务间调用,为什么还要服务注册?
- 当服务很多时,单靠代码手动管理是很麻烦的,需要一个公共组件,统一管理多服务之间的相互调用。
- Eureka用于服务注册,目前官网已经停止更新。
Ⅰ. 什么是服务治理
SpringCloud封装了Netflix公司开发的Eureka模块来实现服务治理。
在传统的RPC远程调用框架中,管理每个服务与服务之间依赖关系比较复杂,管理比较复杂,所以需要使用服务治理,管理服务与服务之间依赖关系,可以实现服务调用、负载均衡、容错等,实现服务发现与注册。
Ⅱ. 什么是服务注册与发现
Eureka采用了CS的设计架构,Eureka Server作为服务注册功能的服务器,它是服务注册中心,而系统中的其他微服务,使用Eureka的客户端连接到Eureka Server并维持心跳连接 。这样系统的维护人员就可以通过Eureka Server来监控系统中各个微服务是否正常运行。
在服务注册与发现中,有一个注册中心。当服务器启动的时候,会把当前自己服务器的信息(比如:服务地址、通讯地址等)以别名方式注册到注册中心中。另一方(消费者/服务提供者),以该别名的方式去注册中心上获取到实际的服务通讯地址,然后再实现本地RPC调用。RPC远程调用框架核心设计思想:在于注册中心,因为使用注册中心管理每个服务与服务之间的依赖关系(服务治理概念)。在任何RPC远程框架中,都会有一个注册中心(存放服务地址相关信息 (接口地址))
Ⅲ. Eureka包含两个组件:Eureka Server 和 Eureka Client
-
Eureka Server 提供服务注册中心
➢ 各个微服务节点通过配置启动后,会在EurekaServer中进行注册,这样EurekaServer中的服务注册表中将存储所有可用服务节点的信息,服务节点的信息可以在界面中直观看到。
-
Eureka Client 通过注册中心进行访问
➢ 是一个Java客户端,用于简化Eureka Server的交互,客户端同时也具备一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后,将会向Eureka Server发送心跳(默认周期为30秒)。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳,Eureka Server将会从服务注册表中表把这个服务节点移除(默认90秒)
2. 单机Eureka构建步骤
Ⅰ. IDEA生成Eureka Server端服务注册中心
-
建Module
cloud-eureka-server7001
-
改POM
<dependencies> <!--eureka-server--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId> </dependency> <!-- 引入自己定义的api通用包,可以使用Payment支付Entity --> <dependency> <groupId>com.atguigu.springcloud</groupId> <artifactId>cloud-api-commons</artifactId> <version>${project.version}</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.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <scope>runtime</scope> <optional>true</optional> </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> </dependency> </dependencies>
-
写YML
server: port: 7001 eureka: instance: hostname: localhost # eureka服务端的实例名称 client: # false表示不向注册中心注册自己。 register-with-eureka: false # false表示自己端就是注册中心,我的职责就是维护服务实例,并不需要去检索服务 fetch-registry: false service-url: # 设置与Eureka Server交互的地址查询服务和注册服务都需要依赖这个地址。 defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
-
主启动
@EnableEurekaServer
告知我是服务注册中心@SpringBootApplication @EnableEurekaServer public class EurekaMain7001 { public static void main(String[] args) { SpringApplication.run(EurekaMain7001.class, args); } }
-
测试
http://localhost:7001/
No application available 没有服务被发现 O(∩_∩)O 因为没有注册服务进来当然不可能有服务被发现。
Ⅱ. EurekaClient端payment8001将注册进Eureka Server成为Service Provider
-
改POM
<!--eureka-client--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency>
-
写YML
eureka: client: # 表示是否将自己注册进EurekaServer默认为true。 register-with-eureka: true # 是否从EurekaServer抓取已有的注册信息,默认为true。单节点无所谓,集群必须设置为true才能配合ribbon使用负载均衡 fetchRegistry: true service-url: # 注册地址 defaultZone: http://localhost:7001/eureka
-
主启动
添加
@EnableEurekaClient
@SpringBootApplication @EnableEurekaClient public class PaymentMain8001 { public static void main(String[] args) { SpringApplication.run(PaymentMain8001.class, args); } }
-
测试
➢ 微服务注册名配置说明
➢ 自我保护机制
上面页面中出现的 EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY’RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE. 就是Eureka的自我保护机制(后面会讲)
Ⅲ. EurekaClient端order80将注册进Eureka Server成为Service Consumer
-
改POM
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency>
-
写YML
spring: application: name: cloud-order-service eureka: client: # 表示是否将自己注册进EurekaServer默认为true。 register-with-eureka: true # 是否从EurekaServer抓取已有的注册信息,默认为true。单节点无所谓,集群必须设置为true才能配合ribbon使用负载均衡 fetchRegistry: true service-url: defaultZone: http://localhost:7001/eureka
-
主启动
添加
@EnableEurekaClient
@SpringBootApplication @EnableEurekaClient public class OrderMain80 { public static void main(String[] args) { SpringApplication.run(OrderMain80.class); } }
-
测试
http://localhost/consumer/payment/get/31
3. 集群Eureka构建步骤
单机版Eureka构建到这就结束了,但是企业中不可能有谁敢说它的服务注册中心是单机版。
因为没有集群的高可用,就会带来一个严重的问题,单点故障。
Ⅰ. Eureka集群原理说明
问题:微服务RPC远程服务调用最核心的是什么
高可用,试想你的注册中心只有一个only one, 它出故障了那就呵呵( ̄▽ ̄)"了,会导致整个为服务环境不可用,所以
解决办法:搭建Eureka注册中心集群 ,实现 负载均衡 + 故障容错
Ⅱ. EurekaServer集群环境构建步骤
-
建Module
新建cloud-eureka-server7002(参考cloud-eureka-server7001)
-
改POM
-
修改映射位置
➢ 找到C:\Windows\System32\drivers\etc路径下的hosts文件
➢ 修改映射配置添加进hosts文件
127.0.0.1 eureka7001.com 127.0.0.1 eureka7002.com
-
写YML(以前单机)
➢ cloud-eureka-server7001
➢ cloud-eureka-server7002
-
主启动
@SpringBootApplication @EnableEurekaServer public class EurekaMain7002 { public static void main(String[] args) { SpringApplication.run(EurekaMain7002.class, args); } }
-
测试
http://eureka7001.com:7001/
http://eureka7002.com:7002/
《相互注册,相互守望》
Ⅲ. 将支付服务8001和订单服务80两个微服务发布到上面2台Eureka集群配置中
-
改两个微服务的YML
修改
defaultZone
即可➢ cloud-provider-payment8001
➢ cloud-consumer-order80
-
测试
➢ 先启动EurekaServer,7001/7002服务
➢ 再启动服务提供者provider,8001
➢ 再启动消费者,80
注册成功
http://localhost/consumer/payment/get/31
Ⅳ. 支付服务提供者8001集群环境构建
多个服务提供者构成集群才可以更好的为消费者提供服务。
-
建Module
新建cloud-provider-payment8002(参考cloud-provider-payment8001)
-
改POM
-
写YML(只需要将端口号修改为8002)
-
主启动
-
业务类(直接把 com包 和 resource下的mapper文件 全部复制过来 修改一下主启动类的名字)
-
修改8001/8002的Controller
@RestController @Slf4j public class PaymentController { @Resource private PaymentService paymentService; @Value("${server.port}") private String serverPort; @PostMapping(value = "/payment/create") public CommonResult create(@RequestBody Payment payment){ int result = paymentService.create(payment); log.info("*****插入结果:" + result); if (result > 0) { return new CommonResult(200, "插入数据库成功,serverPort" + serverPort, result); } else { return new CommonResult(444, "插入数据库失败", null); } } @GetMapping(value = "/payment/get/{id}") public CommonResult getPaymentById(@PathVariable("id") Long id){ Payment payment = paymentService.getPaymentById(id); log.info("*****插入结果:" + payment); if (payment != null) { return new CommonResult(200, "查询成功,serverPort" + serverPort, payment); } else { return new CommonResult(444, "没有对应记录,查询ID" + id, null); } } }
-
测试
http://localhost:8001/payment/get/31
http://localhost:8002/payment/get/31
Ⅴ. 负载均衡
-
❌Bug
订单服务访问地址不能写死
cloud-consumer-order80:
controller.OrderController
-
使用
@LoadBalanced
注解赋予RestTemplate负载均衡的能力cloud-consumer-order80:
config.ApplicationContextConfig
-
测试
完成了默认的轮询的负载机制,每次访问 CLOUD-PAYMENT-SERVICE 服务时,具体的微服务在8001和8002之间进行轮询切换:
Ribbon和Eureka整合后Consumer可以直接调用服务而不用再关心地址和端口号,且该服务还有负载功能了。O(∩_∩)O
4. actuator微服务信息完善
1️⃣ 主机名称:服务名称修改
-
当前问题
➢ 含有主机名称
-
修改cloud-provider-payment8001/8002
-
修改之后
2️⃣ 访问信息有IP信息提示
-
当前问题
➢ 没有IP提示
-
修改cloud-provider-payment8001/8002
➢ YML
-
修改之后
5. 服务发现Discovery
对于注册进eureka里面的微服务,可以通过服务发现来获得该服务的信息。
-
修改cloud-provider-payment8001的Controller
-
8001主启动类
@EnableDiscoveryClient
注解 -
测试
http://localhost:8001/payment/discovery
6. 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 INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.
Ⅱ. 导致原因
为什么会产生Eureka自我保护机制?
为了防止EurekaClient可以正常运行,但是 与 EurekaServer网络不通情况下,EurekaServer不会立刻将EurekaClient服务剔除。
什么是自我保护模式?
默认情况下,如果EurekaServer在一定时间内没有接收到某个微服务实例的心跳,EurekaServer将会注销该实例(默认90秒)。但是当网络分区故障发生(延时、卡顿、拥挤)时,微服务与EurekaServer之间无法正常通信,以上行为可能变得非常危险了——因为微服务本身其实是健康的,此时本不应该注销这个微服务。Eureka通过“自我保护模式”来解决这个问题——当EurekaServer节点在短时间内丢失过多客户端时(可能发生了网络分区故障),那么这个节点就会进入自我保护模式。
在自我保护模式中,Eureka Server会保护服务注册表中的信息,不再注销任何服务实例。
它的设计哲学就是宁可保留错误的服务注册信息,也不盲目注销任何可能健康的服务实例。一句话讲解:好死不如赖活着
综上,自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务(健康的微服务和不健康的微服务都会保留)也不盲目注销任何健康的微服务。使用自我保护模式,可以让Eureka集群更加的健壮、稳定。
一句话:某时刻某一个微服务不可用了,Eureka不会立刻清理,依旧会对该微服务的信息进行保存。
属于CAP里面的AP分支
CAP
- Consistency(一致性):即更新操作成功并返回客户端后,所有节点在同一时间的数据完全一致。对于客户端来说,一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看,则是更新如何复制分布到整个系统,以保证数据最终一致。
- Avaliability(可用性):即服务一直可用,而且是正常响应时间。系统能够很好的为用户服务,不出现用户操作失败或者访问超时等用户体验不好的情况。
- Partition Tolerance(分区容错性):即分布式系统在遇到某节点或网络故障的时候,仍然能够对外提供满足一致性和可用性的服务。分区容错性要求应用虽然是一个分布式系统,但看上去切好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了,其他剩下的机器还能够正常运转满足系统要求,对于用户而言并没有什么体验上的影响。
- CP和AP:分区容错是必须保证的,当发生网络分区的时候,如果要继续服务,那么强一致性和可用性只能2选1
Ⅲ. 怎么禁止自我保护
-
注册中心eureakeServer端7001
➢ 出厂默认,自我保护机制是开启的:
eureka.server.enable-self-preservation=true
➢ 使用
eureka.server.enable-self-preservation = false
可以禁用自我保护模式➢ 关闭效果
在eurekaServer端7001处设置关闭自我保护机制
-
生产者客户端eureakeClient端8001
➢ 默认
# 单位为秒(默认是30秒) eureka.instance.lease-renewal-interval-in-seconds=30 # 单位为秒(默认是90秒) eureka.instance.lease-expiration-duration-in-seconds=90
-
测试
假设8001宕机,关闭8001服务,等待几秒 服务被剔除: