Nažalost, ovaj termin nema dobar analog na ruskom jeziku. Wikipedia daje "višenajamni, višestruki zakup". Ovo se ponekad naziva "višestruko vlasništvo". Ovi termini mogu biti donekle zbunjujući, budući da predmet nije inherentno povezan ni sa iznajmljivanjem ni sa posedovanjem. Ovo je pitanje arhitekture softvera i organizacije njegovog rada. I ovo drugo nije ništa manje važno.
Počeli smo da formulišemo naše razumevanje višestanarstva u isto vreme kada smo počeli da dizajniramo pristup oblaku (servis) modelu rada u 1C:Enterprise. To je bilo prije nekoliko godina. I od tada se naše razumijevanje neprestano širilo. Stalno otkrivamo sve više i više novih aspekata ove teme (prednosti, mane, poteškoće, karakteristike, itd.).
Ponekad programeri shvataju višestanarstvo kao vrlo jednostavnu temu: „kako bi podaci nekoliko organizacija bili pohranjeni u jednoj bazi podataka, morate dodati kolonu sa identifikatorom organizacije svim tabelama i postaviti filter na nju.“ Od ovog trenutka smo, naravno, počeli i sa proučavanjem ovog pitanja. Ali brzo su shvatili da je ovo samo jedna čistina (također, usput, nije laka). Generalno, ovo je „cijela država“.
Osnovna ideja multitenance može se opisati otprilike ovako. Tipična primjena je vikendica dizajnirana za smještaj jedne porodice, koja koristi svoju infrastrukturu (zidovi, krov, vodovod, grijanje itd.). Višestanarska aplikacija je stambena zgrada. U njemu svaka porodica koristi istu infrastrukturu, ali je sama infrastruktura implementirana za cijelu kuću.
Da li je višestanarski pristup dobar ili loš? O tome možete pronaći veoma različita mišljenja. Čini se da uopće ne postoji "dobro ili loše". Morate uporediti prednosti i nedostatke u kontekstu konkretnih zadataka koji se rješavaju. Ali ovo je posebna tema...
U svom najjednostavnijem smislu, cilj višestanarstva je smanjenje troškova održavanja aplikacije „socijalizacijom“ troškova infrastrukture. Ovo je isti pokret kao smanjenje troškova aplikacije korištenjem proizvodnog rješenja (moguće s prilagodbom i modifikacijom), umjesto da ga pišete "po narudžbi". Samo u jednom slučaju je razvoj socijalizovan, au drugom - eksploatacija.
Štaviše, ponavljamo, ne postoji direktna veza sa načinom prodaje. Višestanarska arhitektura se takođe može koristiti u korporativnoj ili IT infrastrukturi odeljenja za automatizaciju velikog broja sličnih filijala i holding preduzeća.
Možemo reći da višestanarstvo nije samo pitanje organizacije skladištenja podataka. Ovo je model kako aplikacija radi kao cjelina (uključujući značajan dio njene arhitekture, njen model implementacije i organizaciju održavanja).
Najteža i najzanimljivija stvar u vezi sa modelom višestanarstva, čini nam se, jeste to što se suština aplikacije „razdvaja“. Dio funkcionalnosti radi sa određenim podatkovnim područjima (stanovima) i „ne zanima“ ga činjenica da u drugim stanovima ima stanara. A neki doživljavaju kuću kao cjelinu i rade za sve stanare odjednom. Pritom, potonji ne mogu zanemariti činjenicu da se ipak radi o zasebnim stanovima, te je potrebno osigurati potreban nivo granularnosti i sigurnosti.
U 1C:Enterprise model višestanarstva implementiran je na nivou nekoliko tehnologija. Ovo su mehanizmi platforme 1C:Enterprise, mehanizmi"I"“, mehanizmi (biblioteke standardnih podsistema).
Svaka od ovih stavki doprinosi izgradnji ukupne infrastrukture stambene zgrade. Zašto je to implementirano u nekoliko tehnologija, a ne u jednoj, na primjer, u platformi? Prije svega, zato što su neki od mehanizama, po našem mišljenju, sasvim primjereni za modifikaciju za određenu opciju implementacije. Ali generalno, ovo je teško pitanje i stalno smo suočeni sa izborom - na kom nivou je bolje implementirati ovaj ili onaj aspekt multistanarstva.
Očigledno je da je osnovni dio mehanizama trebao biti implementiran u platformu. Pa, na primjer, stvarno razdvajanje podataka. Tu ljudi obično počnu pričati o višestanarstvu. Ali na kraju, model višestanarstva je „putovao“ kroz značajan dio mehanizama platforme i zahtijevao je njihovo usavršavanje, au nekim slučajevima i ponovno promišljanje.
Na nivou platforme implementirali smo upravo osnovne mehanizme. Oni vam omogućavaju da kreirate aplikacije koje rade u višestanarskom modelu. Ali da bi aplikacije “živele i radile” u takvom modelu, potrebno je da imate sistem za upravljanje njihovim “životnim aktivnostima”. Za to su zaslužne 1cFresh tehnologije i unificirani sloj poslovne logike na nivou BSP-a. Baš kao što u stambenoj zgradi infrastruktura pruža stanovnicima sve što im je potrebno, tako i 1cFresh tehnologije pružaju sve što im je potrebno za aplikacije koje rade u višestanarskom modelu. A kako bi aplikacije mogle da komuniciraju sa ovom infrastrukturom (bez značajnih modifikacija), odgovarajući „konektori“ se postavljaju u njih u obliku BSP podsistema.
Sa stanovišta mehanizama platforme, lako je primijetiti da kako stječemo iskustvo i razvijamo slučaj korištenja oblaka „1C:Enterprise“, proširujemo sastav mehanizama koji su uključeni u ovu arhitekturu. Navedimo jedan primjer. U višestanarskom modelu, uloge sudionika aplikacijskih usluga značajno se mijenjaju. Značajno se povećava uloga (nivo odgovornosti) onih koji su odgovorni za rad aplikacija. Postalo je neophodno da imaju moćnije alate za kontrolu aplikacija. Zato što korisnici aplikacije (rezidenti) vjeruju prije svega provajderu s kojim rade. Da bismo to učinili, implementirali smo novi . Ovaj mehanizam omogućava administratorima provajdera da ograniče slobodu programera aplikacija na potreban nivo sigurnosti – u suštini, da izoluju rad aplikacije za svakog korisnika unutar određenog sandbox-a.
Ništa manje zanimljiva je i arhitektura za upravljanje aplikacijama koje rade u multitenancy modu (ono što je implementirano u 1cFresh i BSP tehnologijama). Ovdje su, u poređenju sa konvencionalnim modelom implementacije, zahtjevi za automatizacijom procesa upravljanja značajno povećani. Postoje desetine takvih procesa: kreiranje novih oblasti podataka („stanova“), ažuriranje aplikacija, ažuriranje regulatornih informacija, pravljenje rezervnih kopija, itd. I, naravno, zahtjevi za nivoom pouzdanosti i dostupnosti su sve veći. Na primjer, da bismo osigurali pouzdanu interakciju između aplikacija i komponenti upravljačkog sistema, implementirali smo tehnologiju asinhronog sistema poziva sa zagarantovanom isporukom.
Vrlo suptilna tačka je način socijalizacije podataka i procesa. Čini se jednostavno (ako se nekome čini) samo na prvi pogled. Najveći izazov je balans između centralizacije podataka i procesa i decentralizacije. S jedne strane, centralizacija vam omogućava da smanjite troškove (prostor na disku, resursi procesora, napori administratora...). S druge strane, ograničava slobodu „stanara“. Upravo je ovo jedan od momenata „bifurkacije“ aplikacije, kada programer treba istovremeno razmišljati o aplikaciji u užem smislu (opslužuje jedan „stan“) i u širem smislu (opslužuje sve „stanare“ odjednom) .
Kao primjer takve “dileme” mogu se navesti regulatorne i referentne informacije. Naravno, postoji veliko iskušenje da se to učini zajedničkim za sve „stanare“ kuće. Ovo vam omogućava da ga pohranite u jednoj kopiji i ažurirate za sve odjednom. Ali dešava se da su nekim stanovnicima potrebne određene promjene. Čudno, u praksi se to dešava, čak i za informacije koje određuju regulatori (državni organi). Ispostavilo se da je ovo teško pitanje: družiti se ili ne družiti? Primamljivo je, naravno, učiniti informacije općim za sve i privatnim za one koji ih žele. A to već dovodi do veoma teške implementacije. Ali radimo na ovome...
Drugi primjer je dizajn implementacije redovnih procesa (izvršenih po rasporedu, iniciranih od strane sistema kontrole itd.). S jedne strane, mogu se implementirati za svako područje podataka posebno. Lakše je i praktičnije. Ali, s druge strane, tako fina granularnost stvara veliko opterećenje na sistemu. Da biste smanjili opterećenje, morate implementirati socijalizirane procese. Ali zahtijevaju pažljivije proučavanje.
Naravno, ovo postavlja veoma značajno pitanje. Kako programeri aplikacija mogu osigurati višestanarstvo? Šta treba da urade za ovo? Naravno, nastojimo osigurati da teret tehnoloških i infrastrukturnih pitanja padne što je više moguće na pleća isporučene tehnologije, a programer aplikacije razmišlja samo u smislu zadataka poslovne logike. Ali kao i kod drugih važnih arhitektonskih pitanja, programeri aplikacija moraju imati određeno razumijevanje rada u modelu višestanarstva i bit će potreban određeni napor prilikom razvoja aplikacija. Zašto? Jer postoje tačke koje tehnologija ne može automatski pružiti bez uzimanja u obzir semantike podataka. Na primjer, ista definicija granica informacijske socijalizacije. Ali trudimo se da ove poteškoće budu male. Već postoje primjeri implementacije ovakvih aplikacija.
Važna stvar u kontekstu implementacije multitenancy u 1C:Enterprise je da kreiramo hibridni model u kojem jedna aplikacija može raditi iu multitenancy modu i normalnom načinu rada. Ovo je veoma težak zadatak i predmet posebne rasprave.
izvor: www.habr.com