त्रिस्तरीय आर्किटेक्चर

त्रिस्तरीय आर्किटेक्चरचा परिचय

तीन-स्तरीय आर्किटेक्चर हे इंटरनेटवरील सर्वात सामान्य परस्परसंवाद आर्किटेक्चर आहे. जेव्हा दोन-स्तरीय सर्व्हर भाग दोन भागांमध्ये विभागला गेला तेव्हा ते दिसून आले: एक तर्क स्तर आणि डेटा स्तर .

हे असे काहीतरी दिसत होते:

क्लायंट लेयर हा "वितरित अनुप्रयोग" चा भाग आहे जो वापरकर्त्याच्या परस्परसंवादासाठी जबाबदार आहे. या स्तरामध्ये व्यवसाय तर्क नसावा आणि गंभीर डेटा संग्रहित करू नये. तसेच, हे डेटाबेस लेयरशी थेट संवाद साधू नये, परंतु केवळ व्यवसाय तर्क स्तराद्वारे.

तथापि, येथे अजूनही काही तर्क आहे. प्रथम, हा इंटरफेसद्वारे वापरकर्त्याशी संवाद आहे, त्याने प्रविष्ट केलेल्या डेटाचे प्रमाणीकरण, स्थानिक फायलींसह कार्य करणे. यामध्ये सर्व्हरसह काम करताना वापरकर्ता अधिकृतता आणि डेटा एन्क्रिप्शनशी संबंधित प्रत्येक गोष्टीचा देखील समावेश आहे.

दुसरे म्हणजे, हे एक साधे व्यावसायिक तर्क आहे. उदाहरणार्थ, जर एखाद्या ऑनलाइन स्टोअरने उत्पादनांची सूची पाठवली, तर आम्ही त्यांना क्लायंटच्या बाजूने वर्गीकृत आणि फिल्टर करू शकतो. आणि आदिम डेटा स्टोरेज देखील येथे आहे: कॅशिंग, लॉग-इन केलेल्या वापरकर्त्याच्या कुकीज आणि यासारखे.

बिझनेस लॉजिक लेयर दुसऱ्या स्तरावर स्थित आहे, बहुतेक व्यवसाय लॉजिक त्यावर केंद्रित आहे. त्याच्या बाहेर, केवळ क्लायंटला निर्यात केलेले तुकडे, तसेच डेटाबेसमध्ये बुडलेले तर्क घटक (संचयित प्रक्रिया आणि ट्रिगर) राहतात.

बिझनेस लॉजिक सर्व्हरच्या एका भागामध्ये फक्त हेच लॉजिक नसते, तर स्केलिंग समस्या देखील सोडवते: कोड भागांमध्ये विभागला जातो आणि वेगवेगळ्या सर्व्हरवर वितरित केला जातो. काही अत्यंत मागणी असलेल्या सेवा डझनभर सर्व्हरवर चालू शकतात. त्यांच्यातील भार लोड बॅलन्सरद्वारे व्यवस्थापित केला जातो.

सर्व्हर ऍप्लिकेशन्स सहसा अशा प्रकारे डिझाइन केले जातात की सर्व्हरची दुसरी प्रत सहजपणे लॉन्च केली जाऊ शकते आणि त्याच्या इतर प्रतींच्या सहकार्याने कार्य करण्यास सुरवात केली जाते. म्हणजेच, सर्व्हर कोड लिहिण्याच्या प्रक्रियेतही, तुमचा स्टॅटिक क्लास एकाच वेळी लॉन्च केला जाईल याची तुम्हाला कधीही हमी मिळणार नाही.

डेटा लेयर डेटा स्टोरेज प्रदान करते आणि वेगळ्या स्तरावर ठेवला जातो, नियमानुसार, डेटाबेस मॅनेजमेंट सिस्टम (DBMS) द्वारे लागू केला जातो, या घटकाशी कनेक्शन केवळ ऍप्लिकेशन सर्व्हर स्तरावरून प्रदान केले जाते.

डेटा स्तर वेगळे करण्याची कारणे

डेटा लेयरचे पूर्ण वाढ झालेल्या तिसऱ्या लेयरमध्ये विभक्त होणे अनेक कारणांमुळे झाले, परंतु मुख्य म्हणजे सर्व्हरवरील वाढलेला भार.

प्रथम, डेटाबेसला डेटा प्रोसेसिंगसाठी भरपूर मेमरी आणि प्रोसेसर वेळ आवश्यक आहे . म्हणून, ते सर्वत्र स्वतंत्र सर्व्हरवर ठेवले जाऊ लागले.

वाढलेल्या लोडसह, बॅकएंड सहजपणे डुप्लिकेट केले जाऊ शकते आणि एका सर्व्हरच्या दहा प्रती वाढवल्या जाऊ शकतात, परंतु डेटाबेसची नक्कल करणे अशक्य होते - डेटाबेस अद्याप सिस्टमचा एकल आणि अविभाज्य घटक राहिला.

दुसरे म्हणजे, डेटाबेस स्मार्ट झाले आहेत - त्यांचे स्वतःचे व्यवसाय तर्क आहे. त्यांनी संग्रहित प्रक्रिया, ट्रिगर, त्यांच्या स्वतःच्या भाषा जसे की PLSQL चे समर्थन करण्यास सुरुवात केली. आणि प्रोग्रामर देखील दिसू लागले ज्यांनी डीबीएमएसमध्ये चालणारा कोड लिहायला सुरुवात केली.

डेटाशी जोडलेले नसलेले सर्व तर्क बॅकएंडवर नेले गेले आणि डझनभर सर्व्हरवर समांतरपणे लॉन्च केले गेले. डेटाशी गंभीरपणे जोडलेली प्रत्येक गोष्ट डीबीएमएसमध्येच राहिली आणि तेथे आधीच वाढलेल्या लोडच्या समस्या आमच्या स्वतःच्या पद्धती वापरून सोडवाव्या लागल्या:

• डेटाबेस क्लस्टर डेटाबेस सर्व्हरचा एक समूह आहे जो समान डेटा संचयित करतो आणि विशिष्ट प्रोटोकॉल वापरून समक्रमित करतो.
• Sharding - डेटा लॉजिकल ब्लॉक्समध्ये विभाजित केला जातो आणि वेगवेगळ्या डेटाबेस सर्व्हरवर वितरित केला जातो. या दृष्टिकोनातून डेटाबेस बदल राखणे खूप कठीण आहे.
• NoSQL दृष्टीकोन डेटाबेसमध्ये डेटा संग्रहित करणे आहे जे मोठ्या प्रमाणात डेटा संचयित करण्यासाठी तयार केले जातात. हे सहसा डेटाबेस नसतात, परंतु विशिष्ट फाइल स्टोरेज असतात. रिलेशनल डेटाबेसच्या तुलनेत खूप खराब कार्यक्षमता.
• डेटा कॅशिंग. डेटाबेस स्तरावर साध्या कॅशेऐवजी, संपूर्ण कॅशिंग डीबीएमएस दिसू लागले, ज्याने परिणाम केवळ मेमरीमध्ये संग्रहित केला.

हे स्पष्ट आहे की सर्व्हर तंत्रज्ञानाच्या या प्राणीसंग्रहालयाचे व्यवस्थापन करण्यासाठी स्वतंत्र लोक आणि/किंवा संपूर्ण संघांची आवश्यकता होती, ज्यामुळे डेटा लेयरला वेगळ्या स्तरामध्ये काढून टाकण्यात आले.

महत्वाचे! सर्व प्रगत तंत्रज्ञान मोठ्या आयटी कॉर्पोरेशनच्या खोलीत जन्माला येतात, जेव्हा जुने दृष्टिकोन यापुढे नवीन आव्हानांचा सामना करू शकत नाहीत. डेटाबेसेस एका वेगळ्या लेयरमध्ये बनवण्याचा शोध कोणत्याही प्रोग्रामरने लावला नाही, तर ओरॅकल किंवा IBM च्या खोलवर असलेल्या अभियंत्यांच्या गटाने शोधला होता.

मनोरंजक! जेव्हा झुकरबर्गने फेसबुक लिहायला सुरुवात केली तेव्हा त्याने फक्त PHP + MySQL वर काम केले. जेव्हा लाखो वापरकर्ते होते, तेव्हा त्यांनी एक विशेष अनुवादक लिहिला ज्याने सर्व PHP कोड C++ मध्ये अनुवादित केले आणि ते मूळ मशीन कोडमध्ये संकलित केले.

तसेच, MySQL अब्जावधी वापरकर्त्यांचा डेटा संचयित करण्यास सक्षम नाही, म्हणून Facebook ने NoSQL डेटाबेसची संकल्पना विकसित केली आणि एक शक्तिशाली सर्व्हर-साइड NoSQL DBMS - Cassandra लिहिला. तसे, ते पूर्णपणे Java मध्ये लिहिलेले आहे.

ऍप्लिकेशन लॉजिक स्थान अस्पष्टता

आणि जरी त्रि-स्तरीय आर्किटेक्चर जवळजवळ निःसंदिग्धपणे त्याच्या भागांमध्ये भूमिका वितरीत करत असले तरी, सिस्टममध्ये व्यवसाय तर्कशास्त्राचा नवीन भाग (नवीन कोड) कोठे जोडणे आवश्यक आहे हे अचूकपणे निर्धारित करणे नेहमीच शक्य नसते.

अशा अस्पष्टतेचे उदाहरण खालील चित्रात दर्शविले आहे:

सर्व्हरचा भाग राखाडी पार्श्वभूमीने भरलेला आहे, क्लायंटचा भाग पांढऱ्या रंगाने भरलेला आहे. नंतरच्या दृष्टिकोनाचे एक चांगले उदाहरण (अगदी उजवीकडे) आधुनिक मोबाइल अॅप्स आहे. क्लायंट साइड (फोनवर) दृश्य (प्रदर्शन), तर्कशास्त्र आणि डेटा समाविष्टीत आहे. आणि केवळ कधीकधी हा डेटा सर्व्हरसह समक्रमित केला जातो.

सर्वात डावीकडील पर्यायाचे उदाहरण म्हणजे एक सामान्य PHP सर्व्हर, ज्यामध्ये सर्व्हरवर सर्व तर्कशास्त्र आहे आणि ते क्लायंटला आधीपासूनच स्थिर HTML देते. या दोन टोकांच्या दरम्यान कुठेतरी तुमचा प्रकल्प असेल.

कामाच्या सुरूवातीस, आपण प्रकल्पाशी परिचित झाल्यानंतर, आपल्याला त्यावर काम करणार्या प्रोग्रामरशी सल्लामसलत करणे आवश्यक आहे, पुढील कार्याचे तर्क लागू करणे आपल्यासाठी अधिक चांगले आहे.

तसे करण्यास मोकळेपणाने. प्रथम, ते त्यांच्या सनदीसह इतर कोणाच्या मठात चढत नाहीत. दुसरे म्हणजे, तुम्हाला आवश्यक असलेला कोड शोधणे प्रत्येकासाठी (आणि तुम्हालाही) सोपे होईल जिथे तुम्हाला तो सापडेल.