क्लाइंट-सर्वर आर्किटेक्चर

1.1 एप्लीकेशन आर्किटेक्चर

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

बड़े सर्वर अनुप्रयोगों के लिए लोकप्रिय आर्किटेक्चर के उदाहरण:

• स्तरित वास्तुकला (स्तरित वास्तुकला)।
• स्तरित वास्तुकला।
• सर्विस ओरिएंटेड आर्किटेक्चर (SOA)।
• माइक्रोसर्विस आर्किटेक्चर (माइक्रोसर्विस आर्किटेक्चर)।

उनमें से प्रत्येक के अपने पेशेवरों और विपक्ष हैं। लेकिन उनका अध्ययन करने से आपको कुछ नहीं मिलेगा। आर्किटेक्चर प्रश्न का उत्तर है "सिस्टम के भीतर हजारों वस्तुओं की बातचीत को कैसे व्यवस्थित करें" । और जब तक आप समस्या की पूरी जटिलता का अनुभव नहीं करेंगे, तब तक आप समाधान की पूरी बहुमुखी प्रतिभा को नहीं समझ पाएंगे।

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

"जहाँ आवश्यक हो वहाँ परिवर्तन करें" का क्या अर्थ है? क्या ऐसे स्थान हैं जहाँ आपको परिवर्तन करने की आवश्यकता नहीं है? बिल्कुल।

विशिष्ट होने के लिए, मान लें कि आप एक मध्यम बैकएंड प्रोजेक्ट पर काम कर रहे हैं । इसे 20 लोगों की टीम ने 5 साल के लिए लिखा है। इस परियोजना में 100 मानव-वर्ष लगे और इसमें कोड की लगभग 100 हजार पंक्तियाँ थीं। कुल मिलाकर, इसमें दो हजार वर्ग होते हैं, जो विभिन्न आकारों के 10 मॉड्यूल में विभाजित होते हैं।

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

यह कोई बुरा सपना नहीं है जो मैंने आपको डराने के लिए बनाया है। यह एक विशिष्ट परियोजना है। यह और भी बुरा होता है। ऐसा क्यों हो रहा है? इसके कई कारण हो सकते हैं, लेकिन लगभग हमेशा ऐसे होते हैं:

• बहुत सारे लोग परियोजना पर काम करते हैं - उनमें से प्रत्येक इसे थोड़ा अलग तरीके से देखता है।
• 5 साल में प्रोजेक्ट में 10 लोग बदल गए, नए लोगों को यह ज्यादा समझ नहीं आया।
• सॉफ्टवेयर बनाना लगातार बदलाव करना है जो हर चीज को लगातार बदलता रहता है।
• पांच साल पहले, जब हमने आर्किटेक्चर पर फैसला किया, तो प्रोजेक्ट का आइडिया कुछ अलग था।

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

1.2 क्लाइंट-सर्वर इंटरैक्शन की अवधारणा

अब हम उस अवधारणा को समझेंगे जो क्लाइंट-सर्वर आर्किटेक्चर को रेखांकित करती है और आपको यह बेहतर ढंग से समझने की अनुमति देगी कि इंटरनेट पर लाखों कार्यक्रमों की बातचीत कैसे आयोजित की जाती है।

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

निम्नलिखित उदाहरण सर्वर के रूप में दिए जा सकते हैं:

• वेब सर्वर जैसे टॉमकैट।
• डेटाबेस सर्वर जैसे MySQL।
• पेमेंट गेटवे जैसे स्ट्राइप।

क्लाइंट और सर्वर आमतौर पर इंटरनेट के माध्यम से संचार करते हैं (हालांकि वे एक ही स्थानीय क्षेत्र नेटवर्क में और सामान्य रूप से किसी अन्य प्रकार के नेटवर्क में काम कर सकते हैं)। संचार मानक प्रोटोकॉल जैसे HTTP, FTP, या निचले स्तर के प्रोटोकॉल जैसे TCP या UDP पर होता है।

प्रोटोकॉल आमतौर पर सर्वर द्वारा प्रदान की जाने वाली सेवा के प्रकार के अनुसार चुना जाता है। उदाहरण के लिए, यदि यह एक वीडियो कॉल है, तो आमतौर पर UDP का उपयोग किया जाता है।

याद रखें कि टॉमकैट और उसके सर्वलेट कैसे काम करते हैं? सर्वर एक HTTP संदेश प्राप्त करता है, इसे अनपैक करता है, वहां से सभी आवश्यक जानकारी निकालता है और इसे प्रसंस्करण के लिए सर्वलेट में भेजता है। फिर प्रसंस्करण परिणाम वापस HTTP-प्रतिक्रिया में पैक किया जाता है और क्लाइंट को भेजा जाता है।

यह विशिष्ट क्लाइंट-सर्वर इंटरैक्शन है। ब्राउज़र वेब क्लाइंट है और टॉमकैट वेब सर्वर है। टॉमकैट को वेब सर्वर भी कहा जाता है।

लेकिन अगर आप इसके बारे में सोचते हैं, तो नाम महत्वपूर्ण नहीं है, लेकिन सार - कार्यक्रमों के बीच भूमिकाओं का वितरण। HTML पेज में चलने वाली आपकी JS स्क्रिप्ट को क्लाइंट और आपके सर्वलेट को सर्वर कहा जा सकता है । आखिरकार, वे क्लाइंट-सर्वर अवधारणा के ढांचे के भीतर जोड़े में काम करते हैं ।

1.3 एक महत्वपूर्ण बारीकियाँ

यह भी ध्यान देने योग्य है कि क्लाइंट-सर्वर इंटरैक्शन इस सिद्धांत पर आधारित है कि इस तरह की बातचीत क्लाइंट द्वारा शुरू की जाती है : सर्वर केवल क्लाइंट को जवाब देता है और रिपोर्ट करता है कि क्या वह क्लाइंट को सेवा प्रदान कर सकता है और यदि हां, तो किन शर्तों पर .

इससे कोई फर्क नहीं पड़ता कि ग्राहक भौतिक रूप से कहाँ स्थित है और सर्वर कहाँ है। क्लाइंट सॉफ़्टवेयर और सर्वर सॉफ़्टवेयर आमतौर पर विभिन्न मशीनों पर स्थापित होते हैं, लेकिन वे एक ही कंप्यूटर पर भी चल सकते हैं।

इस अवधारणा को जटिल प्रणाली को सरल बनाने की दिशा में पहले कदम के रूप में विकसित किया गया था। उसके पास ये ताकतें हैं:

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

क्लाइंट और सर्वर के बीच बातचीत का सबसे बुनियादी संस्करण चित्र में दिखाया गया है:

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

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

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

महत्वपूर्ण वस्तुओं के जीवन चक्र की निगरानी की जानी चाहिए:

आप सर्वर पर new Thread().start(). इसके बजाय, आपके पास एक थ्रेडपूल होना चाहिए जो सभी सर्विस थ्रेड्स के बीच साझा करेगा।

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

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

1.4 क्लाइंट-सर्वर आर्किटेक्चर

एक अन्य महत्वपूर्ण बिंदु। क्लाइंट-सर्वर आर्किटेक्चर कंप्यूटर के बीच बातचीत के केवल सामान्य सिद्धांतों को परिभाषित करता है , बातचीत का विवरण विभिन्न प्रोटोकॉल द्वारा निर्धारित किया जाता है।

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

क्लाइंट-सर्वर इंटरैक्शन आर्किटेक्चर दो प्रकार के होते हैं: पहले को टू-टियर क्लाइंट-सर्वर आर्किटेक्चर कहा जाता है, दूसरा मल्टी-टियर क्लाइंट-सर्वर आर्किटेक्चर है (कभी-कभी थ्री-टियर आर्किटेक्चर या थ्री-टियर आर्किटेक्चर कहा जाता है, लेकिन यह एक विशेष मामला है)।

क्लाइंट-सर्वर इंटरैक्शन के टू-टियर आर्किटेक्चर के संचालन का सिद्धांत यह है कि इस प्रसंस्करण की प्रक्रिया में अन्य सर्वरों को संदर्भित किए बिना एक सर्वर पर एक अनुरोध का प्रसंस्करण होता है।

टू-टियर क्लाइंट-सर्वर इंटरैक्शन मॉडल को एक साधारण आरेख के रूप में तैयार किया जा सकता है।

यहां आप देख सकते हैं कि पहला स्तर वह सब कुछ है जो क्लाइंट से संबंधित है, और दूसरा स्तर वह सब कुछ है जो सर्वर से संबंधित है।