Nažalost, ovaj izraz nema dobar analog na ruskom jeziku. Wikipedia daje "multi-tenancy, više stanara." To se ponekad naziva "višestruko vlasništvo". Ovi pojmovi mogu biti pomalo zbunjujući, budući da predmet nije inherentno povezan ni s iznajmljivanjem ni s posjedovanjem. To je pitanje arhitekture softvera i organizacije njegovog rada. A ovo drugo nije ništa manje važno.
Počeli smo formulirati svoje razumijevanje višestanarstva u isto vrijeme kada smo počeli dizajnirati pristup cloud (servisnom) 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, značajke itd.).
Ponekad programeri shvaćaju multitency kao vrlo jednostavnu temu: "da bi podaci nekoliko organizacija bili pohranjeni u jednoj bazi podataka, morate dodati stupac s identifikatorom organizacije u sve tablice i postaviti filter na njega." Od ovog trenutka smo, naravno, također započeli naše proučavanje problema. Ali brzo su shvatili da je to samo jedna čistina (također, uzgred rečeno, nimalo laka). Općenito, ovo je "cijela država".
Osnovna ideja višestanarstva može se opisati otprilike ovako. Tipična primjena je vikendica dizajnirana za smještaj jedne obitelji, koja koristi svoju infrastrukturu (zidovi, krov, vodoopskrba, grijanje itd.). Višestanarski zahtjev je stambena zgrada. U njemu svaka obitelj koristi istu infrastrukturu, ali je sama infrastruktura izvedena za cijelu kuću.
Je li višestanarski pristup dobar ili loš? O tome možete pronaći vrlo različita mišljenja. Čini se da uopće ne postoji "dobro ili loše". Morate usporediti prednosti i mane u kontekstu specifičnih zadataka koji se rješavaju. Ali ovo je posebna tema...
U najjednostavnijem smislu, cilj višestanarstva je smanjiti troškove održavanja aplikacije "socijalizacijom" troškova infrastrukture. To je isti pokret kao smanjenje troškova aplikacije korištenjem proizvodnog rješenja (moguće s prilagodbom i modificiranjem), umjesto pisanja "po narudžbi". Samo u jednom slučaju socijalizira se razvoj, au drugom - izrabljivanje.
Štoviše, ponavljamo, nema izravne veze s načinom prodaje. Arhitektura multitenancy također se može koristiti u IT infrastrukturi poduzeća ili odjela za automatizaciju velikog broja sličnih podružnica i holding poduzeća.
Možemo reći da višestanarstvo nije samo stvar organizacije pohrane podataka. Ovo je model kako aplikacija funkcionira kao cjelina (uključujući značajan dio svoje arhitekture, model postavljanja i organizaciju održavanja).
Najteža i najzanimljivija stvar kod višestanarskog modela, čini nam se, je to što se bit aplikacije “račva”. Dio funkcionalnosti radi s određenim područjima podataka (stanovima) i "ne zanima" ih činjenica da u drugim stanovima postoje stanari. A neki doživljavaju kuću kao cjelinu i rade za sve stanovnike odjednom. Pritom se ne može zanemariti činjenica da se ipak radi o zasebnim stanovima te je potrebno osigurati potrebnu razinu granularnosti i sigurnosti.
U 1C:Enterprise model multitenancy implementiran je na razini nekoliko tehnologija. Ovo su mehanizmi platforme 1C:Enterprise, mehanizmi"A"“, mehanizmi (biblioteke standardnih podsustava).
Svaka od ovih stavki doprinosi izgradnji cjelokupne infrastrukture stambene zgrade. Zašto je to implementirano u nekoliko tehnologija, a ne u jednoj, na primjer, u platformi? Prije svega, jer su neki od mehanizama, po našem mišljenju, sasvim prikladni za modifikaciju za određenu opciju implementacije. Ali općenito, ovo je teško pitanje i stalno se suočavamo s izborom - na kojoj je razini bolje implementirati ovaj ili onaj aspekt višestanarstva.
Očito je osnovni dio mehanizama trebalo implementirati u platformu. Pa, na primjer, stvarno odvajanje podataka. Ovdje se obično počinje pričati o višestanarstvu. Ali na kraju je višestanarski model “proputovao” kroz značajan dio mehanizama platforme i zahtijevao njihovu doradu, au nekim slučajevima i preispitivanje.
Na razini platforme implementirali smo točno osnovne mehanizme. Omogućuju vam stvaranje aplikacija koje se izvode u višenamjenskom modelu. No, da bi aplikacije “živjele i radile” u takvom modelu, potrebno je imati sustav za upravljanje njihovim “životnim aktivnostima”. Za to su zaslužne 1cFresh tehnologije i objedinjeni sloj poslovne logike na BSP razini. Kao što u stambenoj zgradi infrastruktura pruža stanovnicima sve što im je potrebno, tako 1cFresh tehnologije pružaju sve što im je potrebno za rad aplikacija u višestanarskom modelu. A kako bi aplikacije mogle komunicirati s ovom infrastrukturom (bez značajnih izmjena), u njih su postavljeni odgovarajući "konektori" u obliku BSP podsustava.
Sa stajališ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 aplikacijske usluge značajno se mijenjaju. Uloga (razina odgovornosti) onih koji su odgovorni za rad aplikacija značajno se povećava. Postalo im je potrebno imati snažnije alate za kontrolu aplikacija. Jer korisnici aplikacije (rezidenti) vjeruju prije svega pružatelju s kojim surađuju. Da bismo to učinili, implementirali smo novi . Ovaj mehanizam omogućuje administratorima pružatelja da ograniče slobodu programera aplikacija na potrebnu razinu sigurnosti - u biti, da izoliraju rad aplikacije za svakog stanara unutar određenog sandboxa.
Ništa manje zanimljiva nije ni arhitektura za upravljanje aplikacijama koje rade u multitenancy modu (ono što je implementirano u 1cFresh i BSP tehnologijama). Ovdje su, u usporedbi s konvencionalnim modelom implementacije, zahtjevi za automatizacijom procesa upravljanja značajno povećani. Postoje deseci takvih procesa: stvaranje novih podatkovnih područja ("stanova"), ažuriranje aplikacija, ažuriranje regulatornih informacija, sigurnosne kopije itd. I, naravno, zahtjevi za razinom pouzdanosti i dostupnosti rastu. Na primjer, kako bismo osigurali pouzdanu interakciju između aplikacija i komponenti upravljačkog sustava, implementirali smo tehnologiju asinkronog sustava poziva sa zajamčenom isporukom.
Vrlo suptilna točka je način socijalizacije podataka i procesa. Čini se jednostavno (ako se nekome čini) samo na prvi pogled. Najveći izazov je ravnoteža između centralizacije podataka i procesa i decentralizacije. S jedne strane, centralizacija vam omogućuje smanjenje troškova (prostor na disku, resursi procesora, napori administratora...). S druge strane, ograničava slobodu “stanara”. Ovo je upravo jedan od trenutaka “bifurkacije” aplikacije, kada programer treba istovremeno razmišljati o aplikaciji u užem smislu (služi jedan “stan”) iu širem smislu (služi 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. To vam omogućuje da ga pohranite u jednoj kopiji i ažurirate za sve odjednom. Ali događa se da neki stanovnici trebaju određene promjene. Začudo, u praksi se to događa, čak i za informacije koje specificiraju regulatori (državna tijela). Ispada da je ovo teško pitanje: družiti se ili ne? Primamljivo je, naravno, informacije učiniti općima za sve i privatnima za one koji to žele. A to već dovodi do vrlo teške provedbe. Ali radimo na tome...
Drugi primjer je dizajn implementacije redovitih procesa (izvršava se prema rasporedu, pokreće ga kontrolni sustav itd.). S jedne strane, mogu se implementirati za svako podatkovno područje zasebno. Lakše je i praktičnije. No, s druge strane, takva fina granularnost stvara veliko opterećenje za sustav. Da biste smanjili opterećenje, morate implementirati socijalizirane procese. Ali zahtijevaju pažljivije proučavanje.
Naravno, ovo postavlja vrlo značajno pitanje. Kako programeri aplikacija mogu osigurati višenamjensko korištenje? Što trebaju učiniti za ovo? Naravno, nastojimo osigurati da teret tehnoloških i infrastrukturnih problema što je više moguće padne na pleća isporučene tehnologije, a programer aplikacije razmišlja samo u okvirima zadataka poslovne logike. No, kao i kod drugih važnih arhitektonskih pitanja, programeri aplikacija trebaju imati određeno razumijevanje rada u višestanarskom modelu i bit će potreban određeni napor pri razvoju aplikacija. Zašto? Jer postoje točke koje tehnologija ne može osigurati automatski bez uzimanja u obzir semantike podataka. Na primjer, ista definicija granica informacijske socijalizacije. No, trudimo se da te poteškoće budu male. Već postoje primjeri implementacije takvih aplikacija.
Važna točka u kontekstu implementacije multitenancy-a u 1C:Enterprise je da stvaramo hibridni model u kojem jedna aplikacija može raditi iu multitenancy modu iu normalnom modu. To je vrlo težak zadatak i predmet je posebne rasprave.
Izvor: www.habr.com