Какие подходы к обработке ошибок в распределенной системе используются?

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

Ключевые стратегии обработки ошибок

• Повторные попытки (Retry): Простейший механизм, при котором неудачный запрос повторяется. Ключевой момент — использовать экспоненциальную задержку (exponential backoff) и джиттер (jitter), чтобы не перегружать целевой сервис. Повторять стоит только для идемпотентных операций и транзиентных (временных) ошибок, таких как таймауты сети.
• Предохранитель (Circuit Breaker): Паттерн, предотвращающий выполнение запросов к неработающему сервису. После определенного количества неудач "цепь разрывается", и все последующие запросы мгновенно завершаются ошибкой, давая сервису время на восстановление. Периодически делаются пробные запросы для проверки восстановления.
• Очередь недоставленных сообщений (Dead Letter Queue - DLQ): При использовании асинхронной коммуникации (очереди сообщений) сообщения, которые не удалось обработать после нескольких попыток, перемещаются в специальную очередь (DLQ) для последующего анализа, ручного вмешательства или повторной обработки.
• Идемпотентность (Idempotency): Гарантия того, что повторное выполнение одной и той же операции (например, из-за retry) приведет к тому же результату, что и однократное выполнение. Это часто достигается через уникальные идентификаторы запросов (idempotency keys).
• Компенсирующие транзакции (Saga Pattern): Для отката распределенных транзакций, где каждая успешная операция должна иметь компенсирующую операцию на случай сбоя в цепочке.

Практический пример: Retry с Circuit Breaker

Рассмотрим пример на Node.js с использованием библиотеки axios для HTTP-запросов и circuit-breaker-js.

const axios = require('axios');
const CircuitBreaker = require('circuit-breaker-js');

// Создаем экземпляр Circuit Breaker
const breaker = new CircuitBreaker({
  timeoutDuration: 5000, // Таймаут операции
  errorThreshold: 50,    // % ошибок для разрыва цепи
  volumeThreshold: 10,   // мин. запросов перед срабатыванием
  resetDuration: 30000   // время до попытки восстановления
});

async function callExternalService(url) {
  // Обертка запроса в Circuit Breaker
  return breaker.run(async () => {
    // Добавляем логику повторных попыток с backoff
    let lastError;
    for (let attempt = 0; attempt < 3; attempt++) {
      try {
        const response = await axios.get(url, { timeout: 2000 });
        return response.data;
      } catch (error) {
        lastError = error;
        if (error.code === 'ECONNABORTED' || error.response?.status >= 500) {
          // Только для временных ошибок - ждем перед повторной попыткой
          await new Promise(resolve => setTimeout(resolve, 1000 * Math.pow(2, attempt)));
          continue;
        }
        // Для клиентских ошибок (4xx) повторять не нужно
        throw error;
      }
    }
    throw lastError; // Все попытки исчерпаны
  });
}

// Использование
callExternalService('https://api.example.com/data')
  .then(data => console.log('Success:', data))
  .catch(err => console.error('Failed after all retries:', err));

В этом примере Circuit Breaker защищает систему от постоянных вызовов падающего сервиса, а внутренний механизм retry с экспоненциальной задержкой пытается справиться с временными сбоями.

Где применяются эти подходы

Эти паттерны являются фундаментальными для построения отказоустойчивых микросервисных архитектур, систем обработки событий (event-driven), интеграций со сторонними API и любых сценариев, где важна надежность межсервисного взаимодействия. Они реализованы во многих фреймворках и облачных сервисах (например, Polly в .NET, resilience4j в Java, встроенные механизмы в AWS Step Functions или Azure Logic Apps).

Вывод: Комбинация retry, circuit breaker, DLQ и идемпотентности позволяет создавать распределенные системы, которые устойчивы к сбоям, самовосстанавливаются и минимизируют влияние отказа одного компонента на всю экосистему. Эти подходы стоит применять везде, где доступность и надежность являются критически важными требованиями.