वितरित अनुप्रयोगहरूको निर्माण ब्लकहरू। शून्य अनुमान

संसार स्थिर छैन। प्रगतिले नयाँ प्राविधिक चुनौतीहरू सिर्जना गर्दछ। परिवर्तनशील आवश्यकताहरू अनुसार, सूचना प्रणालीको वास्तुकला विकसित हुनुपर्छ। आज हामी घटना-संचालित आर्किटेक्चर, कन्करेन्सी, कन्करेन्सी, एसिन्क्रोनी, र तपाईं कसरी एर्लांगमा यी सबैसँग शान्तिपूर्वक बाँच्न सक्नुहुन्छ भन्ने बारेमा कुरा गर्नेछौं।

परिचय

डिजाइन गरिएको प्रणालीको आकार र यसको लागि आवश्यकताहरूको आधारमा, हामी, विकासकर्ताहरूले प्रणालीमा जानकारी आदानप्रदान गर्ने विधि छनौट गर्छौं। अधिकतर अवस्थामा, सेवाहरूको अन्तरक्रियालाई व्यवस्थित गर्न, काम गर्ने विकल्प एक दलालसँग योजना हुन सक्छ, उदाहरणका लागि, RabbitMQ वा kafka मा आधारित। तर कहिलेकाहीँ घटनाहरूको प्रवाह, SLA र प्रणालीमा नियन्त्रणको स्तर यस्तो हुन्छ कि रेडिमेड सन्देश हाम्रो लागि उपयुक्त हुँदैन। अवश्य पनि, तपाईले यातायात तह र क्लस्टर गठनको जिम्मेवारी लिएर प्रणालीलाई अलिकति जटिल बनाउन सक्नुहुन्छ, उदाहरणका लागि ZeroMQ वा nanomsg प्रयोग गरेर। तर यदि प्रणालीसँग मानक एर्लांग क्लस्टरको पर्याप्त थ्रुपुट र क्षमताहरू छन् भने, त्यसपछि थप इकाई परिचय गर्ने मुद्दालाई विस्तृत अध्ययन र आर्थिक औचित्य चाहिन्छ।

प्रतिक्रियाशील वितरित अनुप्रयोगहरूको विषय धेरै फराकिलो छ। लेखको ढाँचा भित्र राख्नको लागि, आजको छलफलको विषय मात्र एर्लांग/एलिक्सिरमा निर्मित समानतापूर्ण वातावरण हुनेछ। Erlang/OTP इकोसिस्टमले तपाईंलाई कम से कम प्रयासको साथ प्रतिक्रियाशील वास्तुकला लागू गर्न अनुमति दिन्छ। तर कुनै पनि अवस्थामा, हामीलाई सन्देश तह चाहिन्छ।

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

डिजाइन लक्ष्य र बाधाहरू परिभाषित गरेर सुरु हुन्छ। मुख्य लक्ष्य विकासको लागि विकासको क्षेत्रमा होइन। हामीले एउटा सुरक्षित र स्केलेबल उपकरण प्राप्त गर्न आवश्यक छ जसको आधारमा हामी सिर्जना गर्न सक्छौं र, सबैभन्दा महत्त्वपूर्ण कुरा, विभिन्न स्तरका आधुनिक अनुप्रयोगहरू विकास गर्न सक्छौं: एकल-सर्भर अनुप्रयोगहरूबाट सानो दर्शकहरूलाई सेवा दिने, जुन पछि 50 सम्मको क्लस्टरहरूमा विकसित हुन सक्छ। -60 नोडहरू, क्लस्टर फेडरेसनहरूसँग समाप्त हुन्छ। तसर्थ, मुख्य लक्ष्य भनेको अन्तिम प्रणालीको विकास र स्वामित्वको लागत घटाएर नाफा बढाउनु हो।

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

• Сघटना उन्मुख।
  प्रणाली सँधै घटनाहरूको प्रवाहबाट पार गर्न र आवश्यक कार्यहरू गर्न तयार छ;
• Мस्केलेबिलिटी।
  व्यक्तिगत ब्लकहरू ठाडो र तेर्सो रूपमा मापन गर्न सकिन्छ। सम्पूर्ण प्रणाली असीम तेर्सो वृद्धि गर्न सक्षम हुनुपर्छ;
• Оदोष सहिष्णुता।
  सबै स्तरहरू र सबै सेवाहरू स्वचालित रूपमा विफलताहरूबाट पुन: प्राप्ति गर्न सक्षम हुनुपर्छ;
• Гग्यारेन्टी प्रतिक्रिया समय।
  समय बहुमूल्य छ र प्रयोगकर्ताहरूले धेरै लामो पर्खनु हुँदैन।

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

पूर्वाधार उपकरण र सबै सेवाहरूको लागि आधारको रूपमा सन्देश पठाउन थप एउटा बिन्दु थपिएको छ: प्रोग्रामरहरूका लागि प्रयोगमा सजिलो।

घटना उन्मुख

एप्लिकेसन एकल सर्भरबाट क्लस्टरमा बढ्नको लागि, यसको वास्तुकलाले लूज कपलिंगलाई समर्थन गर्नुपर्छ। एसिन्क्रोनस मोडेलले यो आवश्यकता पूरा गर्दछ। यसमा, प्रेषक र प्राप्तकर्ताले सन्देशको जानकारी लोडको बारेमा ख्याल राख्छन् र प्रणाली भित्र प्रसारण र मार्गको बारेमा चिन्ता नगर्नुहोस्।

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

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

एकल मेसिन भित्र, Erlang एक उच्च प्रतिस्पर्धी वातावरण सिर्जना गर्दछ। एर्लांग VM मा उपलब्ध अपरेटिङ सिस्टम थ्रेडहरूको सङ्ख्या र यी थ्रेडहरू प्रयोग गर्ने अनुसूचकहरूको सङ्ख्या छनोट गरेर समरूपता र समानान्तरता बीचको सन्तुलन सेट गर्न सकिन्छ।
Erlang प्रक्रियाहरूले राज्य साझेदारी गर्दैन र गैर-ब्लकिङ मोडमा सञ्चालन गर्दछ। यसले परम्परागत ब्लकिङ-आधारित अनुप्रयोगहरू भन्दा अपेक्षाकृत कम विलम्बता र उच्च थ्रुपुट प्रदान गर्दछ। Erlang को शेड्यूलरले CPU र IO को निष्पक्ष आवंटन सुनिश्चित गर्दछ, र ब्लकिङको अनुपस्थितिले एपलाई पीक लोड वा असफलताको बेला पनि प्रतिक्रिया दिन अनुमति दिन्छ।

क्लस्टर स्तरमा, डिस्पोजलको समस्या पनि छ। यो महत्त्वपूर्ण छ कि क्लस्टरका सबै मेसिनहरू समान रूपमा लोड छन् र नेटवर्क ओभरलोड गरिएको छैन। एउटा अवस्थाको कल्पना गरौं: प्रयोगकर्ता ट्राफिक आगमन ब्यालेन्सरहरू (haproxy, nginx, आदि) मा अवतरण गर्दछ, तिनीहरूले उपलब्ध ब्याकएन्डहरूको सेटको बीचमा सम्भव भएसम्म समान रूपमा प्रशोधन अनुरोधहरू वितरण गर्छन्। एप्लिकेसन इन्फ्रास्ट्रक्चर भित्र, आवश्यक इन्टरफेस कार्यान्वयन गर्ने सेवा अन्तिम माइल मात्र हो र प्रारम्भिक अनुरोधमा प्रतिक्रिया दिन अन्य सेवाहरूको संख्या अनुरोध गर्न आवश्यक हुनेछ। आन्तरिक अनुरोधहरूलाई पनि मार्ग र सन्तुलन चाहिन्छ।
डाटा प्रवाहलाई प्रभावकारी रूपमा व्यवस्थापन गर्न, मेसेजिङले विकासकर्ताहरूलाई राउटिङ र लोड ब्यालेन्सिङ व्यवस्थापन गर्न इन्टरफेस प्रदान गर्नुपर्छ। यसका लागि धन्यवाद, विकासकर्ताहरूले माइक्रोसर्भिस ढाँचाहरू (एग्रीगेटर, प्रोक्सी, चेन, शाखा, इत्यादि) प्रयोग गरी मानक समस्याहरू र विरलै उत्पन्न हुने समस्याहरू समाधान गर्न सक्षम हुनेछन्।

व्यापारिक दृष्टिकोणबाट, स्केलेबिलिटी जोखिम व्यवस्थापन उपकरणहरू मध्ये एक हो। मुख्य कुरा इष्टतम उपकरण प्रयोग गरेर ग्राहक अनुरोधहरू सन्तुष्ट छ:

• जब उपकरणको शक्ति प्रगतिको परिणामको रूपमा बढ्छ। यो अपूर्ण सफ्टवेयरको कारणले निष्क्रिय हुनेछैन। Erlang ठाडो राम्रो मापन र सधैं सबै CPU कोर र उपलब्ध मेमोरी प्रयोग गर्न सक्षम हुनेछ;
• क्लाउड वातावरणमा, हामी हालको वा भविष्यवाणी गरिएको लोड र ग्यारेन्टी SLA को आधारमा उपकरणको मात्रा व्यवस्थापन गर्न सक्छौं।

दोष सहिष्णुता

आउनुहोस् दुईवटा स्वसिद्धहरूलाई विचार गरौं: "असफलताहरू अस्वीकार्य छन्" र "त्यहाँ सधैं असफलताहरू हुनेछन्।" व्यवसायको लागि, सफ्टवेयर विफलता भनेको पैसाको हानि हो, र के खराब छ, प्रतिष्ठाको हानि। सम्भावित हानि र गल्ती-सहिष्णु सफ्टवेयर विकासको लागत बीच सन्तुलन, एक सम्झौता अक्सर फेला पार्न सकिन्छ।

छोटो अवधिमा, त्रुटि सहिष्णुता समावेश गर्ने वास्तुकलाले अफ-द-शेल्फ क्लस्टरिङ समाधानहरू खरिद गर्दा पैसा बचत गर्छ। तिनीहरू महँगो छन् र तिनीहरूसँग बगहरू पनि छन्।
लामो अवधिमा, एक दोष-सहिष्णु वास्तुकलाले विकासको सबै चरणहरूमा धेरै पटक आफैंको लागि भुक्तानी गर्दछ।
कोड आधार भित्रको सन्देशले तपाईंलाई विकास चरणमा प्रणाली भित्रका घटकहरूको अन्तरक्रियालाई विस्तृत रूपमा काम गर्न अनुमति दिन्छ। यसले विफलताहरूको जवाफ दिने र व्यवस्थापन गर्ने कार्यलाई सरल बनाउँछ, किनकि सबै महत्वपूर्ण घटकहरूले विफलताहरू ह्यान्डल गर्छन्, र नतिजा प्रणालीले डिजाइनद्वारा असफलता पछि स्वचालित रूपमा सामान्यमा कसरी फर्कने भनेर जान्दछन्।

प्रतिक्रियाशीलता

असफलताको बावजुद, अनुप्रयोगले अनुरोधहरूको जवाफ दिनुपर्छ र SLA पूरा गर्नुपर्छ। वास्तविकता यो हो कि मानिसहरू पर्खन चाहँदैनन्, त्यसैले व्यवसायहरूले तदनुसार अनुकूलन गर्नुपर्छ। अधिक र अधिक अनुप्रयोगहरू अत्यधिक उत्तरदायी हुने अपेक्षा गरिएको छ।
उत्तरदायी अनुप्रयोगहरू वास्तविक समयमा काम गर्छन्। Erlang VM सफ्ट रियल-टाइम मोडमा सञ्चालन हुन्छ। केही क्षेत्रहरूका लागि, जस्तै स्टक व्यापार, औषधि, र औद्योगिक उपकरण नियन्त्रण, कडा वास्तविक-समय मोड महत्त्वपूर्ण छ।
उत्तरदायी प्रणालीहरूले UX सुधार गर्दछ र व्यापारलाई फाइदा पुर्‍याउँछ।

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

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

पहिलो भागको अन्त्य।

फोटोग्राफी @लुकाब्राभो.

स्रोत: www.habr.com