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

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

0 голосов
/ 21 марта 2020

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

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

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

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

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

ВАРИАНТ B : Иметь один topi c, «пользователи», который принимает несколько типов событий

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

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

У кого-нибудь есть сильные предпочтения к любому из вариантов и почему это будет?

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

1 Ответ

0 голосов
/ 21 марта 2020

Я думаю, что вы должны go с опцией B и хранить все события, касающиеся данного "домена" (например, "пользователя") в одной топи c:

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

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

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

  • Репозиторий user-service содержит код службы / лямбда, облачная информация Шаблоны / terraform для сервиса и его подписки topi c
  • Репозиторий sns содержит все шаблоны облачной информации / terraform по темам SNS
  • Репозиторий sqs содержит все шаблоны облачной информации / terraform относительно SQS themes

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

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

...