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

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

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

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

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

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

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

31 голос | спросил xenon 19 J0000006Europe/Moscow 2018, 13:01:26

3 ответа


10

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

Сохранение всего в одной базе данных

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

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

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

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

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

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

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

Доктрина и реальность

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

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

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

ответил Berin Loritsch 19 J0000006Europe/Moscow 2018, 15:59:52
65

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

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

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

ответил Doc Brown 19 J0000006Europe/Moscow 2018, 13:22:28
12

Это не имеет значения.

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

ответил Michael Borgwardt 19 J0000006Europe/Moscow 2018, 13:14:57

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132