🙍🏼 🧓 🚾 वितरित अनुप्रयोगों के बिल्डिंग ब्लॉक। दूसरा सन्निकटन 👾 🐎 🤲

घोषणा

सहकर्मी, मध्य गर्मियों में मैं कतारबद्ध प्रणालियों के डिजाइन पर लेखों की एक और श्रृंखला जारी करने की योजना बना रहा हूं: "VTrade Experiment" - ट्रेडिंग सिस्टम के लिए एक रूपरेखा लिखने का प्रयास। चक्र एक विनिमय, नीलामी और स्टोर के निर्माण के सिद्धांत और व्यवहार का विश्लेषण करेगा। लेख के अंत में, मैं उन विषयों के लिए मतदान का प्रस्ताव करता हूं जो आपके लिए सबसे अधिक रुचि रखते हैं।

यह Erlang / Elixir वितरित प्रतिक्रियाशील अनुप्रयोग चक्र का अंतिम लेख है। पहले लेख में, आप प्रतिक्रियाशील वास्तुकला की सैद्धांतिक नींव पा सकते हैं। दूसरा लेख इस तरह के सिस्टम के निर्माण के लिए बुनियादी पैटर्न और तंत्र को दिखाता है।

आज हम कोड बेस और परियोजनाओं के विकास के मुद्दों को सामान्य रूप से उठाएंगे।

सेवा संगठन

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

स्थिति तब जटिल हो जाती है जब हमें गलती-सहिष्णु वितरित सेवा को लागू करने की आवश्यकता होती है। मान लें कि उपयोगकर्ताओं की आवश्यकताएं बदल गई हैं:

अब सेवा को क्लस्टर के 5 नोड्स पर अनुरोधों को संसाधित करना चाहिए,
पृष्ठभूमि प्रसंस्करण कार्य करने में सक्षम हो,
और अपने प्रोफ़ाइल अपडेट सदस्यता सूचियों को गतिशील रूप से प्रबंधित करने में सक्षम हो।

नोट: हम डेटा के लगातार भंडारण और प्रतिकृति के मुद्दे पर विचार नहीं करते हैं। मान लीजिए कि इन मुद्दों को पहले ही हल कर लिया गया है और सिस्टम में पहले से ही एक विश्वसनीय और स्केलेबल भंडारण परत है, और हैंडलर के पास इसके साथ बातचीत करने के लिए तंत्र हैं।

उपयोगकर्ताओं की सेवा का औपचारिक विवरण अधिक जटिल हो गया है। प्रोग्रामर के दृष्टिकोण से, संदेश परिवर्तन का उपयोग करना न्यूनतम है। पहली आवश्यकता को पूरा करने के लिए, हमें req-resp विनिमय बिंदु पर संतुलन को समायोजित करने की आवश्यकता है।

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

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

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

नेता की पसंद

वितरित प्रणालियों में, एक नेता की पसंद एक लोड की वितरित प्रसंस्करण की योजना बनाने के लिए जिम्मेदार एकमात्र प्रक्रिया नियुक्त करने की प्रक्रिया है।

उन प्रणालियों में जिनका केंद्रीकरण का खतरा नहीं होता है, सार्वभौमिक सर्वसम्मति एल्गोरिदम, जैसे पैक्सोस या बेड़ा, का उपयोग किया जाता है।
चूंकि मैसेजिंग एक दलाल और एक केंद्रीय तत्व है, वह सभी सेवा नियंत्रकों - नेतृत्व के लिए उम्मीदवारों के बारे में जानता है। मैसेजिंग एक नेता को वोट के बिना नियुक्त कर सकता है।

विनिमय बिंदु से शुरू करने और कनेक्ट करने के बाद, सभी सेवाओं को सिस्टम संदेश #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers} । यदि LeaderPid वर्तमान प्रक्रिया के pid मेल खाता है, तो इसे लीडर के रूप में सौंपा गया है, और Servers सूची में सभी नोड्स और उनके पैरामीटर शामिल हैं।
जब एक नया क्लस्टर नोड प्रकट होता है और डिस्कनेक्ट हो जाता है, तो सभी सेवा नियंत्रक #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} और #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} क्रमशः।

इस प्रकार, सभी घटकों को सभी परिवर्तनों के बारे में पता है, और किसी भी समय क्लस्टर में एक नेता की गारंटी है।

बिचौलियों

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

पब-उप अनुकूलन का एक उत्कृष्ट उदाहरण एक व्यावसायिक कोर के साथ एक वितरित अनुप्रयोग है जो अद्यतन घटनाओं को उत्पन्न करता है, उदाहरण के लिए, बाजार मूल्य में परिवर्तन और एक पहुंच परत - एन सर्वर जो वेब क्लाइंट के लिए वेबसोकेट एपीआई प्रदान करते हैं।
यदि आप "माथा" तय करते हैं, तो ग्राहक सेवा इस प्रकार है:

क्लाइंट प्लेटफ़ॉर्म के साथ कनेक्शन स्थापित करता है। सर्वर साइड पर, ट्रैफ़िक को समाप्त करते हुए, इस कनेक्शन की सेवा की प्रक्रिया शुरू होती है।
सेवा प्रक्रिया के संदर्भ में, अद्यतन करने के लिए प्राधिकरण और सदस्यता लेते हैं। प्रक्रिया विषयों के लिए सदस्यता विधि को बुलाती है।
कर्नेल में घटना उत्पन्न होने के बाद, यह कनेक्शनों को परोसने वाली प्रक्रियाओं तक पहुँचाया जाता है।

कल्पना कीजिए कि हमारे पास "समाचार" विषय के 50,000 ग्राहक हैं। सब्सक्राइबर्स को 5 सर्वरों पर समान रूप से वितरित किया जाता है। परिणामस्वरूप, प्रत्येक अपडेट, विनिमय बिंदु पर पहुंचने पर, प्रत्येक सर्वर पर 50,000 बार: उस पर ग्राहकों की संख्या के अनुसार 10,000 बार दोहराया जाएगा। काफी प्रभावी योजना नहीं है, क्या यह है?
स्थिति को बेहतर बनाने के लिए, हम एक प्रॉक्सी को एक्सचेंज प्वाइंट के साथ एक ही नाम देते हैं। वैश्विक नाम रजिस्ट्रार को नाम से निकटतम प्रक्रिया वापस करने में सक्षम होना चाहिए, यह महत्वपूर्ण है।

एक्सेस लेयर के सर्वर पर इस प्रॉक्सी को चलाएं, और वेबसोकेट एपीआई की सेवा करने वाली हमारी सभी प्रक्रियाएं इसे सब्सक्राइब करेंगी, न कि कर्नेल में मूल पब-सब एक्सचेंज पॉइंट। प्रॉक्सी केवल एक अद्वितीय सदस्यता के मामले में कर्नेल की सदस्यता लेता है और अपने सभी ग्राहकों को प्राप्त संदेश को दोहराता है।
नतीजतन, कर्नेल और एक्सेस सर्वर के बीच 50,000 के बजाय 5 संदेश भेजे जाएंगे।

रूटिंग और बैलेंसिंग

अनुरोध-Resp

वर्तमान संदेश कार्यान्वयन में, 7 क्वेरी वितरण रणनीतियाँ हैं:

default । अनुरोध सभी नियंत्रकों को दिया जाता है।
round-robin । के माध्यम से Iterates और cyclically नियंत्रकों के बीच अनुरोध वितरित करता है।
consensus । सेवा प्रदान करने वाले नियंत्रकों को नेताओं और अनुयायियों में विभाजित किया जाता है। अनुरोध केवल नेता को दिए जाते हैं।
consensus & round-robin । समूह में एक नेता है, लेकिन सभी सदस्यों के बीच अनुरोध वितरित किए जाते हैं।
sticky । हैश फ़ंक्शन की गणना और एक विशिष्ट हैंडलर को सौंपा जाता है। इस हस्ताक्षर के बाद के अनुरोध उसी हैंडलर के पास जाते हैं।
sticky-fun । जब विनिमय बिंदु को प्रारंभ किया जाता है, तो sticky संतुलन के लिए हैश गणना फ़ंक्शन अतिरिक्त रूप से स्थानांतरित किया जाता है।
fun । यह चिपचिपा-मज़ा के समान है, केवल इसके अलावा आप इसे पुनर्निर्देशित कर सकते हैं, अस्वीकार कर सकते हैं या प्रीप्रोसेस कर सकते हैं।

वितरण रणनीति तब निर्धारित की जाती है जब विनिमय बिंदु आरंभीकृत होता है।

संदेश सेवा को संतुलित करने के अलावा आप संस्थाओं को टैग कर सकते हैं। सिस्टम में टैग के प्रकारों पर विचार करें:

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

पब उप

पब-सब के लिए, चीजें थोड़ी आसान हैं। हमारे पास एक विनिमय बिंदु है जिसके लिए संदेश प्रकाशित किए जाते हैं। विनिमय बिंदु उन ग्राहकों के बीच संदेश वितरित करता है जो रूटिंग कुंजी की सदस्यता लेते हैं, जिनकी हमें आवश्यकता होती है (हम कह सकते हैं कि यह उन लोगों के लिए एक एनालॉग है)।

स्केलेबिलिटी और लचीलापन

सिस्टम की संपूर्णता प्रणाली की परतों और घटकों की मापनीयता की डिग्री पर निर्भर करती है:

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

स्केलिंग की सादगी और गति अक्सर एक परियोजना की सफलता को निर्धारित करती है। अपने वर्तमान प्रदर्शन में संदेश अनुप्रयोग के साथ बढ़ता है। भले ही हमारे पास 50-60 कारों का समूह न हो, लेकिन हम महासंघ का सहारा ले सकते हैं। दुर्भाग्य से, महासंघ का विषय इस लेख के दायरे से परे है।

आरक्षण

लोड संतुलन के विश्लेषण में, हमने पहले ही सेवा नियंत्रकों के आरक्षण पर चर्चा की है। हालाँकि, मैसेजिंग भी आरक्षित होनी चाहिए। एक नोड या मशीन दुर्घटना की स्थिति में, संदेश स्वचालित रूप से और जल्द से जल्द ठीक हो जाना चाहिए।

मेरी परियोजनाओं में, मैं अतिरिक्त नोड्स का उपयोग करता हूं जो गिरावट की स्थिति में लोड उठाते हैं। Erlang में OTP अनुप्रयोगों के लिए एक मानक वितरित मोड कार्यान्वयन है। वितरित मोड, वास्तव में, पहले से लॉन्च किए गए नोड पर क्रैश किए गए एप्लिकेशन को लॉन्च करके विफलता की स्थिति में पुनर्प्राप्ति करता है। प्रक्रिया पारदर्शी है, एक असफलता के बाद, आवेदन स्वचालित रूप से विफलता नोड में चला जाता है। आप यहां इस कार्यक्षमता के बारे में अधिक पढ़ सकते हैं।

उत्पादकता

चलो कम से कम लगभग खरगोश और हमारे कस्टम संदेश के प्रदर्शन की तुलना करने की कोशिश करते हैं।
मैंने ओपनस्टैक टीम से आधिकारिक खरगोश परीक्षण परिणाम पाया।

खण्ड में 6.14.1.2.1.2.2। मूल दस्तावेज RPC CAST का परिणाम प्रस्तुत करता है:

पहले, हम OS कर्नेल या वीएमंग के लिए कोई अतिरिक्त सेटिंग नहीं करेंगे। परीक्षण की स्थिति:

erl opts: + A1 + sbtu।
एक एकल erlang नोड के भीतर परीक्षण मोबाइल प्रदर्शन में एक पुराने i7 के साथ एक लैपटॉप पर चलता है।
क्लस्टर परीक्षण 10G नेटवर्क वाले सर्वर पर होते हैं।
कोड डॉकटर कंटेनरों में काम करता है। नेट मोड में नेटवर्क।

टेस्ट कोड:

 req_resp_bench(_) -> W = perftest:comprehensive(10000, fun() -> messaging:request(?EXCHANGE, default, ping, self()), receive #'$msg'{message = pong} -> ok after 5000 -> throw(timeout) end end ), true = lists:any(fun(E) -> E >= 30000 end, W), ok.

परिदृश्य 1: परीक्षण एक पुराने i7 मोबाइल निष्पादन के साथ लैपटॉप पर चलता है। टेस्ट, मैसेजिंग और सर्विस को एक डॉकटर कंटेनर में एक नोड पर निष्पादित किया जाता है:

 Sequential 10000 cycles in ~0 seconds (26987 cycles/s) Sequential 20000 cycles in ~1 seconds (26915 cycles/s) Sequential 100000 cycles in ~4 seconds (26957 cycles/s) Parallel 2 100000 cycles in ~2 seconds (44240 cycles/s) Parallel 4 100000 cycles in ~2 seconds (53459 cycles/s) Parallel 10 100000 cycles in ~2 seconds (52283 cycles/s) Parallel 100 100000 cycles in ~3 seconds (49317 cycles/s)

परिदृश्य 2 : 3 नोड्स (NAT) के तहत विभिन्न मशीनों पर चल रहे नोड्स।

 Sequential 10000 cycles in ~1 seconds (8684 cycles/s) Sequential 20000 cycles in ~2 seconds (8424 cycles/s) Sequential 100000 cycles in ~12 seconds (8655 cycles/s) Parallel 2 100000 cycles in ~7 seconds (15160 cycles/s) Parallel 4 100000 cycles in ~5 seconds (19133 cycles/s) Parallel 10 100000 cycles in ~4 seconds (24399 cycles/s) Parallel 100 100000 cycles in ~3 seconds (34517 cycles/s)

सभी मामलों में, CPU उपयोग 250% से अधिक नहीं था

परिणाम

मुझे उम्मीद है कि यह चक्र चेतना की एक डंप की तरह नहीं दिखता है और मेरा अनुभव वितरित प्रणालियों और चिकित्सकों दोनों के शोधकर्ताओं को वास्तविक लाभ देगा जो अपने व्यापार प्रणालियों के लिए वितरित आर्किटेक्चर के निर्माण की राह की बहुत शुरुआत में हैं और जो ब्याज के साथ एर्लांग / एलिर को देखते हैं, लेकिन संदेह क्या यह इसके लायक है ...

फोटो @chuttersnap द्वारा

वितरित अनुप्रयोगों के बिल्डिंग ब्लॉक। दूसरा सन्निकटन