Təəssüf ki, bu terminin yaxşı rusdilli analoqu yoxdur. Vikipediya verir “çox kirayəlik, çoxlu kirayəlik”. Buna bəzən "çoxlu mülkiyyət" deyilir. Bu terminlər bir qədər çaşqınlıq yarada bilər, çünki mövzu mahiyyət etibarı ilə nə icarə, nə də sahiblik ilə əlaqəli deyil. Bu proqram təminatının arxitekturası və onun fəaliyyətinin təşkili məsələsidir. Və sonuncunun əhəmiyyəti heç də az deyil.
Biz 1C:Enterprise-də bulud (xidmət) iş modelinə yanaşma dizayn etməyə başladığımız vaxtda çox icarədarlıq anlayışımızı formalaşdırmağa başladıq. Bu, bir neçə il əvvəl idi. Və o vaxtdan bəri anlayışımız daim genişlənir. Biz bu mövzunun getdikcə daha çox yeni tərəflərini (müsbət, mənfi, çətinliklər, xüsusiyyətlər və s.) kəşf edirik.
Bəzən tərtibatçılar çox kirayəçiliyi çox sadə bir mövzu kimi başa düşürlər: "bir neçə təşkilatın məlumatlarının bir verilənlər bazasında saxlanması üçün bütün cədvəllərə təşkilat identifikatoru olan bir sütun əlavə etməli və üzərinə filtr qoymalısınız." Təbii ki, biz də məsələnin araşdırılmasına bu andan başladıq. Ancaq tez başa düşdülər ki, bu, yalnız bir klirinqdir (yeri gəlmişkən, asan deyil). Ümumiyyətlə, bu, “bütün ölkə”dir.
Çoxillikliliyin əsas ideyasını belə təsvir etmək olar. Tipik bir tətbiq, bir ailənin yerləşdirilməsi üçün nəzərdə tutulmuş bir kottecdir, onun infrastrukturundan (divarlar, dam, su təchizatı, istilik və s.) Istifadə edir. Çox kirayəlik tətbiqi yaşayış binasıdır. Burada hər bir ailə eyni infrastrukturdan istifadə edir, lakin infrastrukturun özü bütün ev üçün həyata keçirilir.
Çox kirayəlik yanaşması yaxşıdır, yoxsa pis? Bununla bağlı çox fərqli fikirlər tapa bilərsiniz. Görünür, heç bir "yaxşı və ya pis" yoxdur. Həll olunan konkret vəzifələr kontekstində müsbət və mənfi cəhətləri müqayisə etməlisiniz. Amma bu ayrı mövzudur...
Ən sadə mənada, çox kirayəçiliyin məqsədi infrastruktur xərclərini “sosiallaşdırmaq” yolu ilə proqramın saxlanması xərclərini azaltmaqdır. Bu, “sifariş vermək üçün” yazmaq əvəzinə, istehsal həllindən istifadə etməklə (bəlkə də fərdiləşdirmə və modifikasiya ilə) tətbiqin dəyərini azaltmaqla eyni hərəkətdir. Yalnız bir halda inkişaf ictimailəşir, digərində isə istismar.
Üstəlik, təkrar edirik, satış üsulu ilə birbaşa əlaqə yoxdur. Çox kirayəlik arxitekturası çoxlu sayda oxşar filialları və holdinq müəssisələrini avtomatlaşdırmaq üçün korporativ və ya departamentli İT infrastrukturunda da istifadə edilə bilər.
Çox icarədarlığın yalnız məlumatların saxlanmasının təşkili məsələsi olmadığını deyə bilərik. Bu, tətbiqin bütövlükdə necə işlədiyinə dair bir modeldir (arxitekturasının əhəmiyyətli hissəsi, yerləşdirmə modeli və texniki xidmət təşkilatı daxil olmaqla).
Çox icarədarlıq modelinin ən çətin və maraqlı tərəfi, bizə elə gəlir ki, tətbiqin mahiyyətinin “ikili olması”dır. Funksionallığın bir hissəsi xüsusi məlumat sahələri (mənzillər) ilə işləyir və digər mənzillərdə sakinlərin olması ilə "maraqlanmır". Bəziləri isə evi bütövlükdə qəbul edir və bir anda bütün sakinlər üçün işləyir. Eyni zamanda, sonuncular, bunların, hər şeydən əvvəl, ayrı-ayrı mənzillər olduğunu və lazımi səviyyədə detallılığı və təhlükəsizliyi təmin etmək lazım olduğunu görməməzlikdən gələ bilməz.
1C:Enterprise-də çox icarə modeli bir neçə texnologiya səviyyəsində həyata keçirilir. Bunlar 1C: Enterprise platformasının mexanizmləri, mexanizmləridir"Və"", mexanizmlər (standart alt sistemlərin kitabxanaları).
Bu maddələrin hər biri yaşayış binasının ümumi infrastrukturunun qurulmasına kömək edir. Niyə bu, məsələn, bir platformada deyil, bir neçə texnologiyada həyata keçirilir? Əvvəla, ona görə ki, bəzi mexanizmlər, fikrimizcə, müəyyən bir yerləşdirmə variantı üçün dəyişdirmək üçün olduqca uyğundur. Ancaq ümumiyyətlə, bu çətin sualdır və biz daim seçim qarşısında qalırıq - çoxmənzilliliyin bu və ya digər aspektini hansı səviyyədə həyata keçirmək daha yaxşıdır.
Aydındır ki, mexanizmlərin əsas hissəsini platformada tətbiq etmək lazım idi. Yaxşı, məsələn, faktiki məlumatların ayrılması. Burada insanlar adətən çox kirayəlik haqqında danışmağa başlayırlar. Ancaq sonda çox icarə modeli platformanın mexanizmlərinin əhəmiyyətli bir hissəsindən "səyahət etdi" və onların təkmilləşdirilməsini, bəzi hallarda isə yenidən düşünməyi tələb etdi.
Platforma səviyyəsində biz tam olaraq əsas mexanizmləri həyata keçirdik. Onlar çox icarə modelində işləyən proqramlar yaratmağa imkan verir. Ancaq tətbiqlərin belə bir modeldə "yaşaması və işləməsi" üçün onların "həyat fəaliyyətlərini" idarə etmək üçün bir sistemə sahib olmalısınız. 1cFresh texnologiyaları və BSP səviyyəsində vahid biznes məntiqi təbəqəsi buna cavabdehdir. Necə ki, yaşayış binasında infrastruktur sakinləri ehtiyac duyduqları hər şeylə təmin edir, 1cFresh texnologiyaları da çox kirayəlik modelində işləyən proqramlar üçün lazım olan hər şeyi təmin edir. Tətbiqlərin bu infrastrukturla (əhəmiyyətli dəyişikliklər etmədən) qarşılıqlı əlaqədə olması üçün onlara müvafiq "bağlayıcılar" BSP alt sistemləri şəklində yerləşdirilir.
Platforma mexanizmləri nöqteyi-nəzərindən qeyd etmək asandır ki, biz təcrübə qazandıqca və “1C: Enterprise” buluddan istifadə nümunəsini inkişaf etdirdikcə, biz bu arxitekturada iştirak edən mexanizmlərin tərkibini genişləndiririk. Bir misal verək. Çox icarə modelində tətbiq xidməti iştirakçılarının rolları əhəmiyyətli dərəcədə dəyişir. Əməliyyat proqramlarına cavabdeh olanların rolu (məsuliyyət səviyyəsi) əhəmiyyətli dərəcədə artır. Onların daha güclü tətbiqə nəzarət vasitələrinə malik olması zəruri oldu. Çünki proqram istifadəçiləri (sakinlər) ilk növbədə işlədikləri provayderə etibar edirlər. Bunun üçün yenisini həyata keçirdik . Bu mexanizm provayder administratorlarına proqram tərtibatçılarının azadlığını tələb olunan təhlükəsizlik səviyyəsi ilə məhdudlaşdırmağa imkan verir - mahiyyət etibarilə hər bir icarəçi üçün tətbiqin işini müəyyən sandbox daxilində təcrid etməyə imkan verir.
Çox icarə rejimində işləyən proqramların idarə edilməsi üçün arxitektura (1cFresh və BSP texnologiyalarında tətbiq olunan) daha az maraqlı deyil. Burada adi yerləşdirmə modeli ilə müqayisədə idarəetmə proseslərinin avtomatlaşdırılması tələbləri xeyli artırılır. Onlarla belə proseslər var: yeni məlumat sahələrinin yaradılması (“mənzillər”), tətbiqlərin yenilənməsi, normativ məlumatların yenilənməsi, ehtiyat nüsxələrin çıxarılması və s. Və təbii ki, etibarlılıq və əlçatanlıq səviyyəsinə tələblər artır. Məsələn, proqramlar və idarəetmə sisteminin komponentləri arasında etibarlı qarşılıqlı əlaqəni təmin etmək üçün zəmanətli çatdırılma ilə asinxron zəng sistemi texnologiyasını tətbiq etdik.
Çox incə məqam məlumatların və proseslərin ictimailəşdirilməsi yoludur. Yalnız ilk baxışdan sadə görünür (kiməsə görünürsə). Ən böyük problem məlumatların və proseslərin mərkəzləşdirilməsi ilə mərkəzsizləşdirmə arasında balansdır. Bir tərəfdən, mərkəzləşdirmə xərcləri azaltmağa imkan verir (disk sahəsi, prosessor resursları, administrator səyləri...). Digər tərəfdən, bu, “icarəçilərin” azadlığını məhdudlaşdırır. Bu, proqramın "bifurkasiyası" məqamlarından biridir, tərtibatçı eyni vaxtda tətbiq haqqında dar mənada (bir "mənzil"ə xidmət edir) və geniş mənada (bir anda bütün "kirayəçilərə" xidmət edir) düşünməli olur. .
Belə bir “dilemma”ya misal olaraq tənzimləyici və istinad məlumatlarını göstərmək olar. Əlbəttə ki, bunu evin bütün "kirayəçiləri" üçün ümumi etmək üçün böyük bir cazibə var. Bu, onu bir nüsxədə saxlamağa və bir anda hamı üçün yeniləməyə imkan verir. Amma elə olur ki, bəzi sakinlər konkret dəyişikliklərə ehtiyac duyurlar. Qəribədir ki, praktikada bu, hətta tənzimləyicilər (hökumət orqanları) tərəfindən müəyyən edilmiş məlumatlar üçün də baş verir. Bu çətin sual kimi çıxır: sosiallaşmaq, ya yox? Məlumatı hamı üçün ümumi, istəyənlər üçün isə özəl etmək təbii ki, cəlbedicidir. Və bu, artıq çox çətin həyata keçirməyə gətirib çıxarır. Amma biz bunun üzərində işləyirik...
Başqa bir misal, müntəzəm proseslərin həyata keçirilməsinin layihələndirilməsidir (qrafik üzrə icra edilir, idarəetmə sisteminin təşəbbüsü ilə və s.). Bir tərəfdən, onlar hər bir məlumat sahəsi üçün ayrıca həyata keçirilə bilər. Daha asan və daha rahatdır. Lakin, digər tərəfdən, belə incə dənəvərlik sistemdə böyük bir yük yaradır. Yükü azaltmaq üçün ictimailəşdirilmiş prosesləri həyata keçirməlisiniz. Lakin onlar daha diqqətli araşdırma tələb edir.
Təbii ki, bu, çox mühüm sual doğurur. Tətbiq tərtibatçıları çox kirayəçiliyi necə təmin edə bilərlər? Bunun üçün nə etməlidirlər? Əlbəttə ki, biz çalışırıq ki, texnoloji və infrastruktur məsələlərinin yükü mümkün qədər təchiz edilmiş texnologiyanın çiyinlərinə düşsün və proqram tərtibatçısı yalnız biznes məntiqi tapşırıqları baxımından düşünür. Lakin digər mühüm memarlıq məsələlərində olduğu kimi, proqram tərtibatçıları çox kirayəlik modelində işləmək barədə müəyyən anlayışa malik olmalıdırlar və tətbiqləri inkişaf etdirərkən müəyyən səy tələb olunacaq. Niyə? Çünki verilənlərin semantikasını nəzərə almadan texnologiyanın avtomatik təmin edə bilməyəcəyi məqamlar var. Məsələn, informasiyanın sosiallaşmasının sərhədlərinin eyni tərifi. Amma biz bu çətinlikləri kiçik saxlamağa çalışırıq. Artıq bu cür tətbiqlərin həyata keçirilməsinə dair nümunələr mövcuddur.
1C:Enterprise-də çox icarədarlığın tətbiqi kontekstində vacib məqam ondan ibarətdir ki, biz bir tətbiqin həm çox icarə, həm də normal rejimdə işləyə biləcəyi hibrid model yaradırıq. Bu, çox çətin işdir və ayrıca müzakirə mövzusudur.
Mənbə: www.habr.com