Deja, šis terminas neturi gero analogo rusų kalba. Vikipedija suteikia „daugia nuoma, daugialypė nuoma“. Tai kartais vadinama „daugia nuosavybe“. Šie terminai gali būti šiek tiek painūs, nes objektas nėra savaime susijęs nei su nuoma, nei su nuosavybe. Tai programinės įrangos architektūros ir jos veikimo organizavimo klausimas. Ir pastarasis yra ne mažiau svarbus.
Pradėjome formuluoti savo supratimą apie daugialypę nuomą tuo pačiu metu, kai pradėjome kurti požiūrį į debesies (paslaugų) darbo modelį 1C: Enterprise. Tai buvo prieš keletą metų. Ir nuo to laiko mūsų supratimas nuolat plėtėsi. Nuolat atrandame vis naujų šios temos aspektų (privalumų, minusų, sunkumų, ypatybių ir kt.).
Kartais kūrėjai daugialypę nuomą supranta kaip labai paprastą temą: „kad vienoje duomenų bazėje būtų saugomi kelių organizacijų duomenys, prie visų lentelių reikia pridėti stulpelį su organizacijos identifikatoriumi ir nustatyti filtrą“. Žinoma, nuo šio momento mes taip pat pradėjome šios problemos tyrimą. Tačiau jie greitai suprato, kad tai tik vienas išvalymas (beje, irgi nelengvas). Apskritai tai yra „visa šalis“.
Pagrindinė daugialypės nuosavybės idėja gali būti apibūdinta maždaug taip. Tipiškas pritaikymas yra kotedžas, skirtas vienai šeimai, kuri naudojasi savo infrastruktūra (sienos, stogas, vandentiekis, šildymas ir kt.). Daugiabučio namo paraiška yra daugiabutis namas. Jame kiekviena šeima naudojasi ta pačia infrastruktūra, tačiau pati infrastruktūra yra įgyvendinta visam namui.
Ar daugialypės nuomos būdas yra geras ar blogas? Šiuo klausimu galite rasti labai skirtingų nuomonių. Atrodo, kad nėra „gero ar blogo“. Reikia palyginti privalumus ir trūkumus konkrečių sprendžiamų užduočių kontekste. Bet čia jau atskira tema...
Paprasčiausia prasme daugialypės nuomos tikslas yra sumažinti programos išlaikymo išlaidas „socializuojant“ infrastruktūros išlaidas. Tai yra tas pats veiksmas, kaip sumažinti programos kainą naudojant gamybos sprendimą (galbūt su pritaikymu ir modifikavimu), o ne rašant „pagal užsakymą“. Tik vienu atveju vystymasis socializuojamas, o kitu – išnaudojimas.
Be to, kartojame, nėra tiesioginio ryšio su pardavimo būdu. Daugiabučio nuomos architektūra taip pat gali būti naudojama įmonių ar padalinių IT infrastruktūroje, siekiant automatizuoti daugybę panašių filialų ir kontroliuojančių įmonių.
Galime pasakyti, kad daugiabučiai nuomai nėra vien tik duomenų saugojimo organizavimas. Tai yra visos programos veikimo modelis (įskaitant didelę jos architektūros dalį, diegimo modelį ir priežiūros organizaciją).
Mums atrodo, kad sudėtingiausias ir įdomiausias kelių nuomos modelio dalykas yra tai, kad programos esmė „išsiskiria“. Dalis funkcionalumo veikia su konkrečiomis duomenų sritimis (butais) ir „nesidomi“ tuo, kad kituose butuose yra gyventojų. O kai kurie namą suvokia kaip visumą ir dirba visiems gyventojams iš karto. Kartu pastarieji negali ignoruoti fakto, kad tai visgi atskiri butai, todėl būtina užtikrinti reikiamą detalumo ir saugumo lygį.
„1C:Enterprise“ daugialypės nuomos modelis įgyvendinamas kelių technologijų lygiu. Tai yra 1C:Enterprise platformos mechanizmai, mechanizmai"Ir"“, mechanizmai (standartinių posistemių bibliotekos).
Kiekvienas iš šių elementų prisideda prie bendros daugiabučio namo infrastruktūros kūrimo. Kodėl tai įgyvendinama keliose technologijose, o ne vienoje, pavyzdžiui, platformoje? Visų pirma todėl, kad kai kurie mechanizmai, mūsų nuomone, yra gana tinkami modifikuoti pagal konkrečią diegimo galimybę. Tačiau apskritai tai sunkus klausimas, ir mes nuolat susiduriame su pasirinkimu – kokiame lygyje geriau įgyvendinti tą ar kitą daugialypės nuomos aspektą.
Akivaizdu, kad platformoje reikėjo įdiegti pagrindinę mechanizmų dalį. Na, pavyzdžiui, faktinis duomenų atskyrimas. Čia žmonės dažniausiai pradeda kalbėti apie daugialypę nuomą. Tačiau galiausiai daugiabučio nuomos modelis „keliavo“ per didelę platformos mechanizmų dalį ir reikalavo juos tobulinti, o kai kuriais atvejais – permąstyti.
Platformos lygiu įdiegėme būtent pagrindinius mechanizmus. Jie leidžia kurti programas, kurios veikia kelių nuomos modeliu. Tačiau norint, kad programos galėtų „gyventi ir dirbti“ tokiame modelyje, reikia turėti jų „gyvenimo veiklos“ valdymo sistemą. Už tai atsakingos 1cFresh technologijos ir vieningas verslo logikos sluoksnis BSP lygiu. Kaip daugiabučiuose namuose infrastruktūra suteikia gyventojams viską, ko jiems reikia, taip ir 1cFresh technologijos suteikia viską, ko reikia daugiabučio modelio programoms. Ir tam, kad programos galėtų sąveikauti su šia infrastruktūra (be reikšmingų pakeitimų), atitinkamos „jungtys“ jose dedamos BSP posistemių pavidalu.
Platformos mechanizmų požiūriu nesunku pastebėti, kad įgydami patirties ir kurdami debesies naudojimo atvejį „1C:Enterprise“, plečiame šioje architektūroje dalyvaujančių mechanizmų sudėtį. Pateikime vieną pavyzdį. Daugianuomos modelyje taikomųjų programų paslaugų dalyvių vaidmenys labai keičiasi. Žymiai padidėja atsakingų už programų valdymą vaidmuo (atsakomybės lygis). Jiems tapo būtina turėti galingesnius programų valdymo įrankius. Kadangi programų vartotojai (gyventojai) pirmiausia pasitiki teikėju, su kuriuo dirba. Norėdami tai padaryti, įdiegėme naują . Šis mechanizmas leidžia teikėjų administratoriams apriboti programų kūrėjų laisvę iki reikiamo saugumo lygio – iš esmės atskirti programos veikimą kiekvienam nuomininkui tam tikroje smėlio dėžėje.
Ne mažiau įdomi yra daugianuomos režimu veikiančių programų valdymo architektūra (kas įdiegta 1cFresh ir BSP technologijose). Čia, lyginant su įprastiniu diegimo modeliu, valdymo procesų automatizavimo reikalavimai yra gerokai išaugę. Tokių procesų yra dešimtys: naujų duomenų zonų („butų“) kūrimas, programų atnaujinimas, norminės informacijos atnaujinimas, atsarginės kopijos ir kt. Ir, žinoma, didėja reikalavimai patikimumo ir prieinamumo lygiui. Pavyzdžiui, norėdami užtikrinti patikimą programų ir valdymo sistemos komponentų sąveiką, įdiegėme asinchroninių skambučių sistemos technologiją su garantuotu pristatymu.
Labai subtilus dalykas yra duomenų ir procesų socializavimo būdas. Atrodo paprasta (jei kam nors atrodo) tik iš pirmo žvilgsnio. Didžiausias iššūkis yra pusiausvyra tarp duomenų ir procesų centralizavimo ir decentralizacijos. Viena vertus, centralizavimas leidžia sumažinti išlaidas (vieta diske, procesoriaus ištekliai, administratoriaus pastangos...). Kita vertus, tai riboja „nuomininkų“ laisvę. Tai yra kaip tik vienas iš programos „susikalimo“ momentų, kai kūrėjas turi vienu metu galvoti apie aplikaciją siaurąja prasme (aptarnauti vieną „butą“) ir plačiąja (aptarnauti visus „nuomininkus“ vienu metu) .
Kaip tokios „dilemos“ pavyzdį galima paminėti reguliavimo ir informacinę informaciją. Žinoma, kyla didelė pagunda padaryti tai įprastą visiems namo „nuomininkams“. Tai leidžia saugoti jį vienoje kopijoje ir atnaujinti visiems iš karto. Tačiau būna, kad kai kuriems gyventojams reikia konkrečių pokyčių. Kaip bebūtų keista, praktikoje taip nutinka net ir informacijai, kurią nurodo reguliavimo institucijos (valdžios institucijos). Pasirodo, tai sunkus klausimas: socializuotis ar nebendrauti? Žinoma, kyla pagunda padaryti informaciją bendrą visiems, o privačią tiems, kurie jos nori. O tai jau veda prie labai sunkaus įgyvendinimo. Bet mes dirbame šiuo klausimu...
Kitas pavyzdys – reguliarių procesų įgyvendinimo projektavimas (vykdomas pagal grafiką, inicijuojamas kontrolės sistemos ir pan.). Viena vertus, juos galima įdiegti kiekvienai duomenų sričiai atskirai. Taip lengviau ir patogiau. Tačiau, kita vertus, toks smulkus detalumas sukuria didelę sistemos apkrovą. Norint sumažinti krūvį, reikia diegti socializuotus procesus. Tačiau jie reikalauja kruopštesnio tyrimo.
Žinoma, tai kelia labai svarbų klausimą. Kaip programų kūrėjai gali užtikrinti daugialypę nuomą? Ką jie turi padaryti dėl to? Žinoma, siekiame, kad technologinių ir infrastruktūros problemų našta kuo labiau kristų ant tiekiamos technologijos pečių, o programų kūrėjas galvotų tik verslo logikos uždaviniais. Tačiau, kaip ir sprendžiant kitus svarbius architektūrinius klausimus, programų kūrėjai turi turėti tam tikrą supratimą apie darbą daugialypiame nuomos modelyje ir reikės šiek tiek pastangų kuriant programas. Kodėl? Kadangi yra dalykų, kurių technologijos negali pateikti automatiškai, neatsižvelgdamos į duomenų semantiką. Pavyzdžiui, tas pats informacinės socializacijos ribų apibrėžimas. Tačiau stengiamės, kad šie sunkumai būtų nedideli. Tokių programų įgyvendinimo pavyzdžių jau yra.
Svarbus dalykas, įgyvendinant daugialypį nuomą 1C: Enterprise, yra tai, kad mes kuriame hibridinį modelį, kuriame viena programa gali veikti tiek daugiabučio, tiek įprastu režimu. Tai labai sunki užduotis ir atskiros diskusijos tema.
Šaltinis: www.habr.com
