Kwa bahati mbaya, neno hili halina mwenza mzuri wa lugha ya Kirusi. Wikipedia inatoa "kukodisha nyingi, kukodisha nyingi". Hii wakati mwingine hujulikana kama "umiliki mwingi". Masharti haya yanaweza kutatanisha kwa kiasi fulani, kwa kuwa mada haihusiani kimaumbile na kodi au umiliki. Hili ni swali la usanifu wa programu na shirika la uendeshaji wake. Na mwisho sio muhimu sana.
Tulianza kuunda uelewa wetu wa multitenancy wakati huo huo tulipoanza kubuni mbinu ya wingu (huduma) mfano wa 1C:Enterprise operation. Hii ilikuwa miaka kadhaa iliyopita. Na tangu wakati huo, uelewa wetu umekuwa ukipanuka kila mara. Tunazidi kugundua vipengele vipya zaidi na zaidi vya somo hili (pluses, minuses, ugumu, vipengele, nk).
Wakati mwingine watengenezaji huelewa multitenancy kama somo rahisi kabisa: "ili data ya mashirika kadhaa kuhifadhiwa katika hifadhidata moja, unahitaji kuongeza safu iliyo na kitambulisho cha shirika kwenye jedwali zote na kuweka kichujio juu yake." Kwa kweli, tulianza pia somo letu la suala hilo kutoka wakati huo. Lakini waligundua haraka kuwa hii ilikuwa kusafisha moja tu (pia, kwa njia, sio rahisi). Kwa ujumla, hii ni "nchi nzima".
Wazo la msingi la multitenancy linaweza kuelezewa kama hii. Maombi ya kawaida ni kottage ya familia moja ambayo hutumia miundombinu yake (kuta, paa, ugavi wa maji, inapokanzwa, nk). Maombi ya multitenancy ni jengo la ghorofa. Ndani yake, kila familia hutumia muundo sawa wa miundombinu, lakini miundombinu yenyewe inatekelezwa kwa nyumba nzima kwa ujumla.
Mbinu ya multitenancy ni nzuri au mbaya? Kuna maoni tofauti sana juu ya hili. Inaonekana kwamba hakuna "nzuri au mbaya" hata kidogo. Unahitaji kulinganisha faida na hasara katika muktadha wa kazi maalum za kutatuliwa. Lakini hilo ni suala tofauti ...
Kwa maana yake rahisi, lengo la multitenancy ni kupunguza gharama ya kudumisha maombi kwa "kushiriki" gharama za miundombinu. Huu ni harakati sawa na kupunguza gharama ya maombi kwa kutumia suluhisho la mzunguko (labda kwa ubinafsishaji na uboreshaji), na sio kuandika "kuagiza". Katika hali moja tu, maendeleo yanajumuishwa katika jamii, na kwa upande mwingine - unyonyaji.
Na, tunarudia, hakuna kiungo cha moja kwa moja kwa njia ya kuuza. Usanifu wa multitenancy pia unaweza kutumika katika miundombinu ya IT ya shirika au ya idara ili kuorodhesha idadi kubwa ya matawi ya aina moja, inayoshikilia biashara.
Tunaweza kusema kwamba multitenancy sio tu suala la kuandaa hifadhi ya data. Huu ni mfano wa programu nzima (ikiwa ni pamoja na sehemu muhimu ya vipengele vya usanifu wake, na mfano wa kupeleka, na shirika la huduma).
Jambo gumu zaidi na la kuvutia juu ya mfano wa multitenancy, inaonekana kwetu, ni kwamba kiini cha maombi ni "uma". Sehemu ya utendaji inafanya kazi na maeneo maalum ya data (vyumba) na "haina nia" kwa ukweli kwamba kuna wapangaji katika vyumba vingine. Na wengine wanaona nyumba kwa ujumla na hufanya kazi mara moja kwa wakaazi wote. Wakati huo huo, mwisho huo hauwezi kupuuza ukweli kwamba hizi bado ni vyumba tofauti, na ni muhimu kuhakikisha kiwango cha lazima cha granularity na usalama.
Katika 1C: Biashara, mfano wa multitenancy unatekelezwa kwa kiwango cha teknolojia kadhaa. Hizi ndizo mifumo ya 1C: Jukwaa la Biashara, mifumo"Na"β, taratibu (maktaba za mifumo midogo ya kawaida).
Kila moja ya vitu hivi huchangia ujenzi wa miundombinu ya jumla ya jengo la ghorofa. Kwa nini hii inatekelezwa katika teknolojia kadhaa, na sio moja, kwa mfano, kwenye jukwaa? Kwanza kabisa, kwa sababu, kwa maoni yetu, ni sahihi kabisa kurekebisha baadhi ya taratibu za chaguo maalum la kupeleka. Lakini kwa ujumla, hili sio swali rahisi, na tunakabiliwa na chaguo kila wakati - kwa kiwango gani ni bora kutekeleza kipengele kimoja au kingine cha multitenancy.
Ni wazi, sehemu ya msingi ya taratibu zinazohitajika kutekelezwa katika jukwaa. Naam, kwa mfano, mgawanyo halisi wa data. Nini kawaida huanza mazungumzo kuhusu multitenancy. Lakini mwisho, mtindo wa multitenancy "ulisafiri" kupitia sehemu kubwa ya mifumo ya jukwaa na kuhitaji uboreshaji wao, na katika hali zingine, kufikiria tena.
Katika ngazi ya jukwaa, tulitekeleza taratibu za kimsingi. Wanakuruhusu kuunda programu zinazofanya kazi katika mfano wa multitenancy. Lakini kwa maombi "kuishi na kufanya kazi" katika mfano kama huo, unahitaji kuwa na mfumo wa kusimamia "shughuli zao za maisha". 1cteknolojia mpya na safu iliyounganishwa ya mantiki ya biashara katika kiwango cha BSP inawajibika kwa hili. Kama ilivyo katika jengo la ghorofa, miundombinu huwapa wakazi kila kitu wanachohitaji, kwa hivyo teknolojia za 1cFresh hutoa kila kitu muhimu kwa programu zinazoendeshwa kwa mtindo wa multitenancy. Na ili programu ziweze kuingiliana na miundombinu hii (bila marekebisho makubwa), "viunganisho" vinavyofanana vimewekwa ndani yao kwa namna ya mfumo mdogo wa BSP.
Kwa upande wa mifumo ya majukwaa, ni rahisi kuona kwamba tunapopata uzoefu na kuendeleza wingu 1C:Kesi ya utumiaji ya Biashara, tunapanua orodha ya mbinu zinazohusika katika usanifu huu. Hebu tuchukue mfano mmoja. Katika mfano wa multitenancy, majukumu ya washiriki wa huduma ya maombi hubadilika sana. Jukumu (kiwango cha uwajibikaji) la wale wanaohusika na uendeshaji wa maombi huongezeka kwa kiasi kikubwa. Ikawa muhimu kwao kuwa na zana zenye nguvu zaidi za udhibiti wa programu. Kwa sababu watumiaji wa programu (wakazi) wanamwamini kwanza mtoa huduma ambaye wanafanya kazi naye. Ili kufanya hivyo, tulitekeleza toleo jipya la 8.3 . Utaratibu huu unaruhusu wasimamizi wa watoa huduma kupunguza uhuru wa wasanidi programu kwa kiwango muhimu cha usalama - kwa kweli, kutenganisha utendakazi wa maombi kwa kila mpangaji ndani ya sanduku fulani la mchanga.
Sio chini ya kuvutia ni usanifu wa kusimamia programu zinazofanya kazi katika hali ya multitenancy (kile kinachotekelezwa katika teknolojia ya 1cFresh na BSP). Hapa, kwa kulinganisha na mfano wa kawaida wa kupeleka, mahitaji ya automatisering ya michakato ya usimamizi yanaongezeka kwa kiasi kikubwa. Kuna kadhaa ya michakato kama hii: kuunda maeneo mapya ya data ("vyumba"), kusasisha programu, kusasisha habari ya udhibiti, chelezo, nk. Na, kwa kweli, mahitaji ya kiwango cha kuegemea na upatikanaji yanaongezeka. Kwa mfano, ili kuhakikisha mwingiliano wa kuaminika kati ya programu na vipengele vya mfumo wa kudhibiti, tulitekeleza teknolojia ya mfumo wa simu usio na usawa na uwasilishaji wa uhakika.
Jambo la hila ni jinsi data na michakato inavyoshirikiwa. Inaonekana rahisi (ikiwa inaonekana kwa mtu) tu kwa mtazamo wa kwanza. Ugumu mkubwa zaidi ni usawa kati ya uwekaji data na michakato na ugatuaji. Kwa upande mmoja, centralization inakuwezesha kupunguza gharama (nafasi ya disk, rasilimali za processor, jitihada za msimamizi ...). Kwa upande mwingine, inazuia uhuru wa "wakazi". Hii ni moja tu ya wakati wa "bifurcation" ya programu, wakati msanidi programu anahitaji kufikiria wakati huo huo juu ya programu kwa maana nyembamba (kutumikia "ghorofa moja") na kwa maana pana (kutumikia " wapangaji" mara moja).
Kama mfano wa "shida" kama hiyo, habari ya kumbukumbu inaweza kutajwa. Bila shaka, kuna jaribu kubwa la kuifanya kawaida kwa "wakazi" wote wa nyumba. Hii hukuruhusu kuihifadhi katika nakala moja, na kuisasisha kwa kila mtu mara moja. Lakini hutokea kwamba mpangaji fulani anahitaji mabadiliko maalum. Oddly kutosha, lakini katika mazoezi hii hutokea, hata kwa taarifa ambayo ni maalum na wasimamizi (miili ya serikali). Inageuka swali gumu: kujumuika au kutojumuika? Inajaribu, kwa kweli, kutoa habari ya jumla kwa kila mtu na ya faragha kwa wale wanaotaka. Na hii tayari inasababisha utekelezaji mgumu sana. Lakini tunalifanyia kazi...
Mfano mwingine ni mpango wa utekelezaji wa taratibu za kawaida (kukimbia kwa ratiba, iliyoanzishwa na mfumo wa udhibiti, nk). Kwa upande mmoja, zinaweza kutekelezwa kwa kila eneo la data tofauti. Ni rahisi na rahisi zaidi. Lakini, kwa upande mwingine, granularity nzuri kama hiyo inaunda mzigo mkubwa kwenye mfumo. Ili kupunguza mzigo, ni muhimu kutekeleza michakato ya kijamii. Lakini zinahitaji kusoma kwa uangalifu zaidi.
Bila shaka, hii inazua swali muhimu sana. Na watengenezaji wa programu wanawezaje kuhakikisha kuwa wanafanya kazi katika hali ya utenaji mwingi? Je, wanahitaji kufanya nini kwa hili? Bila shaka, tunajitahidi kuhakikisha kwamba mzigo wa masuala ya teknolojia na miundombinu unaanguka kwenye mabega ya teknolojia iliyotolewa iwezekanavyo, na msanidi programu anafikiri tu katika kazi za mantiki ya biashara. Lakini kama ilivyo kwa masuala mengine muhimu ya usanifu, watengenezaji wa programu wanahitaji kuwa na uelewa fulani wa kufanya kazi katika mtindo wa multitenancy na jitihada fulani katika maendeleo ya maombi itahitajika. Kwa nini? Kwa sababu kuna nyakati ambazo teknolojia haiwezi kutoa kiotomatiki bila kuzingatia semantiki za data. Kwa mfano, ufafanuzi sawa wa mipaka ya ujamaa wa habari. Lakini tunajaribu kuweka shida hizi ndogo. Mifano ya utekelezaji wa maombi hayo tayari ipo.
Jambo muhimu katika muktadha wa utekelezaji wa multitenancy katika 1C:Enterprise ni kwamba tunaunda muundo wa mseto ambao programu moja inaweza kufanya kazi katika hali ya multitenancy na katika hali ya kawaida. Hii ni kazi ngumu sana na mada ya majadiliano tofauti.
Chanzo: mapenzi.com