वितरित अनुप्रयोगांचे बिल्डिंग ब्लॉक्स. शून्य अंदाजे

जग स्थिर नाही. प्रगतीमुळे नवीन तांत्रिक आव्हाने निर्माण होतात. बदलत्या आवश्यकतांनुसार, माहिती प्रणालीचे आर्किटेक्चर विकसित झाले पाहिजे. आज आपण इव्हेंट-चालित आर्किटेक्चर, कॉन्करन्सी, कॉन्करन्सी, असिंक्रोनी आणि एर्लांगमध्ये या सर्वांसह आपण शांततेने कसे जगू शकता याबद्दल बोलू.

परिचय

डिझाइन केलेल्या सिस्टमच्या आकारावर आणि त्यासाठीच्या आवश्यकतांवर अवलंबून, आम्ही, विकासक, सिस्टममधील माहितीची देवाणघेवाण करण्याची पद्धत निवडतो. बर्याच बाबतीत, सेवांचा परस्परसंवाद आयोजित करण्यासाठी, कार्यरत पर्याय ब्रोकरसह योजना असू शकते, उदाहरणार्थ, RabbitMQ किंवा kafka वर आधारित. परंतु कधीकधी इव्हेंटचा प्रवाह, SLA आणि सिस्टमवरील नियंत्रणाची पातळी अशी असते की तयार मेसेजिंग आमच्यासाठी योग्य नसते. अर्थात, तुम्ही ट्रान्सपोर्ट लेयर आणि क्लस्टर फॉर्मेशनची जबाबदारी घेऊन सिस्टमला थोडे क्लिष्ट करू शकता, उदाहरणार्थ ZeroMQ किंवा nanomsg वापरून. परंतु जर सिस्टममध्ये प्रमाणित एर्लांग क्लस्टरची पुरेशी थ्रूपुट आणि क्षमता असेल, तर अतिरिक्त घटक सादर करण्याच्या मुद्द्यासाठी तपशीलवार अभ्यास आणि आर्थिक औचित्य आवश्यक आहे.

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

सैद्धांतिक आधार

डिझाईनची सुरुवात उद्दिष्टे आणि मर्यादा ठरवून होते. मुख्य ध्येय विकासासाठी विकासाच्या क्षेत्रात नाही. आम्हाला एक सुरक्षित आणि स्केलेबल साधन मिळणे आवश्यक आहे ज्याच्या आधारे आम्ही विविध स्तरांचे आधुनिक ऍप्लिकेशन तयार करू शकतो आणि सर्वात महत्वाचे म्हणजे विकसित करू शकतो: एकल-सर्व्हर ऍप्लिकेशन्सपासून सुरुवात करून लहान प्रेक्षकांना सेवा देणे, जे नंतर 50 पर्यंत क्लस्टरमध्ये विकसित होऊ शकते. -60 नोड्स, क्लस्टर फेडरेशनसह समाप्त होतात. अशा प्रकारे, अंतिम प्रणालीच्या विकासाची आणि मालकीची किंमत कमी करून नफा वाढवणे हे मुख्य ध्येय आहे.

अंतिम प्रणालीसाठी 4 मुख्य आवश्यकता हायलाइट करूया:

• Сइव्हेंट-देणारं.
  घटनांच्या प्रवाहातून जाण्यासाठी आणि आवश्यक कृती करण्यासाठी यंत्रणा नेहमीच तयार असते;
• Мस्केलेबिलिटी
  वैयक्तिक ब्लॉक्स अनुलंब आणि क्षैतिज दोन्ही प्रमाणात मोजले जाऊ शकतात. संपूर्ण प्रणाली असीम क्षैतिज वाढ करण्यास सक्षम असणे आवश्यक आहे;
• Оचुकीची सहनशीलता.
  सर्व स्तर आणि सर्व सेवा आपोआप अयशस्वी होण्यास सक्षम असाव्यात;
• Гहमी प्रतिसाद वेळ.
  वेळ मौल्यवान आहे आणि वापरकर्त्यांनी जास्त वेळ थांबू नये.

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

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

प्रसंगाभिमुख

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

स्केलेबिलिटी

स्केलेबिलिटी आणि सिस्टम कार्यक्षमता एकमेकांच्या पुढे आहेत. अनुप्रयोग घटक सर्व उपलब्ध संसाधने वापरण्यास सक्षम असणे आवश्यक आहे. आपण क्षमतेचा जितका अधिक कार्यक्षमतेने वापर करू शकतो आणि आपल्या प्रक्रिया पद्धती जितक्या चांगल्या प्रकारे वापरता येतील तितके कमी पैसे आपण उपकरणांवर खर्च करू शकतो.

एकाच मशीनमध्ये, एर्लांग एक अत्यंत स्पर्धात्मक वातावरण तयार करते. एरलांग VM ला उपलब्ध ऑपरेटिंग सिस्टम थ्रेड्सची संख्या आणि या थ्रेड्सचा वापर करणार्‍या शेड्युलरची संख्या निवडून समांतरता आणि समांतरता यांच्यातील संतुलन सेट केले जाऊ शकते.
एर्लांग प्रक्रिया राज्य सामायिक करत नाहीत आणि नॉन-ब्लॉकिंग मोडमध्ये कार्य करतात. हे पारंपारिक ब्लॉकिंग-आधारित अनुप्रयोगांपेक्षा तुलनेने कमी विलंब आणि उच्च थ्रूपुट प्रदान करते. एर्लांगचे शेड्युलर CPU आणि IO चे योग्य वाटप सुनिश्चित करते आणि ब्लॉकिंगची अनुपस्थिती कमाल लोड किंवा अयशस्वी असताना देखील ऍप्लिकेशनला प्रतिसाद देण्यास अनुमती देते.

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

व्यवसायाच्या दृष्टिकोनातून, स्केलेबिलिटी हे जोखीम व्यवस्थापन साधनांपैकी एक आहे. उपकरणे चांगल्या प्रकारे वापरून ग्राहकांच्या विनंत्या पूर्ण करणे ही मुख्य गोष्ट आहे:

• जेव्हा प्रगतीच्या परिणामी उपकरणांची शक्ती वाढते. अपूर्ण सॉफ्टवेअरमुळे ते निष्क्रिय होणार नाही. एर्लांग अनुलंब स्केल करते आणि सर्व CPU कोर आणि उपलब्ध मेमरी वापरण्यास नेहमीच सक्षम असेल;
• क्लाउड वातावरणात, आम्ही वर्तमान किंवा अंदाजित लोड आणि हमी SLA यावर अवलंबून उपकरणांचे प्रमाण व्यवस्थापित करू शकतो.

चुकीची सहनशीलता

चला दोन स्वयंसिद्ध गोष्टींचा विचार करूया: "अपयश अस्वीकार्य आहेत" आणि "नेहमी अपयशी असतील." व्यवसायासाठी, सॉफ्टवेअर अयशस्वी म्हणजे पैशाची हानी, आणि सर्वात वाईट म्हणजे प्रतिष्ठा गमावणे. संभाव्य नुकसान आणि फॉल्ट-सहिष्णु सॉफ्टवेअर विकसित करण्याच्या खर्चामध्ये संतुलन साधून, अनेकदा तडजोड केली जाऊ शकते.

अल्पावधीत, दोष सहिष्णुता समाविष्ट करणारे आर्किटेक्चर ऑफ-द-शेल्फ क्लस्टरिंग सोल्यूशन्स खरेदी करण्यावर पैसे वाचवते. ते महाग आहेत आणि त्यात बग देखील आहेत.
दीर्घकाळात, दोष-सहिष्णु वास्तुकला विकासाच्या सर्व टप्प्यांवर स्वतःसाठी अनेक वेळा पैसे देते.
कोड बेसमधील संदेशन तुम्हाला विकासाच्या टप्प्यावर सिस्टममधील घटकांच्या परस्परसंवादाचे तपशीलवार कार्य करण्यास अनुमती देते. हे अपयशांना प्रतिसाद देण्याचे आणि व्यवस्थापित करण्याचे कार्य सुलभ करते, कारण सर्व गंभीर घटक अपयश हाताळतात आणि परिणामी सिस्टमला डिझाइनद्वारे अपयशी झाल्यानंतर आपोआप सामान्य कसे व्हावे हे माहित असते.

प्रतिसाद

अपयशाची पर्वा न करता, अर्जाने विनंत्यांना प्रतिसाद देणे आणि SLA ला भेटणे आवश्यक आहे. वास्तविकता अशी आहे की लोक प्रतीक्षा करू इच्छित नाहीत, म्हणून व्यवसायांनी त्यानुसार परिस्थितीशी जुळवून घेतले पाहिजे. अधिकाधिक अॅप्लिकेशन्स अत्यंत प्रतिसाद देणारे असतील अशी अपेक्षा आहे.
रिस्पॉन्सिव्ह अॅप्लिकेशन्स जवळपास रिअल टाइममध्ये काम करतात. एर्लांग व्हीएम सॉफ्ट रिअल-टाइम मोडमध्ये कार्य करते. काही क्षेत्रांसाठी, जसे की स्टॉक ट्रेडिंग, औषध आणि औद्योगिक उपकरणे नियंत्रण, हार्ड रिअल-टाइम मोड महत्त्वाचा आहे.
प्रतिसाद देणारी प्रणाली UX सुधारते आणि व्यवसायाला फायदा देते.

प्राथमिक सारांश

या लेखाचे नियोजन करताना, मला मेसेजिंग ब्रोकर तयार करण्याचा आणि त्यावर आधारित जटिल प्रणाली तयार करण्याचा माझा अनुभव सांगायचा होता. परंतु सैद्धांतिक आणि प्रेरक भाग बराच विस्तृत असल्याचे दिसून आले.
लेखाच्या दुसऱ्या भागात, मी एक्सचेंज पॉइंट्स, मेसेजिंग पॅटर्न आणि त्यांच्या ऍप्लिकेशनची अंमलबजावणी करण्याच्या सूक्ष्म गोष्टींबद्दल बोलेन.
तिसर्‍या भागात आपण सेवांचे आयोजन, मार्गक्रमण आणि समतोल साधण्याच्या सामान्य मुद्द्यांचा विचार करू. चला स्केलेबिलिटीच्या व्यावहारिक बाजू आणि सिस्टमच्या दोष सहिष्णुतेबद्दल बोलूया.

पहिल्या भागाचा शेवट.

फोटो @लुकाब्राव्हो.

स्त्रोत: www.habr.com