Din păcate, acest termen nu are un echivalent bun în limba română. Wikipedia oferă „multiarendă, închiriere multiplă”. Uneori, acest lucru este numit „proprietate multiplă”. Aceste termeni pot fi puțin confuzi, deoarece subiectul nu este în esență legat de închiriere sau de proprietate. Este o chestiune de arhitectură software și de organizarea exploatării acestuia, ceea ce este la fel de important.
Am început să ne formăm înțelegerea multitenancy în momentul în care am început să proiectăm o abordare pentru modelul de lucru bazat pe cloud (serviciu) „1C:Enterprise”. Acum câțiva ani. Și de atunci, înțelegerea noastră s-a extins constant. Descoperim continuu noi și noi aspecte ale acestui subiect (avantaje, dezavantaje, dificultăți, particularități etc.).
Uneori, dezvoltatorii înțeleg prin multitenancy un concept destul de simplu: „pentru ca datele mai multor organizații să fie stocate într-o singură bază de date, trebuie să adăugăm în toate tabelele o coloană cu identificatorul organizației și să aplicăm un filtru pe baza acesteia”. Desigur, și noi am început studiul acestei probleme de la acest punct. însă ne-am dat seama destul de repede că acesta este doar un aspect (de asemenea, nu chiar ușor). În realitate, este un „ întreg teritoriu”.
Ideea principală a multitenancy poate fi descrisă astfel. O aplicație obișnuită este o casă de vacanță, destinată locuirii unei singure familii, care utilizează infrastructura sa (pereți, acoperiș, alimentare cu apă, încălzire etc.). Pe când o aplicație multitenancy este un bloc de apartamente. În el, fiecare familie folosește aceeași infrastructură, dar infrastructura este realizată pentru întregul bloc în ansamblul său.
Este abordarea multitenancy bună sau proastă? Se pot găsi păreri foarte diferite în privința asta. Se pare că nu există un „bun sau rău” în general. Trebuie comparate avantajele și dezavantajele în contextul problemelor specifice rezolvate. Dar aceasta este o temă separată...
În cea mai simplă înțelegere, scopul multitenancy este de a reduce costurile de întreținere a aplicației prin „socializarea” cheltuielilor pe infrastructură. Este o mișcare similară cu reducerea costului aplicației prin utilizarea unei soluții în serie (poate cu personalizare și ajustări) în loc de dezvoltare „la comandă”. Doar că, în cazul de față, se socializa dezvoltarea, iar în celălalt, exploatarea.
Așadar, repetăm, nu este o legătură directă cu modul de vânzare. Arhitectura multitenancy poate fi aplicată și în infrastructura IT corporativă sau instituțională pentru automatizarea unui număr mare de filiale sau întreprinderi din cadrul unui holding.
Se poate spune că multitenancy nu este doar o problemă de organizare a stocării datelor. Este un model de lucru al aplicației în întregul său (inclusiv o parte semnificativă a aspectelor arhitecturii sale, modelul de desfășurare și organizarea întreținerii).
Ceea ce este cel mai complex și interesant în modelul multitenancy, după cum ni se pare, este că esența aplicației se „divizează”. O parte din funcționalitate lucrează cu anumite domenii de date (apartamente) și „nu este interesată” de faptul că există locatari în alte apartamente. O altă parte percepe întregul imobil și lucrează simultan pentru toți locatarii. Totuși, aceasta din urmă nu poate să ignore faptul că, totuși, sunt apartamente separate și trebuie să asigure un nivel necesar de granularitate și siguranță.
În „1C:Enterprise”, modelul multitenancy este implementat la nivelul mai multor tehnologii. Acestea sunt mecanismele platformei „1C:Enterprise”, mecanismele „” și „”, mecanismele (bibliotecile sistemelor standard).
Fiecare dintre aceste elemente contribuie la construirea infrastructurii generale a unei clădiri cu apartamente. De ce este realizată în mai multe tehnologii și nu într-una singură, de exemplu, în platformă? În primul rând, pentru că o parte din mecanisme, după părerea noastră, poate fi modificată cu ușurință în funcție de varianta specifică de desfășurare. Dar, în linii mari, acesta este o întrebare complexă, iar noi ne confruntăm constant cu alegerea – la ce nivel este mai bine să implementăm un anumit aspect al multitenancy.
Este evident că partea de bază a mecanismelor trebuia implementată în platformă. De exemplu, efectiv împărțirea datelor. Acesta este subiectul de început al discuției despre multitenancy. Dar, în cele din urmă, modelul multitenancy a „acoperit” o parte semnificativă din mecanismele platformei și a necesitat revizuirea lor, iar în unele cazuri, chiar și o redefinire.
La nivel de platformă, am implementat exact mecanismele de bază. Acestea permit crearea de aplicații care funcționează în modelul multitenancy. Dar pentru ca aplicațiile să „trăiască și să funcționeze” în acest model, este nevoie de un sistem de gestionare a „vieții” lor. Pentru aceasta, sunt responsabile tehnologiile 1cFresh și stratul unificat de logică de afaceri la nivelul BSC. Așa cum infrastructura asigură necesitățile locatarilor dintr-un bloc cu apartamente, tehnologiile 1cFresh oferă toate cele necesare aplicațiilor care funcționează în modelul multitenancy. Iar pentru ca aplicațiile să poată interacționa cu această infrastructură (fără modificări semnificative), sunt inserate „prize” corespunzătoare sub formă de subsisteme BSC.
Din perspectiva mecanismelor platformei, se observă cu ușurință că, pe măsură ce acumulăm experiență și dezvoltăm varianta bazată pe cloud a „1C:Enterprise”, extindem compunerea mecanismelor implicate în această arhitectură. Iată un exemplu. În modelul multitenancy, rolurile participanților la întreținerea aplicațiilor se schimbă semnificativ. Crește considerabil rolul (nivelul de responsabilitate) celor care răspund de exploatarea aplicațiilor. Aceștia au nevoie de instrumente de control mai puternice. Pentru că utilizatorii aplicațiilor (locatarii) au încredere mai întâi în furnizorul cu care colaborează. De aceea, în versiunea 8.3 am implementat o nouă . Acest mecanism permite administratorilor furnizorului să limiteze libertatea dezvoltatorilor de aplicații la un nivel de securitate necesar – în esență, să izoleze funcționarea aplicației pentru fiecare locatar în anumite limite ale „sandbox-ului”.
Arhitectura pentru gestionarea aplicațiilor care funcționează în mod multitenant (așa cum este implementat în tehnologiile 1cFresh și BSP) este deosebit de interesantă. Comparativ cu modelul obișnuit de desfășurare, cerințele pentru automatizarea proceselor de gestionare cresc semnificativ. Aceste procese sunt zeci: crearea de noi domenii de date („apartamente”), actualizarea aplicațiilor, actualizarea informațiilor normative, backup de date etc. Și, desigur, cerințele pentru nivelul de fiabilitate și disponibilitate cresc. De exemplu, pentru a asigura interacțiunea fiabilă a aplicațiilor cu componentele sistemului de gestionare, am implementat o tehnologie de sistem de apeluri asincrone cu livrare garantată.
Un aspect foarte delicat este modul de partajare a datelor și proceselor. La prima vedere, pare simplu (dacă asta crede cineva). Cea mai mare dificultate constă în echilibrul între centralizarea datelor și proceselor și descentralizare. Pe de o parte, centralizarea permite reducerea cheltuielilor (spațiu pe disc, resurse ale procesorului, eforturile administratorilor…). Pe de altă parte, limitează libertatea „locatarilor”. Aceasta este exact una dintre problemele „divizării” aplicației, când dezvoltatorul trebuie să se gândească simultan la aplicația în sens restrâns (care deserveste o „apartament”) și în sens larg (care deserveste toți „locatarii” deodată).
Un exemplu al unei astfel de „dileme” este informația normativă. Este evident că tentația de a o face comună pentru toți „locatarii” clădirii este mare. Aceasta permite păstrarea ei într-un singur exemplar și actualizarea imediată pentru toți. Dar se întâmplă adesea ca unora dintre locatari să le fie necesare modificări specifice. Ciudat, dar în practică, acest lucru apare chiar și pentru informațiile specificate de reglementatori (organe guvernamentale). Rezultă o întrebare complicată: să partajăm sau nu? E tentant, desigur, să facem informații comune pentru toți și private pentru doritori. Dar asta deja duce la o realizare mult mai complexă. Dar lucrăm la asta…
Un alt exemplu este proiectarea implementării proceselor regulate (executate conform unui program, inițiate de sistemul de gestionare etc.). Pe de o parte, acestea pot fi implementate pentru fiecare domeniu de date separat. Este mai simplu și mai convenabil. Dar, pe de altă parte, o granularitate atât de mică creează o sarcină mai mare asupra sistemului. Pentru a reduce această sarcină, trebuie implementate procese consolidate. Însă acestea necesită o dezvoltare mai atentă.
Desigur, se ridică o întrebare foarte relevantă. Cum pot dezvoltatorii de aplicații să asigure funcționarea în modul multitenancy? Ce trebuie să facă pentru aceasta? Desigur, ne străduim ca povara întrebărilor tehnologice și infrastructurale să cadă cât mai mult pe umerii tehnologiei furnizate, iar dezvoltatorul aplicației să se gândească doar la logica de afaceri. Dar, precum în alte întrebări arhitecturale importante, dezvoltatorii de aplicații trebuie să aibă o oarecare înțelegere a funcționării în modelul multitenancy, iar unele eforturi vor fi necesare în dezvoltarea aplicațiilor. De ce? Pentru că există aspecte pe care tehnologia nu le poate asigura automat, fără a lua în considerare semantica datelor. De exemplu, aceeași definiție a limitelor consolidării informației. Dar ne străduim ca aceste dificultăți să fie minime. Exemple de implementare a unor astfel de aplicații există deja.
Un aspect important în contextul implementării multitenancy în «1C:Enterprise» este faptul că creăm un model hibrid, în care o aplicație poate funcționa atât în modul multitenancy, cât și în modul obișnuit. Aceasta este o sarcină destul de complicată și un subiect de discuție separată.
Sursa: habr.com
