Стратегии обработки ошибок для бессерверной архитектуры, управляемой событиями

17 декабря 2022 г.

Что такое архитектура, управляемая событиями?

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

Архитектура, управляемая событиями, по своей сути предоставляет все возможности, которые нам нужны от потокового решения. Накладывая управляемые услуги, предоставляемые облачными провайдерами, на архитектуру, управляемую событиями, можно создать бессерверное потоковое решение. Если вы можете сопоставить приведенный выше шаблон с управляемыми сервисами, такими как AWS Lambda, в качестве микросервиса и AWS Kinesis в качестве шины сообщений, вы сможете создать управляемую событиями архитектуру, используя бессерверные стеки.

Стратегии обработки ошибок

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

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

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

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

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

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

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

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

Давайте поговорим о некоторых из упомянутых выше методов более подробно.

Повторяемые ошибки

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

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

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

Шаблон автоматического выключателя

Думайте о шаблоне прерывателя цепи как о функции быстрого сбоя, когда, допустим, ваше приложение дает сбой для одного из сообщений, тогда вы можете захотеть сломать систему для этого события и отправить его в отдельную очередь, также известную как мертвые. очередь писем. Dead Later Queue можно рассматривать как парковку, где вы можете повторить попытку или исследовать неудачное событие. Такое событие чаще всего происходит из-за проблемы с форматом самого события, поэтому часто требуется ручное вмешательство.

n

Автоматический выключатель может находиться в одном из трех состояний:

• Закрыто: удаленная служба работает должным образом. Короткое замыкание не требуется.
• Открыта: удаленная служба не отвечает должным образом, отключена или зависла. Все запросы обрываются. Это состояние достигается только после определенного количества сбоев.
• Полуоткрыто: регистрирует количество успешных попыток инициировать удаленные вызовы. Это помогает проверить, подключен ли удаленный сервер к сети и работает ли он должным образом.

Заключение

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

---

Оригинал