熔断器Hystrix及服务监控Dashboard

服务雪崩效应

当一个请求依赖多个服务的时候:

正常情况下的访问 :

但是,当请求的服务中出现无法访问、异常、超时等问题时(图中的I),那么用户的请求将会被阻塞。

如果多个用户的请求中,都存在无法访问的服务,那么他们都将陷入阻塞的状态中。

Hystrix的引入,可以通过服务熔断和服务降级来解决这个问题。

服务熔断服务降级

Hystrix断路器简介

hystrix对应的中文名字是“豪猪”,豪猪周身长满了刺,能保护自己不受天敌的伤害,代表了一种防御机制,这与hystrix本身的功能不谋而合,因此Netflix团队将该框架命名为Hystrix,并使用了对应的卡通形象做作为logo。

在一个分布式系统里,许多依赖不可避免的会调用失败,比如超时、异常等,如何能够保证在一个依赖出问题的情况下,不会导致整体服务失败,这个就是Hystrix需要做的事情。Hystrix提供了熔断、隔离、Fallback、cache、监控等功能,能够在一个、或多个依赖同时出现问题时保证系统依然可用。

Hystrix服务熔断服务降级@HystrixCommand fallbackMethod

熔断机制是应对雪崩效应的一种微服务链路保护机制。

当某个服务不可用或者响应时间超时,会进行服务降级,进而熔断该节点的服务调用,快速返回自定义的错误影响页面信息。

我们写个项目来测试下;

我们写一个新的带服务熔断的服务提供者项目 microservice-student-provider-hystrix-1004

把 配置和 代码 都复制一份到这个项目里;

pom.xml加 hystrix支持

<!--Hystrix相关依赖-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>

  application.yml

server:
  port: 1004
  context-path: /
spring:
  datasource:
    type: com.alibaba.druid.pool.DruidDataSource
    driver-class-name: com.mysql.jdbc.Driver
    url: jdbc:mysql://localhost:3306/mybatis_ssm?useUnicode=true&characterEncoding=utf8
    username: root
    password: 123
  jpa:
    hibernate:
      ddl-auto: update
    show-sql: true
  application:
    name: microservice-student
  profiles: provider-hystrix-1004

eureka:
  instance:
    hostname: localhost
    appname: microservice-student
    instance-id: microservice-student:1004
    prefer-ip-address: true
  client:
    service-url:
      defaultZone: http://eureka2001.lingerqi.com:2001/eureka/,http://eureka2002.lingerqi.com:2002/eureka/,http://eureka2003.lingerqi.com:2003/eureka/

info:
  groupId: com.lingerqi.testSpringcloud
  artifactId: microservice-student-provider-hystrix-1004
  version: 1.0-SNAPSHOT
  userName: http://lingerqi.com
  phone: 123456 

StudentProviderHystrixApplication_1004

package com.lingerqi.microservicestudentproviderhystrix1004;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.autoconfigure.domain.EntityScan;
import org.springframework.cloud.client.circuitbreaker.EnableCircuitBreaker;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;

@EnableCircuitBreaker
@EntityScan("com.lingerqi.*.*")
@EnableEurekaClient
@SpringBootApplication
public class MicroserviceStudentProviderHystrix1004Application {

    public static void main(String[] args) {
        SpringApplication.run(MicroserviceStudentProviderHystrix1004Application.class, args);
    }

}

4,服务提供者1004中controller新增

package com.lingerqi.microservicestudentproviderhystrix1004.controller;

import com.lingerqi.microservicecommon.entity.Student;
import com.lingerqi.microservicestudentproviderhystrix1004.service.StudentService;
import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.web.bind.annotation.*;

import java.util.HashMap;
import java.util.List;
import java.util.Map;

@RestController
@RequestMapping("/student")
public class StudentProviderController {

    @Autowired
    private StudentService studentService;
    @Value("${server.port}")
    private String port;
    @PostMapping(value="/save")
    public boolean save(Student student){
        try{
            studentService.save(student);
            return true;
        }catch(Exception e){
            return false;
        }
    }

    @GetMapping(value="/list")
    public List<Student> list(){
        return studentService.list();
    }

    @GetMapping(value="/get/{id}")
    public Student get(@PathVariable("id") Integer id){
        return studentService.findById(id);
    }

    @GetMapping(value="/delete/{id}")
    public boolean delete(@PathVariable("id") Integer id){
        try{
            studentService.delete(id);
            return true;
        }catch(Exception e){
            return false;
        }
    }

    @RequestMapping("/ribbon")
    public String ribbon(){
        return "工号【"+port+"】正在为您服务";
    }
    /**
     * 测试Hystrix服务降级
     * @return
     * @throws InterruptedException
     */
    @ResponseBody
    @GetMapping(value="/hystrix")
    @HystrixCommand(fallbackMethod="hystrixFallback")
    public Map<String,Object> hystrix() throws InterruptedException{
//        Thread.sleep(2000);
        Map<String,Object> map=new HashMap<String,Object>();
        map.put("code", 200);
        map.put("info","工号【"+port+"】正在为您服务");
        return map;
    }

    public Map<String,Object> hystrixFallback() throws InterruptedException{
        Map<String,Object> map=new HashMap<String,Object>();
        map.put("code", 500);
        map.put("info", "系统【"+port+"】繁忙,稍后重试");
        return map;
    }
}

这里我正常访问 返回的是 200  业务数据xxxxx

但是我们这里Thread.sleep(2000) 模拟超时;

这里的话 我们加上@HystrixCommand注解 以及 fallbackMethod

表明这个方法我们再 没有异常以及没有超时(hystrix默认1秒算超时)的情况,才返回正常的业务数据;

否则,进入我们fallback指定的本地方法,我们搞的是500  系统出错,稍后重试,有效的解决雪崩效应,以及返回给用户界面

很好的报错提示信息;

microservice-student-consumer-80项目也要对应的加个方法:

  /**
     * 测试Hystrix服务降级
     * @return
     */
    @GetMapping(value="/hystrix")
    @ResponseBody
    public Map<String,Object> hystrix(){
        return restTemplate.getForObject(SERVER_IP_PORT+"/student/hystrix/", Map.class);
    }

测试下先启动三个eureka,再启动带hystrix的provider,最后启动普通的consumer;

因为 Hystrix默认1算超时,所有 sleep了2秒 所以进入自定义fallback方法,防止服务雪崩;

我们这里改sleep修改成100毫秒;

Hystrix默认超时时间设置

Hystrix默认超时时间是1秒,我们可以通过hystrix源码看到,

找到 hystrix-core.jar com.netflix.hystrix包下的HystrixCommandProperties类

default_executionTimeoutInMilliseconds属性局势默认的超时时间

我们系统里假如要自定义设置hystrix的默认时间的话;

application.yml配置文件加上

hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 3000

改成3秒  然后 我们代码里sleep修改成2秒测试;

sleep修改成4秒;

Hystrix服务监控Dashboard

Hystrix服务监控Dashboard仪表盘

Hystrix提供了 准实时的服务调用监控项目Dashboard,能够实时记录通过Hystrix发起的请求执行情况,

可以通过图表的形式展现给用户看。

我们新建项目:microservice-student-consumer-hystrix-dashboard-90

加pom依赖:

<!--Hystrix服务监控Dashboard依赖-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-hystrix-dashboard</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

  启动类加注解:

@SpringBootApplication(exclude={DataSourceAutoConfiguration.class, HibernateJpaAutoConfiguration.class})
@EnableHystrixDashboard

  

启动项目输入:http://localhost:90/hystrix,出现以上图表示OK

测试下;

我们启动三个eureka,然后再启动microservice-student-provider-hystrix-1004

我们直接请求 : http://localhost:1004/student/hystrix

返回正常业务

原文地址:https://www.cnblogs.com/omji0030/p/12008320.html

时间: 2024-10-09 09:36:30

熔断器Hystrix及服务监控Dashboard的相关文章

(四)java springcloud b2b2c shop 多用户商城系统:熔断监控Hystrix Dashboard和Turbine:熔断器Hystrix

说起springcloud熔断让我想起了去年股市中的熔断,多次痛的领悟,随意实施的熔断对整个系统的影响是灾难性的,好了接下来我们还是说正事. 熔断器 雪崩效应 在微服务架构中通常会有多个服务层调用,基础服务的故障可能会导致级联故障,进而造成整个系统不可用的情况,这种现象被称为服务雪崩效应.服务雪崩效应是一种因"服务提供者"的不可用导致"服务消费者"的不可用,并将不可用逐渐放大的过程. 如果下图所示:A作为服务提供者,B为A的服务消费者,C和D是B的服务消费者.A不可

微服务—熔断器Hystrix

前言在微服务架构中,我们将系统拆分成了一个个的服务单元,各单元应用间通过服务注册与发现的方式互相依赖. 由于每个单元都在不同的进程中运行,依赖通过远程调用的方式执行,这样就有可能因为网络原因或是依赖服务自身问题出现调用故障或延迟, 而这些问题会直接导致调用方的对外服务也出现延迟,若此时调用方的请求不断增加,最后就会出现因等待出现故障的依赖方响应而形成任务积压,线程资源无法释放,最终导致自身服务的瘫痪, 进一步甚至出现故障的蔓延最终导致整个系统的瘫痪.如果这样的架构存在如此严重的隐患,那么相较传统

干货分享微服务spring-cloud(4.负载均衡ribbon与熔断器hystrix)

Ribbon是一个基于http和tcp的客户端负载均衡工具 Hystrix具备服务降级.服务熔断.线程和信号隔离.请求缓存.请求合并以及服务监控 为了方便消费者负载均衡效果,复制demo-springcloud-client1并重名为demo-springcloud-client2,修改配置文件和启动类,服务提供者1和2服务名均为spring.application.name=demo-springcloud-client 修改YhqContoller实现,为了方便负载均衡观察效果,demo-s

SpringCloud系列七:Hystrix 熔断机制(Hystrix基本配置、服务降级、HystrixDashboard服务监控、Turbine聚合监控)

1.概念:Hystrix 熔断机制 2.具体内容 所谓的熔断机制和日常生活中见到电路保险丝是非常相似的,当出现了问题之后,保险丝会自动烧断,以保护我们的电器, 那么如果换到了程序之中呢? 当现在服务的提供方出现了问题之后整个的程序将出现错误的信息显示,而这个时候如果不想出现这样的错误信息,而希望替换为一个错误时的内容. 一个服务挂了后续的服务跟着不能用了,这就是雪崩效应 对于熔断技术的实现需要考虑以下几种情况: · 出现错误之后可以 fallback 错误的处理信息: · 如果要结合 Feign

springcloud分布式微服务(四):熔断器Hystrix

熔断器 雪崩效应 在微服务架构中通常会有多个服务层调用,基础服务的故障可能会导致级联故障,进而造成整个系统不可用的情况,这种现象被称为服务雪崩效应.服务雪崩效应是一种因"服务提供者"的不可用导致"服务消费者"的不可用,并将不可用逐渐放大的过程. 如果下图所示:A作为服务提供者,B为A的服务消费者,C和D是B的服务消费者.A不可用引起了B的不可用,并将不可用像滚雪球一样放大到C和D时,雪崩效应就形成了. 熔断器(CircuitBreaker) 熔断器的原理很简单,如同

spring cloud: Hystrix(七):Hystrix的断容器监控dashboard

Hystrix的断容器监控dashboard. dashboard是用来监控Hystrix的断容器监控的,图形化dashboard是如何实现指标的收集展示的. dashboard 本地端口8730 项目地址:http://localhost:8730/hystrix 在Pom.xml文件引入: <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-

Spring Cloud实战之初级入门(四)— 利用Hystrix实现服务熔断与服务监控

目录 1.环境介绍 2.服务监控 2.1 加入依赖 2.2 修改配置文件 2.3 修改启动文件 2.4 监控服务 2.5 小结 3. 利用hystrix实现消费服务熔断 3.1 加入服务熔断 3.2 测试服务熔断 4. 利用turbine监控所有应用 4.1 创建工程 4.2 修改配置文件 4.3 修改启动文件 4.4 启动 5.一点点重要的事情 1.环境介绍 本篇文章涉及到前面文章的工程,mirco-service-provider.mirco-service-consumer以及需要另外新建

SpringCloud学习系列之三----- 断路器Hystrix和断路器监控Dashboar

前言 本篇主要介绍的是SpringCloud中的断路器(Hystrix)和断路器指标看板(Dashboard)的相关使用知识. SpringCloud Hystrix Hystrix 介绍 Netflix创建了一个名为Hystrix的库,它实现了断路器模式.主要的目的是为了解决服务雪崩效应的一个组件,是保护服务高可用的最后一道防线. 开发准备 开发环境 JDK:1.8 SpringBoot:2.1.1.RELEASE SpringCloud:Finchley 注:不一定非要用上述的版本,可以根据

Spring Cloud第十三篇 | Spring Boot Admin服务监控

本文是Spring Cloud专栏的第十三篇文章,了解前十二篇文章内容有助于更好的理解本文: Spring Cloud第一篇 | Spring Cloud前言及其常用组件介绍概览 Spring Cloud第二篇 | 使用并认识Eureka注册中心 Spring Cloud第三篇 | 搭建高可用Eureka注册中心 Spring Cloud第四篇 | 客户端负载均衡Ribbon Spring Cloud第五篇 | 服务熔断Hystrix Spring Cloud第六篇 | Hystrix仪表盘监控