В мультитенантных приложениях один экземпляр обслуживает более одной организации, но в то же время обеспечивает виртуальную изоляцию данных и приложений от других арендаторов приложения. Поскольку аппаратное обеспечение, операционная система и, в некоторых случаях, код приложения одинаковы для всех пользователей приложения, проще поддерживать, отслеживать и вносить дополнительные изменения на основе совокупных данных от клиентов. Это также обеспечивает экономию от масштаба, благодаря которой услуги могут предоставляться арендаторам с меньшими затратами.
Принцип мультитенантности не является новым явлением, он существует уже несколько десятилетий, но с появлением облачных вычислений мультитенантная архитектура получает все большее распространение в пространстве приложений в облаке. Когда вы создаете учетную запись в службе хранения, такой как DropBox, вам выделяется 2 ГБ свободного места из имеющихся у них петабайт. Ваше пространство 2 ГБ предназначено исключительно для вас, и никто другой не сможет получить к нему доступ, если вы не поделитесь им. Но пространство, назначенное каждому пользователю, потенциально находится на том же физическом запоминающем устройстве или наборе физических запоминающих устройств. Таким образом, вы являетесь одним из арендаторов мультитенантной системы хранения DropBox!
Уровни Мультитенанса
Аппаратно-ресурсная мультитенантность
Это простейшая форма многопользовательской аренды, которая существует уже довольно давно! Когда вы получаете хранилище на Amazon S3 для своего приложения, вы получаете пространство в общем хранилище и являетесь одним из многих арендаторов инфраструктуры. Большинство потребителей IaaS являются арендаторами используемой ими инфраструктуры.
Многопрофильность данных
Многопрофильность данных достигается на уровне хранилища данных. В зависимости от ограничений безопасности и соответствия требованиям, а также от цели организации степень архитектурной многопользовательской работы может варьироваться. Организации, которым нужна безопасность и полная изоляция данных, могут выбрать изолированную настройку БД для своей организации. Другие возможные варианты могут включать наличие одной схемы для организации в одной базе данных или наличие отдельного набора таблиц для каждой организации. Подробное рассмотрение этого вопроса можно найти здесь, но оно не будет основным предметом нашего обсуждения здесь.
Когда мы говорим о многопользовательской работе с данными, код приложения, обращающийся к данным, одинаков. Приложение может быть размещено на нескольких серверах для масштабирования, но, по сути, экраны пользовательского интерфейса, логика и настройки арендаторов остаются идентичными, отличаются только данные.
Приложение мультитенси
Многопрофильность, сплетенная на протяжении всего приложения, является наиболее сложным и трудным для достижения. Итак, как это возможно, что каждый тенат будет иметь разную логику и экраны для доступа к разным данным, по-прежнему разделяя общие ресурсы. Давайте посмотрим на архитектуру высокого уровня такой системы: 
Полная мультитенантная система обеспечивает многопользовательскую работу на уровне данных, аналогично многопользовательской работе с данными, о которой мы говорили ранее. На уровне приложения механизм времени выполнения объединяет специфические для арендатора метаданные и данные настройки с кодом ядра, что дает специфическое для арендатора приложение. Та же логика может применяться на уровне данных для случаев, когда у каждого арендатора есть разные типы схем / объектов. С объектными базами данных гораздо проще иметь разные схемы / объекты для каждого тената или даже иметь разные атрибуты на одном объекте для удовлетворения потребностей разных арендаторов.
Сложность в создании полностью сплетенного мультитенантного приложения возникает из-за наличия фильтров для арендаторов на протяжении всего приложения, в то же время способных обеспечить масштаб и скорость. Для этого используются различные механизмы, такие как кэширование метаданных. Наилучшим практическим примером использования нескольких арендаторов в приложениях являются приложения SalesForce.
Многопользовательская аренда в Google App Engine
GAE предоставляет API пространства имен для достижения многопользовательской работы на уровне данных на сегодняшний день. API пространства имен доступен для хранилища данных, очередей задач и Memchache. API Blobstore еще не поддерживает пространство имен, поэтому ваш двоичный ресурс должен быть разделен на уровне приложения с механизмом, разработанным в приложении. API пространства имен также поддерживает домен Служб Google, поэтому, если ваши клиенты будут пользователями приложений Google, вы можете установить для их данных имя домена как Пространство имен. Существуют различные стратегии использования пространства имен, например, на уровне пользователя, на уровне домена приложений Google и т. Д.
Пространство имен можно задать до поступления запроса в приложение с помощью фильтров, настроенных в дескрипторе развертывания. Пространство имен также может быть установлено в запросе на другое пространство имен для получения общих данных, которые могут быть сброшены или снова установлены на старое пространство имен.
Примеры использования
- Задание пространства имен для текущего домена приложений Google — это разделит данные для каждого пользователя приложений Google. Это можно сделать в фильтре, чтобы запрос, поступающий в приложение, учитывал пространство имен. В следующем фрагменте кода мы проверяем, является ли пространство имен пустым, а если оно пустым, мы устанавливаем его в текущий домен приложений Google.
[sourcecode language = ”java”]
if (NamespaceManager.get () == null) {
NamespaceManager.set (NamespaceManager.getGoogleAppsNamespace ());
} [/исходный код]
Если данные разделены для каждого пользователя, то в качестве пространства имен можно использовать идентификатор пользователя;
[sourcecode language = ”java”]
. UserServiceFactory.getUserService () getCurrentUser () getUserId (). [/исходный код]
- Общее пространство имен может использоваться различными арендаторами для доступа к данным, общим для всех арендаторов, например, для доступа к почтовым индексам всех городов США, которые могут быть получены из общего пространства имен.
[sourcecode language = ”java”]
String currentNs = NamespaceManager.get ();
NamespaceManager.set ( «COMMON_NS»);
// Получить данные, которые необходимы из общего пространства имен
NamespaceManager.set (currentNs); [/исходный код]
- Отдельные пространства имен могут использоваться для разделения данных между dev, QA и промежуточными средами, а версии GAE могут использоваться для размещения различных этапов кодовой базы для соответствующих сред.
- База кода различных модулей приложения может быть развернута в разных версиях, таких как mail.APP_NAME.appspot.com, а данные, специфичные для этого модуля, могут храниться в отдельных пространствах имен.
- Общие данные могут храниться в общем пространстве имен, а пространства имен могут переключаться при необходимости.