Kahjuks pole sellel terminil head venekeelset analoogi. Vikipeedia annab "mitmeüüriline, mitmekordne rentimine." Seda nimetatakse mõnikord "mitmeks omandiks". Need mõisted võivad olla mõnevõrra segadusttekitavad, kuna teema ei ole olemuslikult seotud ei rentimise ega omamisega. See on tarkvaraarhitektuuri ja selle töökorralduse küsimus. Ja viimane pole vähem oluline.
Hakkasime sõnastama oma arusaama mitmest üürisuhtest samal ajal, kui hakkasime kavandama lähenemist pilve (teenuse) töömudelile 1C: Enterprise'is. See oli mitu aastat tagasi. Ja sellest ajast alates on meie arusaamine pidevalt laienenud. Avastame selle teemaga pidevalt uusi ja uusi tahke (plusse, miinuseid, raskusi, omadusi jne).
Mõnikord mõistavad arendajad mitmiküürimist kui väga lihtsat teemat: "mitme organisatsiooni andmete salvestamiseks ühte andmebaasi, peate kõikidesse tabelitesse lisama organisatsiooni identifikaatoriga veeru ja määrama sellele filtri." Sellest hetkest alustasime loomulikult ka selle teema uurimist. Kuid nad mõistsid kiiresti, et see oli ainult üks puhastus (ka, muide, mitte lihtne). Üldiselt on see "terve riik".
Mitme majapidamise põhiideed võib kirjeldada umbes nii. Tüüpiline rakendus on ühe pere majutamiseks mõeldud suvila, mis kasutab oma infrastruktuuri (seinad, katus, veevarustus, küte jne). Mitme üürilahenduse rakendus on korterelamu. Selles kasutab iga pere sama infrastruktuuri, kuid infrastruktuur ise on rakendatud kogu maja jaoks.
Kas mitme üürilepingu lähenemisviis on hea või halb? Selle kohta võite leida väga erinevaid arvamusi. Tundub, et pole üldse "head ega halba". Peate võrdlema plusse ja miinuseid konkreetsete lahendatavate ülesannete kontekstis. Aga see on omaette teema...
Lihtsaimas mõttes on mitme üürilepingu eesmärk vähendada rakenduse ülalpidamiskulusid infrastruktuuri kulude "sotsialiseerimise" kaudu. See on sama liigutus, mis rakenduse kulude vähendamisega tootmislahenduse (võimalik, et koos kohandamise ja muutmisega) abil, selle asemel, et seda tellida. Ainult ühel juhul on areng sotsialiseerunud ja teisel juhul ekspluateerimine.
Veelgi enam, kordame, otsest seost müügimeetodiga pole. Mitme üürilepingu arhitektuuri saab kasutada ka ettevõtte või osakondade IT-infrastruktuuris, et automatiseerida suurel hulgal sarnaseid filiaale ja valdusettevõtteid.
Võime öelda, et multiüürimine ei ole ainult andmesalvestuse korraldamise küsimus. See on mudel selle kohta, kuidas rakendus töötab tervikuna (sh oluline osa selle arhitektuurist, juurutusmudel ja hoolduskorraldus).
Meile tundub, et mitme üürimudeli puhul on kõige keerulisem ja huvitavam see, et rakenduse olemus "hargneb". Osa funktsionaalsusest töötab konkreetsete andmepiirkondadega (korteritega) ja ei ole huvitatud sellest, et teistes korterites on elanikke. Ja mõned tajuvad maja tervikuna ja töötavad kõigi elanike jaoks korraga. Samas ei saa viimane mööda vaadata sellest, et tegu on siiski eraldi korteritega ning selleks on vaja tagada vajalik detailsus ja turvalisus.
1C: Enterprise'is rakendatakse mitme üürimudelit mitme tehnoloogia tasemel. Need on platvormi 1C:Enterprise mehhanismid, mehhanismid"Ja"", mehhanismid (standardsete alamsüsteemide teegid).
Kõik need elemendid aitavad kaasa kortermaja üldise infrastruktuuri ülesehitamisele. Miks seda rakendatakse mitmes tehnoloogias, mitte ühes, näiteks platvormis? Esiteks seetõttu, et mõned mehhanismid on meie arvates üsna asjakohased konkreetse kasutuselevõtuvõimaluse jaoks muutmiseks. Kuid üldiselt on see keeruline küsimus ja oleme pidevalt valiku ees - millisel tasemel on parem seda või teist mitme üürilepingu aspekti rakendada.
Ilmselgelt tuli platvormis juurutada mehhanismide põhiosa. No näiteks tegelik andmete eraldamine. Siin hakatakse tavaliselt rääkima mitmest üürist. Kuid lõpuks "rändas mitme üürilepingu mudel" läbi olulise osa platvormi mehhanismidest ja nõudis nende viimistlemist ja mõnel juhul ka ümbermõtestamist.
Platvormi tasemel rakendasime täpselt põhimehhanismid. Need võimaldavad teil luua rakendusi, mis töötavad mitme üürimudeli alusel. Kuid selleks, et rakendused sellises mudelis "elaksid ja töötaksid", peab teil olema süsteem nende "elutegevuse" haldamiseks. Selle eest vastutavad 1cFresh tehnoloogiad ja ühtne äriloogikakiht BSP tasemel. Nii nagu kortermajas pakub infrastruktuur elanikele kõike, mida nad vajavad, pakuvad 1cFresh tehnoloogiad kõike, mida nad vajavad mitme üürimudeliga töötavate rakenduste jaoks. Ja selleks, et rakendused saaksid selle infrastruktuuriga suhelda (ilma oluliste muudatusteta), paigutatakse neisse vastavad "pistikud" BSP alamsüsteemide kujul.
Platvormi mehhanismide seisukohalt on lihtne märgata, et kogemuste omandamisel ja pilvekasutuse juhtumi “1C:Enterprise” arendamisel laiendame selle arhitektuuriga seotud mehhanismide koosseisu. Toome ühe näite. Mitme üürimudeli puhul muutuvad rakendusteenuses osalejate rollid oluliselt. Rakenduste käitamise eest vastutavate isikute roll (vastutuse tase) suureneb oluliselt. Neil oli vaja võimsamaid rakenduste juhtimise tööriistu. Kuna rakenduste kasutajad (elanikud) usaldavad ennekõike pakkujat, kellega nad töötavad. Selleks võtsime kasutusele uue . See mehhanism võimaldab pakkujate administraatoritel piirata rakenduste arendajate vabadust vajaliku turbetasemega – sisuliselt isoleerida rakenduse töö iga rentniku jaoks teatud liivakasti piires.
Mitte vähem huvitav on mitme üürirežiimis töötavate rakenduste haldamise arhitektuur (mida rakendatakse tehnoloogiates 1cFresh ja BSP). Siin on tavapärase juurutusmudeliga võrreldes oluliselt suurenenud nõuded juhtimisprotsesside automatiseerimisele. Selliseid protsesse on kümneid: uute andmepiirkondade (“korterite”) loomine, rakenduste uuendamine, regulatiivse informatsiooni uuendamine, varukoopiad jne. Ja loomulikult tõusevad nõuded töökindluse ja käideldavuse tasemele. Näiteks rakenduste ja juhtimissüsteemi komponentide vahelise usaldusväärse interaktsiooni tagamiseks rakendasime asünkroonse kõnesüsteemi tehnoloogia koos garanteeritud kohaletoimetamisega.
Väga peen punkt on andmete ja protsesside sotsialiseerimise viis. See tundub lihtne (kui kellelegi tundub) ainult esmapilgul. Suurim väljakutse on tasakaal andmete ja protsesside tsentraliseerimise ning detsentraliseerimise vahel. Ühest küljest võimaldab tsentraliseerimine vähendada kulusid (kettaruum, protsessori ressursid, administraatori pingutused...). Teisest küljest piirab see “üürnike” vabadust. See on täpselt üks rakenduse "hargnemise" momente, mil arendajal on vaja üheaegselt mõelda rakendusele nii kitsas tähenduses (ühe "korteri teenindamine") ja laiemas tähenduses (teenindada kõiki "üürnikke" korraga) .
Sellise "dilemma" näitena võib tuua regulatiivse ja viiteteabe. Muidugi on suur kiusatus muuta see kõigile maja “üürnikele” ühiseks. See võimaldab salvestada selle ühes eksemplaris ja värskendada seda kõigi jaoks korraga. Kuid juhtub, et mõned elanikud vajavad konkreetseid muudatusi. Kummalisel kombel juhtub seda praktikas isegi reguleerivate asutuste (valitsusorganite) määratud teabe puhul. See osutub keeruliseks küsimuseks: sotsialiseeruda või mitte? Loomulikult on ahvatlev muuta teave kõigile üldiseks ja soovijatele privaatseks. Ja see viib juba väga keerulise rakendamiseni. Aga me töötame selle kallal...
Teine näide on tavaliste protsesside juurutamise kavandamine (teostatakse ajakava järgi, algatatakse juhtimissüsteemi poolt jne). Ühest küljest saab neid rakendada iga andmepiirkonna jaoks eraldi. See on lihtsam ja mugavam. Kuid teisest küljest tekitab selline peen detailsus süsteemile suure koormuse. Koormuse vähendamiseks peate rakendama sotsialiseeritud protsesse. Kuid need nõuavad hoolikamat uurimist.
Muidugi tõstatab see väga olulise küsimuse. Kuidas saavad rakenduste arendajad tagada mitme üürimise? Mida nad selleks tegema peavad? Loomulikult püüame selle nimel, et tehnoloogiliste ja taristuprobleemide koorem langeks võimalikult palju tarnitava tehnoloogia õlgadele ning rakenduste arendaja mõtleks ainult äriloogikaülesannetest. Kuid nagu ka muude oluliste arhitektuuriprobleemide puhul, peavad rakenduste arendajad mõistma mitme rendimudeliga töötamist ja rakenduste arendamine nõuab mõningaid jõupingutusi. Miks? Sest on punkte, mida tehnoloogia ei suuda automaatselt pakkuda ilma andmete semantikat arvesse võtmata. Näiteks sama infosotsialiseerumise piiride määratlus. Kuid me püüame hoida neid raskusi väikestena. Näiteid selliste rakenduste rakendamisest on juba olemas.
Oluline punkt 1C: Enterprise'i mitme üürimise rakendamise kontekstis on see, et loome hübriidmudeli, milles üks rakendus saab töötada nii mitme üürimise režiimis kui ka tavarežiimis. See on väga raske ülesanne ja eraldi arutelu teema.
Allikas: www.habr.com