AWS SNS - насколько общими должны быть темы и когда следует повторно использовать / создавать темы?

Мы представляем SNS + SQS для обработки создания и распространения событий в нашей архитектуре микросервисов, которая до сих пор полагалась на вызовы HTTPS для связи друг с другом. Мы рассматриваем возможность подключения нескольких очередей SQS к одной теме SNS. Затем события в очередях будут обрабатываться лямбда-выражением или службой, работающей в EC2.

У меня вопрос: насколько общими должны быть темы? Когда нам следует создавать новые темы?

Скажем, у нас есть пользовательский домен, который должен публиковать два события - созданные и удаленные. Мы рассматриваем два варианта:

ВАРИАНТ A: Иметь две темы: «созданные пользователем» и «удаленные пользователем». Каждая тема гарантирует один тип события.

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

ВАРИАНТ Б: Создайте одну тему, "пользователи", которая принимает несколько типов событий.

  • потребители будут нести дополнительную ответственность за фильтрацию событий или выполнение различных действий в зависимости от типа события (они также могут настроить свои подписки на очереди для фильтрации определенных типов событий)

  • может обеспечить одного издателя для каждой темы

Кто-нибудь отдает предпочтение любому из вариантов и почему?

В связи с этим, где бы вы включили облачную конфигурацию для каждого из ресурсов? (следует ли развертывать создание ресурсов очереди вместе с потребителями или они должны работать независимо от любого из издателей / потребителей?)


events amazon-sns amazon-sqs event-driven
person ragis    schedule 21.03.2020    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Я думаю, вам следует выбрать вариант B и сохранить все события, касающиеся данного «домена» (например, «пользователя») в одной теме:

  • упрощает вашу инфраструктуру
  • вы можете представить службы, заинтересованные в нескольких типах событий (например, «создать» и «удалить»). Сложно сделать правильный заказ, используя это из двух тем; представьте, что событие "user-delete" прибывает до события "user-create"
  • пропускная способность может быть проблемой, это действительно зависит от вашего домена (создание и удаление пользователей не похоже на проблему с большим объемом)
  • подумайте об изменениях в структурах данных в ваших темах, внесение изменений в две или более тем одновременно может довольно быстро усложнить

Что касается вашего другого вопроса: держите вашу тему / конфигурацию инфраструктуры отдельно от ваших сервисов. Это отдельная часть инфраструктуры (например, база данных), которую следует хранить отдельно; особенно если вы введете в свою систему больше потребителей и производителей.

РЕДАКТИРОВАТЬ: Это может быть пример «настройки»:

  • Репозиторий user-service содержит шаблоны службы / лямбда-кода, облачной информации / терраформ для службы и подписок на ее темы.
  • Репозиторий sns содержит все шаблоны облачной информации / терраформирования, относящиеся к темам социальных сетей.
  • Репозиторий sqs содержит все шаблоны облачной информации / терраформирования, относящиеся к темам SQS

Вы можете подумать о хранении кода инфраструктуры SNS и SQS в одном репозитории (последние два), но я настоятельно рекомендую хранить все, что относится к определенной службе / лямбда-выражению, в отдельных репозиториях.

Как правило, полезно думать о ваших темах как о «базе данных», такое мышление должно указывать вам правильное направление для всех ваших вопросов.

person Scarysize    schedule 21.03.2020
comment
Спасибо за развернутый ответ! Если я правильно понял ваш совет относительно разделения конфигурации Infra, вы имеете в виду наличие, скажем, serverless.yml, который содержит конфигурацию для темы SNS, ее подписки и очереди SQS (+ хранение и т. Д.), А потребительская лямбда будет развернута отдельно ? И означает ли это, что вы помещаете всю инфра-репо, связанную с событиями, в одно репо, независимо от домена, или в одно инфра-репо для domain = topic? - person ragis; 21.03.2020