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

हा कोर्स नवशिक्यांसाठी डिझाइन केला आहे, कारण तुम्ही दीर्घकाळ गंभीर ऍप्लिकेशनचे आर्किटेक्चर डिझाइन करणार नाही. परंतु काळजी करू नका, नियमापेक्षा चांगली वास्तुकला अपवाद आहे. अनुप्रयोग तयार करण्यापूर्वी योग्य अनुप्रयोग आर्किटेक्चर निवडणे खूप कठीण आहे .

मोठ्या सर्व्हर अनुप्रयोगांसाठी लोकप्रिय आर्किटेक्चरची उदाहरणे:

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

त्यांच्यापैकी प्रत्येकाचे त्याचे फायदे आणि तोटे आहेत. पण त्यांचा अभ्यास केल्याने तुम्हाला काहीही मिळणार नाही. आर्किटेक्चर हे "सिस्टममधील हजारो वस्तूंच्या परस्परसंवादाचे आयोजन कसे करावे" या प्रश्नाचे उत्तर आहे . आणि जोपर्यंत आपण समस्येची संपूर्ण जटिलता अनुभवत नाही तोपर्यंत, आपण समाधानाची संपूर्ण अष्टपैलुत्व समजू शकणार नाही.

सर्व अनुप्रयोग काही प्रकारचे आर्किटेक्चर वापरतात किंवा किमान ढोंग करतात. म्हणून, ऍप्लिकेशन डिझाइनच्या लोकप्रिय पध्दतींचे ज्ञान तुम्हाला ऍप्लिकेशन कसे कार्य करते हे द्रुतपणे आणि चांगल्या प्रकारे समजून घेण्यास अनुमती देईल. आणि याचा अर्थ असा आहे की आपल्याला आवश्यक असलेल्या ठिकाणी बदल करणे.

"आवश्यक तेथे बदल करा" याचा अर्थ काय? तुम्हाला बदल करण्याची गरज नाही अशी काही ठिकाणे आहेत का? नक्की.

विशिष्ट होण्यासाठी, समजा तुम्ही मध्यम बॅकएंड प्रकल्पावर काम करत आहात . हे 20 लोकांच्या टीमने 5 वर्षांपासून लिहिले आहे. प्रकल्पाला 100 मानव-वर्षे लागली आणि त्यात सुमारे 100 हजार ओळी कोड आहेत. एकूण, यात दोन हजार वर्ग आहेत, जे वेगवेगळ्या आकाराच्या 10 मॉड्यूलमध्ये विभागलेले आहेत.

आणि एक कठोर वास्तव जोडा. काही कार्यांचे तर्क अनेक मॉड्यूल्समध्ये पसरलेले असतात. तसेच, बिझनेस लॉजिक हे फ्रंटएंडमध्ये (जावास्क्रिप्टमध्ये लिहिलेले) आणि/किंवा थेट डेटाबेसमध्ये संग्रहित प्रक्रिया म्हणून लिहिलेले असू शकते. तुम्हाला अजूनही खात्री आहे की तुम्ही नेमके कुठे बदल करायचे ते ठिकाण लगेच ठरवू शकाल ?

हे काही भयानक स्वप्न नाही जे मी तुम्हाला घाबरवण्यासाठी बनवले आहे. हा एक वैशिष्ट्यपूर्ण प्रकल्प आहे. ते आणखी वाईट घडते. असे का होत आहे? अनेक कारणे असू शकतात, परंतु जवळजवळ नेहमीच अशी असतात:

  • बरेच लोक या प्रकल्पावर काम करतात - त्यांच्यापैकी प्रत्येकजण ते थोडे वेगळ्या पद्धतीने पाहतो.
  • 5 वर्षांपासून, प्रकल्पात 10 लोक बदलले आहेत, नवीन आलेल्यांना ते फारसे समजले नाही.
  • सॉफ्टवेअर तयार करणे हे सतत बदल घडवून आणणे आहे जे सतत सर्वकाही बदलत असते.
  • पाच वर्षांपूर्वी जेव्हा आम्ही आर्किटेक्चरचा निर्णय घेतला तेव्हा प्रकल्पाची कल्पना काहीशी वेगळी होती.

परंतु मुख्य गोष्ट अशी आहे की प्रकल्पाच्या आर्किटेक्चरची पर्वा न करता, त्यावर काम करणारे सर्व प्रोग्रामर हा प्रकल्प कसा कार्य करतो हे समान समजून घेत होते. चला सर्वात सोप्या संकल्पनेसह प्रारंभ करूया - क्लायंट-सर्व्हर आर्किटेक्चर.

1.2 क्लायंट-सर्व्हर परस्परसंवादाची संकल्पना

आता आम्ही क्लायंट-सर्व्हर आर्किटेक्चरची अधोरेखित संकल्पना समजून घेऊ आणि इंटरनेटवरील लाखो प्रोग्राम्सचा परस्परसंवाद कसा आयोजित केला जातो हे आपल्याला अधिक चांगल्या प्रकारे समजून घेण्यास अनुमती देईल.

नावाप्रमाणेच, या संकल्पनेत दोन पक्षांचा समावेश आहे: क्लायंट आणि सर्व्हर . येथे जीवनात सर्वकाही जसे आहे: क्लायंट या किंवा त्या सेवेचा ग्राहक आहे आणि सर्व्हर सेवा प्रदाता आहे. क्लायंट आणि सर्व्हर हे फिजिकल प्रोग्राम्स आहेत , उदाहरणार्थ ठराविक क्लायंट हा ब्राउझर आहे .

खालील उदाहरणे सर्व्हर म्हणून दिली जाऊ शकतात:

  • वेब सर्व्हर जसे की टॉमकॅट.
  • डेटाबेस सर्व्हर जसे की MySQL.
  • स्ट्राइप सारखे पेमेंट गेटवे.

क्लायंट आणि सर्व्हर सहसा इंटरनेटद्वारे संप्रेषण करतात (जरी ते समान लोकल एरिया नेटवर्कमध्ये आणि सर्वसाधारणपणे इतर कोणत्याही प्रकारच्या नेटवर्कमध्ये कार्य करू शकतात). एचटीटीपी, एफटीपी किंवा टीसीपी किंवा यूडीपी सारख्या निम्न-स्तरीय प्रोटोकॉल्सवर संप्रेषण केले जाते.

प्रोटोकॉल सहसा सर्व्हर प्रदान करत असलेल्या सेवेच्या प्रकारानुसार निवडला जातो. उदाहरणार्थ, जर तो व्हिडिओ कॉल असेल, तर UDP सहसा वापरला जातो.

टॉमकॅट आणि त्याचे सर्व्हलेट्स कसे कार्य करतात ते लक्षात ठेवा? सर्व्हरला HTTP संदेश प्राप्त होतो, तो अनपॅक करतो, तेथून सर्व आवश्यक माहिती काढतो आणि प्रक्रिया करण्यासाठी सर्व्हलेटकडे पाठवतो. नंतर प्रक्रिया परिणाम परत HTTP-प्रतिसादामध्ये पॅक केला जातो आणि क्लायंटला पाठविला जातो.

हा ठराविक क्लायंट-सर्व्हर परस्परसंवाद आहे. ब्राउझर हा वेब क्लायंट आहे आणि टॉमकॅट हा वेब सर्व्हर आहे. टॉमकॅटला वेब सर्व्हर देखील म्हणतात.

परंतु जर आपण त्याबद्दल विचार केला तर, हे नाव महत्त्वाचे नाही, परंतु सार - कार्यक्रमांमधील भूमिकांचे वितरण. एचटीएमएल पेजवर चालणारी तुमची JS स्क्रिप्ट क्लायंट म्हणू शकते आणि तुमच्या सर्व्हलेटला सर्व्हर . शेवटी, ते क्लायंट-सर्व्हर संकल्पनेच्या चौकटीत जोड्यांमध्ये कार्य करतात .

1.3 एक महत्वाची सूक्ष्मता

हे देखील लक्षात घेण्यासारखे आहे की क्लायंट-सर्व्हर परस्परसंवाद या तत्त्वावर आधारित आहे की असा परस्परसंवाद क्लायंटद्वारे सुरू केला जातो : सर्व्हर केवळ क्लायंटला उत्तर देतो आणि अहवाल देतो की तो क्लायंटला सेवा प्रदान करू शकतो की नाही आणि असल्यास, कोणत्या अटींवर .

क्लायंट भौतिकरित्या कुठे आहे आणि सर्व्हर कुठे आहे हे महत्त्वाचे नाही. क्लायंट सॉफ्टवेअर आणि सर्व्हर सॉफ्टवेअर सहसा वेगवेगळ्या मशीनवर स्थापित केले जातात, परंतु ते एकाच संगणकावर देखील चालू शकतात.

ही संकल्पना जटिल प्रणाली सुलभ करण्याच्या दिशेने पहिले पाऊल म्हणून विकसित केली गेली. तिच्याकडे ही सामर्थ्ये आहेत:

  • लॉजिक सरलीकरण : सर्व्हरला क्लायंटबद्दल आणि भविष्यात त्याचा डेटा कसा वापरला जाईल याबद्दल काहीही माहिती नसते.
  • कमकुवत क्लायंट असू शकतात : सर्व संसाधन-केंद्रित कार्ये सर्व्हरवर हस्तांतरित केली जाऊ शकतात.
  • क्लायंट कोड आणि सर्व्हर कोडचा स्वतंत्र विकास.
  • बरेच भिन्न क्लायंट, उदाहरणार्थ टॉमकॅट आणि भिन्न ब्राउझर.

क्लायंट आणि सर्व्हरमधील परस्परसंवादाची सर्वात मूलभूत आवृत्ती चित्रात दर्शविली आहे:

क्लायंट-सर्व्हर

येथे दोन तपशील लक्षात घेणे महत्त्वाचे आहे. प्रथम, चित्र दाखवते की अनेक क्लायंट एका सर्व्हरवर प्रवेश करू शकतात. दुसरे म्हणजे, ते एकाच वेळी त्यात प्रवेश करू शकतात. हा देखील सर्व्हरचा एक महत्त्वाचा भाग आहे.

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

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

महत्त्वाच्या वस्तूंचे जीवनचक्र निरीक्षण करणे आवश्यक आहे:

तुम्ही फक्त द्वारे सर्व्हरवर नवीन थ्रेड सुरू करू शकत नाही new Thread().start(). त्याऐवजी, तुमच्याकडे एक थ्रेडपूल असणे आवश्यक आहे जे सर्व सेवा थ्रेड्समध्ये सामायिक करेल.

तसेच, तुम्ही फक्त असिंक्रोनस टास्क सुरू करू शकत नाही, कारण ते स्वतंत्र थ्रेडमध्ये देखील कार्यान्वित केले जातात. असे कार्य तयार करताना, थ्रेड्सचा कोणता पूल ते कार्यान्वित करत आहे आणि असा पूल ओव्हरफ्लो झाल्यास काय होईल हे आपल्याला नेहमी माहित असले पाहिजे.

फाइल्स आणि निर्देशिकांसह सर्व कार्य संसाधनांसह प्रयत्न करून केले जाणे आवश्यक आहे. जर एखाद्या सामान्य ऍप्लिकेशनमध्ये तुम्ही स्ट्रीम किंवा फाइल बंद करण्यास विसरलात, तर ही समस्या आहे का? तुम्ही प्रोग्राममधून बाहेर पडाल तेव्हा ते स्वतःच बंद होईल. पण जर तुम्ही कोडमध्ये कुठेतरी सर्व्हरवर फाइल बंद करायला विसरलात आणि तुमचा सर्व्हर अनेक महिन्यांपासून चालू आहे... लवकरच अशा हजारो न उघडलेल्या फाइल्स जमा होतील आणि OS वाचण्यासाठी नवीन फाइल्स उघडणे बंद करेल (फायलींसह कार्य करा. OS द्वारे नियंत्रित आहे). टीमलीड तुमच्या डोक्यावर थाप देणार नाही...

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

आणखी एक महत्त्वाचा मुद्दा. क्लायंट-सर्व्हर आर्किटेक्चर संगणकांमधील परस्परसंवादाची केवळ सामान्य तत्त्वे परिभाषित करते , परस्परसंवादाचे तपशील विविध प्रोटोकॉलद्वारे निर्धारित केले जातात.

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

क्लायंट-सर्व्हर इंटरॅक्शन आर्किटेक्चरचे दोन प्रकार आहेत: पहिल्याला द्वि-स्तरीय क्लायंट-सर्व्हर आर्किटेक्चर म्हणतात, दुसरे म्हणजे मल्टी-टायर क्लायंट-सर्व्हर आर्किटेक्चर (कधीकधी तीन-स्तरीय आर्किटेक्चर किंवा तीन-स्तरीय आर्किटेक्चर म्हणतात, पण ही एक विशेष बाब आहे).

क्लायंट-सर्व्हर परस्परसंवादाच्या द्वि-स्तरीय आर्किटेक्चरच्या ऑपरेशनचे तत्त्व असे आहे की या प्रक्रियेच्या प्रक्रियेत इतर सर्व्हरचा संदर्भ न घेता विनंतीची प्रक्रिया एका सर्व्हरवर होते.

दोन-स्तरीय क्लायंट-सर्व्हर परस्परसंवाद मॉडेल एक साधे आकृती म्हणून काढले जाऊ शकते.

द्वि-स्तरीय क्लायंट-सर्व्हर आर्किटेक्चर

येथे तुम्ही पाहू शकता की पहिली पातळी क्लायंटशी संबंधित असलेली प्रत्येक गोष्ट आहे आणि दुसरी पातळी सर्व्हरशी संबंधित असलेली प्रत्येक गोष्ट आहे.