Масштабируемые системы требуют устойчивости. При обслуживании миллионов клиентов любая система хотела бы иметь механизм обработки сбоев, потому что они обязательно произойдут, а также восстановление и обслуживание запросов. Эта проблема решается шаблоном автоматического выключателя. Автоматический выключатель — это механизм для устранения сбоев и выполнения определенных действий. Сбои могут быть вызваны несколькими причинами, такими как высокая нагрузка на серверы, проблемы с подключением, сбои базы данных и т. д. Из-за неожиданных причин любая система может выйти из строя. Но наша цель — восстановить наши системы как можно быстрее.
Теперь я хочу показать аналогичный шаблон на сервере NodeJS. Допустим, я использую сервер Node в качестве веб-прокси, который направляет все клиентские запросы к микросервису, получает данные и возвращает их клиенту.
Это выглядит как простой прокси для API службы поиска для получения списка продуктов. Теперь, что происходит, когда микросервис выходит из строя. Он может выдать клиенту 500, 504, 503 и любые подобные ошибки. Как указывалось ранее, одной из причин может быть то, что поисковая система испытывает всплеск трафика, из-за чего ее производительность достигла своего пика. Чтобы не ухудшать статистику еще больше, нам нужно будет контролировать количество входящих запросов, чтобы машины могли дышать!
Теперь, как мы это делаем? Давайте рассмотрим реализацию базового прерывателя цепи для нашего сервера Node с помощью Opossum.
Итак, давайте посмотрим на этот кусок кода. Это файл с именем circuitBreaker.js, который инициализирует класс CircuitBreaker и предоставляет доступ к его экземпляру. Довольно прямолинейно. Здесь мы хотим импортировать библиотеку Opossum, которая позволит нам создавать наши экземпляры прерывателя. Теперь давайте сосредоточимся на функции создать. Кажется, это принимает параметр config (ниже мы увидим использование этой функции). В теле инициализируется библиотека, конструктор которой принимает два аргумента. Во-первых, это функция «действие», которая возвращает обещание, а во-вторых, объект конфигурации для прерывателя.
«действие» — это основная функция, которая вызывается при срабатывании автоматического выключателя. Внутри этого мы хотим вызвать наш API, завернутый в обещание. Мы создаем нашу функцию действия с помощью функции createAction, а объект конфигурации считывается из config.breakerConfig. При этом наш автоматический выключатель будет создан, возвращен и сохранен в переменной экземпляра. Следует отметить, что эти автоматические выключатели для всех различных API будут созданы при первом запуске нашего сервера.
Теперь каждая конфигурация, передаваемая функции create, предназначена для определенного API службы. Это определяет, какой API мы хотим вызывать и с какими данными/аргументами при срабатывании созданного прерывателя. Поскольку каждый запрос независим и может содержать разные данные, которые мы можем захотеть передать службе, чтобы получить конкретный результат для нашего варианта использования, нам нужен способ получить конфигурацию запроса во время выполнения. Функция getRequestConfig позволит нам добиться этого. Это будет передано из конфигурации уровня API для прерывателя и вызвано во время hitService.
Выше представлен новый файл services.js, в котором теперь представлены наши службы с экземплярами прерывателя цепи. У нас есть servicesConfig, который содержит breakerConfig (содержащий параметры конфигурации Opossum) и getRequestConfig, который будет возвращать параметры моего API всякий раз, когда он вызывается через канал. спусковой крючок прерывателя.
Теперь все, что мы здесь сделали, это использовали поискэкспорт из файла services вместо старого hitSearchService. На этот раз мы вызываем search.fire, который является вызовом триггера прерывателя цепи с нашим запросом и данными. В остальном все будет работать как есть, пока мы сохраняем совместимые форматы данных и возврата ошибок.
Итак, каковы преимущества всего того, что мы сделали? Как было сказано ранее, мы хотим контролировать количество запросов, которые мы делаем, когда исходная система начинает вести себя странно. Когда достигается определенный порог ошибки (errorThresholdPercentage в breakerConfig), цепь «размыкается», и прерыватель больше не пропускает запросы. Он ждет некоторое время (resetTimeout в breakerConfig), делает один вызов API и ждет его разрешения. В случае сбоя он будет ждать еще resetTimeout количество времени, в противном случае цепь замыкается.
Есть больше вариантов конфигурации, которые можно использовать. Обратитесь к https://github.com/nodeshift/opossum для более подробной информации.
