Плохо ли объединять данные в приложении, а не в базе данных в микросервисной архитектуре?

Question

Например, у меня есть сервис Author и Book service. Оба сервиса имеют отдельную базу данных. В сервисе Book мне нужно объединить каждую книгу с одним автором. Я думаю, что у меня есть 3 способа:

1. В сервисе Book я могу общаться со службой Author через некоторый канал связи: TCP, Message Broker и др. c. И я могу выбрать авторов из службы Author, а затем создать JOIN в службе Book (в приложении вместо базы данных)
2. В службе Book я могу определить базу данных представлений, которая предназначена для чтения. единственная копия сервисной базы данных Author (https://microservices.io/patterns/data/cqrs.html). И затем, в сервисе Book, я могу создать JOIN, используя базу данных.
3. Я могу объединить данные на внешней стороне. Во внешнем интерфейсе я могу сделать два HTTP-запроса к службам, а затем соединить данные во внешнем интерфейсе.

Какой способ лучше?

Answer 1

Из вашего вопроса мне не совсем понятно, где и для каких целей вам действительно нужны объединенные данные из двух источников - например: выполняет ли книжный сервис операцию, для которой он нужен? данные из службы авторов или они просто будут передаваться через объединенные данные во внешний интерфейс?

В общем, хорошо, что каждая служба владеет своими данными и другой службой (в вашем случае : frondend) получает и использует данные из нескольких источников. Поэтому, на мой взгляд, вариант 3, вероятно, является хорошим выбором.

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

См. Также обсуждения здесь , здесь и здесь об обмене данными между микросервисами ,

Answer 2

(1) Я бы избегал, потому что это вводит нежелательную степень связи между вашими услугами. Если ваш вариант использования не требует, чтобы гигантские списки названий книг сопровождались указанием выбора c данных от автора db (например, имени автора), я бы избегал репликации, особенно всей базы данных, иначе вы снова будете введение жесткой связи. Даже при том, что распространение определенных c элементов данных, таких как имя, является нормальным (вы уже распространяете идентификатор автора), и служба, и ее база данных должны иметь возможность развиваться независимо и развертываться независимо. Итак, (2) отсутствует.

Это оставляет нас с (3), который очень хорошо работает с интерфейсами на основе GUI, где панель заполняет детали автора вызовом отдыха, в то время как другая панель ниже асинхронно звонит, чтобы заполнить список книг.

Answer 3

Я «архитектурно против» идеи иметь «Книжный сервис» или «Авторский сервис». (Конечно, я знаю, что вы используете это в качестве примера.)

Вот почему: «Книга, как и Автор, вещь». Принимая во внимание, что «Служба» - это не вещь.

«Служба» должна либо предоставлять что-то, либо делать что-то. И все, что он делает или обеспечивает, должно быть завершено и автономно. Книги имеют авторов и авторов пишут книги, поэтому их нельзя разделить. Не берите на себя ответственность потребителей ваших услуг за доступ к нескольким различным службам, чтобы получить то, что им нужно. Если вы видите, что у ваших сервисов есть «перекрывающиеся проблемы», как в этом случае, то это значит, что ваша архитектура имеет недостатки.

Answer 4

Подход 3 - это то, что вам нужно. Чтобы реализовать его, вам нужен API-интерфейс Experience (микросервис), который будет вызывать пользовательский интерфейс, а затем этот микросервис Experience, поскольку самоочевидное имя будет извлекать данные из нижележащих микросервисов, обрабатывать, очищать и отображать пользовательский интерфейс.