Təəssüf ki, bu termini üçün yaxşı bir azərbaycan dilində qarşılığı yoxdur. "Vikipediya" verir «multitenancy, çoxlu icarə». Bunu bəzən «müxtəlif sahibliy» olaraq adlandırırlar. Bu terminlər bir qədər çaşdıra bilər, çünki mövzu əslində icarə və ya mülkiyyətlə bağlı deyil. Bu, məhz proqram təminatının arxitekturası və onun istismarını təşkil etmə məsələsidir. Hətta sonuncusu da az əhəmiyyətli deyil.
Biz multitenancy anlayışımızı «1C: Müəssisəsi» bulud (xidmət) iş modelinə yanaşma layihələndirməyə başladığımız anda formalaşdırmağa başladıq. Bu bir neçə il əvvəl olmuşdu. O zamandan bəri anlayışımız daim genişlənir. Biz bu mövzuda hər zaman yeni və yeni aspektlər (üstünlüklər, çatışmazlıqlar, çətinliklər, xüsusiyyətlər və s.) kəşf edirik.
Bəzən inkişaf etdiricilər multitenancy-yə olduqca sadə bir mövzu kimi yanaşırlar: «bir neçə təşkilatın məlumatlarını bir bazada saxlamaq üçün bütün cədvəllərə təşkilatın identifikatorunu əlavə etmək və bu əsasında süzgəc qurmaq lazımdır». Biz də, əlbəttə, bu məsələni elə bu məqamdan başladıq. Amma kifayət qədər tez başa düşdük ki, bu yalnız bir sahədir (həmçinin, mürəkkəbdir). Ümumilikdə isə bu "bütün bir ölkədir".
Multitenancy-nin əsas ideyasını belə təsvir etmək olar. Adi tətbiq - bir ailənin istifadə etdiyi infraquruluş (divarlar, dam, su təchizatı, isitmə və s.) üçün nəzərdə tutulmuş bir kottecdir. Multitenancy tətbiqi isə bir çoxmərtəbəli binadır. Orada hər ailə eyni infrastrukturnu istifadə edir, lakin həmin infrastruktur bütün bina üçün həyata keçirilmişdir.
Multitenancy yanaşması yaxşıdırmı, pisdir? Bu barədə çox fərqli fikirlər tapa bilərsiniz. Görünür ki, burada "yaxşı və ya pis" anlayışı yoxdur. Müxtəlif məsələlərin kontekstinə görə üstünlükləri və çətinlikləri müqayisə etmək lazımdır. Amma bu ayrı bir mövzudur...
Ən sadə anlayışda multitenancy-nin məqsədi infraqurşa xərclərini azaldaraq tətbiqin saxlanma xərclərini aşağı salmaqdır. Bu, seriyalı həlli tətbiq etməklə (bəlkə də, tənzimləmə və təkmilləşdirmə ilə) tətbiqin xərclərini azaldmaq kimi bir hərəkatdır, "xüsusi sifarişlə" yazmaq əvəzinə. Yalnız bir halda inkişaf edən birgə istifadə olunur, digər halda isə istismar.
Həmçinin, yenə də qeyd edək ki, burada satış üsuluna birbaşa bağlanma yoxdur. Multitenancy arxitekturası, korporativ və ya dövlət IT-infrastrukturunda, çoxsaylı oxşar filialların, holdinqin müəssisələrini avtomatlaşdırma üçün tamamilə tətbiq oluna bilər.
Demək olar ki, multitenancy yalnız məlumatların saxlanma təşkilatı məsələsi deyil. Bu, tətbiqin bütövlükdə iş modelidir (onun arxitekturasının əhəmiyyətli hissəsini, yerləşdirmə modelini və xidmət etmə təşkilatını da əhatə edir).
Multitenancy model's most complex and interesting aspect, as we see it, is that the essence of the application 'splits.' One part of the functionality works with specific data domains (apartments) and 'is not concerned' with residents in other apartments. Meanwhile, another part perceives the house as a whole and works for all residents at once. Nevertheless, the latter cannot abstract from the fact that these are separate apartments, and it is necessary to ensure an adequate level of granularity and security.
In '1C:Enterprise', the multitenancy model is implemented on the level of several technologies. These include the mechanisms of the '1C:Enterprise' platform, mechanisms '» və «', mechanisms (standard subsystem libraries).
Each of these elements contributes to the formation of the overall infrastructure of a multi-apartment building. The reason it is implemented in several technologies, rather than just one, like the platform, is primarily that some mechanisms, in our opinion, are quite appropriate to modify for specific deployment scenarios. However, this is generally a complex question, and we often face the choice of the best level to implement a particular aspect of multitenancy.
It is clear that the basic part of the mechanisms had to be implemented in the platform. For instance, the actual data separation. This is what discussions about multitenancy typically begin with. But ultimately, the multitenancy model 'traversed' a significant portion of the platform's mechanisms and required their refinement, and in some cases, even rethinking.
At the platform level, we implemented exactly the basic mechanisms. They allow the creation of applications that operate in a multitenancy model. But for applications to 'live and work' in such a model, there needs to be a system to manage their 'vital activity.' This is the responsibility of the 1cFresh technologies and the unified business logic layer at the BSP level. Just as the infrastructure in a multi-apartment building provides residents with everything they need, so do the 1cFresh technologies provide applications operating in the multitenancy model with what they require. In order for these applications to interact with this infrastructure (without significant modifications), appropriate 'interfaces' in the form of BSP subsystems are embedded within them.
Platforma mexanizmləri baxımından, "1C:Enterprise" bulud istifadəsi inkişaf etdikcə və təcrübə qazandıqca, bu arxitekturaya daxil olan mexanizmlərin sayını artırdığımızı asanlıqla görmək olar. Bir nümunə verək. Multitenancy modelində tətbiqlərin xidmətində iştirakçıların rollarının quraşdırılması əhəmiyyətli dərəcədə dəyişir. Tətbiqlərin istismarına cavabdeh olanların rolu (məsuliyyət səviyyəsi) xeyli artır. Artıq tətbiqlərə nəzarət üçün daha güclü alətlərə ehtiyac duyulur. Çünki tətbiq istifadəçiləri (müəssislər) əvvəlki illərdə çalışdıqları provayderə güvənirlər. Bunun üçün 8.3 versiyasında yeni . Bu mexanizm, provayderin administratorlarına müvəkkilərin təhlükəsizlik səviyyəsini lazımi dərəcədə məhdudlaşdırmağa imkan verir – əslində, tətbiqin işini hər müvsif üçün müəyyən "sandbox" çərçivəsində izolyasiya edir.
Multitenancy rejimində çalışan tətbiqləri idarə etmək üçün arxitektura da heç də az maraqlı deyil (bu, 1cFresh və BSP texnologiyalarında həyata keçirilən bir şeydir). Burada, adi yayım modelinə nisbətən, idarəetmə proseslərinin avtomatlaşdırılması tələbləri əhəmiyyətli dərəcədə artır. Belə proseslər onlarla: yeni məlumat sahələrinin ("müəssisələrin") yaradılması, tətbiqlərin yenilənməsi, normativ məlumatların yenilənməsi, ehtiyat nüsxə çıxarma və s. Və əlbəttə ki, etibarlılıq və mövcudluq səviyyəsinə tələblər artır. Məsələn, tətbiqlərin idarəetmə sistemi ilə etibarlı qarşılıqlı əlaqəsini təmin etmək üçün zəmanətli çatdırılma ilə asinxron çağırış sistemini həyata keçirdik.
Verilənlərin və proseslərin paylaşılması yolu çox incə bir məqamdır. Bu, yalnız birinci baxışda asan görünür (əgər kiməsə asan görünürsə). Məlumatların və proseslərin mərkəzləşdirilməsi ilə desentralizasiya arasında balans yaratmaq ən böyük çətinlikləri yaradır. Bir tərəfdən, mərkəzləşmə, xərcləri (disk sahəsi, prosessor resursları, administratorların səyləri...) azaltmağa imkan verir. Digər tərəfdən, "müəssisələr" üçün azadlığı məhdudlaşdırır. Bu, tətbiqin "ayrı-ayrı" hissələrinin birindən biridir, burada inkişaf etdirici eyni anda tətbiq haqqında düşünməlidir (bir "müəssisəni" xidmət edən) və geniş mənada (bütün "müəssisələri" eyni anda xidmət edən).
Məsələn, belə bir "dilemmayı" normativ-məlumat məlumatı kimi göstərmək olar. Əlbəttə, bütün "sakinlər" üçün onun ümumi olması üçün cəlbedici çoxdur. Bu, onu bir nüsxədə saxlamağa və bütün bunları eyni anda yeniləməyə imkan verir. Amma olur ki, bəzi sakinlərə spesifik dəyişiklər lazımdır. Qəribəsi budur ki, bu, tənzimləyici (dövlət orqanları) tərəfindən spesifikasiya edilən məlumatlar üçün belə baş verir. Nəticədə, ortaya çətin bir sual çıxır: onu şərtləndirmək, yoxsa etməmək? Hamı üçün ümumi bilgi, istəyənlər üçün isə fərdi məlumat olması cəlbedicidir. Bu isə tamamilə çətin bir icraata gətirib çıxarır. Amma biz bunun üzərində çalışırıq...
Başqa bir misal, müntəzəm proseslərin (cədvələ uyğun icra edilən, idarəetmə sistemi tərəfindən başlanan və s.) layihələndirilməsidir. Bir tərəfdən, onları hər bir məlumat sahəsi üçün ayrı-ayrılıqda həyata keçirmək mümkündür. Bu, daha asan və rahatdır. Amma digər tərəfdən, belə incə granullar sistemdə daha böyük yük yaradır. Yükü azaltmaq üçün, ümummüddətli proseslərin həyata keçirilməsi tələb olunur. Amma bunlar daha diqqətli işlənməyi tələb edir.
Əlbəttə, əhəmiyyətli bir sual yaranır. Tətbiq inkişaf etdiriciləri multitenancy rejimində necə iş görməlidirlər? Bunun üçün onlara nə etməli olduqları lazımdır? Əlbəttə, biz istəyirik ki, texnoloji və infrastruktur məsələlərinin ağırlığı mümkün qədər təmin olunan texnologiyanın üzərinə düşsün, tətbiq inkişaf etdiricisi isə yalnız biznes məntiqi məsələləri düşünməli olsun. Amma digər mühüm arxitektura məsələləri kimi, multitenancy modelində iş prinsipinə birmənalı bir anlayışın olmasına ehtiyac var və tətbiq inkişaf etdirilməsində müəyyən səylər tələb olunacaq. Niyə? Çünki, texnologiyanın məlumatların semantikasını nəzərə almadan avtomatik olaraq təmin edə bilmədiyi müəyyən məqamlar var. Məsələn, məlumatların şərtləndirilmə sərhədlərinin müəyyənləşdirilməsi. Amma biz istəyirik ki, bu çətinliklər minimal olsun. Belə tətbiqlərin icrası üçün misallar artıq mövcuddur.
Multitenancy-nin «1C: Müəssisəsi» kontekstində həyata keçirilməsində vacib məqam, bir tətbiqin həm multitenancy, həm də adi rejimdə işləyə bilən hibrid bir model yaratmağımızdır. Bu, olduqca mürəkkəb bir vəzifədir və ayrı bir müzakirə mövzusudur.
Mənbə: habr.com
