服务注册中心
在传统的RPC远程调用框架中,管理每个服务与服务之间依赖关系比较复杂,管理比较复杂,所以需要使用服务治理来管理服务与服务之间依赖关系,可以实现服务调用、负载均衡、容错等功能,实现服务发现与注册。
SpringCloud封装了Netflix公司开发的Eureka模块来实现服务治理
可以想象好多电话线,需要一个交换机来进行调配,构建通信
Eureka
单机Eureka
基本概念
Eureka包含两个组件:Eureka Server和Eureka Client。
Eureka Server提供服务注册服务,各个节点启动后,会在Eureka Server中进行注册,这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息,服务节点的信息可以在界面中直观的看到。
Eureka Client是一个java客户端,用于简化与Eureka Server的交互,客户端同时也就是一个内置的、使用轮询(round-robin)负载算法的负载均衡器。
IDEA创建服务注册中心
-
创项目
-
改POM(spring-cloud-starter-netflix-eureka-server+常规)
-
写yaml
-
主启动(@EnableEurekaServer)
-
注册中心不需要业务类
-
测试
但是此时是没有服务在Eureka中注册的!
将提供者8001入驻到注册中心中
- 加POM坐标
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
- 加eureka相关配置文件
- 主启动类加注解(@EnableEurekaClient)
- 测试
把消费者80入驻到注册中心
基本同上
在配置中加个服务名称
spring.application.name:cloud-order-service
集群Eureka
Question:微服务RPC远程服务调用最核心的是什么?
Answer:高可用!!
集群Eureka的特点:互相注册,相互守望
新建注册中心7002(参考7001)
-
修改映射文件
在C:\Windows\System32\drivers\etc的hosts文件中
-
YML有区别(互相注册,相互守望)
同理7002也要改
把消费者和提供者注册进集群中
代码层不用改,主要是YML文件
- YML文件
构建服务提供者集群
- 新建服务提供者模块cloud-provider-payment8002
基本的构建方法和8001差不多,我这种小白就直接cp了
YML改下端口!
- 可以在Controller中定义一个端口值,在查询成功时返回当前是哪个端口,来判断使用的哪个提供者的服务。
记住80端口的Controller的地址不要写死!
同时要开启负载均衡!@LoadBalanced注解
Ribbon负载均衡,默认轮询!
Ribbon和Eureka整合后Consumer可以直接调用服务而不用再关心地址和端口号,且该服务还具有负载军俄航能力!
actuator微服务信息完善(小配置)
主机名称修改
针对的是微服务的提供者进行操作(8001、8002)
YML文件中的eureka中添加该属性。
访问有IP信息提示
YML中添加红框处文字
服务发现Discovery
-
功能:对于注册进eureka里面的微服务,可以通过服务发现来获得该服务的信息
-
修改cloud-provider-payment8001的Controller
-
主启动类加@EnableDiscoveryClient
-
测试
Eureka自我保护
保护模式主要用于一组客户端和Eureka Server之间存在网络分区场景下的保护。一旦进入保护模式,Eureka Server将会尝试保护其注册表中的信息,不再删除服务注册表中的数据,也就是不会注销任何微服务。
出现这个红字就说明进入保护模式了!
某时刻某一个微服务不可用了,Eureka不会立刻清理,依旧会对该微服务的信息进行保存。(属于CAP里面的AP分支)
Eureka Server 进入自我保护机制,会出现以下几种情况:
(1) Eureka 不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
(2) Eureka 仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)
(3) 当网络稳定时,当前实例新的注册信息会被同步到其它节点中
在配置文件中配置属性可以控制自我保护机制是否开启(生产环境建议开始)
eureka.server.enable-self-preservation=true
Eureka停更了。。
Zookeeper
SpringCloud整合Zookeeper代替Eureka
整合Zookeeper
创建提供者(同上,只写不同)
pom
把Eureka坐标换成zookeeper坐标
<!--Springboot整合Zookeeper客户端-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zookeeper</artifactId>
</dependency>
YML文件
#端口号
server:
port: 8004
#服务别名
spring:
application:
name: cloud-provider-payment
cloud:
zookeeper:
connect-string: xxx.xxx.xxx.xxx:2181 #公网地址:端口
主启动类
加这个注解@EnableDiscoveryClient
Controller类
@RestController
@Slf4j
public class PaymentController {
@Value("${server.port}") //从配置文件获得值
private String serverPort;
@RequestMapping(value="/payment/zk")
public String paymentzk(){
return "springcloud with zookeeper: "+serverPort+ UUID.randomUUID().toString();
}
}
测试
我启动时报了两个错误
说我的zookeeper配置是无效配置(因为我搭的zookeeper是单机伪集群)
但是好像不影响,还是能够在zookeeper上查询到!
Tips:Zookeeper注册的节点是永久节点还是临时节点?
临时节点
创建消费者
- yaml改端口和服务名
- Config
- Controller
Consul
概念
https://www.consul.io/
启动consul
解压完就一个consul.exe文件,用cmd启动
consul agent -dev
登录http://localhost:8500
服务提供者
-
建工程(cloud-providerconsul-payment8006)
-
POM(spring-cloud-starter-consul-discovery)
-
YML (不要多空格少空格啊!!!我是傻逼)
-
主启动类
-
Controller类(基本同上,改点细节)
-
测试
服务消费者
和zookeeper差不多,yaml和提供者差不多,不写了。。
三个注册中心的异同点
CAP 理论的核心是:一个分布式系统不可能同时很好的满足一致性(C)、可用性(A)、分区容错性(P)这三个需求, 因此,根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三大类:
- CA:单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大(没啥用)
- CP:满足一致性,分区容忍性的系统,通常性能不是特别高
- AP:满足可用性,分区容忍性的系统,通常可能对一致性要求低一些