1,SpringCloud升级,部分组件停用:
1,Eureka停用,可以使用zk作为服务注册中心
2,服务调用,Ribbon准备停更,代替为LoadBalance
3,Feign改为OpenFeign
4,Hystrix停更,改为resilence4j
或者阿里巴巴的sentienl
5.Zuul改为gateway
6,服务配置Config改为 Nacos
2,服务注册与发现
6,Eureka:
前面我们没有服务注册中心,也可以服务间调用,为什么还要服务注册?
当服务很多时,单靠代码手动管理是很麻烦的,需要一个公共组件,统一管理多服务,包括服务是否正常运行,等
Eureka用于服务注册,目前官网已经停止更新
Eureka自我保护:
7,Zookeeper服务注册与发现:
8,Consul:
9,三个注册中心的异同:
3,服务调用
10,Ribbon负载均衡:
进程内LB(本地负载均衡)
集中式LB(服务端负载均衡)
区别
Ribbon就是负载均衡+RestTemplate
Ribbon常用负载均衡算法:
IRule接口,Riboon使用该接口,根据特定算法从所有服务中,选择一个服务,
Rule接口有7个实现类,每个实现类代表一个负载均衡算法
自定义负载均衡算法:
1,ribbon的轮询算法原理
2,自定义负载均衡算法:
- 去掉@LoadBalanced
3,自定义接口
4,接口实现类
5,修改controller:
11,OpenFeign
是一个声明式的web客户端,只需要创建一个接口,添加注解即可完成微服务之间的调用
就是A要调用B,Feign就是在A中创建一个一模一样的B对外提供服务的的接口,我们调用这个接口,就可以服务到B
Feign与OpenFeign区别
使用OpenFeign
bon负载均衡算法
- 自定义负载均衡算法
Feign和OpenFeign
5,fegin需要调用的其他的服务的接口
Feign默认使用ribbon实现负载均衡OpenFeign超时机制:
OpenFeign默认等待时间是1秒,超过1秒,直接报错1,设置超时时间,修改配置文件:
因为OpenFeign的底层是ribbon进行负载均衡,所以它的超时时间是由ribbon控制
OpenFeign日志:
OpenFeign的日志级别有:
4,服务降级:
12,Hystrix服务降级
hystrix中的重要概念:
1,服务降级
比如当某个服务繁忙,不能让客户端的请求一直等待,应该立刻返回给客户端一个备选方案2,服务熔断
当某个服务出现问题,卡死了,不能让用户一直等待,需要关闭所有对此服务的访问，然后调用服务降级3,服务限流
限流,比如秒杀场景,不能访问用户瞬间都访问服务器,限制一次只可以有多少请求使用hystrix,服务降级:
1,为service的指定方法(会延迟的方法)添加@HystrixCommand注解
2,主启动类上,添加激活hystrix的注解
3,触发异常
可以看到,也触发了降级
2,修改order模块,进行服务降级
1,修改配置文件:
2,主启动类添加直接,启用hystrix:
3,修改controller,添加降级方法什么的
4,测试
启动pay模块,order模块,
注意:,这里pay模块和order模块都开启了服务降级
但是order这里,设置了1.5秒就降级,所以访问时,一定会降级
4,重构:
上面出现的问题:
1,降级方法与业务方法写在了一块,耦合度高
2.每个业务方法都写了一个降级方法,重复代码多
解决重复代码的问题:
配置一个全局的降级方法,所有方法都可以走这个降级方法,至于某些特殊创建,再单独创建方法
1,创建一个全局方法
2,使用注解指定其为全局降级方法(默认降级方法)
3,业务方法使用默认降级方法:
4,测试:
解决代码耦合度的问题:
修改order模块,这里开始,pay模块就不服务降级了,服务降级写在order模块即可
1,Payservice接口是远程调用pay模块的,我们这里创建一个类实现service接口,在实现类中统一处理异常
2,修改配置文件:添加:
3,让PayService的实现类生效:
它的运行逻辑是:当请求过来,首先还是通过Feign远程调用pay模块对应的方法但是如果pay模块报错,调用失败,那么就会调用PayMentFalbackService类的当前同名的方法,作为降级方法
4,启动测试
启动order和pay正常访问—ok
此时将pay服务关闭,order再次访问
可以看到,并没有报500错误,而是降级访问实现类的同名方法
这样,即使服务器挂了,用户要不要一直等待,或者报错
问题:
**这样虽然解决了代码耦合度问题,但是又出现了过多重复代码的问题,每个方法都有一个降级方法**
使用服务熔断:
比如并发达到1000,我们就拒绝其他用户访问,在有用户访问,就访问降级方法
1,修改前面的pay模块
1,修改Payservice接口,添加服务熔断相关的方法:
这里属性整体意思是:
10秒之内(窗口,会移动),如果并发==超过==10个,或者10个并发中,失败了6个,就开启熔断器
IdUtil是Hutool包下的类,这个Hutool就是整合了所有的常用方法,比如UUID,反射,IO流等工具方法什么的都整合了
断路器的打开和关闭,是按照一下5步决定的1,并发此时是否达到我们指定的阈值2,错误百分比,比如我们配置了60%,那么如果并发请求中,10次有6次是失败的,就开启断路器3,上面的条件符合,断路器改变状态为open(开启)4,这个服务的断路器开启,所有请求无法访问5,在我们的时间窗口期,期间,尝试让一些请求通过(半开状态),如果请求还是失败,证明断路器还是开启状态,服务没有恢复如果请求成功了,证明服务已经恢复,断路器状态变为close关闭状态
2,修改controller
3,测试:
启动pay,order模块
多次访问,并且错误率超过60%:
此时服务熔断,此时即使访问正确的也会报错:
但是,当过了几秒后,又恢复了
因为在10秒窗口期内,它自己会尝试接收部分请求,发现服务可以正常调用,慢慢的当错误率低于60%,取消熔断
Hystrix所有可配置的属性:
全部在这个方法中记录,以成员变量的形式记录,
以后需要什么属性,查看这个类即可
总结:
当断路器开启后:
其他参数:
熔断整体流程:
1请求进来,首先查询缓存,如果缓存有,直接返回如果缓存没有,--->22,查看断路器是否开启,如果开启的,Hystrix直接将请求转发到降级返回,然后返回如果断路器是关闭的,判断线程池等资源是否已经满了,如果已经满了也会走降级方法如果资源没有满,判断我们使用的什么类型的Hystrix,决定调用构造方法还是run方法然后处理请求然后Hystrix将本次请求的结果信息汇报给断路器,因为断路器此时可能是开启的(因为断路器开启也是可以接收请求的)断路器收到信息,判断是否符合开启或关闭断路器的条件,如果本次请求处理失败,又会进入降级方法如果处理成功,判断处理是否超时,如果超时了,也进入降级方法最后,没有超时,则本次请求处理成功,将结果返回给controller
Hystrix服务监控:
HystrixDashboard
2,使用HystrixDashboard:
之前的pom文件中都添加过了,这个是springboot的监控组件
6,启动9001即可
访问: **localhost:9001/hystrix**
7,注意,此时仅仅是可以访问HystrixDashboard,并不代表已经监控了8001,8002
如果要监控,还需要配置:(8001为例)
8,到此,可以启动服务
启动7001,8001,9001
然后在web界面,指定9001要监控8001:
若有收获，就点个赞吧
0 人点赞
