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

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

Временно да, если на основании этого вы сможете масштабировать текущую систему в соответствии со своими потребностями.

Теперь давайте подумаем, почему в первую очередь вы хотите перейти на микросервисы как на стиль разработки.

1. Небольшие компоненты - проще управлять
2. Независимое развертывание — непрерывная доставка
3. Несколько языков
4. Код организован вокруг бизнес-возможностей
5. а также .....

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

Одна служба должна быть совершенно не осведомлена о том, как другая служба разработала свою внутреннюю структуру.

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

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

Как разделить службы, которые читают данные из одной таблицы:

Теперь давайте сначала создадим фиктивный пример: у нас есть три сервиса Order , Shipping , Customer — три разных микросервиса.

Ниже приведены способы, которыми несколько служб требуют данные из одной таблицы:

1. Службе нужно считывать данные из другой службы для таких вещей, как проверка.

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

Например: при размещении заказа будет вызываться API службы заказов с идентификатором клиента, теперь, когда службе заказов может потребоваться проверить, является ли он действительным клиентом или нет.

Один из подходов: раскрытие информации на уровне базы данных — не рекомендуется — использовать одну и ту же таблицу клиентов, которая привязывает обслуживание заказов к обслуживанию клиентов.

Другой подход: позвоните в другую службу для получения данных

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

Вариант - 2 не проверять при размещении заказа, при проверке события OrderPlaced асинхронно из службы поддержки клиентов и при необходимости проверять и обновлять состояние заказа

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

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

Например: Удалить клиента. вы можете захотеть, чтобы весь заказ клиента также был удален.

В этом случае вам нужно иметь дело с окончательной согласованностью, служба 1 вызовет событие, а затем служба 2 отреагирует соответствующим образом.

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

Если все еще не решено, вы можете написать мне по адресу [email protected], я вам отвечу

В настоящее время я решил продолжить последний упомянутый подход.

Если вам нужна горизонтальная масштабируемость (масштабирование для все большего числа клиентских подключений) для вашей базы данных, вам может быть лучше с технологией, которая была разработана для работы в качестве масштабируемой распределенной системы. Что-то вроде CockroachDB или NoSQL. Cockroachdb, например, имеет встроенные функции разделения и репликации данных и позволяет вам расширяться за счет добавления серверных узлов по мере необходимости.

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

Похоже, у вас была правильная общая идея - разделить по функциональности домена. Вот ссылка на предыдущий ответ об общем дизайне БД с микросервисами.

В мире микросервисов каждый микросервис владеет набором функций и данными, которыми эти функции манипулируют. Если микрослужбе нужны данные, принадлежащие другой микрослужбе, она не может напрямую обращаться к базе данных, поддерживаемой или принадлежащей другой микрослужбе, а будет вызывать API, предоставляемый другой микрослужбой.

Теперь, что касается размещения данных, существуют различные варианты — вы можете хранить данные, принадлежащие микросервису, в базе данных NoSQL, такой как MongoDB, DynamoDB, Cassandra (это действительно зависит от варианта использования микросервиса) ИЛИ вы можете иметь другую таблицу для каждая микрослужба в одном экземпляре базы данных SQL. НО помните, что если вы выберете один экземпляр базы данных SQL с несколькими таблицами, тогда не будет никаких соединений (по сути, никакого взаимодействия) между таблицами, принадлежащими разным микросервисам.

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