К сожалению, у этого термина нет хорошего русскоязычного аналога.
Википедия дает перевод «мультиарендность, множественная аренда».
Иногда это называют «множественным владением».
Эти термины могут несколько сбивать с толку, поскольку предмет по существу не связан ни с арендой, ни с владением.
Это вопрос архитектуры программного обеспечения и организации его работы.
И последнее не менее важно.
Формировать свое понимание мультитенантности мы начали одновременно с проектированием подхода к облачной (сервисной) модели работы в «1С:Предприятии».
Это было несколько лет назад. И с тех пор наше понимание постоянно расширялось.
Мы постоянно открываем все новые и новые аспекты этой темы (плюсы, минусы, трудности, особенности и т.д.).
Иногда разработчики понимают мультитенантность как очень простую тему: «чтобы данные нескольких организаций хранились в одной базе данных, нужно во все таблицы добавить столбец с идентификатором организации и установить по нему фильтр».
Мы, конечно, тоже начали изучение вопроса с этого момента.
Но быстро поняли, что это всего лишь одна поляна (тоже, кстати, непростая).
В общем, это «целая страна».
Основную идею мультиарендности можно описать примерно так.
Типичное применение – коттедж, рассчитанный на проживание одной семьи, которая пользуется его инфраструктурой (стенами, крышей, водоснабжением, отоплением и т. д.).
Многоарендное приложение представляет собой многоквартирный дом.
В нем каждая семья использует одну и ту же инфраструктуру, но сама инфраструктура реализована для всего дома.
Многоарендный подход — это хорошо или плохо? На этот счет можно встретить самые разные мнения.
Кажется, вообще не существует «хорошего» или «плохого».
Сопоставлять плюсы и минусы нужно в контексте конкретных решаемых задач.
Но это отдельная тема.
В самом простом смысле цель мультиарендности — снизить стоимость поддержки приложения за счет «социализации» затрат на инфраструктуру.
Это такое же движение, как снижение стоимости приложения за счет использования производственного решения (возможно, с кастомизацией и модификацией), а не написания его «под заказ».
Только в одном случае развитие обобществлено, а в другом - эксплуатация.
Причем, повторимся, прямой привязки к способу продажи нет. Мультиарендная архитектура также может использоваться в корпоративной или ведомственной ИТ-инфраструктуре для автоматизации большого количества однотипных филиалов и холдинговых предприятий.
Можно сказать, что мультитенантность — это не просто вопрос организации хранения данных.
Это модель того, как приложение работает в целом (включая значительную часть его архитектуры, модель развертывания и организацию его обслуживания).
Самое сложное и интересное в модели multitenancy, как нам кажется, заключается в том, что суть приложения «раздваивается».
Часть функционала работает с конкретными областями данных (квартирами) и «не интересуется» тем, что в других квартирах есть жильцы.
А некоторые воспринимают дом как единое целое и работают сразу на всех жильцов.
При этом последние не могут игнорировать тот факт, что это все-таки отдельные квартиры и необходимо обеспечить необходимый уровень детализации и безопасности.
В «1С:Предприятии» мультиарендная модель реализована на уровне нескольких технологий.
Это механизмы платформы «1С:Предприятие», механизмы 1С:Технология публикации решений 1cFresh " И " 1С:Технология разработки решений 1cFresh ", механизмы БСП (библиотеки стандартных подсистем).
Каждый из этих предметов способствует построению общей инфраструктуры многоквартирного дома.
Почему это реализовано в нескольких технологиях, а не в одной, например, в платформе? Прежде всего потому, что некоторые механизмы, на наш взгляд, вполне целесообразно модифицировать под конкретный вариант развертывания.
Но в целом это сложный вопрос, и мы постоянно стоим перед выбором — на каком уровне лучше реализовать тот или иной аспект мультитенантности.
Очевидно, что базовую часть механизмов необходимо было реализовать в платформе.
Ну, например, собственно разделение данных.
Именно здесь люди обычно начинают говорить о мультиарендности.
Но в итоге модель мультиарендности «прошла» через значительную часть механизмов платформы и потребовала их доработки, а в некоторых случаях и переосмысления.
На уровне платформы мы реализовали именно базовые механизмы.
Они позволяют создавать приложения, работающие в модели мультиарендности.
Но чтобы приложения «жили и работали» в такой модели, нужно иметь систему управления их «жизненной деятельностью».
За это отвечают технологии 1cFresh и слой единой бизнес-логики на уровне BSP. Как в многоквартирном доме инфраструктура обеспечивает жильцов всем необходимым, так и технологии 1cFresh обеспечивают все необходимое для приложений, работающих в мультиарендной модели.
А чтобы приложения могли взаимодействовать с этой инфраструктурой (без существенных модификаций), в них размещаются соответствующие «коннекторы» в виде подсистем BSP. С точки зрения механизмов платформы нетрудно заметить, что по мере приобретения опыта и разработки облачного варианта использования «1С:Предприятие» мы расширяем состав механизмов, которые задействованы в этой архитектуре.
Приведем один пример.
В мультиарендной модели роли участников службы приложений существенно изменяются.
Роль (уровень ответственности) лиц, ответственных за эксплуатацию приложений, существенно возрастает. Им стало необходимо иметь более мощные инструменты контроля приложений.
Потому что пользователи приложения (резиденты) доверяют в первую очередь провайдеру, с которым работают. Для этого мы внедрили новый механизм профиля безопасности .
Этот механизм позволяет администраторам провайдеров ограничить свободу разработчиков приложений до необходимого уровня безопасности — по сути, изолировать работу приложения для каждого арендатора в пределах определенной «песочницы».
Не менее интересна архитектура управления приложениями, работающими в мультитенантном режиме (то, что реализовано в технологиях 1cFresh и BSP).
Здесь по сравнению с традиционной моделью развертывания существенно повышаются требования к автоматизации процессов управления.
Таких процессов десятки: создание новых областей данных («квартир»), обновление приложений, обновление нормативной информации, резервное копирование и т. д. И, конечно же, возрастают требования к уровню надежности и доступности.
Например, для обеспечения надежного взаимодействия приложений и компонентов системы управления мы внедрили технологию асинхронной системы вызовов с гарантированной доставкой.
Очень тонкий момент — способ социализации данных и процессов.
Это кажется простым (если кому-то кажется) только на первый взгляд. Самой большой проблемой является баланс между централизацией данных и процессов и децентрализацией.
С одной стороны, централизация позволяет сократить затраты (дисковое пространство, ресурсы процессора, усилия администратора.
).
С другой стороны, это ограничивает свободу «квартирантов».
Это как раз один из моментов «раздвоения» приложения, когда разработчику необходимо думать одновременно о приложении в узком смысле (обслуживающем одну «квартиру») и в широком (обслуживающем сразу всех «квартирантов») .
В качестве примера такой «дилеммы» можно привести нормативно-справочную информацию.
Конечно, велик соблазн сделать его общим для всех «жильцев» дома.
Это позволяет хранить его в одном экземпляре и обновлять для всех сразу.
Но бывает, что некоторым жильцам нужны конкретные изменения.
Как ни странно, на практике это происходит даже в отношении информации, указанной регуляторами (государственными органами).
Оказывается, это сложный вопрос: социализироваться или не социализироваться? Конечно, заманчиво сделать информацию общей для всех и частной для тех, кто этого хочет. А это уже приводит к очень сложной реализации.
Но мы работаем над этим.
Другой пример — проектирование реализации регулярных процессов (выполняемых по расписанию, инициированных системой управления и т.п.
).
С одной стороны, их можно реализовать для каждой области данных отдельно.
Это проще и удобнее.
Но, с другой стороны, такая мелкая детализация создает большую нагрузку на систему.
Чтобы снизить нагрузку, нужно внедрить социализированные процессы.
Но они требуют более тщательного изучения.
Конечно, это поднимает очень существенный вопрос.
Как разработчики приложений могут обеспечить мультиарендность? Что им для этого нужно сделать? Разумеется, мы стремимся к тому, чтобы груз технологических и инфраструктурных вопросов максимально ложился на плечи поставляемой технологии, а разработчик приложения мыслил только категориями задач бизнес-логики.
Но, как и в случае с другими важными архитектурными вопросами, разработчикам приложений необходимо иметь некоторое представление о работе в модели мультиарендности, и при разработке приложений потребуются определенные усилия.
Почему? Потому что есть моменты, которые технология не может обеспечить автоматически, не учитывая семантику данных.
Например, то же определение границ информационной социализации.
Но мы стараемся свести эти трудности к минимуму.
Уже есть примеры реализации таких приложений.
Важным моментом в контексте реализации мультитенантности в «1С:Предприятии» является то, что мы создаем гибридную модель, в которой одно приложение может работать как в мультиарендном режиме, так и в обычном режиме.
Это очень сложная задача и тема отдельного разговора.
Теги: #1c #1c:предприятие #облако #проектирование систем #Анализ и проектирование систем #SaaS/S+S
-
Icq На Gtalk
19 Oct, 24 -
Исправил Ошибку С Макетами
19 Oct, 24
