Обработка сбоев и запросов трассировки

🙌 Репозиторий Github для приложения: https://github.com/OmarElGabry/microservices-spring-boot

Гистрикс

Если у вас есть, скажем, 3 услуги: A вызывает → B, а B вызывает → C. Что, если в B произошел сбой? Ошибка перейдет в службу C, не так ли?

A -> B (failure) -> C

Другой пример, допустим, служба A вызывает удаленную службу R, и по какой-то причине удаленная служба не работает. Как мы можем справиться с такой ситуацией?

Что мы хотели бы сделать, так это остановить каскад отказов и предоставить способ самовосстановления, что повысит общую отказоустойчивость системы.

Hystrix - это реализация паттерна прерывателя цепи, который позволяет контролировать задержки и отказы между распределенными службами.

Основная идея состоит в том, чтобы остановить каскадные отказы за счет быстрого отказа и восстановить как можно скорее - Важные аспекты отказоустойчивых систем, которые самовосстанавливаются.

Итак, мы добавим Hystrix в сервис галереи и смоделируем сбой в сервисе изображений. В файле pom.xml

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

Весной загружаю основной класс

// ...
@EnableCircuitBreaker      // Enable circuit breakers
public class SpringEurekaGalleryApp {
  public static void main(String[] args) {
    SpringApplication.run(SpringEurekaGalleryApp.class, args);
  }
}

Spring ищет любой метод, помеченный аннотацией @HystrixCommand, и обертывает этот метод, чтобы Hystrix мог его отслеживать.

Hystrix отслеживает сбои в этом методе, и если сбои достигают порогового значения (предела), Hystrix открывает цепь, чтобы последующие вызовы автоматически завершались ошибкой. Следовательно, пока цепь разомкнута, Hystrix перенаправляет вызовы резервному методу.

Итак, в классе контроллера обновите getGallery(), добавьте аннотацию и резервный метод.

В классе контроллера службы изображений выбросить исключение в getImages()

throw new Exception("Images can't be fetched");

Теперь перейдите в браузер и нажмите localhost:8762/gallery/1. У вас должен получиться пустой объект галереи (без изображений).

{
    "id": 1,
    "images": null
}

Сыщик

Если у вас есть, скажем, 3 службы: A, B и C. Мы сделали три разных запроса.

Один запрос пошел от A → B, другой от A → B → C, а последний - от B → C.

A -> B
A -> B -> C
B -> C

По мере роста количества микросервисов отслеживание запросов, которые передаются от одного микросервиса к другому, и выяснение того, как запросы проходят через приложение, может быть довольно сложной задачей.

Sleuth позволяет отслеживать запросы, добавляя уникальные идентификаторы в журналы.

trace id (1st) используется для отслеживания через микросервисы; представляет собой весь путь запроса через все микросервисы, в то время как span id (2nd) используется для отслеживания в рамках отдельного микросервиса.

Чтобы использовать Sleuth, добавьте зависимость к pom.xml…

<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>

И в контроллере службы галереи (или изображения) используйте регистратор для регистрации некоторой информации.

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
// ...
private static final Logger LOGGER = LoggerFactory.getLogger(HomeController.class);
public Gallery getGallery(@PathVariable final int id) {
  LOGGER.info("Creating gallery object ... ");
  // ... 
  LOGGER.info("Returning images ... ");
  return images;
}
// ...

Теперь, когда вы делаете запрос к службе галереи, вы должны увидеть идентификаторы трассировки и диапазона в журналах консоли.

INFO [gallery-service,adcd5217a36fe469,8639d164315daca9,false] ...

Спасибо за чтение! Если вам понравилось, пожалуйста, похлопайте 👏 в ладоши.