Ցավոք, այս տերմինի համար չկա լավ հայերեն համապատասխանություն։ «Վիքիպեդիան» տալիս է «մուլտիարենդում, բազմակի аренда»։ Иногда это называют «множественным владением». Эти термины могут несколько путать, так как предмет не связан по сути ни с арендой, ни с владением. Это вопрос именно архитектуры программного обеспечения и организации его эксплуатации. Причем последнее не менее важно.
Մենք սկսել ենք ձևավորել մեր ընկալումը multitenancy-ի շուրջ միաժամանակ, երբ սկսել ենք նախագծել մեր մոտեցումը «1С:Предприятия»-ի գրուպային (սերվիսային) մոդելի համար։ Դա եղել է մի քանի տարի առաջ։ Եվ այդ ժամանակ մեր ընկալումը անընդհատ ընդլայնվում է։ Մենք մշտապես հայտնաբերել ենք այս թեմայի շուրջ նոր և նոր ասպեկտներ (լավություններ, վատությունները, դժվարությունները, առանձնահատկությունները և այլն)
Որոշ դեպքերում մշակողների համար multitenancy-ը պարզապես հասկացություն է, որը նշանակում է, որ «անձ բազայում պետք է պահվի միաժամանակ մի քանի կազմակերպությունների տվյալներ, և դրա համար բոլոր աղոթներում պետք է ավելացնել կազմակերպության նույնականացման համարանիշի սյունակ և դա որպես ֆիլտր օգտագործել»։ Մենք նույնպես, իհարկե, սկսել ենք մեր հետազոտությունը այս հարցում հենց այս պահին։ Սակայն բավական արագ հասկացանք, որ սա միայն մեկ տարածք է (որը նույնպես, ի դեպ, բարդ խնդիր է)։ Իսկ ընդհանուր առմամբ այս համատեքստում դա «մեծ երկիր» է։
Multitenancy-ի հիմնական գաղափարը կարելի է նկարագրել մոտավորապես հետևյալ կերպ։ Սովորական հավելվածը՝ դա նման է մի առանձնատուն, որը նախատեսված է մեկ ընտանիքի համար, որն օգտագործում է դրա ենթակառուցվածքը (կրանը, տանիքը, ջրամատակարարումն, ջեռուցումը և այլն)։ Իսկ multitenancy-ի հավելվածը՝ դա բազմաբնակարան շենք է։ Արտաքուստ յուրաքանչյուրը ընտանիքը օգտվում է նույն ենթակառուցվածքից, բայց ինքը ենթակառուցվածքը իրականացված է ամբողջ շենքի համար։
Multitenancy-ով մոտեցումը՝ դա լավ է թե վատ։ Այս հարցում կարելի է գտնել շատ տարբեր կարծիքներ։ Երևում է, որ չկա «լավ թե վատ» անընդհատ։ անհրաժեշտ է համեմատել լավությունները և վատությունները՝ կոնկրետ լուծվող խնդիրների համատեքստում։ Բայց սա առանձին թեմա է։
Ամբողջապես պարզ հասկացողությամբ multitenancy-ի նպատակն է նվազեցնել հավելվածի աջակցման ծախսերը՝ ենթակառուցվածքի ծախսերը «համաչափելով»։ Սա նույնպիսի շարժումն է, ինչ հավելվածի արժեքի նվազեցումը՝ ստանդարտ լուծումների կիրառմամբ (ممկի, հետագա կարգավորմամբ և հետազոտությամբ), այլ ոչ թե «հատուկ»։ Մի դեպքում, հանրային է մշակումը, իսկ մյուսում՝ эксплуатацияը։
Զուգահեռ, կրկնում ենք, այստեղ չկա ուղղակի կապ վաճառքի եղանակի հետ։ Multitenancy-ի կամարը կարող է կիրառվել նաև կորպորատիվ կամ պետական IT ենթակառուցվածքում բազմաթիվ միատեսակ մասնաճյուղերի, ընկերությունների ավտոմատացման համար։
Կարելի է ասել, որ multitenancy-ն ոչ միայն տվյալների պահման կազմակերպման հարց է։ Սա ողջ հավելվածի աշխատանքի մոդել է (ներառյալ դրա ճարտարապետության հիմնական ասպեկտները, իր կիրառման մոդելը և սպասարկման կազմակերպումը)։
Մոդելում multitenancy ամենադժվար և հետաքրքիր միջուկը, ինչպիսին մեզ թվframes, այն է, որ application's էությունը «երկբ začne»: Ունի ֆունկցիոնալության մասը աշխատում է տվյալների որոշակի ոլորտների (բնակարանների) հետ և «առանց հետաքրքրություն» չունի այն մասին, թե մեկ այլ բնակարանում ապրողն ով է: Իսկ մյուս մասը միտումնավոր ընկալում է տունն ամբողջությամբ և աշխատում է բոլոր բնակիչների համար: Այս դեպքում վերջինը չի կարող անտեսել այն, որ, այնուամենայնիվ, դա առանձին բնակարաններ են, և անհրաժեշտ է ապահովել անհրաժեշտ մակարդակի մանրամասնություն և անվտանգություն։
«1С:Предприятии» մոդել multitenancy իրականացվում է մի քանի տեխնոլոգիաների մակարդակում: Սա «1С:Предприятия»ի պլատֆորմայի մեխանիզմներն են, մեխանիզմներ «» և «», մեխանիզմներ (միատիպ ստանդարտ ենթահամակարգերի գրադարաններ):
Այս բոլոր առարկաները իրենց ներդրումն ունեն բազմաբնակարան տան ընդհանուր ենթակառուցվածքի կառուցման մեջ: Ինչու է դա իրականացվում մի քանի տեխնոլոգիաների մեջ, այլ ոչ թե մեկում, օրինակ, պլատֆորմում? Նախևառաջ, քանի որ մի քանի մեխանիզմները, մեր կարծիքով, լիովին արդարացված է փոփոխելու կոնկրետ ծավալման տարբերակի դեպքում: Բայց ընդհանուր տեսքով, սա բարդ հարց է, և մենք մշտապես կանգնած ենք ընտրության առաջ – կում կոնկրետ մակարդակում ավելի լավ է իրականացնել multitenancy-ի այս կամ այն կողմը:
Ավելորդ չէ նշել, որ մեխանիզմների հիմնական մասը պետք է իրականացվեր պլատֆորմայում: Օրինակ, տվյալների առանձնացումը: Դա այն բանն է, որտեղ սովորաբար սկսում է զրույցը multitenancy-ի մասին: Բայց, ի վերջո, multitenancy մոդելը «փողը» անցնում է պլատֆորմայի մի զգալի մասի մեխանիզմների, և պահանջ վերաբերում է նրանց բարելավմանը, իսկ որոշ դեպքերում անգամ վերակառուցմանը:
Պլատֆորմի մակարդակում մենք իրականացնում ենք հենց հիմնական մեխանիզմները: Այրանք թույլ են տալիս ստեղծել հավելվածներ, որոնք աշխատում են multitenancy մոդելի մեջ: Բայց որպեսզի հավելվածներն «ապրեն և աշխատեն» այդ մոդելի մեջ, պետք է ունենալ «ապրելակերպի» կառավարաման համակարգ: Դրա համար պատասխանատու են 1cFresh տեխնոլոգիաները և բանաձևի խոշորացված մակարդակը ԲСП-ի վրա: Ինչպես բազմաբնակարան տան ենթակառուցվածքը ապահովում է բնակիչներին անհրաժեշտ բոլորով, այնպես էլ 1cFresh տեխնոլոգիաները ապահովում են հավելվածները, որոնք աշխատում են multitenancy մոդելում: Եվ որպեսզի հավելվածները կարողանան փոխգործակցել այդ ենթակառուցվածքի հետ (առանց նշանակալի վերամշակման), դրանց ներգրավվում են համապատասխան «տեղերի» տեսքով ԲСП-ի ենթահամակարգեր:
Հարթակի մեխանիզմների տեսանկյունից հեշտ է նկատել, որ «1С:Предприятия» ամպային օգտագործման փորձառության և զարգացման ընթացքում մենք ընդլայնում ենք այն մեխանիզմների շարքը, որոնք ներգրավված են այս ճարտարապետությունում։ Վերին օրինակներից մի քանիսը։ Multitenancy մոդելում նշանակալիորեն փոխվում են ծրագրերի սպասարկման մասնակիցների դերերը։ Ջնջվում է նրանց պատասխանատվության մակարդակի նշանակալի աճ։ Նրանց համար անհրաժեշտ է ունենալ ավելի ուժեղ ծրագրերի վերահսկման գործիքներ։ Reason being, ծրագրերի օգտագործողները (ներ դեպքում) վստահում են նախևառաջ օգտատիրոջը, որի հետ նրանք համագործակցում են։ Դրա համար մենք իրականացնում ենք տարբերակ 8.3-ում նորը ։ Այս մեխանիզմը թույլ է տալիս պրովայդերի ադմինիսատարներին սահմանափակել ծրագրավորողների ազատությունը անհրաժեշտ անվտանգության մակարդակով՝ ըստ էության, սահմանափակել ծրագրի աշխատանքը յուրաքանչյուր ներելու համար հատուկ «փոքրիկ խոզարդներում» (sandbox)։
Առանց չափազանց հետաքրքիր է նաև multitenancy ռեժիմում գործող ծրագրերի կառավարման ճարտարապետությունը (ինչը իրականացվում է 1cFresh և ԲՍՊ տեխնոլոգիաների մեջ)։ Այստեղ, սովորական տեղակայման մեթոդի նկատմամբ, զգալիորեն բարձրանում են գործընթացների ավտոմատացման պահանջները։ Այսպիսի գործընթացներ են десятки՝ նոր տվյալների ոլորտների ստեղծում («կառուցվածքներ»), ծրագրերի թարմացում, նորմատիվ տեղեկատվության թարմացում, պահպանում և այլն։ Եվ, իհարկե, բարձրանում են վստահելիության և հասանելիության մակարդակների պահանջները։ Օրինակ, ծրագրերի և կառավարման համակարգի բաղադրիչների միջև վստահելի փոխադարձ կապ ապահովելու համար մենք իրականացնում ենք асинхронական զանգերի համակարգի տեխնոլոգիա երաշխավորված առաքմամբ։
Միայն մեկ հատված է տվյալների և գործընթացների հասարակացումը։ Դա հեշտ է թվում (եթե գոնե մեկի կարծիքով) միայն առաջին հայացքից։ Բալանսը կենտրոնացվածության և գործընթացների միջև մեծագույն բարդություն է ներկայացնում։ Որպեսզի մեկ կողմից, կենտրոնացվածությունը թույլ է տալիս նվազեցնել ծախսերը (դիսկային տարածք, պրոցեսորի ռեսուրսներ, ադմինիստրատորների ջանքերը…)։ Մյուս կողմից, սահմանափակում է «ներողներին»։ Սա հենց այն է, երբ ծրագիրը «եղծորեն» բաժանվում է, երբ ծրագրավորողը պետք է մտածի վաղեմություն ուզելու և բացահայտողները դոլарчացնել, միաժամանակ կենտրոնացնելով երկու ծրագրերի:։
Արժեքային տեղեկատվության նման «դիլեմման» օրինակ կարող է ծառայել նորմատիվ-հետազոտական տեղեկատվությունը: Իհարկե, մեծ գայթակղություն կա այն ընդհանուր անել բոլոր «բնակիչների» համար: Սա թույլ է տալիս սրբագրել այն մեկ օրինակով և թարմացնել բոլորի համար միանգամից: Բայց լինում է, որ որոշ բնակիչների հարկավոր են spesifik փոփոխություններ: Ինչպես զարմանալի է, իրականում դա հաճախ հանդիպում է, նույնիսկ այն տեղեկատվության համար, որը նախատեսված է կարգավորող մարմինների կողմից: Ստացվում է բարդ հարց. ընդհանուր դարձնել, թե ոչ? Զվարճալի է, իհարկե, ստեղծել ընդհանուր տեղեկություն բոլորի համար, և մասնավոր այն ցանկացողների համար: Բայց սա արդեն բարդ իրականացման հանգեցնելու ուղղությամբ է: Բայց մենք աշխատում ենք դրա վրա…
Մեկ այլ օրինակ է կանոնավոր գործընթացների (օրակարգով իրականացվող, կառավարող համակարգի կողմից սկսվող և այլն) իրականացման նախագծումը: Մի կողմից, դրանք կարելի է իրականացնել յուրաքանչյուր տվյալների ոլորտի համար առանձին: Սա ավելի պարզ և հարմար է: Բայց մյուս կողմից, այդպիսի մանր颗粒ություն մեծ բեռ է ստեղծում համակարգի վրա: Բեռը նվազեցնելու համար անհրաժեշտ է իրականացնել ընդհանուր գործընթացներ: Բայց դրանք պահանջում են ավելի մանրակրկիտ մշակման:
Իհարկե, կա չափազանց կարևոր հարց: Ինչպե՞ս ծրագրային մշակումների ստեղծողները ապահովեն multitenancy ռեժիմում աշխատանքի հնարավորությունը: Ի՞նչ պետք է անեն դրա համար: Բնականաբար, մենք ձգտում ենք, որ տեխնոլոգիական և ենթակառուցվածքային հարցերի ծանրությունը առավելագույնս ընկնի տրամադրված տեխնոլոգիայի վրա, իսկ ծրագրային մշակողը մտածի միայն բիզնես-լոգիկայի խնդիրների մասին: Բայց ինչպես մյուս կարևոր ճարտարագիտական հարցերում, որոշակի պատկերացում ունենալու անհրաժեշտություն կա multitenancy մոդելում ծրագրային մշակողներին, և որոշ ջանքեր ծրագրային մշակումների իրականացման գործում պահանջվում են: Ինչու՞: Որովհետև կան պահեր, որոնք տեխնոլոգիան չի կարող ինքնաբերաբար ապահովել տվյալների սեմանտիկան հաշվի առնելով: Օրինակ, նույն տեղեկության հանրայնացման սահմանների սահմանումը: Բայց մենք փորձում ենք, որ այս բարդությունները փոքր լինեն: Տիպիկ հավելվածների իրականացման օրինակներ արդեն կան:
multitenancy- ի_CONTEXT-ը «1Ս:Ծրագրավորում» իրականացման մեջ կարևոր պահերից մեկն այն է, որ մենք ստեղծում ենք հիբրիդային մոդել, որի մեջ մեկ ծրագիր կարող է աշխատել ինչպես multitenancy- ի, այնպես էլ սովորական ռեժիմում: Սա բավականին բարդ խնդիր է և անվիճելի քննարկման առարկա:
Ընտանիք: habr.com
