Pub/Sub
Тема дорожной карты · Software Architecture
Publish-Subscribe (Pub/Sub) — это один из самых распространённых паттернов обмена сообщениями в микросервисной архитектуре. Он обеспечивает гибкость и масштабируемость, позволяя издателям публиковать события, а подписчикам независимо от этого потреблять их. Это особенно полезно для event-driven систем, где события могут происходить независимо от конкретных действий пользователей или систем.
Как это работает
В паттерне Pub/Sub издатель отправляет сообщение в определённый topic, а брокер доставляет это сообщение всем подписчикам этого topic. Подписчики могут подключаться и отключаться в любое время, что позволяет издателю не беспокоиться о текущем состоянии подписчиков. Именование topics должно быть тщательным, так как это публичный контракт между издателями и подписчиками. Обычно формат topic выглядит так: <домен>.<тип-события>.<версия> (например, orders.placed.v1). Издатели добавляют события с стабильными схемами данных (JSON, Avro, Protobuf), а подписчики потребляют эти события независимо со своими собственными offsets.
Для предотвращения разрыва в схемах данных, можно использовать schema registry (например, Confluent Schema Registry или AWS Glue Schema Registry). Это помогает избежать ситуаций, когда изменения в схеме данных могут сломать подписчиков. Важно добавить структурированное логирование на этапы publish и consume, чтобы упростить отладку и понимание потока данных.
Когда применять
Pub/Sub особенно эффективен в ситуациях, когда одно событие должно быть разослано множеству потребителей без необходимости координации со стороны издателя. Это также полезно, когда потребители обрабатывают события с очень разной скоростью, или когда вы можете добавлять больше потребителей позже без необходимости изменения кода издателя. Однако, следует избегать использования Pub/Sub для тесных паттернов запроса-ответа, где прямые вызовы API могут быть более простыми и эффективными.
Типичные ошибки
Одной из самых распространённых ошибок в реализации Pub/Sub является schema drift, когда издатели меняют форму события, что может привести к тому, что подписчики будут работать некорректно. Для предотвращения этой проблемы можно использовать schema registry.
Второй типичной ошибкой является неправильное предположение о порядке событий. Большинство брокеров не гарантируют глобальный порядок событий, особенно если события распространяются через несколько партиций. Дизайны, которые полагаются на глобальный порядок событий, могут провалиться на масштабе.
Третья распространённая ошибка — это вечные попытки повторной обработки сообщений, которые не могут быть обработаны (poison messages). Это может привести к тому, что система будет занята обработкой этих сообщений вечно. Для предотвращения этой проблемы можно использовать dead-letter queue (DLQ) для обработки сообщений, которые не могут быть успешно обработаны.