ProHoster > Blogs > Administrācija > Par vairāku īri

Par vairāku īri

Diemžēl Å”im terminam nav laba krievu valodas analoga. Vikipēdija sniedz tulkojums "vairāku Ä«re, daudzkārtēja Ä«re." To dažreiz sauc par "vairākām Ä«paÅ”umtiesÄ«bām". Å ie termini var bÅ«t zināmā mērā mulsinoÅ”i, jo priekÅ”mets pēc bÅ«tÄ«bas nav saistÄ«ts ne ar Ä«ri, ne ar Ä«paÅ”umtiesÄ«bām. Tas ir programmatÅ«ras arhitektÅ«ras un tās darbÄ«bas organizācijas jautājums. Un pēdējais ir ne mazāk svarÄ«gs.

Mēs sākām formulēt savu izpratni par vairāku Ä«ri, tajā paŔā laikā, kad sākām izstrādāt pieeju mākoņa (pakalpojuma) darba modelim programmā 1C:Enterprise. Tas bija pirms vairākiem gadiem. KopÅ” tā laika mÅ«su izpratne ir nepārtraukti paplaÅ”inājusies. Mēs pastāvÄ«gi atklājam arvien jaunus Ŕīs tēmas aspektus (plusus, mÄ«nusus, grÅ«tÄ«bas, iezÄ«mes utt.).

Par vairāku īri

Dažkārt izstrādātāji saprot vairāku Ä«ri kā ļoti vienkārÅ”u priekÅ”metu: "lai vairāku organizāciju dati tiktu glabāti vienā datu bāzē, visām tabulām jāpievieno kolonna ar organizācijas identifikatoru un jāiestata tajā filtrs." No Ŕī brīža mēs, protams, arÄ« sākām Ŕī jautājuma izpēti. Bet viņi ātri saprata, ka tas ir tikai viens izcirtums (arÄ«, starp citu, nav viegli). Kopumā Ŕī ir ā€œvisa valstsā€.

DaudzdzÄ«vokļu pamatideju var raksturot apmēram Ŕādi. Tipisks pielietojums ir kotedža, kas paredzēta vienai Ä£imenei, kas izmanto savu infrastruktÅ«ru (sienas, jumts, Å«densapgāde, apkure utt.). DaudzdzÄ«vokļu ēka ir daudzdzÄ«vokļu ēka. Tajā katra Ä£imene izmanto vienu un to paÅ”u infrastruktÅ«ru, bet pati infrastruktÅ«ra ir ieviesta visai mājai.

Vai daudzdzÄ«vokļu pieeja ir laba vai slikta? Par to var atrast ļoti dažādus viedokļus. Å Ä·iet, ka vispār nav ā€œlaba vai sliktaā€. Ir jāsalÄ«dzina plusi un mÄ«nusi konkrēto risināmo uzdevumu kontekstā. Bet tā ir atseviŔķa tēma...

Tās vienkārŔākajā nozÄ«mē vairāku Ä«rēju mērÄ·is ir samazināt lietojumprogrammas uzturÄ“Å”anas izmaksas, ā€œsocializējotā€ infrastruktÅ«ras izmaksas. Å Ä« ir tāda pati kustÄ«ba kā lietojumprogrammas izmaksu samazināŔana, izmantojot ražoÅ”anas risinājumu (iespējams, ar pielāgoÅ”anu un modifikācijām), nevis rakstot to ā€œpēc pasÅ«tÄ«jumaā€. Tikai vienā gadÄ«jumā attÄ«stÄ«ba tiek socializēta, bet otrā - ekspluatācija.

Turklāt mēs atkārtojam, ka nav tieÅ”as saiknes ar pārdoÅ”anas metodi. Vairāku Ä«res arhitektÅ«ru var izmantot arÄ« korporatÄ«vā vai departamenta IT infrastruktÅ«rā, lai automatizētu lielu skaitu lÄ«dzÄ«gu filiāļu un holdinga uzņēmumu.

Mēs varam teikt, ka vairāku Ä«ri nav tikai datu uzglabāŔanas organizÄ“Å”anas jautājums. Å is ir modelis, kas parāda, kā lietojumprogramma darbojas kopumā (ieskaitot ievērojamu tās arhitektÅ«ras daļu, izvietoÅ”anas modeli un uzturÄ“Å”anas organizāciju).

Sarežģītākā un interesantākā lieta vairāku Ä«res modelÄ«, mums Ŕķiet, ir tā, ka lietojumprogrammas bÅ«tÄ«ba ā€œsadalÄ«tiesā€. Daļa funkcionalitātes darbojas ar konkrētām datu zonām (dzÄ«vokļiem) un ā€œneinteresēā€ par to, ka citos dzÄ«vokļos ir iedzÄ«votāji. Un daži uztver māju kopumā un strādā visiem iedzÄ«votājiem uzreiz. Tajā paŔā laikā pēdējie nevar ignorēt faktu, ka tie galu galā ir atseviŔķi dzÄ«vokļi, un ir nepiecieÅ”ams nodroÅ”ināt nepiecieÅ”amo precizitātes un droŔības lÄ«meni.

Programmā 1C:Enterprise vairāku Ä«rēju modelis ir ieviests vairāku tehnoloÄ£iju lÄ«menÄ«. Å ie ir platformas 1C:Enterprise mehānismi, mehānismi1C: tehnoloÄ£iju publicÄ“Å”anas risinājumi 1cFresh"Un"1C: Risinājumu izstrādes tehnoloÄ£ija 1cFresh", mehānismi BSP (standarta apakÅ”sistēmu bibliotēkas).

Katrs no Å”iem posteņiem veicina daudzdzÄ«vokļu mājas kopējās infrastruktÅ«ras izbÅ«vi. Kāpēc tas tiek ieviests vairākās tehnoloÄ£ijās, nevis vienā, piemēram, platformā? Pirmkārt, tāpēc, ka daži mehānismi, mÅ«suprāt, ir diezgan piemēroti, lai tos pārveidotu konkrētai izvietoÅ”anas iespējai. Bet kopumā tas ir sarežģīts jautājums, un mēs pastāvÄ«gi saskaramies ar izvēli - kādā lÄ«menÄ« ir labāk Ä«stenot Å”o vai citu vairāku Ä«res aspektu.

AcÄ«mredzot platformā bija jāievieÅ” mehānismu pamata daļa. Nu, piemēram, faktiskā datu atdalÄ«Å”ana. Å eit cilvēki parasti sāk runāt par vairāku Ä«ri. Bet galu galā vairāku Ä«res modelis ā€œizceļojaā€ cauri nozÄ«mÄ«gai platformas mehānismu daļai un prasÄ«ja to pilnveidoÅ”anu un dažos gadÄ«jumos arÄ« pārdomāŔanu.

Platformas lÄ«menÄ« mēs ieviesām tieÅ”i pamata mehānismus. Tie ļauj izveidot lietojumprogrammas, kas darbojas vairāku nomas modeli. Bet, lai lietojumprogrammas "dzÄ«votu un strādātu" Ŕādā modelÄ«, jums ir jābÅ«t sistēmai viņu "dzÄ«ves aktivitāŔu" pārvaldÄ«bai. Par to ir atbildÄ«gas 1cFresh tehnoloÄ£ijas un vienots biznesa loÄ£ikas slānis BSP lÄ«menÄ«. Tāpat kā daudzdzÄ«vokļu mājā infrastruktÅ«ra nodroÅ”ina iedzÄ«votājus ar visu nepiecieÅ”amo, tā arÄ« 1cFresh tehnoloÄ£ijas nodroÅ”ina visu nepiecieÅ”amo aplikācijām, kas darbojas vairāku māju Ä«res modelÄ«. Un, lai lietojumprogrammas varētu mijiedarboties ar Å”o infrastruktÅ«ru (bez bÅ«tiskām modifikācijām), attiecÄ«gie "savienotāji" tiek ievietoti BSP apakÅ”sistēmu veidā.

No platformas mehānismu viedokļa ir viegli pamanÄ«t, ka, gÅ«stot pieredzi un attÄ«stot mākoņa lietoÅ”anas gadÄ«jumu ā€œ1C:Enterpriseā€, mēs paplaÅ”inām Å”ajā arhitektÅ«rā iesaistÄ«to mehānismu sastāvu. Sniegsim vienu piemēru. Vairāku Ä«res modeli ietvaros aplikāciju servisa dalÄ«bnieku lomas bÅ«tiski mainās. Ievērojami palielinās to personu loma (atbildÄ«bas lÄ«menis), kuras ir atbildÄ«gas par lietojumprogrammu darbÄ«bu. Viņiem kļuva nepiecieÅ”ami jaudÄ«gāki lietojumprogrammu kontroles rÄ«ki. Tā kā lietojumprogrammu lietotāji (rezidenti) vispirms uzticas pakalpojumu sniedzējam, ar kuru viņi strādā. Lai to izdarÄ«tu, mēs ieviesām jaunu droŔības profila mehānisms. Å is mehānisms ļauj pakalpojumu sniedzēju administratoriem ierobežot lietojumprogrammu izstrādātāju brÄ«vÄ«bu lÄ«dz vajadzÄ«gajam droŔības lÄ«menim - bÅ«tÄ«bā izolēt lietojumprogrammas darbÄ«bu katram nomniekam noteiktā smilÅ”u kastē.

Ne mazāk interesanta ir vairāku Ä«res režīmā strādājoÅ”u lietojumprogrammu pārvaldÄ«bas arhitektÅ«ra (kas tiek ieviesta 1cFresh un BSP tehnoloÄ£ijās). Å eit, salÄ«dzinot ar parasto izvietoÅ”anas modeli, prasÄ«bas vadÄ«bas procesu automatizācijai ir ievērojami paaugstinātas. Šādu procesu ir desmitiem: jaunu datu apgabalu (ā€œdzÄ«vokļuā€) izveide, aplikāciju atjaunināŔana, normatÄ«vās informācijas atjaunināŔana, dublējumkopijas utt. Un, protams, pieaug prasÄ«bas attiecÄ«bā uz uzticamÄ«bas un pieejamÄ«bas lÄ«meni. Piemēram, lai nodroÅ”inātu uzticamu mijiedarbÄ«bu starp lietojumprogrammām un vadÄ«bas sistēmas komponentiem, mēs ieviesām asinhrono zvanu sistēmas tehnoloÄ£iju ar garantētu piegādi.

Ä»oti smalks punkts ir datu un procesu socializācijas veids. Tas Ŕķiet vienkārÅ”i (ja kādam Ŕķiet) tikai no pirmā acu uzmetiena. Lielākais izaicinājums ir lÄ«dzsvars starp datu un procesu centralizāciju un decentralizāciju. No vienas puses, centralizācija ļauj samazināt izmaksas (diska vieta, procesora resursi, administratora pÅ«les...). No otras puses, tas ierobežo ā€œÄ«rniekuā€ brÄ«vÄ«bu. Tas ir tieÅ”i viens no aplikācijas ā€œbifurkācijasā€ brīžiem, kad izstrādātājam vienlaicÄ«gi jādomā par aplikāciju Å”aurā nozÄ«mē (apkalpojot vienu ā€œdzÄ«vokliā€) un plaŔā nozÄ«mē (apkalpojot visus ā€œÄ«rniekusā€ vienlaikus) .

Kā Ŕādas ā€œdilemmasā€ piemēru var minēt normatÄ«vo un atsauces informāciju. Protams, ir liels kārdinājums padarÄ«t to kopÄ«gu visiem mājas ā€œÄ«rniekiemā€. Tas ļauj to saglabāt vienā eksemplārā un atjaunināt visiem vienlaikus. Bet gadās, ka dažiem iedzÄ«votājiem nepiecieÅ”amas konkrētas izmaiņas. Savādi, bet praksē tas notiek pat attiecÄ«bā uz informāciju, ko nosaka regulatori (valdÄ«bas iestādes). Tas izrādās grÅ«ts jautājums: socializēties vai nesocializēties? Protams, ir vilinoÅ”i padarÄ«t informāciju vispārÄ«gu visiem un privātu tiem, kas to vēlas. Un tas jau noved pie ļoti sarežģītas Ä«stenoÅ”anas. Bet mēs strādājam pie Ŕī...

Vēl viens piemērs ir regulāru procesu ievieÅ”anas projektÄ“Å”ana (tiek izpildÄ«ta pēc grafika, iniciēta ar kontroles sistēmu utt.). No vienas puses, tos var ieviest katram datu apgabalam atseviŔķi. Tas ir vienkārŔāk un ērtāk. Bet, no otras puses, Ŕāda smalka precizitāte rada lielu slodzi sistēmai. Lai samazinātu slodzi, jāievieÅ” socializēti procesi. Bet tie prasa rÅ«pÄ«gāku izpēti.

Protams, tas rada ļoti nozÄ«mÄ«gu jautājumu. Kā lietojumprogrammu izstrādātāji var nodroÅ”ināt vairāku Ä«ri? Kas viņiem Å”ajā nolÅ«kā jādara? Protams, mēs cenÅ”amies panākt, lai tehnoloÄ£isko un infrastruktÅ«ras jautājumu nasta pēc iespējas vairāk gulstas uz piegādātās tehnoloÄ£ijas pleciem, un lietojumprogrammu izstrādātājs domā tikai par biznesa loÄ£ikas uzdevumiem. Taču, tāpat kā ar citiem svarÄ«giem arhitektÅ«ras jautājumiem, lietojumprogrammu izstrādātājiem ir jābÅ«t zināmai izpratnei par darbu vairāku Ä«res modeli, un, izstrādājot lietojumprogrammas, bÅ«s jāpieliek pÅ«les. Kāpēc? Jo ir punkti, kurus tehnoloÄ£ija nevar nodroÅ”ināt automātiski, neņemot vērā datu semantiku. Piemēram, tā pati informācijas socializācijas robežu definÄ«cija. Taču mēs cenÅ”amies, lai Ŕīs grÅ«tÄ«bas bÅ«tu mazas. Šādu lietojumprogrammu ievieÅ”anas piemēri jau ir.

SvarÄ«gs punkts saistÄ«bā ar vairāku Ä«res iespēju ievieÅ”anu 1C: Enterprise ir tas, ka mēs veidojam hibrÄ«da modeli, kurā viena lietojumprogramma var darboties gan vairāku Ä«res režīmā, gan parastajā režīmā. Tas ir ļoti grÅ«ts uzdevums un ir atseviŔķas diskusijas priekÅ”mets.

Avots: www.habr.com

Pievieno komentāru