Реляционная БД в микросервисах

Question

У меня есть монолитное приложение c, которое в настоящее время использует базу данных PostgreSQL, и схемы настроены так, как вы ожидаете для большинства реляционных баз данных, с различными табличными данными, связанными с пользователем через FK на user_id. .

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

Я понимаю, что одна большая БД противоречит общим принципам проектирования микросервисов, но мне не ясно, какой будет альтернатива.

Больше всего меня беспокоит каскадирование отдельных баз данных, в которых будут храниться данные микросервиса. В простом rdb я могу просто каскадно удалять, и DB будет обрабатывать работу по различным таблицам. В случае микросервисов, как это будет работать? Нужна ли мне отдельная служба, которая обрабатывает удаление пользовательских данных из других баз данных службы?

Я не совсем понимаю, как перенести традиционное приложение с реляционной БД в архитектуру микросервиса?

РЕДАКТИРОВАТЬ:

Чтобы уточнить - конкретная c архитектурная / проектная проблема, с которой я сталкиваюсь, заключается в следующем:

Я разделил свое приложение на несколько микросервисов. По моему мнению, все еще реляционные:

Геолокация - сервис, который проверяет данные геометрии, записи в PostGIS и возвращает определенную информацию. Основная цель - записать местоположение конкретного пользователя для последующего обращения к нему

Изображение - простой сервис загрузки для загрузки изображений и хранения метаданных в БД.

Load-Image - Простой сервис, который возвращает случайный набор изображений на основе таких параметров, как местоположение, и данные профиля пользователя, такие как возраст, пол и т. д. c

профиль - сервис, который просто управляет данными пользователя, такими как возраст, пол, et c

Обычно эти три элемента имеют таблицу каждый в большем дБ, а не свои отдельные дб. Фильтрация изображений, скажем, по местоположению и возрасту - это очень простой JOIN и фильтр.

Как что-то подобное будет работать в микросервисной архитектуре? Если данные полностью хранятся в разных БД, как бы мне настроить logi c для фильтрации данных? Я мог бы дублировать данные, которые не часто меняются, например информацию о профиле, и добавить их в документ MongoDB, который будет содержать данные изображений, включая user_id и данные профиля - однако данные о местоположении могут регулярно меняться, и постоянные обновления не кажутся практичными.

Какой будет лучший подход? Или я должен придерживаться общей СУБД только для тех немногих служб?

Answer 1

Все сводится к дублированию данных, почему мы хотим их и как мы ими управляем.

В начале нашей карьеры нас учили о дублировании данных в контексте дублирования с целью избыточность, например, при репликации базы данных или резервных копий. Нас также учили, что данные могут моделироваться реляционным образом с ограничениями, обеспечивающими целостность модели. На самом деле, целостность модели является священной. Без целостности, как вы можете иметь последовательность? Ответ в том, что вы не можете. Своего рода.

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

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

Итак, теперь мы понимаем дублирование данных и почему мы этого хотим, давайте перейдем к тому, как нам удается иметь много дублирования. Давайте попробуем пример:

В реляционной базе данных, скажем, у нас есть таблица «Клиенты», которая содержит идентификатор клиента и данные клиента, и другая таблица «Заказы», ​​которая содержит идентификатор заказа, идентификатор клиента и детали заказа. Допустим, у нас также есть приложение для заказа, которое должно удалять все заказы клиента, если клиент удаляется за GDPR.

Поскольку мы переносим нашу систему на микросервисы, мы решили создать службу под названием «Клиенты».

Итак, мы создаем сервис со следующей операцией:

• DELETE / Customers / {customerId} - удаляет клиента

Мы создаем еще один сервис под названием Orders. с помощью следующих операций:

• GET / orders / customer / {customerId} - получает все заказы для клиента
• DELETE / orders / {orderId} - удаляет заказ

Мы создаем UX-экран для удаления клиента. UX сначала вызывает службу заказов, чтобы получить все заказы для клиента. Затем он перебирает список заказов, вызывая службу заказов, чтобы удалить заказ. Затем он вызывает службу клиентов для удаления пользователя.

Этот пример очень прост c, но, как вы можете видеть, нет другого выбора, кроме как организовать операцию "Удалить клиента" из вызывающей стороны, которая в данном случае это пользовательский интерфейс. Конечно, то, что было бы одной транзакцией atomi c в базе данных, не переводится в несколько вызовов HTTP / s, поэтому возможно, что некоторые вызовы могут не завершиться успешно, оставив систему в целом в несовместимом состоянии. В этом случае необходимо устранить несоответствие с помощью какого-либо механизма восстановления.

Answer 2

В микросервисной архитектуре у нас есть опция: использовать базу данных для каждой службы или общую базу данных. У этой схемы есть свои преимущества и недостатки. Лучше всего использовать архитектуру базы данных для каждой службы, но когда приложение monolithi c имеет множество функций, процедур или спецификаций базы данных c на уровне базы данных, тогда мы можем использовать подход с общей базой данных, я знаю, что это не лучшая практика если у вас есть время и пропускная способность, тогда вы должны go для базы данных для каждой услуги. Поскольку ваша задача каскадировать отдельные базы данных, вам нужно удалить каскад из базы данных и реализовать глобальную обработку транзакций в вашем приложении и выполнить все связанные с каскадом запросы из этой транзакции.