Malangnya, istilah ini tidak mempunyai persamaan bahasa Rusia yang baik. Wikipedia menyediakan "Berbilang penyewaan, berbilang penyewaan." Ini kadangkala dipanggil "pemilikan berbilang." Istilah ini boleh menjadi agak mengelirukan, kerana perkara pokok pada dasarnya tidak berkaitan sama ada dengan penyewaan atau pemilikan. Ini adalah soal seni bina perisian dan organisasi operasinya. Yang terakhir ini tidak kurang pentingnya.
Kami mula membangunkan pemahaman kami tentang multitenancy pada masa yang sama kami mula mereka bentuk pendekatan kepada model pengendalian awan (perkhidmatan) untuk 1C:Enterprise. Itu beberapa tahun lalu. Dan sejak itu, pemahaman kami sentiasa berkembang. Kami sentiasa menemui aspek baharu subjek ini (kebaikan, keburukan, kerumitan, keanehan, dll.).
Kadangkala pembangun mentafsirkan multitenancy sebagai konsep yang sangat mudah: "Untuk menyimpan data daripada berbilang organisasi dalam satu pangkalan data, anda perlu menambah lajur dengan ID organisasi pada semua jadual dan menetapkan penapis padanya." Kami, sudah tentu, memulakan kerja kami mengenai isu ini dari saat itu. Tetapi kami dengan cepat menyedari bahawa ini hanyalah satu bidang (dan satu bidang yang kompleks, dengan cara itu). Malah, ia adalah "seluruh negara."
Idea asas multitenancy boleh diterangkan secara kasar seperti berikut. Apl biasa ialah kotej yang direka untuk satu keluarga, yang berkongsi infrastrukturnya (dinding, bumbung, bekalan air, pemanasan, dll.). Walau bagaimanapun, apl multitenancy ialah bangunan apartmen. Setiap keluarga menggunakan infrastruktur yang sama, tetapi infrastruktur itu sendiri dilaksanakan untuk keseluruhan bangunan.
Adakah multitenancy pendekatan yang baik atau buruk? Pendapat mengenai perkara ini berbeza-beza. Nampaknya tiada perkara seperti "baik atau buruk." Kebaikan dan keburukan perlu ditimbang dengan cabaran khusus yang ditangani. Tapi itu topik berasingan...
Dalam erti kata yang paling mudah, matlamat multitenancy adalah untuk mengurangkan kos penyelenggaraan aplikasi dengan "mensosialkan" kos infrastruktur. Ini adalah pendekatan yang sama seperti mengurangkan kos aplikasi dengan menggunakan penyelesaian standard (mungkin dengan penyesuaian dan penghalusan), dan bukannya membangunkan penyelesaian tersuai. Perbezaannya ialah dalam satu kes, pembangunan disosialisasikan, dan dalam satu lagi, operasi adalah.
Lebih-lebih lagi, mari kita ulangi, ini tidak terikat langsung dengan kaedah jualan. Seni bina multitenancy boleh digunakan dengan mudah dalam infrastruktur IT korporat atau jabatan untuk mengautomasikan sebilangan besar cawangan atau syarikat induk yang serupa.
Multitenancy, boleh dikatakan, adalah lebih daripada sekadar mengatur storan data. Ia merupakan model untuk keseluruhan operasi aplikasi (termasuk aspek penting seni binanya, model penggunaannya dan organisasi penyelenggaraannya).
Aspek yang paling kompleks dan menarik bagi model multitenancy, pada pendapat kami, ialah kefungsian teras aplikasi adalah bercabang dua. Sesetengah fungsi berfungsi dengan kawasan data tertentu (pangsapuri) dan tidak menyedari kehadiran penduduk di pangsapuri lain. Fungsi lain melihat bangunan secara keseluruhan dan berfungsi untuk semua penduduk secara serentak. Walau bagaimanapun, yang kedua tidak boleh mengabaikan hakikat bahawa ini, selepas semua, pangsapuri individu, dan tahap butiran dan keselamatan yang diperlukan mesti dipastikan.
Dalam 1C:Enterprise, model multitenancy dilaksanakan pada tahap beberapa teknologi. Ini ialah mekanisme platform 1C:Enterprise, mekanisme bagi"Dan"», mekanisme (perpustakaan subsistem standard).
Setiap elemen ini menyumbang kepada infrastruktur keseluruhan bangunan berbilang penyewa. Mengapa ini dilaksanakan dalam pelbagai teknologi dan bukannya satu, seperti platform? Terutamanya kerana kami percaya beberapa mekanisme boleh diubah suai dengan sewajarnya untuk senario penggunaan tertentu. Tetapi secara umum, ini adalah isu yang kompleks, dan kami sentiasa menghadapi pilihan lapisan mana yang terbaik untuk melaksanakan setiap aspek multitenancy.
Jelas sekali, mekanisme teras perlu dilaksanakan dalam platform. Contohnya, pengasingan data itu sendiri—jenis yang biasanya memulakan perbincangan tentang multitenancy. Tetapi akhirnya, model multitenancy menjejaskan sebahagian besar mekanisme platform dan memerlukan penghalusannya, dan dalam beberapa kes, memikirkan semula.
Di peringkat platform, kami melaksanakan mekanisme teras. Ini membolehkan penciptaan aplikasi yang berjalan dalam model berbilang penyewaan. Walau bagaimanapun, untuk aplikasi berfungsi dengan betul dalam model ini, sistem untuk menguruskan kitaran hayatnya diperlukan. Ini dicapai melalui teknologi 1cFresh dan lapisan logik perniagaan bersatu di peringkat sistem sokongan perniagaan (BSS). Sama seperti infrastruktur dalam bangunan apartmen menyediakan semua yang mereka perlukan kepada penduduk, teknologi 1cFresh menyediakan semua yang diperlukan untuk aplikasi yang dijalankan dalam model berbilang penyewaan. Untuk membolehkan aplikasi berinteraksi dengan infrastruktur ini (tanpa pengubahsuaian ketara), "penyambung" yang sesuai dibenamkan di dalamnya dalam bentuk subsistem BSS.
Dari segi mekanisme platform, mudah untuk melihat bahawa semasa kami memperoleh pengalaman dan membangunkan penyelesaian 1C:Enterprise berasaskan awan, kami sedang mengembangkan mekanisme yang terlibat dalam seni bina ini. Mari kita berikan satu contoh. Dalam model multitenancy, pengagihan peranan dalam kalangan peserta penyelenggaraan aplikasi berubah dengan ketara. Peranan (tahap tanggungjawab) mereka yang bertanggungjawab untuk operasi aplikasi telah meningkat dengan ketara. Mereka kini memerlukan alat kawalan aplikasi yang lebih berkuasa. Ini kerana pengguna aplikasi (penyewa) mempercayai, pertama sekali, pembekal yang mereka bekerjasama. Untuk menangani perkara ini, kami melaksanakan ciri baharu dalam versi 8.3. Mekanisme ini membolehkan pentadbir pembekal menyekat kebebasan pembangun aplikasi kepada tahap keselamatan yang diperlukan—pada asasnya, mengasingkan operasi aplikasi untuk setiap penyewa dalam kotak pasir tertentu.
Sama menariknya ialah seni bina untuk mengurus aplikasi yang berjalan dalam mod berbilang penyewaan (seperti yang dilaksanakan dalam teknologi 1cFresh dan BSP). Di sini, berbanding model penggunaan standard, keperluan untuk mengautomasikan proses pengurusan adalah jauh lebih tinggi. Terdapat berpuluh-puluh proses sedemikian: mencipta kawasan data baharu ("pangsapuri"), mengemas kini aplikasi, mengemas kini maklumat kawal selia, sandaran dan sebagainya. Dan, sudah tentu, keperluan untuk kebolehpercayaan dan ketersediaan meningkat. Contohnya, untuk memastikan interaksi yang boleh dipercayai antara aplikasi dan komponen sistem pengurusan, kami melaksanakan sistem panggilan tak segerak dengan penghantaran terjamin.
Perkara yang sangat halus ialah cara data dan proses dikongsi. Ia kelihatan mudah (jika ia kelihatan begitu kepada sesiapa sahaja) hanya pada pandangan pertama. Cabaran terbesar terletak pada mengimbangi pemusatan data dan proses dengan desentralisasi. Di satu pihak, pemusatan mengurangkan kos (ruang cakera, sumber CPU, usaha pentadbir, dll.). Sebaliknya, ia mengehadkan kebebasan "penyewa." Ini betul-betul salah satu aspek aplikasi "bifurcation," apabila pembangun mesti mempertimbangkan aplikasi secara serentak dalam erti kata yang sempit (melayani satu "apartmen") dan dalam erti kata yang luas (melayan semua "penyewa" serentak).
Contoh "dilema" sedemikian ialah maklumat kawal selia dan rujukan. Sememangnya, ia menggoda untuk menjadikannya biasa bagi semua "penduduk" bangunan. Ini membolehkan kedua-duanya menyimpannya dalam satu salinan dan mengemas kininya untuk semua orang sekaligus. Tetapi kadangkala, penduduk tertentu memerlukan perubahan tertentu. Anehnya, ini berlaku dalam amalan, walaupun untuk maklumat yang ditentukan oleh pengawal selia (agensi kerajaan). Ini menimbulkan persoalan yang sukar: untuk generalisasi atau tidak untuk generalisasi? Sudah tentu, ia menggoda untuk menjadikan maklumat umum untuk semua orang dan peribadi bagi mereka yang menginginkannya. Tetapi ini membawa kepada pelaksanaan yang agak rumit. Tetapi kami sedang mengusahakannya...
Contoh lain ialah reka bentuk proses biasa (dijadualkan, dimulakan oleh sistem kawalan, dsb.). Di satu pihak, mereka boleh dilaksanakan secara berasingan untuk setiap kawasan data. Ini lebih mudah dan lebih selesa. Walau bagaimanapun, sebaliknya, pelaksanaan yang terperinci sedemikian menghasilkan beban yang ketara pada sistem. Untuk mengurangkan beban ini, adalah perlu untuk melaksanakan proses bersama. Walau bagaimanapun, ini memerlukan reka bentuk yang lebih teliti.
Sememangnya, ini menimbulkan persoalan penting. Bagaimanakah pembangun aplikasi boleh memastikan multitenancy? Apa yang perlu mereka lakukan? Sudah tentu, kami berusaha untuk memastikan bahawa beban isu teknologi dan infrastruktur jatuh sebanyak mungkin di bahu teknologi yang dibekalkan, meninggalkan pembangun aplikasi untuk berfikir semata-mata dari segi logik perniagaan. Tetapi seperti isu seni bina penting yang lain, pembangun aplikasi perlu mempunyai sedikit pemahaman tentang cara multitenancy berfungsi, dan beberapa usaha akan diperlukan semasa pembangunan aplikasi. kenapa? Kerana terdapat aspek yang teknologi tidak dapat menangani secara automatik tanpa mempertimbangkan semantik data. Contohnya, mentakrifkan sempadan maklumat yang dikongsi. Tetapi kami berusaha untuk memastikan cabaran ini seminimum mungkin. Contoh pelaksanaan aplikasi sedemikian sudah wujud.
Aspek penting dalam melaksanakan multitenancy dalam 1C:Enterprise ialah kami mencipta model hibrid yang mana satu aplikasi boleh beroperasi dalam kedua-dua mod multitenancy dan standard. Ini adalah tugas yang sangat kompleks dan subjek perbincangan yang berasingan.
Sumber: www.habr.com
