Микро Услуги - Идентичность Объекта как Зависимость - PullRequest
0 голосов
/ 08 ноября 2019

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

Возьмем для примера: Micro Service A: Служба рассылки новостей Micro Service B: Служба доставки почты A Чтобы доставить свою задачу, необходимо доставить рассылку новостей;таким образом, служба A явно зависит от B

. Служба A создает сообщение, используя контракт событий, определенный B, и помещает его в очередь. Чтобы А распознал асинхронный ответ (успех / сбой), службе А необходимо будет прикрепить к сообщению идентификатор, который служба В должна будет ретранслировать. Я считаю, что это обратная зависимость, и ее следует избегать.

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

Служба A будет синхронно вызывать B с определенным контрактом сообщенийB. затем немедленно вернет идентификатор, принадлежащий B и сохраненный A. Ответ указывает, что операция была поставлена ​​в очередь, но еще не обработана. Также будет возвращено имя очереди / темы, на которую опубликован ответ. Это важно, потому что я считаю, что очередь / тема должна принадлежать службе, которая публикует события. Служба A должна будет поместить эту операцию во внутреннюю очередь, чтобы обеспечить отказоустойчивость в случае, если служба B временно недоступна. Когда сообщение доставлено, оно будет содержать идентификацию сообщения, что нормально, потому что идентификация принадлежит самой службе B.

Мне очень интересно услышать ваши мысли об этом подходе.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...