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

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

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

Например, если я использовал AWS и имел 3 службы, я должен создать 3 базы данных для каждой службы в одном экземпляре RDS или создать 3 экземпляра RDS, каждый из которых содержит базу данных, которая используется независимо каждой из 3 служб?

Если лучше использовать несколько баз данных в одном экземпляре RDS, будет ли она лишена цели иметь независимые службы, потому что:

1. Ресурс экземпляра RDS будет распределен между службами. Повлияет ли Служба A, которая может интенсивно использовать базу данных в определенное время, на Службу B, которая использует другую базу данных, но в том же экземпляре RDS?

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

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

Хранение всего этого в одной базе данных

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

Хранение баз данных отдельно

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

Какую проблему вы решаете?

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

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

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

Учение и Реальность

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

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

Реальность такова, что конкретным потребностям вашего проекта понадобится другой набор компромиссов, чтобы своевременно выполнить работу и справиться с нагрузкой на систему, которую вы измеряете (плюс немного больше). Полагайте, что высокая цель - это полностью изолированный интерфейс, микросервис и трио уровня данных. Чем больше спроса на вашу систему, тем ближе к этой цели вы, вероятно, должны быть. Мы не все [insert name of highly successful web entity here], и они не начали там, где они сейчас. Иногда вам просто нужно начать с не идеальной ситуации и быть счастливым с этим.

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

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

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

Это не важно

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

Экземпляр RDS представляет собой один блок. Если у вас есть несколько баз данных в одном экземпляре, то они совместно используют процессор / память и т. Д.

Если производительность вашего микросервиса связана с производительностью его базы данных : разверните несколько копий микросервиса, каждая из которых использует свою базу данных, но с каждой базой данных в одном и том же экземпляре RDS. Бессмысленно * (кроме аварийного переключения). Ваш микросервисный кластер будет работать с той же скоростью, что и один микросервис

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

Обычно ваш микросервис получает данные из базы данных, выполняет некоторую логику и записывает некоторую информацию обратно в базу данных. Узким местом производительности является логика , а не выбор и / или вставка.

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

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

Есть две плоскости, на которых действует эта инкапсуляция:

• Первое логично на уровне приложений. Ваша служба владеет некоторыми бизнес-объектами в вашей системе, и ей необходимо сохранять состояние этих объектов. То, что какая-то конкретная база данных поддерживает эти бизнес-объекты, это просто детали реализации. Сохраняя отдельную базу данных, вы не позволяете другим службам иметь доступ к вашей реализации через черный ход, вынуждая их использовать ваш общедоступный интерфейс. Цель здесь - чистая архитектура и дисциплинированное программирование. Где именно находится база данных, не имеет значения на этом уровне, если у вашей службы есть правильные сведения о соединении, чтобы он мог ее найти.

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

Я думаю, что это могло бы помочь быть немного более теоретическим здесь. Одной из мотивирующих идей, лежащих в основе микросервисов, является процесс обмена сообщениями - ничего общего. Микросервис подобен актеру в модели актера. Это означает, что каждый процесс поддерживает свое собственное локальное состояние, и единственный способ для одного процесса получить доступ к состоянию другого - отправка сообщений (и даже тогда другой процесс может ответить, как ему нравится, на эти сообщения). Под «каждым микросервисом есть своя собственная база данных» подразумевается, что состояние процесса (т. Е. Микросервис) является локальным и частным . В значительной степени, это говорит о том, что «база данных» должны быть соотнесеныс микросервисом, т.е. «база данных» должна храниться и выполняться на том же логическом узле, что и микросервис. Различные «экземпляры» микросервиса являются отдельными процессами, и поэтому каждый из них должен иметь свою собственную «базу данных».

С этой точки зрения глобальная база данных или база данных, совместно используемая микросервисами или даже экземплярами микросервиса, будет представлять собой общее состояние. «Подходящий» способ справиться с этим с точки зрения микросервисов состоит в том, чтобы общая база данных поддерживалась микросервисом «базы данных». Другие микросервисы, которые хотят знать о содержимом базы данных, будут отправлять сообщения в этот «микросервис базы данных». Это, как правило, не устраняет необходимость в локальном состоянии (т. Е. Для «баз данных» экземпляра микросервиса) для исходных микросервисов! Что меняется, так это то, что представляет местное государство. Вместо хранения «Пользователь Салли - администратор», он будет хранить «Микросервис базы данных сказал:« Пользователь Салли - администратор пять минут назад ». Другими словами, о состоянии других микросервисов.

Преимущество этого заключается в том, что каждый микросервис автономен. Это делает микросервис атомной единицей отказа. Вам (в основном) не нужно беспокоиться о микросервисе в каком-то частично функциональном состоянии. Конечно, проблема была перенесена в сеть микросервисов. Микросервис может оказаться неспособным выполнить желаемую функцию из-за невозможности связаться с другими микросервисами. Преимущество, однако, заключается в том, что микросервис будет в четко определенном состоянии и вполне может быть в состоянии предложить ухудшенное или ограниченное обслуживание, например, отработав устаревшие убеждения. Недостатком является то, что очень сложно получить непротиворечивый снимок системы в целом, и может быть довольно много (нежелательных) избыточностей и дублирования.

Конечно, предложение не помещать экземпляр Oracle в каждый контейнер Docker. Во-первых, не каждому микросервису нужна «база данных». Некоторые процессы не нуждаются в постоянном состоянии для правильной работы. Например, микросервис, который транслирует между двумя протоколами, не обязательно нуждается в постоянном состоянии. Когда требуется постоянное состояние, слово «база данных» - это просто слово «постоянное состояние». Это может быть файл с JSON в нем или база данных Sqlite или локально работающая копия Oracle, если вы хотите, или любые другие средства локальнопостоянное хранение данных. Если «база данных» не является локальной, то с точки зрения чисто микросервисов она должна рассматриваться как отдельный (микро) сервис. С этой целью никогда не имеет смысла иметь экземпляр RDS в качестве «базы данных» для микросервиса. Опять же, перспектива - это не «группа микросервисов с собственными базами данных RDS», а «группа микросервисов, которые взаимодействуют с базами данных RDS». На этом этапе не имеет значения, хранятся ли данные в одном и том же экземпляре базы данных или нет.

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