Как правило, запрос может вызывать множество служб. Если нижестоящая служба ненормальна и не может нормально возвращать результаты, все вышестоящие службы будут ждать, что в конечном итоге может привести к исчерпанию большого количества ресурсов службы и вызвать лавину.
Проще говоря, когда вы кодируете, вы должны защищать свои собственные службы.Когда вы инициируете запрос на другую службу, вы должны хорошо работать с отказоустойчивостью и переходом на более раннюю версию и не влиять на свою собственную службу из-за других служб.
Есть очень простой способ, можно попробовать поймать. Даже если вызов сообщает об ошибке, он не заставляет собственную службу сообщать об ошибке. Однако этот метод только принимает ошибку, но все равно будет ждать в процессе запроса, пока не истечет время ожидания или не вернет результат ошибки. Более того, он все равно будет вызываться каждый раз, когда приходит запрос, если блоков слишком много, проблему лавины не решить.
Тогда hystrix здесь. Он может реализовать задержку и отказоустойчивость сервисных вызовов, и его характеристики следующие:
- Запрос на перенос: используйте HystrixCommand для переноса вызовов на другие службы.
- Механизм срабатывания: когда частота ошибок службы превышает определенный порог, Hystrix может отключиться и прекратить запрашивать службу на определенный период времени.
- Изоляция ресурсов: Hystrix поддерживает небольшой пул потоков ( режим массовой защиты ) (или семафор ) для каждой зависимости. Если пул потоков заполнен, запросы к службе немедленно отклоняются, а не ставятся в очередь , что ускоряет определение сбоя.
- Мониторинг: Hystrix может отслеживать рабочие индикаторы и изменения конфигурации почти в реальном времени, такие как успех, сбой, тайм-аут и отклоненные запросы.
- Механизм отката: выполнение логики отката в случае сбоя запроса, истечения времени ожидания, отклонения или при размыкании прерывателя цепи. Логика отката предоставляется разработчиком, например, возврат значения по умолчанию.
- Самовосстановление: после того, как автоматический выключатель был разомкнут в течение определенного периода времени, он автоматически переходит в « полуоткрытое » состояние.
Применение:
1. Введите зависимости
Внедрить координаты зависимостей Hystrix в проект потребителя сервиса (автоматическая доставка микросервисов) (можно добавить и в родительский проект)
<!--hystrix--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix</artifactId> </dependency>2. Добавьте аннотацию открытия предохранителя @EnableCircuitBreaker в класс запуска проекта потребителя службы.
3. Определите метод обработки перехода на более раннюю версию службы и используйте атрибут fallbackMethod @HystrixCommand в бизнес-методе , чтобы связать его с методом обработки понижения версии службы (этот метод будет использоваться при обрыве цепи).
/* 定义回退方法，返回预设默认值 注意：该方法形参和返回值与原始方法（也就是@HystrixCommand注解的方法）保持一致 */ public Integer myFallBack(Long userId) { return -123333; // 兜底数据 } @HystrixCommand( // 线程池标识，要保持唯一，不唯一的话就共用了，可以使用方法的名字 threadPoolKey = "findResumeOpenStateTimeoutFallback", // 线程池细节属性配置 threadPoolProperties = { @HystrixProperty(name="coreSize",value = "2"), // 线程数 @HystrixProperty(name="maxQueueSize",value="20") // 等待队列长度 }, // commandProperties熔断的一些细节属性配置 commandProperties = { // 每一个属性都是一个HystrixProperty，根据需要定制属性 //超时时间 @HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value="2000"), // 统计时间窗口定义 @HystrixProperty(name = "metrics.rollingStats.timeInMilliseconds",value = "8000"), // 统计时间窗口内的最小请求数 @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold",value = "2"), // 统计时间窗口内的错误数量百分比阈值 @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage",value = "50"), // 自我修复时的活动窗口长度 @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds",value = "3000") }, fallbackMethod = "myFallBack" // 回退方法 ) @GetMapping("/checkStateTimeoutFallback/{userId}") public Integer findResumeOpenStateTimeoutFallback(@PathVariable Long userId) { // 使用ribbon不需要我们自己获取服务实例然后选择一个那么去访问了（自己的负载均衡） String url = "http://lagou-service-resume/resume/openstate/" + userId; // 指定服务名 Integer forObject = restTemplate.getForObject(url, Integer.class); return forObject; }
Режим склада:
В приведенном выше примере мы видим, что threadPoolKey и threadPoolProperties также настроены, что является пулом потоков. Это режим стены хранилища.Настроив threadPoolKey и сохранив его уникальным (вы можете использовать имя метода, чтобы сохранить его уникальным, в противном случае несколько методов с аннотациями hystrix будут совместно использовать один и тот же пул потоков), чтобы hystrix предоставлял независимые методы для соответствующие методы. следующее:
1. Общий пул потоков
2. Независимый пул потоков
Проще говоря, режим стены хранилища может обеспечить независимость от пула потоков. Таким образом, новые потоки не будут создаваться постоянно, и можно будет не беспокоиться о том, что потоки в одном и том же пуле будут заняты другими предприятиями.
Принцип работы:
Для метода аннотации hystrix принцип работы hystrix:
- При возникновении проблемы с вызовом метода другими службами будет открыто временное окно (например, 10 сек.).
- Достигло ли количество обращений в проблемную службу за эти 10 секунд установленного минимального количества запросов (например, равного 10)
- Если нет, вернитесь к шагу 1 и снова начните считать.
- Если оно достигнуто, то зависит от доли количества отказов и от того, достигло ли оно установленного значения (например, установленного 50%)
- Если он достигнут, это означает, что более половины из них вышли из строя, сработали и больше не запрашивают соответствующую услугу.
- Если нет, вернитесь к шагу 1 и снова начните считать.
- Если он отключается, вам нужно время от времени проверять, была ли восстановлена услуга. Подход Hystrix заключается в открытии активного окна (по умолчанию 5 секунд), то есть каждые 5 секунд будет передаваться запрос на доступ к проблемному сервису, в случае успеха он перейдет к шагу 1 для повторной регистрации, в случае неудачи просто повторно выполнить текущий процесс.
Вышеуказанные параметры можно настроить самостоятельно, например, в приведенном выше примере конфигурация такая:
В течение 8 секунд, если количество запросов достигает 2 , а частота отказов превышает 50%, он отключится; после отключения активное окно устанавливается на 3 секунды .
commandProperties = { // 每一个属性都是一个HystrixProperty，根据需要定制属性 //超时时间 @HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value="2000"), // 统计时间窗口定义 @HystrixProperty(name = "metrics.rollingStats.timeInMilliseconds",value = "8000"), // 统计时间窗口内的最小请求数 @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold",value = "2"), // 统计时间窗口内的错误数量百分比阈值 @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage",value = "50"), // 自我修复时的活动窗口长度 @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds",value = "3000") },Его также можно настроить в файле конфигурации, и он действует глобально.
Панель мониторинга обрыва цепи:
Это проверка конкретной ситуации с автоматическим выключателем, сколько запросов, сколько сбоев и т. д. Если вы хотите это увидеть, вам нужно ввести зависимости:
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency>Затем перейдите к интерфейсу /actuator/hystrix.stream, но он не интуитивно понятен, он полностью текстовый. В настоящее время мы можем создать службу платформы мониторинга.
1. Создайте новый сервис и введите зависимости:
<!--hystrix--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix</artifactId> </dependency> <!--hystrix 仪表盘--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency>2. Добавьте @EnableHystrixDashboard в класс запуска , чтобы активировать панель мониторинга.
3. В юмл:
eureka: client: serviceUrl: # eureka server的路径 defaultZone: http://lagoucloudeurekaservera:8761/eureka/,http://lagoucloudeurekaserverb:8762/eureka/ #把 eureka 集群中的所有 url 都填写了进来，也可以只写一台，因为各个 eureka server 可以同步注册表 instance: #使用ip注册，否则会使用主机名注册了（此处考虑到对老版本的兼容，新版本经过实验都是ip） prefer-ip-address: true #自定义实例显示格式，加上版本号，便于多版本管理，注意是ip-address，早期版本是ipAddress instance-id: ${spring.cloud.client.ip-address}:${spring.application.name}:${server.port}:@project.version@4. Для сбора данных в отслеживаемом сервисе необходимо зарегистрировать сервлет в отслеживаемом сервисе
@SpringBootApplication @EnableDiscoveryClient //@EnableHystrix // 开启Hystrix功能 @EnableCircuitBreaker // 开启熔断器功能 //@SpringCloudApplication 综合性的注解 @SpringCloudApplication = @SpringBootApplication + @EnableDiscoveryClient + @EnableCircuitBreaker public class AutodeliverApplication8090 { public static void main(String[] args) { SpringApplication.run(AutodeliverApplication8090.class,args); } // 使用RestTemplate模板对象进行远程调用 @Bean @LoadBalanced public RestTemplate getRestTemplate() { return new RestTemplate(); } /** * 在被监控的微服务中注册一个serlvet，后期我们就是通过访问这个servlet来获取该服务的Hystrix监控数据的 * 前提：被监控的微服务需要引入springboot的actuator功能 * @return */ @Bean public ServletRegistrationBean getServlet(){ HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet(); ServletRegistrationBean registrationBean = new ServletRegistrationBean(streamServlet); registrationBean.setLoadOnStartup(1); registrationBean.addUrlMappings("/actuator/hystrix.stream"); registrationBean.setName("HystrixMetricsStreamServlet"); return registrationBean; } }5. Получите доступ к службе панели мониторинга платформы мониторинга: http://localhost:9000/hystrix, а затем найдите отслеживаемую цель в поле ввода: http://localhost:8090/actuator/hystrix.stream.
С приведенной выше панелью мы можем видеть конкретную ситуацию в службе, но в реальном проекте есть много экземпляров службы, не было бы очень хлопотно, если бы нам приходилось каждый раз вводить данные вручную? В настоящее время требуется агрегация для агрегирования информации обо всех микросервисах, а затем просмотра агрегации на панели мониторинга.
Сервисная сборка:
1. Ввести зависимости:
<!--hystrix turbine聚合监控--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-turbine</artifactId> </dependency> <!-- 引入eureka客户端的两个原因 1、微服务架构下的服务都尽量注册到服务中心去，便于统一管理 2、后续在当前turbine项目中我们需要配置turbine聚合的服务，比如，我们希望聚合 lagou-service-autodeliver这个服务的各个实例的hystrix数据流，那随后 我们就需要在application.yml文件中配置这个服务名，那么turbine获取服务下具体实例的数据流的 时候需要ip和端口等实例信息，那么怎么根据服务名称获取到这些信息呢？ 当然可以从eureka服务注册中心获取 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency>2. Настройте микросервисы для агрегирования
server: port: 9001 Spring: application: name: lagou-cloud-hystrix-turbine eureka: client: serviceUrl: # eureka server的路径 defaultZone: http://lagoucloudeurekaservera:8761/eureka/,http://lagoucloudeurekaserverb:8762/eureka/ #把 eureka 集群中的所有 url 都填写了进来，也可以只写一台，因为各个 eureka server 可以同步注册表 instance: #使用ip注册，否则会使用主机名注册了（此处考虑到对老版本的兼容，新版本经过实验都是ip） prefer-ip-address: true #自定义实例显示格式，加上版本号，便于多版本管理，注意是ip-address，早期版本是ipAddress instance-id: ${spring.cloud.client.ip-address}:${spring.application.name}:${server.port}:@project.version@ #turbine配置 turbine: # appCofing配置需要聚合的服务名称，比如这里聚合自动投递微服务的hystrix监控数据 # 如果要聚合多个微服务的监控数据，那么可以使用英文逗号拼接，比如 a,b,c appConfig: lagou-service-autodeliver clusterNameExpression: "'default'" # 集群默认名称3. Добавьте аннотацию @EnableTurbine в класс запуска.
4. Доступ: на панели инструментов вам нужно только найти адрес службы агрегации, чтобы увидеть статус всех микросервисов.
http://локальный:9001/турбина.поток