springcloud: 服务熔断与网关

一，Hystrix简介 

 

Hystrix是一个用于处理分布式系统的延迟和容错的开源库, 在分布式系统里,许多依赖不可避免的会调用失败,比如超时、异常等,Hystrix能够保证在一个依赖出问题的情况下， 不会导致整体服务失败,避免级联故障，以提高分布式系统的弹性。（理念设计和思想）

服务雪崩
多个微服务之间调用的时候,假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其它的微服务,这就是所谓的“扇出”。
如果扇出的链路上某个微服务的调用响应时间过长或者不可用,对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”.

Hystrix重要概念-

服务降级fallback，

服务熔断break，

服务限流flowlimit；

服务降级：fallback

1，服务器忙，不让客户端等待立即返回一个友好提示

2，哪些情况会发出降级：程序运行异常，超时，服务熔断触发服务降级，线程池、信号量打满也会导致服务降级

服务熔断：

1，类比保险丝达到最大访问服务后，直接拒绝访问，拉闸限电，然后调用服务降级的方法友好显示

2，服务的降级->熔断-恢复调用链路

服务限流 秒杀高并发等操作，严禁一窝蜂拥挤，大家排队，一秒钟N个，有序进行

1，构建cloud-provider-hystrix-payment8001（带hystrix的provider服务端）注册进入eurake，启动7001，和该模块，

http://localhost:7001/

http://localhost:8001/payment/hystrix/ok/1

http://localhost:8001/payment/hystrix/timeout/1

正确->错误 降级熔断 恢复

假设上万个请求访问一个借口，

tomacat的默认的工程线程数被打满了，没有多余的线程分解压力和处理

假设外部消费者80访问，消费者只能干等，服务端8001拖死

2.新建80消费者（带hystrix，hystrix一般用在消费侧）

http://localhost:8083/consumer/payment/hystrix/ok/3

假设上万个请求访问8001服务端一个借口，那么8001同一层次的其他接口服务被困死，因为tomcat线程池里的工作线程已经被挤占完毕，80此时调用8001，客户端访问响应缓慢

解决的要求：
1.超时导致服务器变慢
2.出错（宕机或程序运行出错）

解决
1.对方服务(8001)超时了，调用者(80)不能一-直卡死等待,必须有服务降级
2.对方服务(8001 )down机了，调用者(80)不能一-直卡死等待，必须有服务降级
3.对方服务(8001)OK,调用者(80)自己出故障或有自我要求(自己的等待时间小于服务提供者），自己降级处理

二，Hystrix之服务降级支付侧fallback

1.服务降级
降级配置：@ HystrixCommand

2,8001从自身找问题：设置自身调用超时时间的峰值，峰值内可以正常运行,超过了需要有兜底的方法处理，作服务降级fallback

@HystrixCommand报异常后如何处理
一旦调用服务方法失败并抛出了错误信息后,会自动调用@HystrixCommand标注好的fallbackMethod调用类中的指定方法

业务类启用@ HystrixCommand，

主启动类激活
添加新注解@ EnableCircuitBreaker

http://localhost:8001/payment/hystrix/timeout/1 （超过3秒，调用兜底方法）

1.超时异常
2.计算异常

三，Hystrix之服务降级订单侧fallback

客户端进行降级（一般在客户端）

yml:

 主启动：加@EnableHystrix

业务类：

@HystrixCommand(fallbackMethod = "paymentInfo_TimeOutHandler", commandProperties = {
        @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "500")
})

启动客户端80，服务端8001，服务端没有问题，但客户端出现异常调用兜底方法

http://localhost:8083/consumer/payment/hystrix/timeout/1

四，Hystrix之全局服务降级DefaultProperties

兜底方法与业务逻辑方法耦合度高，每个方法需要兜底代码膨胀

客户端80

问题解决
1.@DefaultProperties(defaultFallback = “)

1除了个别重要核心业务有专属,普通的可以通过@DefaultProperties(defaultFallback=“”) 统- -跳转到统- 处理结果页面
通用的和独享的各自分开,避免了代码膨胀，合理减少了代码量

http://localhost:8083/consumer/payment/hystrix/timeout/1

五，Hystrix之通配服务降级FeignFallback

要解决的问题：
和业务逻辑混合一块，代码混乱

解决：

解耦
服务降级，客户端去调用服务端，碰.上服务端宕机或关闭

本次案例服务降级处理是在客户端80实现完成的，与服务端8001没有关系
只需要为Feign客户端定义的接口添加一个服务降级处理的实现类即可实现解耦

常见异常
运行时异常
超时异常
宕机

操作：

修改cloud-consumer-feign-hystrix- order80
1.重新新建一个类(PaymentFallbackService)实现该接口， 统一为接口里面的方法进行异常处理
2.PaymentFallbackService类实现PaymentFeignClientService接口

3，fallback = PaymentFallbackService.class

 http://localhost:8083/consumer/payment/hystrix/ok/1 没有问题

关闭8001（相当于宕机），再次访问，错误降级

六，服务熔断
1.类比保险丝达到最大服务访问后，直接拒绝访问，拉闸限电，然后调用服务降级的方法并返回友好提示
2.就是保险丝 服务的降级->进而熔断->恢复调用链路

熔断机制概述

断路器关闭-》打开-》半开

正常每秒100个请求->现在每秒600个请求->断路器打开->现在每秒80个请求->半开->关闭

熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务出错不可用或者响应时间太长时,会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。
当检测到该节点微服务调用响应正常后，恢复调用链路。

在Spring Cloud框架里，熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值,缺省是5秒内20次调用失败,就会启动熔断机制。熔断机制的注解是@HystrixCommand.

MartinFlower

Software Architecture Guide

七，Hystrix之服务熔断案例

操作：

修改cloud-provider-hystrix-payment8001
PaymentService

http://localhost:8001/payment/circuit/1

测试：多次错误，然后慢慢正确，发现刚开始不满足条件，就算是正确的访问地址也不能进行

服务熔断总结
熔断类型
1.熔断打开
请求不再进行调用当前服务，内部设置时钟一般为MTTR (平均故障处理时间)，当打开时长达到所设时钟则进入半熔断状态

2.熔断关闭
熔断关闭不会对服务进行熔断

3.熔断半开
部分请求根据规则调用当前服务，如果请求成功且符合规则则认为当前服务恢复正常，关闭熔断
 

断路器开启或者关闭的条件
1.当满足一定的阀值的时候(默认10秒内超过20个请求次数)
2.当失败率达到一定的时候(默认10秒内超过50%的请求失败)
3.到达以上阀值，断路器将会开启
4.当开启的时候，所有请求都不会进行转发
5.一段时间之后(默认是5秒) ,这个时候断路器是半开状态，会让其中一个请求进行转发。
6.如果成功，断路器会关闭，若失败，继续开启。重复4和5

断路器开启后
1:再有请求调用的时候，将不会调用主逻辑，而是直接调用降级fallback.通过断路器,实现了自动地发现错误并将降级逻辑切换为主逻辑，减少响应延迟的效果。
2:原来的主逻辑要如何恢复呢?
对于这一问题，hytrix也为我们实现了自动恢复功能。
当断路器打开,对主逻辑进行熔断之后，hystrix会启动一 个休眠时间窗，在这个时间窗内,降级逻辑是临时的成为主逻辑，当休眠时间窗到期，断路器将进入半开状态,释放- -次请求到原来的主逻辑上,如果此次请求正常返回,那么断路器将继续闭合,主逻辑恢复，如果这次请求依然有问题，断路器继续进入打开状态，休眠时间窗重新计时。
 

八，服务监控hystrixDashboar
概述：
除了隔离依赖服务的调用以外，Hystrix还提供 了准实时的调用监控(Hystrix Dashboard) . Hystrix会持续地记录所有通过Hystrix发起的请求的执行信息，并以统计报表和图形的形式展示给用户,包括每秒执行多少请求多少成功,多少失败等。Netflix通过hystrix-metrics-event-stream项目实现了对以上指标的监控。Spring Cloud也提供了Hystrix Dashboard的整合,对监控内容转化成可视化界面。
 

1，新建cloud-consumer-hystrix-dashboard9001

2，启动cloud-consumer-hystrix-dashboard9001该微服务后续将监控微服务8001

3，测试
地址：http://localhost:9001/hystrix

1.修改cloud-provider-hystrix-payment8001
   注意:新版本Hystrix需要在主启动类MainAppHystrix8001中指定监控路径

 2.监控测试
2.1启动1个eureka可
2.2观察监控窗口
9001监控8001
地址：http://localhost:8001/hystrix.stream

测试地址：http://localhost:8001/payment/circuit/1
http://localhost:8001/payment/circuit/-1

一，GateWay简介

是什么
Cloud全家桶中有个很重要的组件就是网关，在1.x版本中都是 采用的Zuul网关;
但在2.x版本中，zuul的升级一直跳票, SpringCloud最后自己研发了一个网关替代Zuul,那就是SpringCloud Gateway一句话: gateway是原zuul1.x版的替代

Gateway是在Spring生态系统之上构建的API网关服务,基于Spring 5, Spring Boot 2和Project Reactor等技术。
Gateway旨在提供一 种简单辆有效的方式来对API进行路由，以吸提供一 些强大的过滤器功能，例如:熔断、限流、重试等

SpringCloud Gateway是Spring Cloud的一个全新项目，基纡Spring 5.0+Spring Boot 2.0和Project Reactor等技术开发的网关，它旨在为微服务架构提供-种简单有效的统一的API路由管理方式。

SpringCloud Gateway作为Spring Cloud生态系统中的网关,目标是替代Zuul,在Spring Cloud 2.0以上版本中，没有对新版本的Zuul 2.0以上最新高性能版本进行集成，仍然还是使用的Zuul 1.x非Reactor模式的老版本。而为了提升网关的性能，SpringCloud Gateway是基于WebFlux框架实现的，而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty.

Spring Cloud Gateway的目标提供统一的路由方式且基于Filter 链的方式提供了网关基本的功能，例如:安全,监控/指标,和限流。
 

三大核心概念：

Route（路由）：路由是构建网关的基本模块，它由id，目标URI，一系列的断言和过滤器组成，如果断言为true则匹配该路由

Predicate（断言） ： 开发人员可以匹配http请求中的所有内容（列如请求头或请求参数），如果请求与断言相匹配则进行路由

filter（过滤）： 指的是spring框架中gatewayfilter的实例，使用过滤器，可以在请求路由前或后对请求进行修改

工作流程

 

 核心逻辑是路由转发+执行过滤链

（nigix是对外网关，gateway是对内网关）

1.新建Module：cloud-gateway-gateway9527

 2，

启动7001
启动8001
 启动9527网关

http://localhost:7001/

http://localhost:8001/payment/get/1

http://localhost:9527/payment/get/1

1.在配置文件yml中配置（上一篇博客）
2.代码中注入RouteLocator的Bean

http://localhost:9527/game

二，GateWay配置动态路由

默认情况下Gateway会根据注册中心注册的服务列表,以注册中心上微服务名为路径创建动态路由进行转发,从而实现动态路由的功能

1.启动：一个eureka7001 +两个服务提供者8001/8002

2,需要注意的是uri的协议为lb，表示启用Gateway的负 载均衡功能。
lb://serviceName是spring cloud
gateway在微服务中自动为我们创建的负载均衡uri

 地址：http://localhost:9527/payment/lb
效果：8001/8002两个端口切换

三，Predicate

Route Predicate Factories是什么
Spring Cloud Gateway将路由匹配作为Spring WebFlux HandlerMapping基础架构的一部分。

Spring Cloud Gateway包括许多内置的Route Predicate工厂。所有这些Predicate都与HTTP请求的不同属性匹配。 多个Route Predicate工厂可以进行组合Spring Cloud Gateway创建Route对象时，使用RoutePredicateFactory创建Predicate对象, Predicate对象可以赋值给Route。Spring Cloud Gateway包含许多内置的Route Predicate Factories.

所有这些谓词都匹配HTTP请求的不同属性。多种谓词工厂可以组合,并通过逻辑and.

常用的Route Predicate

After Route Predicate
Before Route Predicate
Between Route Predicate
Cookie Route Predicate
Header Route Predicate
Host Route Predicate
Method Route Predicate
Path Route Predicate
Query Route Predicate

四，GateWay的Filter

是什么：

路由过滤器可用于修改进入的HTTP请求和返回的HTTP响应，路由过滤器只能指定路由进行使用。
Spring Cloud Gateway内置了多种路由过滤器，他们都由GatewayFilter的工厂 类来产生

生命周期：
1.pre
2.post

GlobalFilter

自定义过滤器
自定义全局GlobalFilter
1.实现两个接口

 http://localhost:9527/payment/lb?uname=111

http://localhost:9527/payment/lb

参考尚硅谷周阳老师springcloud