开发者学堂课程【微服务框架 Spring Cloud 快速入门：服务熔断】学习笔记与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/614/detail/9362
服务熔断
目录
一． 前言
二．服务熔断
一、前言
Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败。比如超时、异获等，Hystrix 能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。
(也就是说现在做了一件不好的事情，出现一种异常程序，从而调不通，则此时Hystrix 如何挽救）
"断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝)，向调用方返回一个符合预期的、可处埋的备选响应(FallBack)，而不是长时间的等待或者抛出调用方无法处理的异常，这样就保让胀务调H方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。
只要有一个新的组件 cloud 会有两步：
Hystrix断路器
maven-—-GAV 坐标
相应技术组件的新注解标签
@EnableXXXX
@HystrixCommand
向调用方返回一个符合预期的、可处理的备选响应〈FallBack)，而不是长时间的等待或者抛出调用方无法处理的异常会进行服务的降级，进而熔断该节点微服务的调用，快速返回"错误"的响应信息。
microservicecloud-provider-dept-hystrix-8001
(熔断机制的微服务机动者。所说的微本分是客户端软负载均衡，但是此时是在providr 端）
二．服务熔断
1.是什么
熔断机制是应对雪崩效应的一种微服务链路保护机制。
当扇出链路的某个微服务不可用或者响应时间太长时(Spring拥有一种思想叫AOP，面向切面编程时一定会有一种东西叫做前置通知，后置通知，环绕通知，其中有一个技术细节，是异常通知。这个时候和hystrix进行对比，从而学新技术并复习老技术）会进行服务的降级，进而熔断该节点微服务的调用，快速返回"错误"的响应信息。
当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是 @HystrixCommand。
2. 参考microservicecloud-provider-dept-8001
新建microservicecloud-provider-dept-hystrix-8001，进入页面
参考8001，则需将pom，配置文件，供成包拷入。
3. POM
（1）修改内容
添加与hystrix相关内容
<! --hystrix -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix<artifactId>
</dependency>
（2）全部内容
<projectxmins="http://maven.apache.org/POMN/4.0.0”xmIns:xsi="http://ow.w3.org/2001/XNLSchema-instancexsi:schemaLocation="http://maven.apache.org/PON/4.0.0 http: //maven.apache.org/xsd/maven-4.0.0.xsd"><modelVersion>4.0.0</ modelVersion>
<parent>
<groupId>com.atguigu.springcloud</groupId><artifactId>microservicecloud< / artifactId><version>0.0.1-SNAPSHOT</version>
</parent>
<artifactId>microservicecloud-provider-dept-hystrix-8001</artifactId>
<dependencies>
<!--hystrix -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix</ artifactId>
</ dependency>
<!-- 引入自己定义的api通用包，可以使用Dept部门Entity -->
<dependency>
<groupId>com.atguigu.springcloud</groupId>
<artifactId>microservicecloud-api
< / artifactId><version>${project.version}</version>
首先解决 pom 依赖配置
Kproject xmlns="http: / /maven.apache.org/PON/4.0.0”xmlns:xsi="http:/ /ww.w3.org/20r<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>com.atguigu.springcloud</groupId><artifactId>microssrxicecloud</ artifactId><version>0.0.1-SNAPSHOT</version>
</parent>
<artifactId>microservicecloud-provider-dept-hystrix-8001</artifactId></project>
本次重要的是解决 hystrix 组件技术
<!-- hystrix -->
<dependency>
<groupId>brg.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix</artifactId>
4.YML
既然为8001，则先拷贝，再进行修改。将com包复制，回到8001进行粘贴，yml和application 配置文件自然而行。而8001需进行数据库连接，已重复，直接参考8001。
内部内容进行修改：
Yml 文件中所修改部分:
service-url:
defaultZone: http://leureka7001.com:7001/eureka , http://eureka7002.com:7002/eureka/ ,http://eureka7003.com:7003/eure
instance:
instance-id: microservicecloud-dept8001-hystrix#自定义服务名称信息
prefer-ip-address: true#访问路径可以显示 IP 地址Ⅰ
相当于打开原有8001，其中数据库，mybatis 统统不变，变的是：
之前 id 为 microservicecloud-dept8001
现在为 microservicecloud-dept8001-hystrix 表明 depart 是在 hystrix 熔断器的微服务
随后
instance:
instance-id: microservicecloud-dept8001-hystrix
#自定义 hystrix 相关的服务名称信息
prefer-ip-address: true
#访问路径可以显示IP地址
与其他8001一样照旧。
5.修改DeptController
（1）HystrixCommand 报异常后如何处理
(一旦调用服务方法失败并抛出了错误信息后，会自动调用 @HystrixCommand 标注好的 fallbackMethod 调用类中的指定方法)
回到 Controller，有 Controller 调用 Deptservice。当异常 向调用方返回一个符合预期的、可处理的备选响应。
假设调用get方法，一二三号记录都有。
假设现在调用按照ID查询，ID为9999（此记录数据库中无），则为所查出的值，就不再是department，而是一个null。
假设查出时为null,则故意人为抛出throw Runtime' exception相当于用微服务告诉服务调用者出错，此时查询一号记录能够正常返回一号部门；若查询9999无此部门，这是组件ID无此应当到控制间查询，应当返回给其他人员要用HystrixCommand 报异常 后如何处理（类似于异常通知）
@RequestMapping(value = "/dept/get/{id} " , method = RequestMethod .GET)public Dept get(@PathVariable("id") Long id)
{
return service.get(id);I
}
此处主要讲熔断，Hystrix。其他点不重要。
public class DeptController
{
@Autowired
private DeptService service = null;
@RequestMapping(value="/dept/get/{id} " , method=RequestMethod.GET)
@Hystrixcommand(fa1lbackMethod = "processHystrix_Get")
public Dept get(@Pathvariab1e("id") Long id)
{
Dept dept = this.service.get(id);
if(null == dept)
{
throw new RuntimeExceptio"该ID: "+id+"没有没有对应的信息");
}
return dept;
Controller为service层，正常调用dept/get/比方二号记录
现今有五条记录，能够查出二号记录并不会报错。
假设ID为2，正常返回 depart，则结果dept；
假设ID为9999或超过5，100，且无此条记录，那么null，
故意人为throw new RuntimeExceptio"该ID: "+ig+"没有没有对应的信息");（127没有对应信息）
此时程序报出异常，微服务提供者无法解决，此时会写@HystrixCommand(fa1lbackMethod = "processHystrix_Get")
想调用方（消费者）返回一个符合预期的、可处理的备选（FallBack)言下之意，如果get能够正常调用，则返回正常数据，如果get调用出错，则@HystrixCommand为处理故障，处理异常，处理微服务不好使用最终的方法。
fa1lback意思为调用get出现状况，则使用processHystrix_Get方法。
processHystrix_Get方法为 public Dept processHystrix_Get(@Pathvariable("id") Long id)
也就是说能够成功调用返回数据，不能成够调用也要返回数据。
如下：代码重新修改，不再是重点。
package com.atguigu.springcloud.controller;import java.util.List;口
@RestController
public class DeptController
{
//一旦调用服努方法失败并抛出了错误信息后，会自动调用@CHystrixCommand 标注好的 fallbackMethod 调用类中的指定方法
}
主要研究熔断。
（2）代码内容
@RestController
public class DeptController
@Autowired
private DeptService service = null;
@RequestMapping(value=" /dept/get/{id} " ,method=RequestMethod.GET)
@HystrixCommand(fallbackMethod = "processHystrix_Get")
public Dept get(@PathVariable("id") Long id)
{
Dept dept = this.service.get( id);
if(null == dept)
{
throw new RuntimeException("该ID: "+id+"没有没有对应的信息");
}
return dept;
}
public Dept processHystrix_Get(@PathVariable("id") Long id)
return new Dept().setDeptno(id)
setDname("该ID: "+id+"没有没有对应的信息, null--@HystrixCommand")
setDb_source( "no this database in MySQL");
正常情况下可以查出二号记录不为空，那么返回真实记录。
若抛出get，则有为 get 垫底的 fallbackmethod 方法。此方法处理 Hystrix 使 get方法出事。
因为成效访问 depart，则返回例如：
访问127，该127没有对应信息 nul1--@Hystrixcommandl（说明调用到服务熔断机制）；相当于以一个函数depart，只不过depart被写成包含异常的信息。则前端工程师看到标志位，可以进行排错页面的处理。
总而言之：/—旦调用服务方法失败并抛出了错误信息后，会自动调用HystrixCommand标注好的fallbackMethod调用类中的指定方法
Get方法不好使用，用 fallbackmethod 垫底，而用 processHystrix_Get方法
修改主体动类：@EnablexxXXX相应注解标签
6. 修改主启动类DeptProvider8001_Hystrix_ App并添加新注解@EnableCircuitBreaker
package com.atguigu.springcloud;
import org.springframework.boot.SpringApplication;口
@SpringBootApplication
@EnableEurekaClient//本服务启动后会自动注册进eureka服务中@EnableDiscoveryClient [/服务发现
@EnableCircuitBreaker/ /对hystrixR熔断机制的支持public class DeptProvider8001_App
{
public static void main(String[] args)
{
SpringApplication.run(Deptprovider8001_App.class，args);
}
}
接下来进行测试
7.测试
（1）3个eureka先启动
（2）主启动类 DeptProvider8001_Hystrix_App
进行修改，如下：
public class DeptProvider8001THystrix_App（微服务提供者）
（3）Consumer启动microservicecloud-consumer-dept-80
目前端口：8001 正常调用返回值/异常调用熔断是否起效
三个依次进行，将进行主启动类DeptProvider8001_Hystrix_App，若启动成功，
这是带熔断的服务，端口还是8001。说明消费者找的是8001。只要8001端口上有服务，不管后面的服务是什么，只认端口。
紧接上方，打开消费者启动。
（4）http://localhost/consumer/dept/get/112
由于微服务启动越来越多，注册时间越来越长。首先看7001；可看到集群1.2.3.，注意微服务注册成功。
后方uP(1) - microservicecloud-dept8001-hystrix从何而来？
spring:
application:
name: microservicecloud-deptl
代表MCROSERVICECLoUD-DEPT
Eureka/instance/instance-ID：
microservicecloud-dept8001-hystrix
代表：microservicecloud-dept8001-hystrix
不带熔断普通版的为microservicecloud-dept8001
microservicecloud-dept8001-hystrix带熔断的hystrix的800
从而保证微服务没有张冠李戴。
接下来看消费者调用：
现今有一号记录。或者
一号记录：
二号记录：
正常操作可以返回，但是故意查一个不存在的ID
此时产生的结果：
{"deptno":235," dname" :"该ID:235没有没有对应的信息, nul1--@HystrixCommand ,"db_source :" no this database in MySQ0L""
符合consumer向调用方返回一个符合预期的、可处理的备选响应（FallBack) ,并得到熔断报错异常信息。
这便是对熔断机制的演示。
