11 граблей распределенных систем: личный опыт backend-разработчика с практическими советами

[arthurpro]

я заставку вижу вот так, в стиле fallout ))

[Neuronix]

В конце сказали, что не будете рассказывать про distributed tracing и дальше пошли про него рассказывать

[senior__pomidor]

Статья интересная, но хотел бы немного дополнить:

1. Флуд запросов — кроме экспоненциальных ретраев можно еще jitter использовать. Это на тот случай, чтобы все повторные запросы одновременно не пошли, добавляется случайная величина к каждой задержке повтора. Но это не отменяет экспоненциальное увеличение таймаутов между ретраями. Просто если 1000 запросов пошли в ретрай в одно и то же время, то, скорее всего, они так и будут через одинаковые промежутки времени делать повторные запросы.

2. Согласованность и порядок событий — сами номера помогут только на стороне потребителя событий, можно также и отметку времени использовать, но время в распределенных системах — понятие относительное. А вот порядок сообщений должен гарантировать транспорт, будь то какой-то MQ или Kafka. Понятно, что транспорт гарантирует порядок того, что в него пришло. А ошибка могла быть при отправке сообщения, и тем самым порядок сбился. Но в таком случае можно применить шардирование, и для сохранения порядка событий по какой-то сущности она должна обрабатываться на одном и том же инстансе микросервиса.

[milo]

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

По поводу ретраев есть ещё подход с "подсказками" со стороны сервера - сервер возвращает клиенту заголовок retry after. Конечно, это все неисключающие друг друга подходы.

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