मैं एक वेब-आधारित सास समाधान बनाने की कोशिश कर रहा हूं, और मैंने एक सड़क को मारा जहां मैं मल्टी टेनेंसी या मल्टी उदाहरण का उपयोग करना सुनिश्चित नहीं कर रहा हूं। मैं वर्णन करने की कोशिश करूंगा कि मैं क्या हासिल करने की कोशिश कर रहा हूं, और प्रत्येक दृष्टिकोण फायदे और नुकसान (मेरी राय, जो मैंने पढ़ा है उसके अनुसार)। कृपया अपने सुझावों को उस स्थिति में शामिल करें जब मैंने एक दृष्टिकोण से दूसरे में कुछ भी याद किया।
जैसा कि मैं बनाने की कोशिश कर रहा हूं, यह अनुप्रयोग है, जैसा कि मैंने उल्लेख किया है, एक सास समाधान जहां कंपनियां अपने खाते बना सकती हैं, और प्रत्येक खाते / कंपनी के पास स्वयं के उपयोगकर्ता, ग्राहक, उत्पाद, सेवाएं ... आदि हैं। प्रत्येक उपयोगकर्ता; जो एक कंपनी कर्मचारी है; एक खाते / कंपनी से संबंधित केवल उसकी / उसकी कंपनी के ग्राहकों, उत्पादों और सेवाओं तक पहुंच होगी। कंपनियों के पास असीमित संख्या में ग्राहक, उत्पाद और सेवाएं हो सकती हैं, इस प्रकार प्रत्येक कंपनी का अपना डेटा केंद्र होना चाहिए।
उसके लिए मैंने एक साझा डेटाबेस (लॉगिन प्रयोजनों के लिए सभी उपयोगकर्ताओं को क्रेडेंशियल्स को सहेजने) और कई डेटाबेस साझा स्कीमा (प्रति खाता / कंपनी डेटाबेस) को बनाने का फैसला किया। असल में, मल्टी टेनेंसी ।
तब किसी ने इसके बजाय मल्टी इंस्टेंस का उपयोग करने का सुझाव दिया , जहां प्रत्येक कंपनी का अपना इंस्टेंस होगा (यानी कोड, लाइब्रेरी, डेटाबेस, फ्रेमवर्क ... आदि) दूसरी कंपनियों से पूरी तरह से अलग। यह बेहतर लगता है क्योंकि मुझे एक अतिरिक्त परत की देखभाल करने की आवश्यकता नहीं है जहां मुझे यह सुनिश्चित करने की आवश्यकता है कि प्रत्येक किरायेदार के उपयोगकर्ताओं की पहुंच उनकी कंपनी के डेटा तक ही हो। मुझे लगता है कि यह उल्लेख करना अच्छा है कि मैं इस दृष्टिकोण को प्राप्त करने के लिए डॉकर पर निर्भर हूं (मैंने पहले कभी इसका इस्तेमाल नहीं किया है), लेकिन मुझे लगता है कि इसमें सुविधाओं की कमी है (बाद में उन पर) मुझे भविष्य में आवश्यकता होगी (कम से कम मैंने नहीं किया था) 'उन्हें थोड़ी खोज के साथ खोजें)।
हालांकि, प्रत्येक दृष्टिकोण पेशेवरों और विपक्षों के साथ आता है, इसलिए मैं निर्णय नहीं ले सका कि किस दृष्टिकोण के साथ जाना है। यहाँ एक सूची है, लेकिन मेरे साथ नंगे हैं क्योंकि मुझे उन दोनों में ज्ञान की कमी है, इसलिए कुछ ऐसा हो सकता है जिसके बारे में मुझे जानकारी नहीं है, या एक समस्या का हल जो मुझे वेब पर नहीं मिला: [प्रत्येक दृष्टिकोण है एक क्रमबद्ध सूची जिसकी मैंने एक के बाद एक तुलना की]
मल्टी टेनेंसी :
- साझा होस्ट / हार्डवेयर, साझा कोड और बहु डेटाबेस।
- यह आसान कोड और ठीक कीड़े की कार्यक्षमता (साझा कोड) का विस्तार करने के।
- यह कठिन हार्डवेयर (क्लाउड सेवा इस्तेमाल कर सकते हैं) का विस्तार, या कोड में परिवर्तन कर के बिना किसी अन्य व्यवस्था करने के लिए अलग-अलग किरायेदार के डेटाबेस ले जाने के लिए।
- सबसे महत्वपूर्ण बात, जैसा कि मैंने पहले उल्लेख किया है, मुझे यह सुनिश्चित करने के लिए सिस्टम में एक अतिरिक्त परत जोड़ने की जरूरत है कि उपयोगकर्ता वास्तव में उसकी / उसकी कंपनी से संबंधित है, और अन्य कंपनी की जानकारी तक पहुंच नहीं है।
बहु उदाहरण :
- साझा किए गए या बिना होस्ट किए गए होस्ट / हार्डवेयर, प्रति उदाहरण कोड, और डेटाबेस प्रति उदाहरण।
- यह कठिन कार्यक्षमता या ठीक कीड़े विस्तार करने के लिए (मुझे यकीन है कि डोकर में यह करने के लिए जहां एक उदाहरण या डोकर कंटेनर के लिए कार्यक्षमता / सुविधा जोड़ सकते हैं और इसे दूसरों को तैनात एक तरह से वहाँ है अगर नहीं कर रहा हूँ)।
- यह आसान किसी भिन्न होस्ट / हार्डवेयर के लिए पूरे उदाहरण ले जाने के लिए।
- उदाहरण के रूप में, मुझे उस परत का ध्यान रखने की आवश्यकता नहीं है क्योंकि प्रत्येक उदाहरण का अपना डेटाबेस होगा।
सभी फायदे और नुकसान बेमानी हैं क्योंकि मैं स्वयं कुछ भी करना चाहता हूं (जैसा कि प्रत्येक किरायेदार के लिए मैन्युअल रूप से एक उदाहरण बना रहा है), और यही कारण है कि मुझे डॉकर समाधान पर संदेह है, जब तक कि इसे हल करने का कोई तरीका नहीं है, जो शायद मुख्य है सवाल का कारण। मैं इसकी सराहना करता हूं यदि आप समाधान के संदर्भ में प्रश्न का उत्तर देंगे, और आपको क्यों लगता है कि यह दृष्टिकोण अन्य की तुलना में बेहतर है।
मामले में जो मदद करेगा (शायद?), हम लारवेल को बैक-एंड के लिए मुख्य ढांचे के रूप में उपयोग कर रहे हैं (सभी बाकी)।