Относно многонаемността

За съжаление, този термин няма добър рускоезичен аналог. Уикипедия дава превод "multi-tenancy, множествено наемане." Това понякога се нарича "множествена собственост". Тези термини могат да бъдат донякъде объркващи, тъй като предметът не е присъщо свързан нито с отдаване под наем, нито с притежаване. Това е въпрос на архитектура на софтуера и организация на неговата работа. И последното е не по-малко важно.

Започнахме да формулираме нашето разбиране за мултинаемност по същото време, когато започнахме да проектираме подход към облачния (услуген) модел на работа в 1C:Enterprise. Това беше преди няколко години. И оттогава нашето разбиране непрекъснато се разширява. Постоянно откриваме нови и нови аспекти на тази тема (плюсове, минуси, трудности, характеристики и т.н.).

Понякога разработчиците разбират многонаемността като много проста тема: „за да могат данните на няколко организации да се съхраняват в една база данни, трябва да добавите колона с идентификатора на организацията към всички таблици и да зададете филтър върху нея.“ Ние, разбира се, също започнахме нашето проучване на въпроса от този момент. Но те бързо разбраха, че това е само едно сечище (също, между другото, не лесно). Като цяло, това е „цяла държава“.

Основната идея за многонаемност може да бъде описана по следния начин. Типично приложение е вила, предназначена за настаняване на едно семейство, което използва своята инфраструктура (стени, покрив, водоснабдяване, отопление и др.). Приложението за многонаемно жилище е жилищна сграда. При него всяко семейство ползва една и съща инфраструктура, но самата инфраструктура е реализирана за цялата къща.

Многонаемният подход добър или лош ли е? Можете да намерите много различни мнения по този въпрос. Изглежда, че изобщо няма „добро или лошо“. Трябва да сравните плюсовете и минусите в контекста на конкретните задачи, които се решават. Но това е отделна тема...

В най-простия смисъл, целта на мултитенантността е да се намалят разходите за поддръжка на приложение чрез „социализиране“ на инфраструктурните разходи. Това е същото движение като намаляване на цената на приложение чрез използване на производствено решение (вероятно с персонализиране и модификация), вместо да го напишете „по поръчка“. Само в единия случай се социализира развитието, а в другия – експлоатацията.

Освен това, повтаряме, няма пряка връзка с метода на продажба. Архитектурата с множество клиенти може също да се използва в корпоративна или отделна ИТ инфраструктура за автоматизиране на голям брой подобни клонове и холдингови предприятия.

Можем да кажем, че мултинаемността не е просто въпрос на организиране на съхранение на данни. Това е модел на начина, по който приложението работи като цяло (включително значителна част от неговата архитектура, неговия модел на внедряване и неговата организация за поддръжка).

Най-трудното и интересно нещо в модела с множество наемници ни се струва, че същността на приложението се „раздвоява“. Част от функционалността работи с конкретни зони с данни (апартаменти) и „не се интересува“ от факта, че има жители в други апартаменти. А някои възприемат къщата като цяло и работят за всички жители наведнъж. В същото време последните не могат да пренебрегнат факта, че това все пак са отделни апартаменти и е необходимо да се осигури необходимото ниво на детайлност и сигурност.

В 1C:Enterprise моделът на многонаемност се изпълнява на ниво няколко технологии. Това са механизмите на платформата 1C:Enterprise, механизмите на1C: Технология за публикуване на решения 1cFresh"И"1C:Технология за разработка на решения 1cFresh“, механизми BSP (библиотеки на стандартни подсистеми).

Всеки от тези елементи допринася за изграждането на цялостната инфраструктура на една жилищна сграда. Защо това е реализирано в няколко технологии, а не в една, например в платформа? На първо място, защото някои от механизмите, според нас, са напълно подходящи за модифициране за конкретна опция за внедряване. Но като цяло това е труден въпрос и ние постоянно сме изправени пред избор - на какво ниво е по-добре да внедрим този или онзи аспект на многонаемността.

Очевидно основната част от механизмите трябваше да бъдат внедрени в платформата. Е, например, действителното разделяне на данните. Това е мястото, където хората обикновено започват да говорят за мултинаемане. Но в крайна сметка моделът на мултинация „пропътува“ през значителна част от механизмите на платформата и изисква тяхното усъвършенстване, а в някои случаи и преосмисляне.

На ниво платформа внедрихме точно основните механизми. Те ви позволяват да създавате приложения, които се изпълняват в модел с множество клиенти. Но за да могат приложенията да „живеят и работят“ в такъв модел, трябва да имате система за управление на техните „житейски дейности“. За това са отговорни технологиите 1cFresh и единен слой на бизнес логика на ниво BSP. Точно както в една жилищна сграда инфраструктурата осигурява на обитателите всичко, от което се нуждаят, така и технологиите 1cFresh осигуряват всичко необходимо за приложения, работещи в модел с множество наематели. И за да могат приложенията да взаимодействат с тази инфраструктура (без значителни модификации), съответните „конектори“ се поставят в тях под формата на BSP подсистеми.

От гледна точка на механизмите на платформата е лесно да се забележи, че докато натрупваме опит и развиваме случая на използване на облак „1C:Enterprise“, ние разширяваме състава на механизмите, които участват в тази архитектура. Да дадем един пример. В модела с множество клиенти ролите на участниците в услугата за приложения се променят значително. Ролята (нивото на отговорност) на лицата, отговорни за работата на приложенията, нараства значително. За тях стана необходимо да имат по-мощни инструменти за контрол на приложенията. Защото потребителите на приложението (резиденти) се доверяват преди всичко на доставчика, с който работят. За да направим това, внедрихме нов механизъм за защитен профил. Този механизъм позволява на администраторите на доставчиците да ограничат свободата на разработчиците на приложения до необходимото ниво на сигурност - по същество да изолират работата на приложението за всеки клиент в рамките на определена пясъчна среда.

Не по-малко интересна е архитектурата за управление на приложения, работещи в мултитенарен режим (това, което е внедрено в технологиите 1cFresh и BSP). Тук, в сравнение с конвенционалния модел на внедряване, изискванията за автоматизация на процесите на управление са значително повишени. Има десетки такива процеси: създаване на нови области с данни („апартаменти“), актуализиране на приложения, актуализиране на нормативна информация, архивиране и т.н. И, разбира се, изискванията за нивото на надеждност и достъпност се увеличават. Например, за да осигурим надеждно взаимодействие между приложенията и компонентите на системата за управление, внедрихме технология за асинхронна система за повикване с гарантирана доставка.

Много тънък момент е начинът на социализиране на данни и процеси. Изглежда просто (ако изглежда на някого) само на пръв поглед. Най-голямото предизвикателство е балансът между централизацията на данни и процеси и децентрализацията. От една страна, централизацията ви позволява да намалите разходите (дисково пространство, процесорни ресурси, усилия на администратора...). От друга страна, ограничава свободата на „наемателите“. Това е точно един от моментите на „раздвояване“ на приложението, когато разработчикът трябва да мисли едновременно за приложението в тесен смисъл (обслужващо един „апартамент“) и в широк смисъл (обслужващо всички „наематели“ наведнъж) .

Като пример за такава „дилема“ може да се цитира регулаторна и справочна информация. Разбира се, има голямо изкушение да го направите общо за всички „наематели“ на къщата. Това ви позволява да го съхранявате в едно копие и да го актуализирате за всички наведнъж. Но се случва някои жители да се нуждаят от специфични промени. Колкото и да е странно, на практика това се случва, дори и за информация, която е определена от регулаторите (правителствените органи). Това се оказва труден въпрос: да се социализираме или да не се социализираме? Изкушаващо е, разбира се, да направим информацията обща за всички и лична за тези, които я искат. А това вече води до много трудно изпълнение. Но ние работим върху това...

Друг пример е проектирането на изпълнението на регулярни процеси (изпълнявани по график, инициирани от системата за управление и т.н.). От една страна, те могат да бъдат реализирани за всяка област от данни поотделно. По-лесно и удобно е. Но, от друга страна, такава фина детайлност създава голямо натоварване на системата. За да намалите натоварването, трябва да внедрите социализирани процеси. Но те изискват по-внимателно проучване.

Разбира се, това повдига много важен въпрос. Как разработчиците на приложения могат да осигурят мултинаемност? Какво трябва да направят за това? Разбира се, ние се стремим да гарантираме, че тежестта на технологичните и инфраструктурни проблеми пада възможно най-много върху плещите на предоставената технология, а разработчикът на приложения мисли само от гледна точка на задачите на бизнес логиката. Но както при други важни архитектурни въпроси, разработчиците на приложения трябва да имат някакво разбиране за работа в модела с множество наематели и ще са необходими известни усилия при разработването на приложения. Защо? Защото има точки, които технологията не може да предостави автоматично, без да вземе предвид семантиката на данните. Например, същото определение на границите на информационната социализация. Но ние се опитваме да поддържаме тези трудности малки. Вече има примери за внедряване на такива приложения.

Важен момент в контекста на внедряването на мултитенантност в 1C:Enterprise е, че ние създаваме хибриден модел, при който едно приложение може да работи както в режим на мултитенантност, така и в нормален режим. Това е много трудна задача и е предмет на отделна дискусия.

Източник: www.habr.com