त्रिस्तरीय वास्तुकला

त्रि-स्तरीय वास्तुकला का परिचय

थ्री-टियर आर्किटेक्चर इंटरनेट पर सबसे आम इंटरैक्शन आर्किटेक्चर है। यह तब प्रकट हुआ जब दो-स्तरीय सर्वर भाग को दो भागों में विभाजित किया गया: एक तर्क परत और एक डेटा परत ।

यह कुछ ऐसा दिखता था:

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

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

दूसरे, यह एक साधारण व्यावसायिक तर्क है। उदाहरण के लिए, यदि किसी ऑनलाइन स्टोर ने उत्पादों की सूची भेजी है, तो हम उन्हें क्लाइंट साइड पर सॉर्ट और फ़िल्टर कर सकते हैं। और आदिम डेटा भंडारण भी यहाँ है: कैशिंग, लॉग-इन उपयोगकर्ता कुकीज़, और इसी तरह।

व्यापार तर्क परत दूसरे स्तर पर स्थित है, अधिकांश व्यावसायिक तर्क इस पर केंद्रित हैं। इसके बाहर, केवल अंश जो क्लाइंट को निर्यात किए जाते हैं, साथ ही डेटाबेस में विसर्जित तर्क तत्व (संग्रहीत कार्यविधियाँ और ट्रिगर) बने रहते हैं।

व्यापार तर्क सर्वर के एक बहुत हिस्से में न केवल यही तर्क होता है, बल्कि स्केलिंग समस्याओं को भी हल करता है: कोड को भागों में विभाजित किया जाता है और विभिन्न सर्वरों को वितरित किया जाता है। कुछ अत्यधिक मांग वाली सेवाएं दर्जनों सर्वरों पर चल सकती हैं। उनके बीच लोड को लोड बैलेंसर द्वारा प्रबंधित किया जाता है।

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

डेटा परत डेटा भंडारण प्रदान करती है और इसे एक अलग स्तर पर रखा जाता है, एक नियम के रूप में, डेटाबेस प्रबंधन प्रणाली (डीबीएमएस) के माध्यम से लागू किया जाता है, इस घटक से कनेक्शन केवल एप्लिकेशन सर्वर स्तर से प्रदान किया जाता है।

डेटा स्तर को अलग करने के कारण

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

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

बढ़े हुए लोड के साथ, बैकएंड को आसानी से डुप्लिकेट किया जा सकता था और एक सर्वर की दस प्रतियां बढ़ाई जा सकती थीं, लेकिन डेटाबेस को डुप्लिकेट करना असंभव था - डेटाबेस अभी भी सिस्टम का एकल और अविभाज्य घटक बना रहा।

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

सभी तर्क जो डेटा से बंधे नहीं थे, उन्हें बैकएंड पर ले जाया गया और दर्जनों सर्वरों पर समानांतर में लॉन्च किया गया। डेटा से गंभीर रूप से बंधा सब कुछ DBMS के अंदर बना रहा, और वहाँ पहले से ही बढ़े हुए भार की समस्याओं को हमारे अपने तरीकों से हल करना पड़ा:

• एक डेटाबेस क्लस्टर डेटाबेस सर्वर का एक समूह है जो समान डेटा को संग्रहीत करता है और एक विशिष्ट प्रोटोकॉल का उपयोग करके इसे सिंक्रनाइज़ करता है।
• शेयरिंग - डेटा को लॉजिकल ब्लॉक्स में विभाजित किया जाता है और विभिन्न डेटाबेस सर्वरों में वितरित किया जाता है। इस दृष्टिकोण के साथ डेटाबेस परिवर्तन को बनाए रखना बहुत कठिन है।
• NoSQL दृष्टिकोण डेटा को बड़ी मात्रा में डेटा संग्रहीत करने के लिए बनाए गए डेटाबेस में संग्रहीत करना है। ये अक्सर डेटाबेस भी नहीं होते हैं, लेकिन विशिष्ट फ़ाइल स्टोरेज होते हैं। रिलेशनल डेटाबेस की तुलना में बहुत खराब कार्यक्षमता।
• डेटा कैशिंग। डेटाबेस स्तर पर एक साधारण कैश के बजाय, संपूर्ण कैशिंग DBMS दिखाई दिया, जिसने परिणाम को केवल मेमोरी में संग्रहीत किया।

यह स्पष्ट है कि सर्वर प्रौद्योगिकियों के इस चिड़ियाघर को प्रबंधित करने के लिए अलग-अलग लोगों और/या पूरी टीमों की आवश्यकता थी, जिसके कारण डेटा परत को एक अलग परत में हटा दिया गया।

महत्वपूर्ण! सभी उन्नत प्रौद्योगिकियां बड़े आईटी निगमों की गहराई में पैदा होती हैं, जब पुराने दृष्टिकोण अब नई चुनौतियों का सामना नहीं करते हैं। डेटाबेस को एक अलग परत में बनाने का आविष्कार किसी प्रोग्रामर ने नहीं किया था, बल्कि इंजीनियरों के एक समूह ने ओरेकल या आईबीएम की गहराई में कहीं किया था।

दिलचस्प! जब जुकरबर्ग ने फेसबुक लिखना शुरू किया, तो उन्होंने केवल PHP+MySQL पर काम किया। जब लाखों उपयोगकर्ता थे, तो उन्होंने एक विशेष अनुवादक लिखा जिसने सभी PHP कोड को C ++ में अनुवादित किया और इसे देशी मशीन कोड में संकलित किया।

साथ ही, MySQL अरबों उपयोगकर्ताओं के डेटा को संग्रहीत करने में सक्षम नहीं है, इसलिए Facebook ने NoSQL डेटाबेस की अवधारणा विकसित की और एक शक्तिशाली सर्वर-साइड NoSQL DBMS - कैसेंड्रा लिखा। वैसे, यह पूरी तरह से जावा में लिखा गया है।

अनुप्रयोग तर्क स्थान अस्पष्टता

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

ऐसी अस्पष्टता का एक उदाहरण नीचे दी गई तस्वीर में दिखाया गया है:

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

सबसे बाएं विकल्प का एक उदाहरण एक विशिष्ट PHP सर्वर है, जिसमें सर्वर पर सभी तर्क हैं, और यह क्लाइंट को पहले से ही स्थिर HTML देता है। कहीं इन दो चरम सीमाओं के बीच, आपकी परियोजना स्थित होगी।

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

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