Одна база данных против нескольких баз данных - архитектура микросервисов

Question

Я планирую построить проект на микроуслугах. Мне было интересно узнать, какой дизайн будет лучше с точки зрения базы данных?

1) Храните отдельную базу данных для каждой услуги, как показано на рисунке.

2) Несколько приложений указывают на 1 базу данных.

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

Например, у нас есть сервис Клиенты (отдельный проект говорит с БД 1) и сервис Продукты (отдельный проект говорит с БД 2), где я должен хранить клиента и продукт отображение (продукты, купленные клиентом)?

Как насчет модуля отчетов в долгосрочной перспективе, где мне нужны объединения по нескольким таблицам (которые находятся в разных базах данных из-за архитектуры, упомянутой в пункт 1)?

Answer 1

Второй подход - это анти-шаблон «Общая база данных» в архитектуре Microservices.

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

Эти ссылки также имеют свои преимущества и недостатки в приведенных выше ссылках в конце страниц.

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

Для аналитики и статистики необходимо отправлять данные из всех баз данных в модуль отчетности. Другими словами, вам нужно построить процесс etl. Для этой цели обычно используется брокер сообщений, такой как Apache Kafka . Эта страница хорошо описывает этот подход.

Создание архитектуры микросервиса - очень сложная и обширная задача, связанная с множеством проблем и схем проектирования, которые позволяют минимизировать эти проблемы. Я рекомендую прочитать книгу " Шаблоны микросервисов ", в которой рассматриваются различные шаблоны проектирования архитектуры микросервисов.