Event-based Microservices: обработка ошибок
Очень важно правильно обрабатывать ошибки и не набрать снежный ком, который сможет вывести вашу систему из строя. Особо остро проблема стоит в микросервисной архитектуре из-за большого количества проблем, добавляемой самой распределенной моделью.
Ошибки можно разделить на два типа:
— Временные (проблемы с подключением, системные сбои)
— Постоянные (баги, ошибки сериализации)
Временные ошибки можно решить простым образом — ретраями. Постоянные ошибки в основном требуют внимания человека, они должны зажечь алертинги.
В архитектуре, построенной на событийной модели все осложняется тем, что у нас есть пайплайн обработки сообщений, который критично важно не перегрузить/остановить. Также важно не потерять сообщения, которые не смогли обработать.
В статье приводится два способа обработки приведенных выше типов ошибок:
Retry Events.
Основной смысл в том, что мы помечаем событие как обработанное, вынимаем его из пайплайна и прикапываем где-то в стороне как "требующее повторной обработки". Это специальное сообщение содержит всю информацию о первоначальном событии, чтобы чуть позже (например, когда сеть восстановится) его можно было легко повторить. Если после нескольких повторов сообщение не обрабатывается успешно, его стоит обработать как dead letter.
Dead letter events.
Основной смысл такой же - помечаем события как обработанные, вынимаем из пайплайна, прикапываем в стороне. При сообщения такого рода должны зажигать алертинги и привлекать людей к починке проблемы. Сообщения можно также повторить, отправив в пайплайн после устранения первоочередной проблемы.
https://medium.com/usertesting-engineering/event-based-microservices-error-handling-7c84e3cb1332
https://docs.microsoft.com/ru-ru/azure/event-grid/manage-event-delivery
#article #practices #distributed #microservices #medium #en
Очень важно правильно обрабатывать ошибки и не набрать снежный ком, который сможет вывести вашу систему из строя. Особо остро проблема стоит в микросервисной архитектуре из-за большого количества проблем, добавляемой самой распределенной моделью.
Ошибки можно разделить на два типа:
— Временные (проблемы с подключением, системные сбои)
— Постоянные (баги, ошибки сериализации)
Временные ошибки можно решить простым образом — ретраями. Постоянные ошибки в основном требуют внимания человека, они должны зажечь алертинги.
В архитектуре, построенной на событийной модели все осложняется тем, что у нас есть пайплайн обработки сообщений, который критично важно не перегрузить/остановить. Также важно не потерять сообщения, которые не смогли обработать.
В статье приводится два способа обработки приведенных выше типов ошибок:
Retry Events.
Основной смысл в том, что мы помечаем событие как обработанное, вынимаем его из пайплайна и прикапываем где-то в стороне как "требующее повторной обработки". Это специальное сообщение содержит всю информацию о первоначальном событии, чтобы чуть позже (например, когда сеть восстановится) его можно было легко повторить. Если после нескольких повторов сообщение не обрабатывается успешно, его стоит обработать как dead letter.
Dead letter events.
Основной смысл такой же - помечаем события как обработанные, вынимаем из пайплайна, прикапываем в стороне. При сообщения такого рода должны зажигать алертинги и привлекать людей к починке проблемы. Сообщения можно также повторить, отправив в пайплайн после устранения первоочередной проблемы.
https://medium.com/usertesting-engineering/event-based-microservices-error-handling-7c84e3cb1332
https://docs.microsoft.com/ru-ru/azure/event-grid/manage-event-delivery
#article #practices #distributed #microservices #medium #en