Því miður hefur þetta hugtak ekki góða hliðstæðu á rússnesku. Wikipedia gefur "fjölleigu, fjölleigu." Þetta er stundum kallað „fjöleignarhald“. Þessir skilmálar geta verið nokkuð ruglingslegir, þar sem efnið er ekki í eðli sínu tengt annaðhvort að leigja eða eiga. Þetta er spurning um hugbúnaðararkitektúr og skipulag á rekstri hans. Og hið síðarnefnda er ekki síður mikilvægt.
Við byrjuðum að móta skilning okkar á fjöleign á sama tíma og við byrjuðum að hanna nálgun á skýja (þjónustu) líkanið af vinnu í 1C:Enterprise. Þetta var fyrir nokkrum árum. Og síðan þá hefur skilningur okkar stöðugt stækkað. Við erum stöðugt að uppgötva fleiri og fleiri nýjar hliðar á þessu efni (kostir, gallar, erfiðleikar, eiginleikar osfrv.).
Stundum skilja forritarar fjöltengi sem mjög einfalt viðfangsefni: "til þess að gögn nokkurra stofnana séu geymd í einum gagnagrunni þarftu að bæta dálki með auðkenni fyrirtækisins við allar töflur og setja síu á það." Við byrjuðum að sjálfsögðu líka að rannsaka málið frá þessari stundu. En þeir áttuðu sig fljótt á því að þetta var aðeins eitt hreinsun (einnig, við the vegur, ekki auðvelt). Almennt séð er þetta „heilt land“.
Grunnhugmyndinni um fjölmenningu má lýsa eitthvað á þessa leið. Dæmigert forrit er sumarhús sem er hannað til að hýsa eina fjölskyldu, sem notar innviði þess (veggi, þak, vatnsveitur, upphitun osfrv.). Fjöleignarumsókn er fjölbýlishús. Þar notar hver fjölskylda sömu innviði, en innviðirnir sjálfir eru útfærðir fyrir allt húsið.
Er fjöleignaraðferðin góð eða slæm? Það má finna mjög skiptar skoðanir á þessu. Það virðist vera ekkert "gott eða slæmt" yfirleitt. Þú þarft að bera saman kosti og galla í samhengi við þau sérstöku verkefni sem verið er að leysa. En þetta er sérstakt umræðuefni...
Í sínum einfaldasta skilningi er markmið fjöleignarhúss að draga úr kostnaði við að viðhalda forriti með því að „félagsfæra“ innviðakostnað. Þetta er sama hreyfing og að draga úr kostnaði við forrit með því að nota framleiðslulausn (hugsanlega með sérsniðnum og breytingum), frekar en að skrifa það „eftir pöntun“. Aðeins í einu tilviki er þróun félagsvædd og í hinu - arðrán.
Þar að auki, við endurtökum, það er engin bein tenging við söluaðferðina. Margtenancy arkitektúr er einnig hægt að nota í upplýsingatækni innviðum fyrirtækja eða deilda til að gera sjálfvirkan fjölda svipaðra útibúa og eignarhaldsfyrirtækja.
Við getum sagt að fjöleign sé ekki bara spurning um að skipuleggja gagnageymslu. Þetta er líkan af því hvernig forritið virkar í heild sinni (þar á meðal verulegur hluti af arkitektúr þess, dreifingarlíkani og viðhaldsskipulagi þess).
Það erfiðasta og áhugaverðasta við fjöleignarlíkanið, að því er okkur sýnist, er að kjarninn í forritinu „tvískiptur“. Hluti virkninnar vinnur með ákveðin gagnasvæði (íbúðir) og hefur „ekki áhuga“ á því að íbúar séu í öðrum íbúðum. Og sumir skynja húsið sem eina heild og vinna fyrir alla íbúa í einu. Á sama tíma getur hið síðarnefnda ekki horft fram hjá því að þetta eru þegar allt kemur til alls aðskildar íbúðir og nauðsynlegt er að tryggja nauðsynlega nákvæmni og öryggi.
Í 1C:Enterprise er fjöleignarlíkanið útfært á stigi nokkurra tækni. Þetta eru kerfi 1C:Enterprise vettvangsins, kerfi"Og"", kerfi (söfn staðlaðra undirkerfa).
Hver þessara atriða stuðlar að uppbyggingu heildarinnviða fjölbýlishúss. Hvers vegna er þetta útfært í nokkrum tækni, en ekki í einni, til dæmis á vettvang? Fyrst af öllu, vegna þess að sum kerfin, að okkar mati, eru alveg viðeigandi til að breyta fyrir tiltekinn dreifingarvalkost. En almennt séð er þetta erfið spurning og við stöndum stöðugt frammi fyrir vali - á hvaða stigi er betra að innleiða þennan eða hinn þátt fjöleignarhalds.
Augljóslega þurfti að innleiða grunnhluta aðferðanna á pallinum. Jæja, til dæmis, raunverulegur gagnaaðskilnaður. Þar fer fólk yfirleitt að tala um fjöleignarhús. En á endanum „ferðast“ fjöleignarlíkanið í gegnum verulegan hluta af kerfum pallsins og krafðist betrumbóta þeirra, og í sumum tilfellum endurhugsunar.
Á vettvangsstigi innleiddum við nákvæmlega grunnaðferðirnar. Þeir gera þér kleift að búa til forrit sem keyra í fjöleignarlíkani. En til þess að forrit geti „lifað og starfað“ í slíku líkani þarftu að hafa kerfi til að stjórna „lífsstarfsemi“ þeirra. 1cFersk tækni og sameinað viðskiptarökfræðilag á BSP stigi bera ábyrgð á þessu. Rétt eins og í fjölbýlishúsi veitir innviðir íbúum allt sem þeir þurfa, þannig veitir 1cFresh tæknin allt sem þeir þurfa fyrir forrit sem keyra í fjöleignarlíkani. Og svo að forrit geti haft samskipti við þennan innviði (án verulegra breytinga), eru samsvarandi „tengi“ settir í þau í formi BSP undirkerfa.
Frá sjónarhóli kerfisbúnaðar er auðvelt að taka eftir því að þegar við öðlumst reynslu og þróum skýjanotkunartilvikið „1C:Enterprise,“ erum við að auka samsetningu aðferðanna sem taka þátt í þessum arkitektúr. Við skulum nefna eitt dæmi. Í fjöleignarlíkaninu breytast hlutverk þátttakenda umsóknarþjónustu verulega. Hlutverk (ábyrgðarstig) þeirra sem bera ábyrgð á rekstri umsókna eykst til muna. Það varð þeim nauðsynlegt að hafa öflugri forritastjórnunartæki. Vegna þess að notendur forrita (íbúar) treysta fyrst og fremst þjónustuveitunni sem þeir vinna með. Til að gera þetta innleiddum við nýtt . Þetta fyrirkomulag gerir stjórnendum þjónustuveitenda kleift að takmarka frelsi forritara við tilskilið öryggisstig - í rauninni til að einangra rekstur forritsins fyrir hvern leigjanda innan ákveðins sandkassa.
Ekki síður áhugavert er arkitektúrinn til að stjórna forritum sem starfa í fjöltenningarham (það sem er útfært í 1cFresh og BSP tækni). Hér, samanborið við hefðbundna dreifingarlíkanið, eru kröfur um sjálfvirkni stjórnunarferla auknar verulega. Það eru heilmikið af slíkum ferlum: að búa til ný gagnasvæði ("íbúðir"), uppfæra forrit, uppfæra reglugerðarupplýsingar, afrit o.s.frv. Og auðvitað aukast kröfur um áreiðanleika og aðgengi. Til dæmis, til að tryggja áreiðanlegt samspil milli forrita og stjórnkerfishluta, innleiddum við ósamstillta símtalakerfistækni með trygga afhendingu.
Mjög lúmskur punktur er leiðin til að samskipta gögnum og ferlum. Það virðist einfalt (ef einhverjum sýnist) aðeins við fyrstu sýn. Mesta áskorunin er jafnvægið milli miðstýringar gagna og ferla og valddreifingar. Annars vegar gerir miðstýring þér kleift að draga úr kostnaði (diskapláss, örgjörvaauðlindir, viðleitni stjórnenda...). Á hinn bóginn takmarkar það frelsi „leigjenda“. Þetta er einmitt eitt af augnablikum „tvískiptinga“ forritsins, þegar verktaki þarf að hugsa samtímis um forritið í þröngum skilningi (þjónar einni „íbúð“) og í víðum skilningi (þjónar öllum „leigjendum“ í einu). .
Sem dæmi um slíkt „vandamál“ má nefna reglugerðar- og tilvísunarupplýsingar. Auðvitað er mikil freisting að gera það sameiginlegt öllum „leigjendum“ hússins. Þetta gerir þér kleift að geyma það í einu eintaki og uppfæra það fyrir alla í einu. En það kemur fyrir að sumir íbúar þurfa sérstakar breytingar. Merkilegt nokk, í reynd gerist þetta, jafnvel fyrir upplýsingar sem tilgreindar eru af eftirlitsaðilum (ríkisstofnunum). Þetta reynist vera erfið spurning: að umgangast eða ekki að umgangast? Það er auðvitað freistandi að gera upplýsingarnar almennar fyrir alla og persónulegar fyrir þá sem vilja. Og þetta leiðir nú þegar til mjög erfiðrar framkvæmdar. En við erum að vinna í þessu...
Annað dæmi er hönnun á innleiðingu reglulegra ferla (framkvæmt samkvæmt áætlun, frumkvæði að eftirlitskerfinu o.s.frv.). Annars vegar er hægt að útfæra þau fyrir hvert gagnasvæði fyrir sig. Það er auðveldara og þægilegra. En á hinn bóginn skapar svo fínn kornleiki mikið álag á kerfið. Til að draga úr álaginu þarftu að innleiða félagslega ferla. En þeir krefjast vandlegrar rannsóknar.
Þetta vekur auðvitað mjög mikilvæga spurningu. Hvernig geta forritarar tryggt fjöleign? Hvað þurfa þeir að gera fyrir þetta? Auðvitað kappkostum við að tryggja að byrðar tækni- og innviðamála falli eins mikið og hægt er á herðum tækninnar sem fylgir og forritarinn hugsar eingöngu út frá viðskiptarökfræðiverkefnum. En eins og með önnur mikilvæg byggingarmál, þurfa forritarar að hafa einhvern skilning á því að vinna í fjöleignarlíkaninu og nokkur áreynsla verður krafist við þróun forrita. Hvers vegna? Vegna þess að það eru atriði sem tæknin getur ekki veitt sjálfkrafa án þess að taka tillit til merkingarfræði gagnanna. Til dæmis sömu skilgreiningu á mörkum upplýsingafélagsmótunar. En við reynum að halda þessum erfiðleikum litlum. Nú þegar eru dæmi um framkvæmd slíkra umsókna.
Mikilvægur punktur í samhengi við innleiðingu fjöleignar í 1C:Enterprise er að við erum að búa til blendingslíkan þar sem eitt forrit getur starfað bæði í fjöleignarstillingu og venjulegri stillingu. Þetta er mjög erfitt verkefni og efni til sérstakrar umræðu.
Heimild: www.habr.com