Приложение SAAS с микросервисами и базой данных для каждого арендатора

Question

Я разрабатываю веб-приложение для мультитенантной модели SAAS, где из-за каких-то правил мы решили иметь одну базу данных на каждого арендатора и рассматриваем микросервисы для нашего промежуточного программного обеспечения. Но я немного запутался, когда микросервисная архитектура говорит о том, что «каждый микросервис имеет свою собственную базу данных». Итак, вот мои вопросы

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

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

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

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

Ниже приведено высокоуровневое проектирование, с которого мы начали здесь

Answer 1

Здесь следует различать 2 вещи:

1. Sharding базы данных Sharding - это шаблон архитектуры базы данных, связанный с горизонтальным разделением, в котором вы разделяете базу данных на основе некоторого логическогоключ. В вашем случае вашим логическим ключом является ваш Арендатор (tenantId или tenantCode). Sharding позволит вам разделить ваши данные из одной базы данных в несколько физических баз данных. В идеале вы можете иметь базу данных на ключ логического шарда. В вашем случае это означает, что вы можете иметь в лучшем случае базу данных на каждого арендатора. Имейте в виду, что вам не нужно разделять это так далеко. Если ваши данные не настолько велики, чтобы стоить помещать данные каждого арендатора в отдельную базу данных, начните с 2 баз данных и поместите половину ваших арендаторов в 1 физическую базу данных и половину во вторую физическую базу данных. Затем вы можете согласовать это на своем прикладном уровне, сохранив в какой-либо конфигурации или другой таблице в базе данных, какой клиент находится в какой базе данных. По мере роста ваших данных вы можете мигрировать и / или создавать дополнительные физические базы данных или физические фрагменты.

2. База данных на микро-сервис Это одно из основных правил в архитектуре микро-сервисов, согласно которому каждый микро-сервис имеет свою собственную базу данных. Для этого есть несколько причин. Некоторые из них:

   • Масштабирование
   • Изоляция
   • Использование различных технологий баз данных для различных микро-сервисов (при необходимости)
   • разделение команды разработчиков

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

Ваши вопросы

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

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

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

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

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

• Физически разделяйте данные на разные сегменты только в тех микро-сервисах, где они вам нужны. Допустим, у вас есть 2 микро-услуги: продукт-инвентарь-микро-сервис и клиенты-микро-сервис. Допустим, у вас есть 300 миллионов продуктов в вашей базе данных product-инвентарь-micro-service и только 500 000 клиентов. Вам не нужно иметь базу данных на каждого арендатора в микро-сервисе клиентов, но в микро-сервисе инвентаризации продуктов с 300 миллионами записей, что было бы очень полезно с точки зрения производительности. Как я уже говорил выше, начните с малого с 1 или 2 физических баз данных и увеличивайте и мигрируйте с течением времени, когда ваши данные увеличиваются, и вам это нужно. Таким образом, вы сэкономите некоторые затраты на разработку и обслуживание ваших серверов, по крайней мере, на время, когда вам это не нужно.

Answer 2

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

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

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

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

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

• Вы можете иметь экземпляр базы данных (скажем, экземпляр SQL Server) для каждого микросервиса, а в каждом экземпляре - схему для каждого арендатора.
• Это может быть излишним с самого начала, и я думаю, что было бы безопасно создать схему для комбинации услуги / арендатора, пока это число не станет проблемой.

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

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