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