Сообщения: как выглядят ваши сообщения

Question

Этот вопрос касается очереди сообщений между сервисной архитектурой. Вряд ли что-то найти по этой теме.

Ситуация: Микросервис A и микросервис B. Микросервис A имеет дело с сущностью "что-то", а B необходимо о. Я придерживаюсь общего мнения, чтобы не обсуждать границы.

В нашем случае A отправляет сообщение, которое содержит событие и идентификатор связанной сущности, например Событие: что-то создано SomethingID: 1234

B использует это сообщение, и, если ему нужна дополнительная информация, он извлекает его из A с SomethingID.

Второй подход заключается в том, что сообщение содержит не только приведенную выше информацию, но и метаданные, например Событие: что-то создано SomethingID: 1234 SomeFieldKey: someFieldValue ...

Постное сообщение: Pro: * Меньше использования сети * Всегда одинаковая структура сообщений Минусы: * Если информация от A требуется по требованию, должен быть какой-то механизм, чтобы поймать e. г. сбои сети

Жирное сообщение: Pro: * Информация уже есть Против: * Что делать, если приложенной информации недостаточно?

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

Спасибо за ответы заранее

Answer 1

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

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

Когда потоки данных между задержками сети служб для нас не были проблемой (я имею в виду не из-за увеличения размераПолезная нагрузка)

Таким образом, вы должны разрешить отдельным службам принимать вызовы.У каждого сервиса есть SLA, который соответствует времени отклика, и когда его нарушают, вы проверяете, обнаруживаете узкие места и устраняете их.