目录
- Hystrix简单介绍
- Hystrix服务熔断（服务端）
- Hystrix服务降级（客户端）
- Dashboard流监控
- Zuul路由网关
一、Hystrix简单介绍
分布式体系结构中的应用程序有数十依赖关系，每个依赖关系在某些时候将不可避免的失败
什么是服务雪崩
- 多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C,而微服务B和微服务C有调用其他的微服务，这就是“扇出”
- 如果 扇出 的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占越来越多的系统资源（所有的请求都会堵到A的地方），进而引起系统崩溃，所谓的雪崩效应
- 对于高流量的应用来说，单一的后端依赖可能会导致服务器上所有的资源都在几秒内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他的系统资源紧张，导致系统发生更多的级联故障，这些都表示要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或者系统。
什么是Hystrix
- 是一个用于处理分布式系统延迟和容错的开源库，在分布式系统中，许多依赖不可避免的会调用失败，比如超时，异常等
- Hystrix能保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性
- "断路器"本身是一种开关设置，当某个服务单元发生故障之后，通过断路器的故障监控（熔断），向调用的方法返回一个服务预期的，可处理的备选响应（Fallback)而不是长时间的等待或者抛出调用方法无法处理的异常，这样就可以保证了服务调用方的线程不会被长时间，不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩
什么是服务熔断
- 熔断机制是应对雪崩效应的一种微服务链路保护机制，当某个服务故障后，避免所有的请求堵在该服务引起雪崩，通过熔断、降级返回自定义的信息
- 当扇出链路的某个微服务不可用或者响应时间太长，会进行服务的降级，进而熔断该节点微服务的调用，快速返回 错误的响应消息。当检测到该节点微服务调用响应正常之后恢复调用链路。
- SpringCloud的熔断机制通过hystrix实现。Hystrix会监控微服务之间调用的情况，当失败的调用达到一定阀值，缺省5秒内20次调用失败就会启动熔断机制。熔断机制的注解是
@HystrixCommand
二、Hystrix服务熔断（服务端）
- 导入依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix</artifactId>
<version>1.4.6.RELEASE</version>
</dependency>- 服务端Controller层的配置
@HystrixCommand - 主类注解开启功能
@EnableCircuitBreaker - 测试使用，熔断的机制体现就是当业务引发服务端异常的时候，作出备用方法调用，像正常似的返回前端自定义的json数据
需要注意
- 在controller层加服务熔断是方法（单个api级别的）级别的，这样每个api方法都需要写一个 失败的回调函数
- 服务熔断是在服务端，某个服务超时或者异常，引起熔断，类似保险丝
- 服务降级是在客户端，从整体的网站请求负载考虑，当某个服务熔断或者关闭之后，服务不再被调用，此时在客户端，我们可以准备一个FailbackFactory ，使关闭的服务访问时不会出现500，而是返回自定义的信息
三、Hystrix服务降级（客户端）
什么是服务降级
- 某场景下的高并发，多个微服务不够用了，需要将暂时不需要用的微服务关闭（服务器关闭，可以理解为未服务熔断，此时客户端需要做些处理，避免404），给并发的服务器更多的资源，避免资源的浪费
- 类似之前写的服务熔断的方法，只不过需要写在 客户端api模块 对应service的服务接口上面，然后以该接口为整体实现服务降级，返回自定义信息（类似服务熔断返回信息方式，）
- 服务熔断是在服务端配置，服务降级是在客户端配置
基本使用
- 导依赖
- 配置开启服务降级
- 新建FailbackFactory实现类，然后重写create方法，需要返回的是 降级之后的service接口，因为业务的service是接口，需要重写业务方法，就是在这里返回自定义的信息（响应时间过程或服务崩掉需要服务降级）
四、Dashboard流监控
什么是Dashboard流监控
- 像上图的请求经过网关之后，有时需要监控便于查看某服务的情况，是否稳定、报错等
- 配置在客户端的监控组件，可以访问配置的端口，可视化监控
基本使用
- 导依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix</artifactId>
<version>1.4.6.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix-dashboard</artifactId>
<version>1.4.6.RELEASE</version>
</dependency>- 配置端口application.yaml中配置
server.port=9001 - 编写主类，注解开启监控
@EnableHystrixDashboard，测试监控是否开启 - 然后配置需要在服务端配置，服务端导包
- 主类增加ServletBean，配合监控使用
- 访问监控页面，然后使用图中配置的监控的服务端发送请求，观察
监控数据如何看
五、Zuul路由网关
什么是Zuul
- Zuul包含了对请求的路由和过滤 两个最主要的功能
- 路由：负责将外部请求转发到具体的微服务实例上，是实现外部访问同一入口的基础，像当于先要进大门
- 过滤：负责对请求的处理过程二段干预，是实现请求校验，服务聚合等功能的基础。Zuul和Eureka进行整合，将Zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获得其他微服务的消息，即以后访问得微服务都是通过Zuul跳转的
- 可以隐藏微服务的端口和地址，使用配置的zuul微服务的地址（zuul微服务地址+微服务名+restful风格请求）来访问
注意
- Zuul服务最终还是会注册进Eureka，只不过请求需要先经过它然后在到对应的微服务
- 提供 代理 + 路由 + 过滤 三大功能
基本使用
- 导依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zuul</artifactId>
<version>1.4.6.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka</artifactId>
<version>1.4.6.RELEASE</version>
</dependency>- 配置
- 主类，注解开启网关
@EnableZuulProxy - 测试
