Несколько очередей SQS против 1 темы SNS

Question

Сегодня мы обсуждали лучшее решение, и ни одна из сторон не пришла к соглашению.

У нас есть продукт, который принимает "сообщения". Каждый раз, когда мы получаем новое сообщение, нам нужно отправить эти данные 3 службам для обработки.

Служба # 1 требует, чтобы данные были в специальном формате. для этого мы помещаем данные в SQS, из которых служба читает.

Служба # 2 считывает поля сообщения: [a, b, c], и мы отправляем в формате протофуфа.

Служба # 3 читает поля сообщений: [a, b, c, d, e], также protobuf. * ​​1009 *

Для сервисов № 2 и № 3 мы отправляем данные в 2 отдельных квеста SQS. Тем не менее, мы могли бы отправлять данные в теме SNS, из которой читаются очереди №2 и №3. Для этого мы бы отправили протобуф службы № 3, так как он имеет все поля, необходимые для службы № 2.

Человек, написавший сервис №2, не хочет этого делать, потому что он не хочет получать дополнительные данные, которые они просто игнорируют.

Человек, написавший службу # 3, считает, что система затрачивает ресурсы на протобуфинг и отправку в 2 отдельные очереди SQS вместо 1 темы SNS, когда служба # 2 может просто прочитать протобуф # 3 и просто игнорировать ненужные поля.

С точки зрения архитектуры, кто прав?

Answer 1

Дебаты, которые вы обсуждаете, являются мнением.Существует компромисс с обоими подходами.В конце концов, вы должны стремиться к тому, что будет лучше в долгосрочной перспективе (скажем, через 1 год)

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

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

Издатель должен публиковать данные в формате, который в большинстверодовая форма с их точки зрения.Это также гарантирует, что приложение издателя не пересекает их домен.

Оптимизация ресурсов за счет объединения услуг будет действительно плохим подходом.

Answer 2

Используйте SNS, если вы хотите "уведомить" другие службы о событии, особенно если есть несколько служб, которые могут быть заинтересованы в этом событии.

Вся дифференциация на основе формата выглядит как искусственная конструкция, котораяделает необходимым использование SQS.SQS лучше всего подходит для двухточечной связи.

Публикация в 2-3 местах из одного сервиса открывает ваш сервис до проблем атомарности и надежности (что происходит, если сервис публикации падает после публикации в SQS, но перед публикацией в SNS?).Наличие единой системы, в которую помещаются сообщения, облегчает решение этих проблем.

В конце концов, все сводится к тому, чего требует ваша система.Если бы это зависело от меня, я бы изменил все нисходящие сервисы, чтобы получать уведомления через SNS (с единым форматом для всех из них).