Вызов зависимого микросервиса

Question

Допустим, у меня есть 2 микросервиса: Service1 и Service2.У каждого из них есть своя база данных.Service1 имеет EntityA, а Service2 имеет EntityB

EntityA {
    Long id;
    //other fields
    EntityB entity;
}

EntityB{
     //other fields
}

Я использую RestTemplate Spring для извлечения и сохранения данных.Проблема заключается в том, что при извлечении EntityA из базы данных Service1 у меня нет данных EntityB, поскольку они хранятся в базе данных Service2, я понимаю, что должен сделать вызов rest через RestTemplate, чтобы извлечь EntityB из базы данных Service2, но как насчет отношений междулица - должен ли EntityA по-прежнему иметь весь объект EntityB внутри, хотя его поля в большинстве случаев равны нулю, кроме id?Что мне не хватает?Заранее спасибо.

Answer 1

Я сталкивался с этим шаблоном, и я думаю, что он полезен для вашей ситуации.
Шаблон называется CQRS (разделение ответственности по запросам команд, полный набор)

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

При изменении любого EntityA с Service1 , Service1 публикует событие.То же самое касается Service2 , когда любой EntityB si изменился, он также опубликует событие.

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

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

Идея в основном отсюда: https://microservices.io/patterns/data/cqrs.html. Я бы также прочитал хотя бы раздел «когда использовать этот шаблон»отсюда: https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs

Answer 2

С технической точки зрения ваша проблема может быть исправлена ​​с помощью API Gateway .

В двух словах, вы должны определить новый микросервис, скажем gateway service, который будет называтьсявашими клиентами API.Затем gateway service будет:

1. Invoke Service1 для получения Entity1 вместе с id для Entity2
2. Invoke Service2 для получения Entity2на основе идентификатора из шага 1.
3. Объедините два ответа (в вашем случае, установите значения Entity2 внутри Entity1).
4. Верните агрегированный ответ клиенту.

При проектировании следует учитывать две вещи:

• Ваш клиент API не должен знать, что его данные извлекаются двумя службами.
• Как правило, лучше собирать отклики клиентов в шлюзе, так как это обеспечивает более высокий уровень развязки между вашими микросервисами.Например, вы можете смоделировать ваши сущности следующим образом (и удалить зависимость модели данных между Service1 и Service2, что позволяет двум службам развиваться независимо).

См. Нижефрагмент:

// In Service1
EntityA {
    Long bId; 
}

// In Service2
EntityB{

}

// In Gateway
Response {
    EntityA a;
    EntityB b;
}

Решение о погоде Entity1 должно ссылаться на Entity2 не в зависимости от того, как распределяются ваши данные, а от потребностей вашего бизнеса.Если у вас будет монолитное приложение, и в этом контексте для Entity1 будет иметь смысл ссылаться на Entity2, все равно имеет смысл сделать это в микросервисной среде.

Answer 3

Два решения, которые приходят мне в голову, являются одновременно простыми и сложными.

Дубликаты данных

Между MS обычно имеется высокодоступная кластерная система pub-sub или очереди сообщений. Когда EntityB сохраняется в Service2, вы отправляете событие в очередь или систему pub-sub. Service1 может подписаться на это конкретное событие и сохранить информацию о EntityB в своей собственной базе данных.

Логика групповой области

Возможно, слишком большая корреляция между областями Service1 и Service2. В этом случае вам может потребоваться сгруппировать ваши сервисы в один сервис.