Какие данные попадают в сообщение между распределенными приложениями? - PullRequest
Новая
       74

Какие данные попадают в сообщение между распределенными приложениями?

0 голосов
/ 29 апреля 2019

Я пытаюсь внедрить очереди в нашу микросервисную архитектуру, а именно AWS SNS / SQS.

Например, у меня есть этот сценарий. После создания заказа Orders MS вызывает событие OrderCreated, и это событие публикует сообщение в AWS OrderCreated SNS. Очередь SQS InvoiceCreate подписана на OrderCreated SNS и получит это сообщение.

Бедствие делает сцену до сих пор. Если Invoicing MS прослушивает InvoiceCreate queueu и извлекает все новые сообщения - Invoicing MS должен создать счет, но у меня вопрос к каким данным?

а) связаться с Заказом MS (для заказа данных, актуальных для создания счета). Если это невозможно, сообщение будет оставаться в очереди до тех пор, пока MS Invoicing не сможет собрать соответствующие данные

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

При выборе MS Invoicing MS не будет отделяться и будет зависеть от Заказа MS, но, с другой стороны, он может собирать дополнительные данные, отличные от данных, упакованных с исходным сообщением.

При выборе B, поскольку событие OrderCreated и OrderCreated SNS действительно не знают, кто будет использовать данные сообщения, т.е. OrderCreated также может быть использован для выполнения различных действий, я запутался, как точно решить, какие данные должны быть вставлены в это сообщение

1 Ответ

1 голос
/ 01 мая 2019

Наша архитектура настроена больше как ваш вариант B. Чтобы использовать ваш пример, служба заказов будет публиковать свое событие OrderCreated и прикреплять - в качестве полезной нагрузки - большую часть (или даже всю) информации о заказе в разделе полезной нагрузки сообщение. Мы форматируем сообщение и полезную нагрузку как JSON для совместимости, но вы можете делать что угодно.

В некоторых случаях мы публикуем не всю информацию, а только отдельные поля для объекта «Добавлен / отредактирован» - это зависит от сервиса и чувствительности информации. Пока вы только добавляете поля к сообщению (не удаляете ни одного), вы выполняете контракт и не очень тесно связаны с ним.

Опять же, к вашему примеру, InvoiceService может получить информацию из одного или нескольких из нескольких вариантов:

  • Вытащите его прямо из сообщения OrderCreated, если включите все необходимое
  • Извлеките все возможное из сообщения OrderCreated, опубликуйте событие InvoiceStarted, которое запускает службу OrderService (и / или другие) для отправки ему сообщения OrderInvoiceComplete с остальными необходимыми сведениями
  • Сохраняйте локальную копию всех необходимых ему ключевых данных, заполняемых подпиской на другие события, чтобы можно было объединять данные OrderCreated с некоторыми локальными данными для уточнения счета

Лучше всего избегать, чтобы InvoiceService отвечала на сообщение, совершая вызов непосредственно обратно в OrderService - это довольно тесная связь, которую можно избежать, просто отправив сообщение обратно, если это необходимо.

Итак, есть много вариантов. Лично я предпочитаю методику помещения всех данных, которые могут быть полезны в сообщения, когда вещи создаются / обновляются, и позволяющие потребляющим службам решать, что использовать / игнорировать. В нашем сценарии это работает хорошо, но у нас есть только несколько хорошо изолированных клиентов, которые обращаются к нашим услугам, поэтому могут быть более безопасные способы сделать это, которые нам не нужны.

...