Отслеживание потока данных в распределенных/устаревших системах

У меня есть 2 микросервиса [A, B], а сервис [B] имеет интеграцию с устаревшей системой [C]. Сервис [B] обычно генерирует unique-identifier и включает его в поток в [C], а также передает обратно в [A]. Таким образом осуществлялось согласование между системами.

Проблема действительно началась, когда возникла потребность в службе [D], которую [A] должен вызывать параллельно, чтобы информировать [C].

Хотя имеет смысл заставить [A] сгенерировать уникальный идентификатор и отправить его как [B], так и [D] для решения проблемы, это не так просто из-за стоимости изменения в [C]. Таким образом, нам все еще нужно каким-то образом иметь уникальный идентификатор [B] для [D], чтобы соединить данные в [C].

Ценю, если кто-то может направить меня, если есть тактический шаблон для решения этой проблемы.


comment
Здравствуйте, вы отметили свой вопрос Domain Driven Design. Я предлагаю вам подробнее рассказать о том, как выглядит domain problem. Что делают эти службы? Что это за процесс? Для меня имеет смысл, чтобы инициатор процесса определял идентификатор процесса.   -  person Alex Buyny    schedule 29.10.2019


Ответы (1)


Немного сложно следить за всеми сервисами без схемы, но я постараюсь. Вы говорите, что C передает идентификатор обратно в A в текущем процессе, поэтому я предполагаю эту структуру вызова

A -> B (create ID) -> C -> A

Теперь вы хотите представить

A -> D -> C -> A

И вам нужно, чтобы C знал, какое сообщение из пути ADC связано с каким сообщением из пути ABC. Это правильно?

Лучшее решение — позволить A создать идентификатор для всех, например

A (Create ID) -> B (use ID given by A) -> C -> A
A (Use same ID) -> D -> C -> A

Если вы не можете изменить код для создания одного идентификатора в службе A, попробуйте использовать 2 разных идентификатора сообщения. Это было бы неуклюже, так как вам нужно где-то хранить, чтобы вы могли сказать, что msg123 исходит из того же источника, что и msgABC, но это решит проблему.

Это даст вам

A -> B (create ID1) -> C -> A
A (Create ID2) -> D -> C -> A
person Brad Irby    schedule 28.10.2019