微服务架构整理-（八、SpringCloud实战之Hystrix [1]）_应用未采用注册中心机制还算微服务架构吗

最新推荐文章于 2024-11-03 11:01:20 发布

2401_84558326

最新推荐文章于 2024-11-03 11:01:20 发布

阅读量301

点赞数 4

分类专栏：程序员文章标签： java 面试学习

本文链接：https://blog.csdn.net/2401_84558326/article/details/138777593

版权

程序员专栏收录该内容

130 篇文章 0 订阅

订阅专栏

总结

至此，文章终于到了尾声。总结一下，我们谈论了简历制作过程中需要注意的以下三个部分，并分别给出了一些建议：

技术能力：先写岗位所需能力，再写加分能力，不要写无关能力；
项目经历：只写明星项目，描述遵循 STAR 法则；
简历印象：简历遵循三大原则：清晰，简短，必要，要有的放矢，不要海投；

以及最后为大家准备的福利时间：简历模板+Java面试题+热门技术系列教程视频

在这里插入图片描述

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

+ - [添加依赖](#_13)
	- [配置启动类](#_22)
	- [添加熔断机制](#_38)
	- [服务降级](#_68)
	- * [超时](#_70)
		* [异常](#_91)
+ [总结](#_143)

前言

我们知道，在微服务架构中，每个服务都是独立运行，服务与服务之间通过注册中心彼此发现和消费对方提供的服务，但是由于种种原因，可能存在如下问题：

因网络原因服务的响应太慢
某服务挂掉，还没有被踢除的情况下，导致访问请求一直得不到响应。

当请求得不到响应，后续不断有新的请求到来时，就会出现请求堵塞的情况，一个服务的堵塞引起下一个服务的堵塞，当堵塞蔓延到整个系统时，导致大部分微服务都无法正常工作，从而导致整个系统崩掉，这就是微服务架构中的雪崩现象。为了解决这个问题，在微服务架构中产生了熔断机制。熔断是电路中的专有名词，当电路出现问题（例如过载）时，熔断器立马“跳闸”，从而保护整个电路。微服务之父Martin Fowler在其论文CircuitBreaker中提出此概念。
其设计思路是这样，当服务提供者在规定时间内没有响应时，直接跳转到一个服务降级处理函数，而不是长时间的等待，这样避免调用时因为等待而线程一直得不到释放，导致雪崩的现象。

Hystrix概念

针对上述情况，Netflix提供了一套开源框架Hystrix,该框架的目标在于通过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。 Hystrix 具备服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等强大功能。 SpringCloud 在此基础上进行了封装实现了熔断器、线程隔离等一系列服务保护功能。

Hystrix使用

在SpringCloud 中使用熔断器 Hystrix 是非常简单和方便的，只需要简单两步即可。这里继续以之前的商城为例，在自己的订单（order）中查询商品(product)。

添加依赖

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
            <version>2.2.10.RELEASE</version>
        </dependency>

配置启动类

在启动类中使用 @EnableCircuitBreaker 注解开启断路器功能

@SpringBootApplication
// 激活EurekaClient
@EnableEurekaClient
//激活Hystrix
@EnableCircuitBreaker
public class OrderApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }
}

添加熔断机制

在服务消费者的方法上添加注解@HystrixCommand(fallbackMethod="handleTimeout")，其中fallbackMethod中指定的是服务降级后处理的函数。当在指定的时间里没有响应时，便会回调handle函数。响应时间默认为1000ms，可以通过commandProperties来指定，例如将响应时间设为1500ms，@HystrixCommand(fallbackMethod = "handleTimeout",commandProperties = { @HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value = "1500") })。

    @GetMapping(value = "/buy/{id}")
    //@HystrixCommand(fallbackMethod = "handleTimeout")
    @HystrixCommand(fallbackMethod = "handleTimeout",commandProperties = {
        @HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value = "1500")
    })
    public Product findById(@PathVariable Long id) {
        Product product = null;
        URI uri = null;
        try {
            uri = new URI("http://service-product/product/" + id);
        } catch (URISyntaxException e) {
            e.printStackTrace();
        }
        //这里故意弄一个超时，强迫其服务降级
        try {
            Thread.sleep(4000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        product = restTemplate.getForObject(uri, Product.class);
        return product;
    }

服务降级

有两种情况可以导致服务降级，一种是调用服务时超时，另一种是调用服务时抛出异常。

超时

调用服务提供者的方法超时时，Hystrix机制便会进行服务降级，通过回调@HystrixCommand中fallbackMethod指定的函数来进行降级，这种方法虽然得不到用户想要的结果，但保证了服务的可用性，不至于造成雪崩现象。这里需要注意此函数的返回值以及参数列表需要与添加熔断的方法保持一致。接上面的代码，这里给出handleTimeout方法。

    public Product handle(Long id) {
        Product product = new Product();
        product.setId(0L);
        product.setName("A fake product");
        product.setPrice(new BigDecimal(0));
        return product;
    }

运行结果：

{
    "id": 0,
    "name": "A fake product",
    "price": 0
}

注意：超时不管发生在服务调用方，还是服务提供者方都会进行服务降级。针对上面的两段代码，在服务消费者的方法findById上添加的熔断机制，findById中调用了服务提供者的方法 http://service-product/product/{id}, 不管在哪个方法中发生了超时，都会回调handleTimeout方法。