Микросервис, вызывающий несколько функций по сравнению с пользовательской клиент-специфической функцией

Question

У меня есть микросервис, который предоставляет некоторые функции gRPC. Каждая функция gRPC просто получает данные из таблицы в виде одной записи (используя параметр id) или всех записей. Клиент - это бэкэнд-система управления данными, и ему необходимо создать отчет, который потребует данных от нескольких сервисных функций.

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

Плюсы - Клиент и Микросервис будут независимы друг от друга

Минусы - несколько вызовов gRPC (рассмотрим 5 на запись * 30 записей)

Но почему-то это кажется неправильным (возможно, это монолитная архитектура), просто чтобы показать 30 записей, нам нужно будет сделать 150 вызовов gRPC. Следовательно, альтернативой может быть создание новой функции gRPC, которая объединяет все данные в самой службе.

Плюсы - только 1 звонок gRPC

Минусы - Клиент и микросервис становятся зависимыми друг от друга, какой тип поражает назначение микросервиса.

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

Answer 1

Если я правильно понимаю ваше утверждение, внутренний клиент собирает данные из нескольких служб / функций для создания отчета. Поэтому я предполагаю, что это только для чтения, так как это для отчетности. Сам отчет представляет собой другой ограниченный контекст или поддомен. Он имеет характеристики поведения, отличные от моделей чтения-записи /CRUD. Вот что такое шаблон CQRS - идея о том, что вы можете использовать другую модель для обновления информации, чем модель, которую вы используете для чтения информации.

Так что в вашем случае это практично, эффективно и оптимально создать другую услугу / функцию, которая уже объединяет данные, прежде чем возвращать их потребляющим клиентам. Эти комбинированные модели данных могут быть прямо из вашего уровня данных (с помощью запроса выбора или сохраненных процедур).

С другой стороны, для меня, даже работающего с микросервисами, по-прежнему действует основное правило распределения объектов: "Не распространяйте объекты. Если возможно. (Мартин Фаулер, Enterprise Integration Patterns)".