Diemžēl šim terminam nav laba latviešu valodas ekvivalenta. "Vikipēdija" norāda "multientitāte, vairāku nomu". Dažreiz to dēvē arī par "vairāku īpašumu". Šie termini var nedaudz sajaukt, jo tēma būtībā nav saistīta ne ar nomu, ne īpašumu. Tas ir jautājums par programmatūras arhitektūru un tās ekspluatācijas organizēšanu, kas nav mazāk svarīgi.
Mēs sākām veidot savu izpratni par multientitāti tajā pašā laikā, kad uzsākām projektu pieeju klientu iespēju modelim "1C: Uzņēmums". Tas bija pirms vairākiem gadiem. Kopš tā laika mūsu izpratne pastāvīgi paplašinās. Mēs pastāvīgi atklājam šajā tēmā arvien jaunas un jaunas nianses (priekšrocības, trūkumi, sarežģījumi, iezīmes utt.).
Dažreiz izstrādātāji saprot multientitāti kā pavisam vienkāršu jautājumu: "lai vairāku organizāciju dati tiktu glabāti vienā datubāzē, ir jāizveido visās tabulās kolonna ar organizācijas identifikatoru un jāizveido filtrs pēc tās". Mēs arī, protams, sākām mūsu izpēti par šo jautājumu no šī brīža. Bet pietiekami ātri sapratām, ka tas ir tikai viena daļa (tāpat, starp citu, nav vienkārša). Patiesībā tā ir "vesela valsts".
Galveno multientitātes ideju var aprakstīt apmēram šādi. Parasts lietojums ir kotedža, kas paredzēta vienai ģimenei, kas izmanto tās infrastruktūru (sienas, jumts, ūdensapgāde, apkure utt.). Bet multientitātes lietojums ir daudzstāvu māja. Tajā katra ģimene izmanto vienādu infrastruktūras komplektu, bet pati infrastruktūra ir izstrādāta visai mājai kopumā.
Vai pieeja multientitātei ir laba vai slikta? Tam var atrast ļoti atšķirīgus viedokļus. Šķiet, ka nav vispār "labi vai slikti". Jāsalīdzina ieguvumi un trūkumi konkrētu uzdevumu kontekstā. Bet tā ir atsevišķa tēma…
Vienkāršākajā izpratnē multientitātes mērķis ir samazināt izdevumus par lietojuma uzturēšanu, sociāli daloties ar infrastruktūras uzturēšanas izdevumiem. Tas ir tāds pats solis kā lietojuma izmaksu samazināšana, izmantojot standarta risinājumu (iespējams, ar iestatījumiem un pielāgojumiem), nevis rakstot "pēc pasūtījuma". Tikai vienā gadījumā tiek kopīgi izstrādāts, bet otrā - ekspluatācija.
At the same time, we reiterate that there is no direct connection to the sales method here. The multitenancy architecture can also be applied in corporate or departmental IT infrastructures to automate a large number of similar branches and holding companies.
It can be said that multitenancy is not just a matter of data storage organization. It is a model for the operation of the application as a whole (including a significant part of its architecture aspects, deployment model, and service organization).
The most complex and interesting aspect of the multitenancy model, as we see it, is that the essence of the application is 'split'. Part of the functionality works with specific data domains (apartments) and 'does not care' about the tenants in other apartments. Meanwhile, another part perceives the house as a whole and operates for all tenants. However, the latter cannot abstract from the fact that these are indeed separate apartments, and necessary levels of granularity and security must be ensured.
In '1C:Enterprise', the multitenancy model is implemented at several technology levels. These are mechanisms of the '1C:Enterprise' platform, the mechanisms of '" un "', mechanisms (standard subsystem libraries).
Each of these elements contributes to the construction of the common infrastructure of the apartment building. Why is this implemented in several technologies instead of just one, for example, the platform? Primarily because we believe that some mechanisms are reasonable to modify based on specific deployment options. But in general, this is a complex question, and we constantly face the choice of at what level it is better to implement a particular aspect of multitenancy.
It is clear that the basic part of the mechanisms needed to be implemented in the platform. For example, the very separation of data. This is usually where the conversation about multitenancy begins. However, in the end, the multitenancy model 'traveled through' a significant part of the platform's mechanisms and required their refinement, and in some cases, even rethinking.
Platformas līmenī mēs esam ieviesuši tieši pamata mehānismus. Tie ļauj izveidot lietotnes, kas darbojas multitenancy modelī. Tomēr, lai lietotnes „dzīvotu un darbotos” šādā modelī, ir nepieciešama sistēma, kas pārvalda to „dzīves ciklu”. Par to rūpējas tehnoloģijas 1cFresh un standartizēta biznesa loģikas slāņa BSP līmenī. Tāpat kā dzīvokļu mājā infrastruktūra nodrošina iedzīvotājus visam nepieciešamajam, tehnoloģijas 1cFresh nodrošina visam nepieciešamajam lietotnes, kas darbojas multitenancy modelī. Un, lai lietotnes varētu mijiedarboties ar šo infrastruktūru (bez būtiskām izmaiņām), tajās tiek iebūvēti atbilstoši „savienojumi” BSP apakšsistēmu veidā.
No platformas mehānismu skata viedokļa ir viegli pamanīt, ka, attīstoties un gūstot pieredzi mākoņvarianta izmantošanā „1C: Uzņēmums”, mēs paplašinām mehānismu kopumu, kas iesaistīts šajā arhitektūrā. Apskatīsim vienu piemēru. Multitenancy modelī būtiski mainās lomu sadalījums lietotņu apkalpes dalībniekiem. Ievērojami palielinās to lomu (atbildības līmenis), kas atbild par lietotņu ekspluatāciju. Viņiem ir nepieciešams rīkoties ar jaudīgākiem instrumentiem lietotņu uzraudzībai. Jo lietotņu lietotāji (iedzīvotāji) vispirms uzticas pakalpojumu sniedzējam, ar kuru viņi strādā. Tādēļ mēs versijā 8.3 ieviešam jauno . Šis mehānisms ļauj pakalpojumu sniedzēju administratoriem ierobežot lietotņu izstrādātāju brīvību nepieciešamajā drošības līmenī – būtībā izolēt lietotnes darbu katram iedzīvotājam noteiktās „smilšu kastes” (sandbox) robežās.
Arhitektūra, kas nodrošina lietojumprogrammu pārvaldību multitenancy režīmā (kā to īsteno 1cFresh un BSP tehnoloģijās), ir ne mazāk interesanta. Šajā gadījumā, salīdzinot ar parasto izvietošanas modeli, parādās daudz augstākas automatizācijas prasības pārvaldības procesos. Šādu procesu ir desmitiem: jaunu datu jomu («dzīvokļu») izveide, lietojumprogrammu atjaunināšana, normatīvās informācijas atjaunināšana, dublēšana utt. Un, protams, pieaug prasības pēc uzticamības un pieejamības. Piemēram, lai nodrošinātu uzticamu lietojumprogrammu savienojamību ar vadības sistēmas komponentiem, mēs ieviešam tehnoloģiju asinkronās zvanu sistēmas ar garantētu piegādi.
Ļoti smalks mirklis ir datu un procesu publiskošanas veids. Tas no pirmā acu uzmetiena var šķist vienkārši (ja kādam tā šķiet). Vislielāko sarežģītību rada līdzsvara uzturēšana starp datu un procesu centralizāciju un decentralizāciju. No vienas puses, centralizācija ļauj samazināt izmaksas (disku vietu, procesora resursus, administratoru piepūli…). No otras puses, tā ierobežo «iedzīvotāju» brīvību. Tas ir tieši viens no «divišķa» programmatūras aspektiem, kad izstrādātājam jādomā vienlaikus par lietojumprogrammu šaurā nozīmē (apkalpojot vienu «dzīvokli») un plašā nozīmē (apkalpojot visus «iedzīvotājus»).
Kā šādas «dilemmes» piemēru var minēt normatīvo informāciju. Protams, pastāv liela vēlme padarīt to kopīgu visiem «iedzīvotājiem» mājā. Tas ļauj glabāt to vienā eksemplārā un atjaunināt uzreiz visiem. Bet dažreiz kādam iedzīvotājam ir nepieciešamas specifiskas izmaiņas. Kā smieklīgi, tas patiešām notiek praksē, pat attiecībā uz informāciju, kas ir noteikta regulētājiem (valsts iestādēm). Tādējādi rodas grūti atbildams jautājums: publiskot vai nepublikot? Protams, kārdinājums ir izveidot kopīgu informāciju visiem un individuālu tiem, kas to vēlas. Bet tas jau noved pie pavisam sarežģītas īstenošanas. Bet mēs pie tā strādājam...
Vēl viens piemērs ir regulāru procesu projektēšana un īstenošana (kas tiek veikti saskaņā ar grafiku, ierosināti vadības sistēmas utt.). No vienas puses, tos var ieviest katrai datu jomai atsevišķi. Tas ir vienkāršāk un ērtāk. Bet, no otras puses, šāda sīka sadalīšana rada lielu slodzi uz sistēmu. Lai samazinātu slodzi, ir jāīsteno centralizēti procesi. Bet tie prasa rūpīgāku izstrādi.
Protams, rodas ļoti būtisks jautājums. Kā izstrādātājiem nodrošināt darbu multitenancy režīmā? Ko viņiem vajadzētu darīt? Protams, mēs cenšamies, lai tehnoloģisko un infrastruktūras jautājumu smagums maksimāli gulstas uz piegādātās tehnoloģijas pleciem, bet lietojumprogrammas izstrādātājam vajadzētu domāt tikai par biznesa loģikas uzdevumiem. Tomēr, tāpat kā ar citiem svarīgiem arhitektūras jautājumiem, izstrādātājiem jābūt kaut kādai izpratnei par darbu multitenancy modelī un noteikti būs nepieciešamas zināmas pūles lietojumprogrammu izstrādē. Kāds iemesls? Tāpēc, ka ir momenti, kurus tehnoloģija nevar automātiski nodrošināt, ņemot vērā datu semantiku. Piemēram, tā pati informācijas centralizācijas robežu noteikšana. Bet mēs cenšamies, lai šīs grūtības būtu minimālas. Šādu lietojumprogrammu īstenošanas piemēri jau ir.
Svarīgs moments attiecībā uz multitenancy īstenošanu «1C:Uzņēmumā» ir tas, ka mēs izveidojam hibrīda modeli, kurā viena lietojumprogramma var darboties gan multitenancy režīmā, gan parastajā režīmā. Tas ir diezgan sarežģīts uzdevums un ir atsevišķas diskusijas priekšmets.
Avots: habr.com
