Связь между микросервисами, общим объектом или другим адом

Question

прочитал много книг о микросервисах и не нашел ответа на мой вопрос.

Ситуация: Имеет службу A Служба A, имеет сущность Cat

Имеет службу B Служба B нуждается в получении Cat от службыДобавьте несколько новых полей в класс и отправьте их в службу C.

Вопрос: 1) мне нужно разделить сущность Cat между службами? (Я знаю, это плохая идея, потому что мы получаем тесную связь) 2) Создайте некоторый класс данных в Сервисе B для десериализации ответа на объект (так что ... мы получаем дублирование кода) 3) возможно, есть хороший шаблон для общения?

Answer 1

ИМХО, это уже не Cat после того, как служба B обогатила данные из службы A. Поскольку микросервис должен инкапсулировать домен, должна быть только одна служба, которая производит Cat s, которая в вашем примере является службой AСлужба B производит что-то еще, может быть, это CatHistory или CatWithToys, но не Cat. Здесь нет дублирования кода, так как служба A не знает о полях, которые обогащены службой B, они находятся вне домена службы A.

Answer 2

Короткий ответ: # 2

Длинный ответ:

Я участвовал в большом проекте по микросервисам, где мы изначально делили код (DTO) между проектами, чтобы упростить связь. Мы узнали, что это болезненный подход. Во-первых, обновление библиотеки «api» означало обновление всех клиентов службы, даже если большинству из них изменения не нужны. Во-вторых, не было возможности обеспечить обратную совместимость. Несмотря на то, что мы могли бы обновить все службы до одной и той же версии библиотеки, и все прошло бы, развертывания обычно не работают атомарно, как это всегда в постоянно включенной среде, поэтому изменения были по своей сути небезопасными. Наконец, почти ни одному клиенту не нужны все поля, которые выходят из API, но у них есть объект со всеми полями, используемыми в их коде.

В конце концов, мы покончили с проектами API. На самом деле, это JSON, создаваемый службой, это API, а не DTO, используемый для генерации JSON. У клиентов будет свой DTO, содержащий только те поля, которые им нужны. Контрактное тестирование с использованием Pact гарантировало, что API не изменились несовместимыми способами.

Answer 3

Вероятно, для этого нет единственно правильного ответа, поскольку он всегда будет немного самоуверенным.

Я бы предпочел слабую связь и пойти на контрактный подход. Полагаю, что вы не заинтересованы в создании веб-сервисов на основе SOAP, я полагаю, что вы будете делать какие-то RESTful-сервисы.

Я бы взглянул на Swagger (или некоторые аналогичные технологии) для создания подхода «сначала контракт». Таким образом вы сможете создавать классы API на сервере (производитель) и клиенте (потребитель) из контракта.