Блог

Как я описал в вопросе, если бы я внедрил архитектуру микросервисов, стала бы централизованная база данных чтения / записи узким местом?

Чтобы расширить с помощью примера, допустим, у меня есть три микросервиса: users , teams и team_members . У каждого из них есть свой собственный микросервис, но все они полагаются друг на друга в базе данных, поэтому эксклюзивные параллельные базы данных были бы неподходящими. Поскольку микросервисы предназначены для распределения работы на нескольких разных серверах, не сводит ли центральная база данных в конечном итоге на нет назначение этих микросервисов, поскольку все они в конечном итоге обращаются к одному и тому же серверу?

…если бы я внедрил архитектуру микросервисов, стала бы централизованная база данных чтения / записи узким местом?

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

Фактически, далее по вашему вопросу вы непосредственно озвучиваете эту концепцию:

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

Если микросервисы совместно используют таблицы базы данных, то все, что вы эффективно сделали, — это создали одну единственную «службу» с несколькими компонентами, которые, как оказалось, потребляют друг друга по какой-то внеполосной передаче, а не по прямой двоичной ссылке в памяти.

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

Расширяя ваш пример, служба пользователей будет знать о командах. Как он узнает? Что ж, служба команд передаст данные команды в службу пользователей. Аналогичным образом, служба team_members будет получать данные от обеих служб. Теперь у всех служб есть все данные, необходимые им для выполнения своей работы.

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

Чтобы добавить к тому, на что был дан ответ выше…

При декомпозиции вашего домена вместо использования модели взаимодействия с одним объектом используйте взаимодействие свойств / полей и ограниченный контекст для создания ваших компонентов / микросервисов.

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

И еще один компонент может содержать адрес пользователя, и еще один — информацию о возрасте, поле и семейном положении пользователя, и еще один будет содержать его кредитную карту и банковские реквизиты…

В итоге вы получите отдельные таблицы для каждого ограниченного контекста.

Способ размещения таблиц зависит от вашей нагрузки и инфраструктуры (все таблицы в одной базе данных и на одном сервере или нескольких базах данных / серверах).

Просто чтобы уточнить, эти таблицы не имеют ссылочной целостности, если бы у вас была ссылочная целостность, вы бы повторно ввели связь, и это вернет вас к проблеме конкуренции в базе данных…

Посмотрите эту презентацию Уди Дахана, чтобы узнать гораздо больше деталей

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

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