Sayange, istilah iki ora duwe analog basa Rusia sing apik. Wikipedia menehi "multi-tenancy, multi-tenancy." Iki kadhangkala disebut "multiple ownership." Istilah kasebut bisa uga rada mbingungake, amarga subyek kasebut ora ana hubungane karo nyewa utawa duwe. Iki minangka pitakonan babagan arsitektur piranti lunak lan organisasi operasine. Lan sing terakhir ora kurang penting.
Kita wiwit ngrumusake pemahaman kita babagan multitenancy bebarengan karo kita wiwit ngrancang pendekatan kanggo model maya (layanan) karya ing 1C: Enterprise. Iki sawetara taun kepungkur. Lan wiwit iku pangerten kita terus berkembang. Kita terus-terusan nemokake aspek anyar babagan subyek iki (pro, kontra, kesulitan, fitur, lsp).
Kadhangkala pangembang ngerti multitenancy minangka subyek sing gampang banget: "supaya data sawetara organisasi bisa disimpen ing siji database, sampeyan kudu nambah kolom karo pengenal organisasi menyang kabeh tabel lan nyetel filter ing." Kita, mesthi, uga miwiti sinau babagan masalah kasebut wiwit saiki. Nanging dheweke cepet ngerti yen iki mung siji kliring (uga, kanthi cara, ora gampang). Umumé, iki minangka "negara kabèh".
Ide dhasar saka multitenancy bisa diterangake kaya iki. Aplikasi khas yaiku pondokan sing dirancang kanggo nampung siji kulawarga, sing nggunakake infrastruktur (tembok, gendheng, sumber banyu, pemanasan, lan liya-liyane). Aplikasi multitenancy minangka bangunan apartemen. Ing kono, saben kulawarga nggunakake prasarana sing padha, nanging infrastruktur kasebut ditindakake kanggo kabeh omah.
Apa pendekatan multitenancy apik utawa ala? Sampeyan bisa nemokake panemu sing beda banget babagan iki. Kayane ora ana "apik utawa ala" babar pisan. Sampeyan kudu mbandhingake pro lan kontra ing konteks tugas tartamtu sing ditanggulangi. Nanging iki topik sing kapisah ...
Ing pangertèn sing paling gampang, tujuan multitenancy yaiku nyuda biaya njaga aplikasi kanthi "sosialisasi" biaya infrastruktur. Iki minangka gerakan sing padha karo nyuda biaya aplikasi kanthi nggunakake solusi produksi (bisa uga kanthi kustomisasi lan modifikasi), tinimbang nulis "kanggo pesenan." Mung ing siji kasus pembangunan sosialisasi, lan ing liyane - eksploitasi.
Menapa malih, kita mbaleni, ora ana link langsung menyang cara adol. Arsitektur multitenancy uga bisa digunakake ing infrastruktur IT perusahaan utawa departemen kanggo ngotomatisasi akeh cabang lan perusahaan sing padha.
Kita bisa ujar manawa multitenancy ora mung babagan ngatur panyimpenan data. Iki minangka model babagan cara aplikasi bisa digunakake kanthi wutuh (kalebu bagean penting saka arsitektur, model penyebaran, lan organisasi pangopènan).
Sing paling angel lan menarik babagan model multitenancy, misale jek kita, yaiku inti saka aplikasi "bifurcates." Bagéyan saka fungsi bisa digunakake karo wilayah data tartamtu (apartemen) lan "ora kasengsem" ing kasunyatan sing ana residents ing apartemen liyane. Lan sawetara ndeleng omah kanthi wutuh lan bisa digunakake kanggo kabeh warga bebarengan. Ing wektu sing padha, sing terakhir ora bisa nglirwakake kasunyatan manawa iki, sawise kabeh, apartemen sing kapisah, lan perlu kanggo njamin tingkat granularitas lan keamanan sing dibutuhake.
Ing 1C: Enterprise, model multitenancy dileksanakake ing tingkat sawetara teknologi. Iki minangka mekanisme saka platform 1C: Enterprise, mekanisme saka"Lan""mekanisme kab (perpustakaan subsistem standar).
Saben item kasebut nyumbang kanggo pambangunan infrastruktur sakabèhé bangunan apartemen. Yagene iki dileksanakake ing sawetara teknologi, lan ora ing siji, contone, ing platform? Kaping pisanan, amarga sawetara mekanisme, miturut pendapat kita, cukup cocog kanggo ngowahi kanggo pilihan panyebaran tartamtu. Nanging umume, iki minangka pitakonan sing angel, lan kita terus-terusan ngadhepi pilihan - ing tingkat apa luwih apik kanggo ngetrapake aspek multitenancy iki utawa kasebut.
Temenan, bagean dhasar saka mekanisme sing kudu ditindakake ing platform kasebut. Inggih, contone, pamisahan data nyata. Iki ngendi wong biasane miwiti ngomong babagan multitenancy. Nanging ing pungkasan, model multitenancy "lelungan" liwat bagean penting saka mekanisme platform lan mbutuhake refinement, lan ing sawetara kasus, rethiking.
Ing tingkat platform, kita nindakake persis mekanisme dhasar. Padha ngidini sampeyan nggawe aplikasi sing mbukak ing model multitenancy. Nanging supaya aplikasi bisa "urip lan bisa" ing model kuwi, sampeyan kudu duwe sistem kanggo ngatur "kegiatan urip". 1cTeknologi seger lan lapisan logika bisnis manunggal ing tingkat BSP tanggung jawab kanggo iki. Kaya ing bangunan apartemen, infrastruktur nyedhiyakake kabeh sing dibutuhake kanggo warga, mula teknologi 1cFresh nyedhiyakake kabeh sing dibutuhake kanggo aplikasi sing mlaku ing model multitenancy. Lan supaya aplikasi bisa sesambungan karo infrastruktur iki (tanpa modifikasi sing signifikan), "konektor" sing cocog diselehake ing wangun subsistem BSP.
Saka sudut pandang mekanisme platform, gampang dingerteni manawa nalika entuk pengalaman lan ngembangake kasus panggunaan awan "1C: Perusahaan," kita ngembangake komposisi mekanisme sing ana ing arsitektur iki. Ayo menehi conto. Ing model multitenancy, peran peserta layanan aplikasi diganti sacara signifikan. Peran (tingkat tanggung jawab) wong sing tanggung jawab kanggo ngoperasikake aplikasi mundhak sacara signifikan. Dadi kudu duwe alat kontrol aplikasi sing luwih kuat. Amarga pangguna aplikasi (penduduk) dipercaya pisanan kabeh panyedhiya sing bisa digunakake. Kanggo nindakake iki, kita dileksanakake anyar . Mekanisme iki ngidini administrator panyedhiya mbatesi kebebasan pangembang aplikasi menyang tingkat keamanan sing dibutuhake - ing intine, kanggo ngisolasi operasi aplikasi kanggo saben panyewa ing kothak wedhi tartamtu.
Ora kurang menarik yaiku arsitektur kanggo ngatur aplikasi sing beroperasi ing mode multitenancy (apa sing ditindakake ing teknologi 1cFresh lan BSP). Ing kene, dibandhingake karo model panyebaran konvensional, syarat kanggo otomatisasi proses manajemen saya tambah akeh. Ana puluhan pangolahan kasebut: nggawe wilayah data anyar ("apartemen"), nganyari aplikasi, nganyari informasi peraturan, serep, lan liya-liyane. Lan, mesthi, syarat kanggo tingkat linuwih lan kasedhiyan saya tambah. Contone, kanggo mesthekake interaksi dipercaya antarane aplikasi lan komponen sistem kontrol, kita nindakake teknologi sistem telpon bedo karo pangiriman dijamin.
Titik sing subtle banget yaiku cara sosialisasi data lan proses. Iku misale jek prasaja (yen misale jek kanggo wong) mung ing kawitan marketing. Tantangan paling gedhe yaiku keseimbangan antara sentralisasi data lan proses lan desentralisasi. Ing sisih siji, sentralisasi ngidini sampeyan nyuda biaya (ruang disk, sumber daya prosesor, upaya administrator ...). Ing sisih liya, mbatesi kebebasan "penyewa". Iki minangka salah sawijining momen "bifurkasi" aplikasi, nalika pangembang kudu mikir bebarengan babagan aplikasi ing pangertèn sing sempit (nglayani siji "apartemen") lan ing pangertèn sing wiyar (nglayani kabeh "penyewa" bebarengan) .
Minangka conto "dilema" kuwi, siji bisa nyebut informasi peraturan lan referensi. Mesthi, ana godaan gedhe kanggo nggawe umum kanggo kabeh "penyewa" omah. Iki ngidini sampeyan nyimpen ing siji salinan lan nganyari kanggo kabeh wong bebarengan. Nanging kedadeyan sawetara warga mbutuhake owah-owahan tartamtu. Anehe, ing laku iki kedadeyan, malah kanggo informasi sing ditemtokake dening regulator (badan pemerintah). Iki dadi pitakonan sing angel: sosialisasi utawa ora sosialisasi? Iku nggodho, mesthi, kanggo nggawe informasi umum kanggo kabeh wong lan pribadi kanggo sing pengin. Lan iki wis ndadékaké kanggo implementasine angel banget. Nanging kita lagi nggarap iki ...
Conto liyane yaiku desain implementasi proses reguler (dilaksanakake ing jadwal, diwiwiti dening sistem kontrol, lan liya-liyane). Ing tangan siji, bisa dileksanakake kanggo saben area data kanthi kapisah. Iku luwih gampang lan luwih trep. Nanging, ing sisih liya, granularitas sing apik kasebut nggawe beban gedhe ing sistem kasebut. Kanggo nyuda beban, sampeyan kudu ngetrapake proses sosialisasi. Nanging dheweke mbutuhake sinau sing luwih ati-ati.
Mesthi, iki nuwuhake pitakonan sing penting banget. Kepiye pangembang aplikasi bisa njamin multitenancy? Apa sing kudu ditindakake kanggo iki? Mesthi, kita usaha kanggo mesthekake yen beban masalah teknologi lan infrastruktur tiba sabisa ing pundak teknologi sing diwenehake, lan pangembang aplikasi mung mikir babagan tugas logika bisnis. Nanging kaya masalah arsitektur penting liyane, pangembang aplikasi kudu duwe sawetara pangerten babagan nggarap model multitenancy lan sawetara gaweyan bakal dibutuhake nalika ngembangake aplikasi. Kenging punapa? Amarga ana titik sing teknologi ora bisa nyedhiyani kanthi otomatis tanpa njupuk menyang akun semantik saka data. Contone, definisi sing padha karo wates sosialisasi informasi. Nanging kita nyoba supaya kangelan iki cilik. Wis ana conto implementasine aplikasi kasebut.
Titik penting ing konteks implementasine multitenancy ing 1C: Enterprise yaiku kita nggawe model hibrida sing siji aplikasi bisa digunakake ing mode multitenancy lan mode normal. Iki minangka tugas sing angel banget lan dadi topik diskusi sing kapisah.
Source: www.habr.com
