एक गैर-किरायेदार आवेदन से बाहर बहु-किरायेदार आवेदन कैसे करें

मैं मल्टी-टेनेंसी की परिभाषा नहीं दूंगा, उन्होंने पहले भी कई बार यहां और यहां के बारे में लिखा है । और लेख के विषय पर सीधे जाना और निम्नलिखित प्रश्नों के साथ शुरू करना बेहतर है:

एप्लिकेशन को तुरंत मल्टीटैनेंट क्यों नहीं किया जाता है?

ऐसा होता है कि एप्लिकेशन को केवल क्लाइंट साइड पर इंस्टॉलेशन के लिए विकसित किया गया है। आप इस तरह के एप्लिकेशन को उत्पाद के रूप में बॉक्सिंग या सॉफ्टवेयर कह सकते हैं। एक ग्राहक एक बॉक्स खरीदता है और अपने सर्वर पर एप्लिकेशन को तैनात करता है (ऐसे अनुप्रयोगों के कई उदाहरण हैं)।

लेकिन समय के साथ, डेवलपर कंपनी यह सोच सकती है कि एप्लिकेशन को क्लाउड में रखना अच्छा होगा ताकि इसे किराए पर दिया जाए (सेवा के रूप में सॉफ्टवेयर)। इस परिनियोजन विधि में क्लाइंट और डेवलपर कंपनी दोनों के लिए फायदे हैं। ग्राहक जल्दी से एक कार्य प्रणाली प्राप्त कर सकते हैं और तैनाती और प्रशासन की चिंता नहीं कर सकते। आवेदन किराए पर लेते समय, आपको बड़े एकमुश्त निवेश की आवश्यकता नहीं होती है।

और डेवलपर कंपनी नए ग्राहकों को, साथ ही नए कार्यों को प्राप्त करेगी: क्लाउड में एप्लिकेशन को तैनात करना, प्रशासन करना, नए संस्करणों को अपडेट करना, अपडेट करने के दौरान डेटा का माइग्रेट करना, डेटा बैकअप, गति और त्रुटियों की निगरानी करना, यदि वे होते हैं तो समस्याओं को ठीक करना।

क्लाउड में एप्लिकेशन मल्टी-टेनेंट क्यों होना चाहिए?

क्लाउड में एप्लिकेशन लगाने के लिए, इसे बहु-किरायेदार बनाने के लिए आवश्यक नहीं है। लेकिन तब निम्न समस्या होगी: प्रत्येक ग्राहक के लिए, आपको पट्टे पर दिए गए आवेदन के साथ क्लाउड में एक समर्पित स्टैंड तैनात करना होगा, और यह पहले से ही महंगा है, दोनों क्लाउड स्टैंड संसाधनों की खपत और प्रशासन के संदर्भ में। आवेदन में बहु-किरायेदारी को लागू करना अधिक लाभदायक है ताकि एक उदाहरण कई ग्राहकों (संगठनों) की सेवा कर सके।

यदि एप्लिकेशन एक साथ काम करने वाले उपयोगकर्ताओं को 1000 खींचता है, तो यह समूह ग्राहकों (संगठनों) के लिए फायदेमंद है, ताकि कुल में वे 1000 उपयोगकर्ताओं को प्रति एप्लिकेशन इंस्टेंस का वांछित भार दे सकें। और फिर बादल संसाधनों का सबसे इष्टतम उपभोग होगा।

मान लें कि एप्लिकेशन को 20 उपयोगकर्ताओं (संगठन के कर्मचारी) के लिए एक संगठन द्वारा किराए पर लिया गया है। फिर आपको सही लोड तक पहुंचने के लिए इन संगठनों में से 50 को समूह में रखने की आवश्यकता है। संगठनों को एक-दूसरे से अलग करना महत्वपूर्ण है। एक संगठन एक आवेदन को किराए पर देता है, केवल अपने कर्मचारियों को वहां जाने देता है, केवल अपने डेटा को संग्रहीत करता है, और यह नहीं देखता है कि अन्य संगठन भी उसी एप्लिकेशन द्वारा प्रस्तुत किए जाते हैं।

बहु-किरायेदारी को लागू करने का मतलब यह नहीं है कि आवेदन को अब संगठन के सर्वर पर स्थानीय रूप से तैनात नहीं किया जा सकता है। आप एक ही समय में दो परिनियोजन विधियों का समर्थन कर सकते हैं:

• बादल में बहु-किरायेदार आवेदन;
• ग्राहक सर्वर पर एकल-किरायेदार आवेदन।

हमारा आवेदन इसी तरह आया है: गैर-किरायेदार से बहु-किरायेदार तक। और इस लेख में मैं मल्टी-टेनेंसी विकसित करने में कुछ दृष्टिकोण साझा करूंगा।

गैर-किरायेदार के रूप में डिज़ाइन किए गए एप्लिकेशन में बहु-किरायेदारी कैसे लागू करें?

हम तुरंत विषय को सीमित कर देंगे, हम केवल विकास पर विचार करेंगे, हम परीक्षण के मुद्दों, संस्करण को जारी करने, परिनियोजन और प्रशासन पर नहीं छूएंगे। इन सभी क्षेत्रों में, बहु-किरायेदारी के उद्भव को भी ध्यान में रखा जाना चाहिए, लेकिन अब हम केवल विकास के बारे में बात करेंगे।

यह समझने के लिए कि एक आवेदन क्या है जो किरायेदार नहीं था और बहु-किरायेदार बन गया, मैं इसका उद्देश्य, उपयोग की गई सेवाओं और प्रौद्योगिकियों की एक सूची का वर्णन करूंगा।

यह एक ECM प्रणाली (DirectumRX) है, जिसमें 10 सेवाएं (5 अखंड सेवाएं और 5 माइक्रोसर्विसेज) शामिल हैं। इन सभी सेवाओं को एक शक्तिशाली सर्वर पर या कई सर्वरों पर रखा जा सकता है।

प्रयुक्त तकनीकों का ढेर:
.NET + SQLServer / Postgres + NHibernate + IIS + RabbitMQ + Redis

तो, सेवाओं को बहु-किरायेदार बनाने के लिए क्या करना है? ऐसा करने के लिए, आपको सेवाओं में निम्नलिखित तंत्र को परिष्कृत करने की आवश्यकता है, अर्थात्, किरायेदारों के बारे में ज्ञान जोड़ें:

• डेटा भंडारण;
• ORM;
• डेटा कैशिंग;
• अनुरोध प्रसंस्करण;
• प्रसंस्करण कतार संदेश;
• विन्यास;
• प्रवेश;
• पृष्ठभूमि के कार्य करना;
• माइक्रोसर्विस के साथ बातचीत;
• संदेश दलाल के साथ बातचीत।

हमारे आवेदन के मामले में, ये मुख्य स्थान थे जिनमें सुधार की आवश्यकता थी। आइए उन पर अलग से विचार करें।

डेटा संग्रहण विधि चुनना

जब आप मल्टी-टेनेंसी के बारे में लेख पढ़ते हैं, तो सबसे पहली बात यह है कि वे डेटा संग्रहण कैसे व्यवस्थित करते हैं। वास्तव में, बिंदु महत्वपूर्ण है।

हमारी ईसीएम प्रणाली के लिए, मुख्य भंडारण एक रिलेशनल डेटाबेस है, जिसमें लगभग 100 टेबल हैं। कई संगठनों के डेटा के भंडारण को कैसे व्यवस्थित किया जाए ताकि संगठन A किसी भी तरह से संगठन B के डेटा को न देख सके?

कई योजनाओं को जाना जाता है (इन योजनाओं के बारे में बहुत कुछ लिखा जा चुका है):

• प्रत्येक संगठन के लिए अपना स्वयं का डेटाबेस बनाएं (प्रत्येक किरायेदार के लिए);
• सभी संगठनों के लिए एक डेटाबेस का उपयोग करें, लेकिन प्रत्येक संगठन के लिए डेटाबेस में अपनी योजना बनाएं;
• सभी संगठनों के लिए एक डेटाबेस का उपयोग करें, लेकिन प्रत्येक तालिका में "किरायेदार / संगठन कुंजी" एक कॉलम जोड़ें।

स्कीम का चुनाव आकस्मिक नहीं है। हमारे मामले में, पसंदीदा विकल्प को समझने के लिए सिस्टम प्रशासन के मामलों पर विचार करना पर्याप्त है। मामले निम्नानुसार हैं:

• किरायेदार जोड़ें (एक नया संगठन एक सिस्टम किराए पर);
• किरायेदार को हटा दें (संगठन ने किराए पर लेने से इनकार कर दिया);
• किरायेदार को दूसरे क्लाउड स्टैंड में स्थानांतरित करें (क्लाउड स्टैंड के बीच लोड को फिर से वितरित करें जब एक स्टैंड लोड से निपटने के लिए बंद हो जाता है)।

किरायेदार स्थानांतरण मामले पर विचार करें। स्थानांतरण का मुख्य कार्य संगठन के डेटा को दूसरे स्टैंड में स्थानांतरित करना है। स्थानांतरण करना मुश्किल नहीं है यदि किरायेदार का अपना डेटाबेस है, लेकिन यह एक सिरदर्द होगा यदि आप 100 तालिकाओं में विभिन्न संगठनों के डेटा को मिलाते हैं। तालिकाओं से केवल आवश्यक डेटा निकालने का प्रयास करें, उन्हें किसी अन्य डेटाबेस में स्थानांतरित करें, जहां पहले से ही अन्य किरायेदारों का डेटा है, और ताकि उनके पहचानकर्ता अंतर न करें।

अगला मामला एक नए किरायेदार के अलावा है। मामला भी सरल नहीं है। किरायेदार जोड़ना सिस्टम निर्देशिकाओं, उपयोगकर्ताओं, अधिकारों को भरने की आवश्यकता है, ताकि आप सिस्टम में लॉग इन कर सकें। यह कार्य एक संदर्भ डेटाबेस को क्लोन करके सबसे अच्छा हल किया गया है, जिसमें पहले से ही आपकी जरूरत की सभी चीजें हैं।

किरायेदार हटाने का मामला बहुत आसानी से किरायेदार डेटाबेस को अक्षम करके हल किया जाता है।

इन कारणों के लिए, हमने एक योजना चुनी: एक किरायेदार - एक डेटाबेस ।

ORM

हमने डेटा संग्रहण विधि को चुना, अगला सवाल: चयनित योजना के साथ काम करने के लिए ओआरएम कैसे सिखाना है?

हम निहर्नेट का उपयोग करते हैं। यह आवश्यक था कि निबर्नेट कई डेटाबेस के साथ काम करे और समय-समय पर दाईं ओर स्विच करे, उदाहरण के लिए, http अनुरोध पर निर्भर करता है। यदि हम संगठन ए के अनुरोध को संसाधित करते हैं, तो डेटाबेस ए का उपयोग किया गया था, और यदि अनुरोध संगठन बी से है, तो डेटाबेस बी।

NHibernate के पास ऐसा अवसर है। आपको NHibernate.Connection.DriverConnectionProvider के कार्यान्वयन को ओवरराइड करने की आवश्यकता है। जब भी NHibernate डेटाबेस कनेक्शन खोलना चाहता है, तो वह कनेक्शन स्ट्रिंग प्राप्त करने के लिए DriverConnectionProvider को कॉल करता है। यहां हम इसे आवश्यक एक के साथ बदल देंगे:

public class MyDriverConnectionProvider : DriverConnectionProvider { protected override string ConnectionString => TenantRegistry.Instance.CurrentTenant.ConnectionString; } 

TenantRegistry क्या है। Instance.CurrentTenant मैं थोड़ी देर बाद बताऊंगा।

डेटा कैशिंग

डेटाबेस प्रश्नों को कम करने या कई बार एक ही चीज़ की गणना नहीं करने के लिए अक्सर सेवाएं डेटा को कैश करती हैं। समस्या यह है कि किरायेदारों द्वारा कैश को तोड़ दिया जाना चाहिए यदि किरायेदार डेटा कैश किया गया है। यह स्वीकार्य नहीं है कि किसी संगठन के डेटा कैश का उपयोग किसी अन्य संगठन से अनुरोध संसाधित करते समय किया जाए। सबसे सरल उपाय प्रत्येक कैश की कुंजी में एक किरायेदार पहचानकर्ता जोड़ना है:

 var tenantCacheKey = cacheKey + TenantRegistry.Instance.CurrentTenant.Id; 

प्रत्येक कैश बनाते समय इस समस्या को याद रखना चाहिए। हमारी सेवाओं में बहुत सारे कैश हैं। प्रत्येक में किरायेदार पहचानकर्ता को ध्यान में नहीं रखना भूल जाने के लिए, कैश के साथ काम को एकजुट करना बेहतर है। उदाहरण के लिए, एक सामान्य कैशिंग तंत्र बनाएं जो किरायेदारों के संदर्भ में बॉक्स से कैश हो जाएगा।

लॉगिंग

जल्दी या बाद में, सिस्टम में कुछ गलत हो जाएगा, आपको लॉग फ़ाइल खोलने और उसका अध्ययन करने की आवश्यकता होगी। पहला सवाल यह है कि किस उपयोगकर्ता और किस संगठन की ओर से ये कार्रवाई की गई?

यह सुविधाजनक है जब लॉग की प्रत्येक पंक्ति में एक किरायेदार पहचानकर्ता और एक किरायेदार उपयोगकर्ता नाम होता है। यह जानकारी आवश्यक हो जाती है, उदाहरण के लिए, संदेश समय:

 2019-05-24 17:05:27.985 <message> [User2 :Tenant1] 2019-05-24 17:05:28.126 <message> [User3 :Tenant2] 2019-05-24 17:05:28.173 <message> [User4 :Tenant3] 

डेवलपर को यह नहीं सोचना चाहिए कि लॉग को किस किरायेदार को लिखना है, यह लॉगिंग सिस्टम के "हुड के नीचे" स्वचालित, छिपा हुआ होना चाहिए।

हम NLog का उपयोग करते हैं, इसलिए मैं इस पर एक उदाहरण दूंगा। किरायेदार पहचानकर्ता को सुरक्षित करने का सबसे आसान तरीका NLog.LayoutRenderers.LayoutRenderer है , जो आपको प्रत्येक लॉग प्रविष्टि के लिए किरायेदार पहचानकर्ता प्राप्त करने की अनुमति देगा:

  [LayoutRenderer("tenant")] public class TenantLayoutRenderer : LayoutRenderer { protected override void Append(StringBuilder builder, LogEventInfo logEvent) { builder.Append(TenantRegistry.Instance.CurrentTenant.Id); } } 

और फिर लॉग टेम्पलेट में इस LayoutRenderer का उपयोग करें:

 <target layout="${odate} ${message} [${user} :${tenant}]"/> 

कोड निष्पादन

उपरोक्त उदाहरणों में, मैंने अक्सर निम्नलिखित कोड का उपयोग किया:

 TenantRegistry.Instance.CurrentTenant 

यह बताने का समय है कि इसका क्या मतलब है। लेकिन पहले आपको उस दृष्टिकोण को समझने की आवश्यकता है जिसका हम सेवाओं में पालन करते हैं:

कोई भी कोड निष्पादन (एक HTTP अनुरोध संसाधित करना, एक कतार संदेश को संसाधित करना, एक अलग थ्रेड में पृष्ठभूमि कार्य करना) कुछ किरायेदार के साथ जुड़ा होना चाहिए।

इसका मतलब है कि कोड निष्पादन में किसी भी स्थान पर कोई भी पूछ सकता है: "किस किरायेदार के लिए यह धागा काम करता है?" या दूसरे तरीके से, "वर्तमान किरायेदार क्या है?"

TenantRegistry.Instance.CurrentTenant वर्तमान धारा के लिए वर्तमान किरायेदार है। स्ट्रीम और किरायेदार को हमारे अनुप्रयोगों में जोड़ा जा सकता है। वे अस्थायी रूप से जुड़े हुए हैं, उदाहरण के लिए, एक HTTP अनुरोध संसाधित करते समय या कतार से एक संदेश संसाधित करते समय। किरायेदार को एक धारा में बाँधने का एक तरीका इस प्रकार है:

 //    . using (TenantRegistry.Instance.SwitchTo(tenantId)) { // ,     . var tenant = TenantRegistry.Instance.CurrentTenant; //     . var connectionString = tenant.ConnectionString; //  . var id = tenant.Id; } 

एक थ्रेड से बंधा एक किरायेदार कोड में कहीं भी प्राप्त किया जा सकता है, टेनेंट रीजेंसी से संपर्क करके - यह एक सिंगलटन है, जो किरायेदारों के साथ काम करने के लिए एक एक्सेस प्वाइंट है। इसलिए, कनेक्शन स्ट्रिंग या किरायेदार पहचानकर्ता का पता लगाने के लिए निहर्नेट और NLog इस सिंगलटन (विस्तार बिंदुओं पर) का उपयोग कर सकते हैं।

पृष्ठभूमि के कार्य

सेवाओं में अक्सर पृष्ठभूमि कार्य होते हैं जिन्हें टाइमर पर निष्पादित करने की आवश्यकता होती है। पृष्ठभूमि कार्य संगठन के डेटाबेस तक पहुंच सकते हैं, और फिर प्रत्येक किरायेदार के लिए पृष्ठभूमि कार्य किया जाना चाहिए। ऐसा करने के लिए, प्रत्येक किरायेदार के लिए एक अलग टाइमर या धागा शुरू करना आवश्यक नहीं है। एक धागा / टाइमर के भीतर विभिन्न किरायेदारों में एक कार्य करना संभव है। ऐसा करने के लिए, टाइमर हैंडलर में, हम किरायेदारों को छांटते हैं, प्रत्येक किरायेदार को एक धारा के साथ जोड़ते हैं और एक पृष्ठभूमि कार्य करते हैं:

 //    . foreach (var tenant in TenantRegistry.Instance.Tenants) { //    . using (TenantRegistry.Instance.SwitchTo(tenant.Id)) { //     . } } 

दो किरायेदारों को एक ही समय में प्रवाह से नहीं जोड़ा जा सकता है, यदि हम एक को जोड़ते हैं, तो दूसरा प्रवाह से अलग हो जाता है। हम सक्रिय रूप से इस दृष्टिकोण का उपयोग करते हैं ताकि पृष्ठभूमि कार्यों के लिए धागे / टाइमर का उत्पादन न हो।

एक किरायेदार के साथ http अनुरोध को कैसे सहसंबंधित करें

क्लाइंट के http अनुरोध को संसाधित करने के लिए, आपको यह जानना होगा कि वह किस संगठन से आया है। यदि उपयोगकर्ता पहले से ही प्रमाणित है, तो किरायेदार पहचानकर्ता को प्रमाणीकरण कुकी (यदि एप्लिकेशन के साथ काम ब्राउज़र के माध्यम से किया जाता है) या JWT टोकन में संग्रहीत किया जा सकता है। लेकिन क्या होगा अगर उपयोगकर्ता ने अभी तक प्रमाणित नहीं किया है? उदाहरण के लिए, एक अनाम उपयोगकर्ता ने एक एप्लिकेशन वेबसाइट खोली है और प्रमाणित करना चाहता है। ऐसा करने के लिए, वह एक लॉगिन और पासवर्ड के साथ एक अनुरोध भेजता है। इस उपयोगकर्ता की तलाश करने के लिए किस संगठन के डेटाबेस में?

साथ ही, आवेदन करने के लिए लॉगिन पेज प्राप्त करने के लिए अनाम अनुरोध प्राप्त होंगे, और यह विभिन्न संगठनों के लिए भिन्न हो सकता है, उदाहरण के लिए, स्थानीयकरण की भाषा।

अनाम http- अनुरोध और संगठन (किरायेदार) के सहसंबंध की समस्या को हल करने के लिए, हम संगठनों के लिए उप-डोमेन का उपयोग करते हैं। उपडोमेन का नाम संगठन के नाम से बना है। उपयोगकर्ताओं को सिस्टम के साथ काम करने के लिए उपडोमेन का उपयोग करना चाहिए:

 https://company1.service.com https://company2.service.com 

इन पतों पर एक ही मल्टी-टेनेंट वेब सेवा उपलब्ध है। लेकिन अब सेवा समझती है कि किस संगठन से एक अनाम http अनुरोध आएगा, जो डोमेन नाम पर केंद्रित है।
डोमेन नाम और किरायेदार का बंधन वेब सेवा कॉन्फ़िगरेशन फ़ाइल में किया जाता है:

 <tenant name="company1" db="database1" host="company1.service.com" /> <tenant name="company2" db="database2" host="company2.service.com" /> 

विन्यास सेवाओं के बारे में नीचे वर्णित किया जाएगा।

Mikroservisy। डेटा भंडारण

जब मैंने कहा कि ईसीएम प्रणाली को 100 तालिकाओं की आवश्यकता है, तो मैंने अखंड सेवाओं के बारे में बात की। लेकिन ऐसा होता है कि एक microservice को एक रिलेशनल स्टोरेज की आवश्यकता होती है, जिसमें इसके डेटा को स्टोर करने के लिए 2-3 टेबल की आवश्यकता होती है। आदर्श रूप से, प्रत्येक माइक्रोसिस्ट में अपना स्वयं का भंडारण होता है, जिसमें केवल इसकी पहुंच होती है। और माइक्रोसेवर तय करता है कि किरायेदारों के संदर्भ में डेटा को कैसे संग्रहीत किया जाए।

लेकिन हम दूसरे तरीके से गए: हमने संगठन के सभी डेटा को एक डेटाबेस में संग्रहीत करने का निर्णय लिया। यदि एक माइक्रोसैस सर्विस के लिए रिलेशनल स्टोरेज की आवश्यकता होती है, तो यह मौजूदा संगठन डेटाबेस का उपयोग करता है ताकि डेटा अलग-अलग स्टोरेज में न बिखरे, लेकिन एक डेटाबेस में एकत्र किया जाता है। अखंड सेवाएं समान डेटाबेस का उपयोग करती हैं।

डेटाबेस में माइक्रोसर्विसेज केवल अपने टेबल के साथ काम करते हैं, और एक मोनोलिथ या अन्य माइक्रोसेवा के टेबल के साथ काम करने की कोशिश नहीं करते हैं। इस दृष्टिकोण के पक्ष और विपक्ष हैं।

पेशेवरों:

• एक स्थान पर संगठन डेटा;
• बैकअप और संगठन डेटा को पुनर्स्थापित करने के लिए आसान;
• बैकअप में, सभी सेवाओं का डेटा सुसंगत है।

विपक्ष:

• स्केलिंग करते समय सभी सेवाओं के लिए एक डेटाबेस एक संकीर्ण गर्दन है (DBMS संसाधनों की आवश्यकताएं बढ़ जाती हैं);
• माइक्रोसर्विसेज के पास एक-दूसरे की तालिकाओं तक भौतिक पहुंच होती है, लेकिन इस सुविधा का उपयोग नहीं करते हैं।

Mikroservisy। किरायेदारों के ज्ञान की हमेशा आवश्यकता नहीं होती है।

एक माइक्रोसिस्ट को पता नहीं हो सकता है कि यह बहु-किरायेदार वातावरण में काम करता है। हमारी सेवाओं में से एक पर विचार करें, जो दस्तावेजों को HTML में बदलने में लगी हुई है।

सेवा क्या करती है:

1. किसी दस्तावेज़ को कनवर्ट करने के लिए RabbitMQ कतार से एक संदेश लेता है।
   
   • संदेश से दस्तावेज़ पहचानकर्ता और किरायेदार पहचानकर्ता को पुनः प्राप्त करता है
2. दस्तावेज़ संग्रहण सेवा से दस्तावेज़ डाउनलोड करें।
   
   • इसके लिए एक अनुरोध उत्पन्न होता है जिसमें यह दस्तावेज़ पहचानकर्ता और किरायेदार पहचानकर्ता को प्रेषित करता है
3. HTML को एक दस्तावेज़ देता है।
4. HTML को रूपांतरण परिणामों को संग्रहीत करने की सेवा में देता है।

सेवा दस्तावेजों को संग्रहीत नहीं करती है और रूपांतरण परिणामों को संग्रहीत नहीं करती है। उन्हें किरायेदारों का अप्रत्यक्ष ज्ञान है: किरायेदार पहचानकर्ता पारगमन में सेवा से गुजरता है।

Mikroservisy। उप-डोमेन की जरूरत नहीं है

मैंने लिखा है कि उप-डोमेन अनाम http अनुरोधों की समस्या को हल करने में मदद करते हैं:

 https://company1.service.com https://company2.service.com 

लेकिन सभी सेवाएँ अनाम अनुरोधों के साथ काम नहीं करती हैं, सबसे पहले प्रमाणीकरण की आवश्यकता होती है। इसलिए, जो माइक्रोसॉफ़्ट, http के माध्यम से काम करते हैं, वे अक्सर इस बात की परवाह नहीं करते हैं कि होस्टनाम क्या अनुरोध करता है, वे JWT टोकन या प्रत्येक अनुरोध के साथ आने वाले प्रमाणीकरण कुकी से किरायेदार के बारे में सभी जानकारी प्राप्त करते हैं।

का विन्यास

सेवाओं को कॉन्फ़िगर करने की आवश्यकता है ताकि वे किरायेदारों के बारे में जान सकें। अर्थात्:

• किरायेदारों के डेटाबेस से जुड़ने के लिए तार निर्दिष्ट करें;
• किरायेदारों को डोमेन नाम बाँधें;
• किरायेदार की डिफ़ॉल्ट भाषा और समय क्षेत्र निर्दिष्ट करें।

किरायेदारों में कई सेटिंग्स हो सकती हैं। हमारी सेवाओं के लिए, हम xml कॉन्फ़िगरेशन फ़ाइलों में किरायेदार सेटिंग्स सेट करते हैं। यह web.config नहीं है और न ही app.config। यह एक अलग xml फ़ाइल है, जिसके परिवर्तन को सेवाओं को रिबूट किए बिना पकड़ने में सक्षम होना चाहिए ताकि एक नए किरायेदार को जोड़ने से पूरे सिस्टम को पुनरारंभ न करें।

सेटिंग्स की सूची कुछ इस प्रकार है:

 <!--  . --> <block name="TENANTS"> <tenant name="Jupiter" db="DirectumRX_Jupiter" login="admin" password="password" hyperlinkUriScheme="jupiter" hyperlinkFileExtension=".jupiter" hyperlinkServer="http://jupiter-rx.directum.ru/Sungero" helpAddress="http://jupiter-rx.directum.ru/Sungero/help" devHelpAddress="http://jupiter-rx.directum.ru/Sungero/dev_help" language="Ru-ru" isAttributesSignatureAbsenceAllowed="false" endorsingSignatureLocksSignedProperties="false" administratorEmail ="admin@jupiter-company.ru" feedbackEmail="support@jupiter-company.ru" isSendFeedbackAllowed="true" serviceUserPassword="password" utcOffset="5" collaborativeEditingEnabled="false" collaborativeEditingForced="false" /> <tenant name="Mars" db="DirectumRX_Mars" login="admin" password="password" hyperlinkUriScheme="mars" hyperlinkFileExtension=".mars" hyperlinkServer="http://mars-rx.directum.ru/Sungero" helpAddress="http://mars-rx.directum.ru/Sungero/help" devHelpAddress="http://mars-rx.directum.ru/Sungero/dev_help" language="Ru-ru" isAttributesSignatureAbsenceAllowed="false" endorsingSignatureLocksSignedProperties="false" administratorEmail ="root@mars-ooo.ru" feedbackEmail="support@mars-ooo.ru" isSendFeedbackAllowed="true" serviceUserPassword="password" utcOffset="-1" collaborativeEditingEnabled="false" collaborativeEditingForced="false" /> </block> 

जब कोई नया संगठन किसी सेवा को किराए पर लेता है, तो उसे इसके लिए कॉन्फ़िगरेशन फ़ाइल में एक नया किरायेदार जोड़ना होगा। और यह वांछनीय है कि अन्य संगठनों को यह महसूस नहीं होता है। आदर्श रूप से, सेवाओं का पुनः आरंभ नहीं होना चाहिए।

हम पर सभी सेवाएँ पुनः आरंभ किए बिना एक विन्यास लेने में सक्षम हैं, लेकिन सबसे महत्वपूर्ण सेवाएँ (मोनोलिथ) ऐसा करने में सक्षम हैं।

परिणाम

जब कोई एप्लिकेशन बहु-किरायेदार बन जाता है, तो ऐसा लगता है कि विकास की जटिलता नाटकीय रूप से बढ़ गई है। लेकिन फिर आपको बहुपरतता की आदत होती है, और इसके समर्थन को एक सामान्य आवश्यकता के रूप में मानते हैं।

यह भी याद रखने योग्य है कि मल्टी-टेनेंसी न केवल विकास है, बल्कि परीक्षण, प्रशासन, तैनाती, अद्यतन, बैकअप, डेटा माइग्रेशन भी है। लेकिन एक और बार उनके बारे में बेहतर।