前言:目前我们的项目是微服务架构,基于dubbo框架,服务之间的调用是通过rpc调用的。刚开始没有任何问题,项目运行健康、良好。可是过了一段时间,线上总有人反应查询订单失败,等过了一段时间才能查到。这是怎么回事呢?打开后台的日志一看出现了一些RpcException和TimeOutException,原来是远程调用超时了,可能某个服务在请求的高发期访问数据库异常,IO阻塞,返回接口异常了。后来这个问题越来越频繁,如何解决这个棘手的问题呢?
一:Hystrix是什么?
1.1:基本解释
Hystrix最开始由Netflix(看过美剧的都知道,它是一个美剧影视制作的巨头公司)开源的,后来由Spring Cloud Hystrix基于这款框架实现了断路器、线程隔离等一系列服务保护功能,该框架的目标在于通过控制访问远程系统、服务和第三方库的节点,从而延迟和故障提供更强大的容错能力。hystrix具备服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等强大功能。起到了微服务的保护机制,防止某个单元出现故障.从而引起依赖关系引发故障的蔓延,最终导致整个系统的瘫痪。
1.2:断路器的概念
断路器本身是一个开关装置,用在电路上保护线路过载,当线路中有电器发生短路的时候。“断路器”能够及时切断故障,防止发生过载、发热甚至起火等严重后果。当分布式架构中,断路器模式起到的作用也是类似的。当某个服务发生故障的时候,通过断路器的故障监控向调用方返回一个错误响应,而不是长时间的线程挂机,无限等待。这样就不会使线程因故障服务被长时间占用不释放,避免了故障在分布式系统中的蔓延。如下图是现实中的断路器,它是一个开关装置:
二:Hystrix解决超时问题
2.1:问题
假设我们前端提供了用户查询订单的功能,首先请求映射到OrderController,控制器通过调用服务orderService获取订单信息,前端传过来两个参数:一个是订单id,一个是用户id,orderService需要通过用户id调取用户服务来获取用户的相关信息返回给订单服务去组装信息,假设这里是通过http请求的,我们有一个单独的工程叫做:userService部署在其他的服务器上。但是这个服务器宕机了,这时候订单服务调取用户信息就失败了,然后查询订单整个请求就失败了!由一个服务的宕机就导致整个查询都失败了,牵一发而动全身。流程见下图:
2.2:使用Hystrix进行服务降级
2.2.1:引入hystrix依赖 这里引入了spring-cloud-starter-netflix-hystrix,springboot的starter里面整合了hystrix
<properties> <java.version>1.8</java.version> <spring-cloud.version>Greenwich.SR1</spring-cloud.version> </properties> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId> </dependency> <dependency> <groupId>cn.hutool</groupId> <artifactId>hutool-all</artifactId> <version>4.5.1</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>${spring-cloud.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>
2.2.2:模拟订单请求
首先通过OrderController映射/order请求,获取前端传入的参数orderId和useId,然后调用orderDetailService方法,
@RestController public class OrderController { @Resource private OrderService orderService; /** * 获取订单信息 * * @param orderNo * @return */ @PostMapping("/order") public ResultVo<OrderDetail> getOrderInfo(@RequestParam("orderId") Long orderNo, @RequestParam("userId") Long userId) { OrderDetail orderDetail = orderService.orderDetailService(orderNo, userId); ResultVo resultVo = new ResultVo<>(); resultVo.setCode(100); resultVo.setMessage("请求成功"); resultVo.setData(orderDetail); return resultVo; } }
2.2.3:订单服务调取其他服务
这里引入了RestTemplate,它是一个spring封装的http映射请求工具类,然后通过http请求访问url = "http://192.168.80.153:8070/user/getUser"获取用户名,将值给订单对象。不过假如在这其中发生了调用异常,请求用户服务异常的话,那么返回给前端就是一串空的订单信息,导致用户看到的订单为空。在使用hystrix之后,可以用@HystrixCommand(fallbackMethod = "orderFallBack")注解,在fallbackMethod中指定回退的方法,这里必须注意在@HystrixCommand上的方法其指定的回调方法必须和原方法的参数保持一致,这里包括参数类型、参数个数、参数顺序。我们在回调用法中模拟去查询缓存数据,返回给订单。有人又要问了,如果查询缓存服务器再异常呢?不排除这种可能性。如果是这样的话,依然可以使用@HystrixCommand注解在回调方法中,再指定其他的回调方法:
@Service public class OrderService { @Autowired private RestTemplate restTemplate; /** * 根据订单id获取订单详情 * * @param orderId * @param userId * @return */ @HystrixCommand(fallbackMethod = "orderFallBack") public OrderDetail orderDetailService(Long orderId, Long userId) { if (Objects.isNull(orderId)) { return null; } OrderDetail orderDetail = OrderDBSource.getOrderDB().get(orderId); //调用user服务 final String url = "http://192.168.80.153:8070/user/getUser"; String userName = ""; ResponseEntity<String> responseEntity = restTemplate.postForEntity(url, userId, String.class); String returnContent = responseEntity.getBody(); if (Objects.nonNull(responseEntity) && StrUtil.isNotEmpty(returnContent)) { userName = returnContent; } if (ObjectUtil.isNotNull(orderDetail)){ orderDetail.setUserName(userName); } return orderDetail; } /** * 异常调用的回调方法 * * @return */ public OrderDetail orderFallBack(Long orderId, Long userId) { OrderDetail orderDetail = OrderDBSource.getOrderCache().get(orderId); final String unknown = "未知用户"; orderDetail.setUserName(unknown); return orderDetail; } }
2.3.4:模拟测试
为了方便测试,首先我们将请求服务暂时先注释,然后用postman测试看正常的返回应该是这样的,这里使用了备注为数据库获取的订单,表明它没有走回调方法,因为这里没有访问用户url获取用户信息,程序可以正常访问。我再放开
加上获取用户服务的链接,实际上用户服务是无法访问到的,访问的话就会超时,超时会被hystrix捕捉到,然后走fallBack指定的方法,我们来测试一下,可以看到实际上走的是缓存中查询到的订单,可以看到用户服务已经成功的降级了,降级后的订单信息虽然是缓存获取到的,可能会存在延时等问题(当然只要维护好缓存就可以避免这个问题)。但是比没有任何数据带来的用户一点会更好!
三:Hystrix的流程
Hystrix实际上的工作原理是这样的:通过command来解耦请求与返回操作,在具体的实例中就是,Hystrix会对依赖的服务进行观察,通过command.toObservable调用返回一个观察的对象,同时发起一个事件,然后用Subscriber对接受到的事件进行处理。在command命令发出请求后,它通过一系列的判断,顺序依次是缓存是否命中、断路器是否打开、线程池是否占满,然后它才会开始对我们编写的代码进行实际的请求依赖服务的处理,也就是Hystrix.run方法,如果在这其中任一节点出现错误或者抛出异常,它都会返回到fallback方法进行服务降级处理,当降级处理完成之后,它会将结果返回给,际的调用者,经过一系列流程处理的,它的具体工作流程如下:
四:总结
本篇博客讲述了Hystrix是什么?然后解释了Hystrix如何进行服务降级处理以及简单的处理流程,讲到的内容是最为常用的功能,还有一些关于Hystrix的缓存、线程池的隔离技术等由于篇幅的原因,没有详细的讲解到,不过作为一篇入门级的Hystrix教程博客是基本够的。在实际的开发中,如何保持服务的健壮性、服务的可用性、尽量的减少bug,提升用户体验都是我们开发者的使命,这条优化和提升之路永远没有尽头,go ahead!
参考资料《spring cloud微服务实战》
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持小牛知识库。
本文向大家介绍详解SpringCloud微服务架构之Hystrix断路器,包括了详解SpringCloud微服务架构之Hystrix断路器的使用技巧和注意事项,需要的朋友参考一下 一:什么是Hystrix 在分布式环境中,许多服务依赖项中的一些将不可避免地失败。Hystrix是一个库,通过添加延迟容差和容错逻辑来帮助您控制这些分布式服务之间的交互。Hystrix通过隔离服务之间的访问点,停止其间的
本文向大家介绍SpringCloud-Alibaba-Sentinel服务降级,热点限流,服务熔断,包括了SpringCloud-Alibaba-Sentinel服务降级,热点限流,服务熔断的使用技巧和注意事项,需要的朋友参考一下 前言: 除了流量控制以外,对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。一个服务常常会调用别的模块,可能是另外的一个远程服务、数据库,或者第三方 A
可以通过服务降级功能 1 临时屏蔽某个出错的非关键服务,并定义降级后的返回策略。 向注册中心写入动态配置覆盖规则: RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension(); Registry registry = regist
网上给的原因是:服务降级和隔离是为了保护服务调用方 但是我逻辑上一直没捋顺,有大佬能讲一下 降级(或隔离)的过程吗 ps:微服务刚入门,勿喷
在分布式环境下,特别是微服务结构的分布式系统中, 一个软件系统调用另外一个远程系统是非常普遍的。这种远程调用的被调用方可能是另外一个进程,或者是跨网路的另外一台主机, 这种远程的调用和进程的内部调用最大的区别是,远程调用可能会失败,或者挂起而没有任何回应,直到超时。更坏的情况是, 如果有多个调用者对同一个挂起的服务进行调用,那么就很有可能的是一个服务的超时等待迅速蔓延到整个分布式系统,引起连锁反应
安装 composer require hyperf/circuit-breaker 为什么要熔断? 分布式系统中经常会出现由于某个基础服务不可用造成整个系统不可用的情况,这种现象被称为服务雪崩效应。为了应对服务雪崩,一种常见的做法是服务降级。而 hyperf/circuit-breaker 组件,就是为了来解决这个问题的。 使用熔断器 熔断器的使用十分简单,只需要加入 Hyperf\Circu
我将使用Laravel框架构建micrservices。我有用户微服务,它处理客户端凭证并验证它们(为客户端创建JWT)。此外,还有另一种需要用户认证的微服务。 问题是,如果秘密访问令牌密钥仅在用户微服务中,我如何验证客户端在微服务(用户微服务除外)中的访问令牌?或者,我应该在每个微服务中保留密钥吗?
本文向大家介绍springcloud 熔断器Hystrix的具体使用,包括了springcloud 熔断器Hystrix的具体使用的使用技巧和注意事项,需要的朋友参考一下 说起springcloud熔断让我想起了去年股市中的熔断,多次痛的领悟,随意实施的熔断对整个系统的影响是灾难性的,好了接下来我们还是说正事。 熔断器 雪崩效应 在微服务架构中通常会有多个服务层调用,基础服务的故障可能会导致级联故