Контекст ответа
Прежде чем ответить на ваши конкретные вопросы, позвольте мне добавить некоторый контекст о решении, которое я вижу.С несколькими арендаторами приходит управление арендаторами.И, как и в документе, на который вы ссылаетесь, вероятно, будет какой-то каталог, содержащий всю специфичную для арендатора информацию.Одной из этих частей информации может (скорее всего, будет) строка подключения к конкретной базе данных арендатора.
Представьте, что клиент подключается, и система получает базу данных для подключения из каталога, в зависимости от того, какой арендаторэто (давайте назовем это контекстом арендатора).Приложение передаст строку подключения остальной части приложения для работы.
Теперь вот прелесть решения: эта строка подключения может указывать (практически) куда угодно.Он может указывать на базу данных в пуле или на управляемый экземпляр.Это могло бы даже указать на локальную базу данных, которая была сделана доступной через Интернет.Все потому, что приложение не зависит от того, где находятся данные, оно просто получает строку подключения и начинает работать.
1.Что произойдет, если мое приложение превысит 500 пользователей?Какие есть варианты для эффективного масштабирования?(когда вы достигнете предела Эластичного пула)
Предполагая, что под пользователями вы подразумеваете арендаторов: ничего не происходит.Новые базы данных создаются в любом месте, доступном для приложения, например, в новом пуле.И поскольку строка подключения для арендатора может указывать куда угодно, это совершенно нормально.
2.Насколько хорошо этот вариант подходит для миграций EF Core?
Этот параметр подходит также для миграций EF Core, как и для любой другой модели базы данных: обновления базы данных необходимо выполнять вдостойный и управляемый способ.Это можно сделать, например, запустив миграцию или скрипт обновления.Факт остается фактом: вам нужно обновить несколько баз данных.И чтобы это работало, разумно иметь достойный план миграции.
Есть несколько вариантов, чтобы смягчить возможные проблемы или, по крайней мере, ограничить возможность поломки материала.Один из них - создавать только те миграции, которые только добавляют к вашей текущей модели.Другой способ состоит в том, чтобы отделить модель базы данных от приложения, имея асинхронный коммуникационный уровень между ними, как служебная шина.
Это довольно сложная стратегия для определения, которая сильно зависит от таких факторов, как тип создаваемого приложения, частота, с которой вы будете обновлять базу данных, и сложность схемы базы данных.
3.Любые другие предложения о том, как начать и подойти к этому позже?
Насколько мне известно: если вы знаете, что это грядет, действуйте по нему сейчас ,Внедрение мультитенантности проще всего на раннем этапе.Чем дальше, тем сложнее, потому что вы, вероятно, начнете жестко кодировать (не совсем, но вроде) соединения в своем приложении, которые должны быть разъединены, как только вы захотите добавить многопользовательский режим.
Заключение
Если я правильно истолковал ваш вопрос, вы знаете, что многопользовательская аренда станет «вещью» для вашего заявления.Это означает, что вам нужно обратиться к нему с самого начала.Но вам не обязательно иметь полноценный мультитенант с самого начала ... вам просто нужно подготовить для этого.
Получение более технической информации: например, вы можете реализовать TenantContext, который идентифицирует клиента при входе в систему и получает соответствующие строки подключения (хранилище, служебная шина, база данных и т. Д.) При входе в систему.Затем в остальной части приложения получите строки подключения из TenantContext и используйте их для получения специфичных для клиента данных.
Сначала, например, во время разработки, контекст может быть очень простым и возвращать информацию только для одного арендатора.Но из-за развязки, которую вы представили, остальная часть приложения уже подготовлена для мульти-аренды.Как только потребность в ней станет реальной, все, что вам нужно сделать, это реализовать TenantContext.
РЕДАКТИРОВАТЬ:
В качестве дополнения из-за комментария ниже: там - это способ заранее зарегистрировать DbContext экземпляров в системе DI.Вы можете реализовать что-то вроде ConnectionStringResolver, которое вставляется в контекст.Как только вам действительно понадобится DbContext, контекст арендатора также станет известен.DbContext создается, используя ConnectionStringResolver, чтобы найти правильную строку подключения для арендатора.