За съжаление, този термин няма добър български аналог. „Уикипедия“ дава „мултиарендност, множество наеми“. Понякога това се нарича „множество владение“. Тези термини могат да бъдат малко объркващи, тъй като предметът не е свързан с наемането или владението. Това е въпрос на архитектура на софтуера и организация на неговата експлоатация. И последното не е по-малко важно.
Започнахме да формираме нашето разбиране за multitenancy едновременно с проектирането на подхода към облачната (сервисна) модел на работа на „1С:Предприятие“. Това беше преди няколко години. И оттогава нашето разбиране постоянно се разширява. Постоянно откриваме нови аспекти на този предмет (плюсове, минуси, трудности, особености и т.н.).
Понякога разработчиците разбират под multitenancy напълно прост предмет: „за да се съхраняват данните на няколко организации в една база, трябва да добавим в таблиците колона с идентификатора на организацията и да установим филтър по нея“. Ние също, разбира се, започнахме нашето проучване на въпроса от този момент. Но достатъчно бързо разбрахме, че това е само едно поле (също, между другото, не просто). А всъщност, това е „цяла страна“.
Основната идея на multitenancy може да бъде описана така. Обикновено приложение – това е вила, предназначена за живеене на едно семейство, което ползва инфраструктурата му (стени, покрив, водоснабдяване, отопление и т.н.). А multitenancy-приложение – това е многофамилна сграда. В него всяко семейство ползва същата инфраструктура, но самата инфраструктура е реализирана за цялата сграда.
А подходът multitenancy – това е добре или лошо? Мненията по този въпрос могат да бъдат много различни. Изглежда, че няма „добре или лошо“ изобщо. Трябва да се сравняват плюсовете и минусите в контекста на конкретни решавани задачи. Но това е отделна тема…
В най-простото разбиране целта на multitenancy е да се намалят разходите за поддържане на приложението чрез „общи“ разходи за инфраструктура. Това е същото движение, като намаляването на цената на приложението чрез прилагане на масово решение (възможно с настройка и доработка), а не написване „по поръчка“. Само в един случай се общественява разработката, а в другия – експлоатацията.
Тук е важно да подчертаем, че няма пряка зависимост от начините на продажба. Архитектурата на multitenancy може напълно да се използва и в корпоративни или ведомствени IT инфраструктури за автоматизиране на множество подобни клонове или предприятия в холдинг.
Може да се каже, че multitenancy не е просто въпрос на организация на съхранение на данни. Това е модел на работа на приложението като цяло (включително значителна част от аспектите на архитектурата му, модела на разгръщане и организацията на обслужването).
Най-интересното и сложно в модела multitenancy, както изглежда, е, че същността на приложението "раздваива". Част от функционалността работи с конкретни области от данни (апартаменти) и "не се интересува" от това, че има наематели в други апартаменти. А част от функционалността възприема сградата като цяло и работи веднага за всички наематели. Освен това последната не може да абстрахира от факта, че все пак става дума за отделни апартаменти и е необходимо да се осигури необходимото ниво на грануларност и сигурност.
В "1С:Предприятие" моделът multitenancy се реализира на ниво няколко технологии. Това са механизмите на платформата "1С:Предприятие", механизмите "» и «", механизмите (библиотеки на стандартни подсистеми).
Всеки от тези елементи допринася за изграждането на общата инфраструктура на многофамилна сграда. Защо това се реализира в няколко технологии, а не в една, например в платформата? Преди всичко, защото част от механизмите, по наше мнение, е уместно да се модифицират при конкретната версия на разгръщане. Но в обобщение, това не е прост въпрос и постоянно ставаме пред избора – на какво ниво да реализираме определен аспект от multitenancy.
Очевидно е, че основната част от механизмите трябваше да бъде реализирана в платформата. Например, самото разделение на данните. То, с което обикновено започва разговорът за multitenancy. Но в крайна сметка моделът multitenancy "премина" през значителна част от механизмите на платформата и изискваше тяхното подобряване, а в някои случаи и преразглеждане.
На платформено ниво реализирахме точно основните механизми. Те позволяват създаването на приложения, работещи в модел на многобройност. Но за да могат приложенията да "живеят и работят" в такъв модел, трябва да имаме система за управление на тяхната "жизненост". За това отговарят технологиите 1cFresh и унифицираният слой бизнес логика на ниво БСП. Подобно на инфраструктурата в многофамилна сграда, която осигурява на живущите всичко необходимо, така и технологиите 1cFresh осигуряват всичко необходимо на приложенията, работещи в модела на многобройност. А за да могат приложенията да взаимодействат с тази инфраструктура (без съществени доработки), в тях се поставят съответните "разъеми" под формата на подсистеми БСП.
От гледна точка на механизмите на платформата е лесно да се забележи, че с напредъка и развитието на облачния вариант на "1С:Предприятие" разширяваме състава на механизмите, които участват в тази архитектура. Нека дадем един пример. В модела на многобройност значително се променя разпределението на ролите на участниците в обслужването на приложения. Значително се увеличава ролята (нивото на отговорност) на тези, които отговарят за експлоатацията на приложенията. Необходимо е те да имат по-мощни инструменти за контрол на приложенията. Защото потребителите на приложенията (жилищата) доверяват преди всичко на доставчика, с когото работят. Затова реализирахме в версия 8.3 нов . Този механизъм позволява на администраторите на доставчика да ограничат свободата на разработчиците на приложения до необходимото ниво на сигурност – по същество, да изолират работата на приложението за всеки обитател в определени рамки на "пясъчника" (sandbox).
Също толкова интересна е архитектурата за управление на приложения, работещи в режим multitenancy (каквато се реализира в технологиите 1cFresh и BCP). Тук, в сравнение с обичайната модел на разгръщане, значително се повишават изискванията към автоматизацията на управленските процеси. Такива процеси са десетки: създаване на нови области за данни („апартаменти“), обновяване на приложения, обновяване на нормативна информация, резервно копиране и т.н. И, разбира се, се увеличава и изискванията за надеждност и достъпност. Например, за да осигурим надеждно взаимодействие на приложенията с компонентите на системата за управление, реализирахме технология за асинхронна система за повиквания с гарантирано доставяне.
Много деликатен момент е начинът на обединяване на данните и процесите. На пръв поглед това изглежда просто (ако на някого му изглежда така). Най-голямата сложност идва от баланса между централизацията на данните и процесите и децентрализацията. От една страна, централизацията позволява намаляване на разходите (дисково пространство, ресурси на процесора, усилия на администраторите…). От друга страна, това ограничава свободата на „обитателите“. Това е един от моментите на „раздвоение“ на приложението, когато разработчикът трябва да мисли едновременно за приложението в тесен смисъл (обслужващо един „апартамент“) и в широк смисъл (обслужващо всички „обитатели“).
Като пример за такава „дилема“ може да се наведе нормативната справочна информация. Разбира се, съществува голямо изкушение да я направим обща за всички „жители“ на сградата. Това позволява да я съхраняваме в един екземпляр и да я обновяваме наведнъж за всички. Но понякога се оказва, че на някой обитател са нужни специфични промени. Както странно да звучи, но на практика това се среща дори и за информация, специфицирана от регулаторите (държавни органи). Получава се не лесен въпрос: да се обедини или не да се обедини? Изкушаващо е да направим обща информация за всички и частна за желаещите. А това вече води до съвсем сложна реализация. Но ние работим по този въпрос...
Друг пример е проектирането на реализация на регулярни процеси (изпълнявани по график, инициирани от управленската система и т.н.). От една страна, те могат да бъдат реализирани за всяка област от данни поотделно. Това е по-лесно и удобно. Но от друга страна, такава фина грануларност създава голямо натоварване на системата. За да намалим натоварването, трябва да реализираме общи процеси. Но те изискват по-внимателна обработка.
Разбира се, повдига се много важен въпрос. Как разработчиците на приложения да осигурят работа в режим на multitenancy? Какво трябва да направят за това? Разбира се, ние се стремим към това, технологичните и инфраструктурни въпроси да паднат на плещите на доставяната технология, а разработчикът на приложението да се фокусира единствено върху бизнес логиката. Но както и с други важни архитектурни въпроси, разработчиците на приложения трябва да имат някаква представа за работата в модела multitenancy и определени усилия при разработката на приложения ще са необходими. Защо? Защото съществуват моменти, които технологията не може да осигури автоматично без да отчита семантиката на данните. Например, определянето на границите на общата информация. Но ние се стараем тези трудности да са минимални. Вече има примери за реализирани такива приложения.
Важен момент в контекста на реализацията на multitenancy в „1С:Предприятие“ е, че ние създаваме хибриден модел, в който едно приложение може да работи както в режим на multitenancy, така и в обикновен режим. Това е доста сложна задача и обект на отделно обсъждане.
Източник: habr.com
