Нажаль, у гэтага тэрміна няма добрага рускамоўнага аналогу. «Вікіпедыя» дае "мультыярэнднасць, множная арэнда". Часам гэта называюць "множным уладаннем". Гэтыя тэрміны могуць некалькі блытаць, бо прадмет не злучаны па ісце ні з арэндай, ні з валоданнем. Гэтае пытанне менавіта архітэктуры праграмнага забеспячэння і арганізацыі яго эксплуатацыі. Прычым апошняе не менш важнае.
Мы пачалі фармаваць наша разуменне multitenancy адначасова з тым, як пачалі праектаваць падыход да хмарнай (сэрвіснай) мадэлі працы «1С:Прадпрыемствы». Гэта было некалькі гадоў таму. І з таго часу нашае разуменне ўвесь час пашыраецца. Мы ўвесь час выяўляем у гэтага прадмета ўсё новыя і новыя аспекты (плюсы, мінусы, складанасці, асаблівасці і да т.п.).
Часам распрацоўнікі разумеюць пад multitenancy суцэль просты прадмет: "каб дадзеныя некалькіх арганізацый захоўваліся ў адной базе, трэба дадаць ва ўсе табліцы калонку з ідэнтыфікатарам арганізацыі і ўсталяваць па ёй фільтр". Мы таксама, канешне, пачалі сваю прапрацоўку пытання з гэтага моманту. Але дастаткова хутка зразумелі, што гэта толькі адна палянка (таксама, дарэчы, няпростая). А ўвогуле гэта «цэлая краіна».
Асноўную ідэю multitenancy можна апісаць прыкладна так. Звычайнае прыкладанне - гэта катэдж, разлічаны на пражыванне адной сям'і, якая карыстаецца яго інфраструктурай (сцены, дах, водазабеспячэнне, ацяпленне і да т.п.). А multitenancy-дадатак - гэта шматкватэрны дом. У ім кожная сям'я карыстаецца такім жа складам інфраструктуры, але сама інфраструктура рэалізавана для ўсёй хаты цалкам.
А падыход multitenancy - гэта добра ці дрэнна? На гэта можна знайсці вельмі розныя меркаванні. Уяўляецца, што няма "добра ці дрэнна" наогул. Параўноўваць трэба плюсы і мінусы ў кантэксце канкрэтных развязальных задач. Але гэта асобная тэма…
У найпростым разуменні мэта multitenancy – знізіць выдаткі на падтрыманне дадатку за кошт «абагульнення» выдаткаў на інфраструктуру. Гэта такі ж рух, як зніжэнне кошту дадатку за кошт прымянення тыражнага рашэння (магчыма, з настройкай і дапрацоўкай), а не напісанне «пад замову». Толькі ў адным выпадку абагульняецца распрацоўка, а ў іншым - эксплуатацыя.
Прычым, паўторымся, тут няма прамой завязкі на спосаб продажу. Архітэктура multitenancy можа цалкам прымяняцца і ў карпаратыўнай або ведамаснай IT-інфраструктуры для аўтаматызацыі вялікай колькасці аднатыпных філіялаў, прадпрыемстваў холдынгу.
Можна сказаць, што multitenancy - гэта не проста пытанне арганізацыі захоўвання дадзеных. Гэта мадэль працы прыкладання цалкам (уключаючы і істотную частку аспектаў яго архітэктуры, і мадэль разгортвання, і арганізацыю абслугоўвання).
Самае складанае і цікавае ў мадэлі multitenancy як нам здаецца, што сутнасць прыкладання "раздвойваецца". Частка функцыянальнасці працуе з канкрэтнымі абласцямі дадзеных (кватэрамі) і "не цікавіцца" тым, што ёсць жыхары ў іншых кватэрах. А частка ўспрымае хату цалкам і працуе адразу для ўсіх жыхароў. Пры гэтым апошняя не можа абстрагавацца ад таго, што ўсё ж такі гэта асобныя кватэры, і трэба забяспечваць неабходны ўзровень гранулярнасці і бяспекі.
У "1С:Прадпрыемстве" мадэль multitenancy рэалізуецца на ўзроўні некалькіх тэхналогій. Гэта механізмы платформы "1С:Прадпрыемствы", механізмы»І«», механізмы (бібліятэкі стандартных падсістэм).
Кожны з гэтых прадметаў уносіць свой уклад у пабудову агульнай інфраструктуры шматкватэрнага дома. Чаму гэта рэалізуецца ў некалькіх тэхналогіях, а не ў адной, напрыклад, у платформе? Першым чынам таму, што частка механізмаў, па нашым меркаванні, суцэль дарэчы мадыфікаваць пры пэўным варыянце разгортвання. Але ў агульным выглядзе гэта няпростае пытанне, і мы ўвесь час становімся перад выбарам - на якім узроўні лепш рэалізоўваць той ці іншы аспект multitenancy.
Відавочна, што базавую частку механізмаў патрабавалася рэалізаваць у платформе. Ну, напрыклад, уласна падзел дадзеных. Тое, з чаго звычайна пачынаюць размову пра multitenancy. Але ў выніку мадэль multitenancy праехалася па істотнай частцы механізмаў платформы і запатрабавала іх дапрацоўкі, а ў некаторых выпадках і пераасэнсаванні.
На ўзроўні платформы мы рэалізавалі менавіта базавыя механізмы. Яны дазваляюць ствараць прыкладанні, якія працуюць у мадэлі multitenancy. Але каб прыкладанні "жылі і працавалі" у такой мадэлі, трэба мець сістэму кіравання іх "жыццядзейнасцю". За гэта адказваюць тэхналогіі 1cFresh і ўніфікаваны пласт бізнэс-логікі на ўзроўні БСП. Гэтак жа як у шматкватэрным доме інфраструктура забяспечвае жыхароў усім неабходным, так і тэхналогіі 1cFresh забяспечваюць усім неабходным прыкладанні, якія працуюць у multitenancy мадэлі. А каб прыкладанні маглі ўзаемадзейнічаць з гэтай інфраструктурай (без істотных дапрацовак), у іх змяшчаюцца адпаведныя «раздымы» у выглядзе падсістэм БСП.
З пункту гледжання механізмаў платформы лёгка заўважыць, што па меры атрымання досведу і развіцці хмарнага варыянту выкарыстання "1С:Прадпрыемствы" мы пашыраем склад механізмаў, якія ўцягнутыя ў гэтую архітэктуру. Прывядзем адзін прыклад. У мадэлі multitenancy істотна мяняецца расстаноўка роляў удзельнікаў абслугоўвання прыкладанняў. Істотна павялічваецца роля (узровень адказнасці) тых, хто адказвае за эксплуатацыю прыкладанняў. Ім стала неабходна мець больш магутныя інструменты кантролю дадаткаў. Таму што карыстачы прыкладанняў (жыхары) давяраюць першым чынам правайдэру, з якім яны працуюць. Для гэтага мы рэалізавалі ў версіі 8.3 новы . Гэты механізм дазваляе адміністратарам правайдэра абмежаваць свабоду распрацоўшчыкаў прыкладанняў неабходным узроўнем бяспекі - па сутнасці, ізаляваць працу прыкладання для кожнага жыхара ў пэўных рамках «пясочніцы» (sandbox).
Ані не меншую цікавасць уяўляе сабой архітэктура для кіравання прыкладаннямі, якія працуюць у рэжыме multitenancy (тое, што рэалізуецца ў тэхналогіях 1cFresh і БСП). Тут, у параўнанні са звычайнай мадэллю разгортвання, істотна павялічваюцца патрабаванні да аўтаматызацыі працэсаў кіравання. Такіх працэсаў дзясяткі: стварэнне новых абласцей дадзеных («кватэр»), абнаўленне прыкладанняў, абнаўленне нарматыўнай інфармацыі, рэзервовае капіраванне і г. д. І, вядома, узрастаюць патрабаванні да ўзроўню надзейнасці і даступнасці. Напрыклад, для забеспячэння надзейнага ўзаемадзеяння дадаткаў з кампанентамі сістэмы кіравання мы рэалізавалі тэхналогію асінхроннай сістэмы выклікаў з гарантаванай дастаўкай.
Вельмі тонкім момантам з'яўляецца спосаб абагульнення звестак і працэсаў. Простым гэта здаецца (калі камусьці здаецца) толькі на першы погляд. Найбольшую складанасць уяўляе баланс паміж цэнтралізацыяй дадзеных і працэсаў і дэцэнтралізацыяй. З аднаго боку, цэнтралізацыя дазваляе зменшыць выдаткі (дыскавай прасторы, рэсурсаў працэсара, намаганняў адміністратараў…). З іншага боку, абмяжоўвае свабоду "жыхароў". Гэта як раз адзін з момантаў «раздвойвання» прыкладанні, калі распрацоўніку трэба думаць адначасова пра прыкладанне ў вузкім сэнсе (абслугоўваючае адну «кватэру») і ў шырокім сэнсе (абслугоўваючае адразу ўсіх «жыльцоў»).
Як прыклад такой "дылемы" можна прывесці нарматыўна-даведачную інфармацыю. Зразумела, вялікая спакуса зрабіць яе агульнай для ўсіх "жыхароў" дома. Гэта дазваляе і захоўваць яе ў адным экзэмпляры, і абнаўляць адразу для ўсіх. Але бывае так, што нейкаму жыльцу неабходны спецыфічныя змены. Як ні дзіўна, але на практыцы гэта сустракаецца, нават для інфармацыі, якая спецыфікавана рэгулятарамі (дзяржаўнымі органамі). Атрымліваецца няпростае пытанне: абагульняць ці не абагульняць? Павабна, вядома, зрабіць агульную інфармацыю для ўсіх і прыватную для ахвочых. А гэта ўжо вядзе да зусім няпростай рэалізацыі. Але над гэтым мы працуем…
Яшчэ адным прыкладам з'яўляецца праектаванне рэалізацыі рэгулярных працэсаў (выкананых па раскладзе, якія ініцыююцца кіравальнай сістэмай і да т.п.). З аднаго боку, іх можна рэалізаваць для кожнай вобласці дадзеных асобна. Гэта прасцей і зручней. Але, з іншага боку, такая дробная гранулярнасць стварае вялікую нагрузку на сістэму. Каб зменшыць нагрузку, трэба рэалізоўваць абагульненыя працэсы. Але яны патрабуюць больш стараннай прапрацоўкі.
Зразумела, напрошваецца вельмі істотнае пытанне. А як распрацоўшчыкам дадаткаў забяспечыць працу ў рэжыме multitenancy? Што ім трэба для гэтага рабіць? Вядома, мы імкнемся да таго, каб цяжар тэхналагічных і інфраструктурных пытанняў максімальна клалася на плечы пастаўляемай тэхналогіі, а распрацоўшчык прыкладання думаў бы толькі ў задачах бізнес-логікі. Але як і з іншымі важнымі архітэктурнымі пытаннямі, нейкае ўяўленне аб працы ў мадэлі multitenancy распрацоўнікам прыкладанняў мець трэба і нейкія намаганні пры распрацоўцы прыкладанняў запатрабуюцца. Чаму? Таму што ёсць моманты, якія тэхналогія не можа забяспечыць аўтаматычна без уліку семантыкі даных. Напрыклад, тое ж вызначэнне межаў абагульнення інфармацыі. Але мы імкнемся, каб гэтыя складанасці былі невялікімі. Прыклады рэалізацыі такіх дадаткаў ужо ёсць.
Важным момантам у кантэксце рэалізацыі multitenancy у "1С:Прадпрыемстве" з'яўляецца тое, што мы ствараем гібрыдную мадэль, у якой адно прыкладанне можа працаваць і ў рэжыме multitenancy, і ў звычайным рэжыме. Гэта вельмі няпростая задача і прадмет асобнага абмеркавання.
Крыніца: habr.com