👨🏼‍⚖️ 😄 👩🏽‍🤝‍👨🏼 वितरित अनुप्रयोगों के बिल्डिंग ब्लॉक। पहला तरीका 🐣 👩‍💼 🍵

पिछले लेख में, हमने प्रतिक्रियात्मक वास्तुकला की सैद्धांतिक नींव की जांच की। यह डेटा स्ट्रीम के बारे में बात करने का समय है, प्रतिक्रियाशील एर्लांग / एलिक्सिर सिस्टम को लागू करने के तरीके और उनमें संदेश भेजने के तरीके:

प्रतिक्रिया का अनुरोध करें
रिक्वेस्ट-चंक्ड रिस्पांस
अनुरोध के साथ प्रतिक्रिया
प्रकाशित: सदस्य बनने
उलटा प्रकाशित-सदस्यता
कार्य का वितरण

SOA, MSA और मैसेजिंग

SOA, MSA - सिस्टम आर्किटेक्चर, जो बिल्डिंग सिस्टम के नियमों को परिभाषित करते हैं, जबकि मैसेजिंग उनके कार्यान्वयन के लिए आदिम प्रदान करता है।

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

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

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

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

सिस्टम घटक सीधे या एक दलाल के माध्यम से बातचीत करते हैं। संदेश सेवा के दृष्टिकोण से, प्रत्येक सेवा के कई जीवन चरण होते हैं:

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

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

एक्सचेंजों

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

संदेश विनिमय पैटर्न (MEPs)

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

अनुरोध - प्रतिक्रिया या आरपीसी

RPC का उपयोग तब किया जाता है जब हमें किसी अन्य प्रक्रिया से प्रतिक्रिया प्राप्त करने की आवश्यकता होती है। यह प्रक्रिया एक ही साइट पर या एक अलग महाद्वीप पर स्थित हो सकती है। नीचे संदेश के माध्यम से ग्राहक और सर्वर की बातचीत का एक चित्र है।

चूंकि मैसेजिंग पूरी तरह से अतुल्यकालिक है, क्लाइंट के लिए एक्सचेंज 2 चरणों में विभाजित है:

प्रस्तुत करने का अनुरोध
```
messaging:request(Exchange, ResponseMatchingTag, RequestDefinition, HandlerProcess). 
```
विनिमय - विनिमय बिंदु के लिए एक अनूठा नाम
ResponseMatchingTag - प्रतिक्रिया को संभालने के लिए स्थानीय लेबल। उदाहरण के लिए, विभिन्न उपयोगकर्ताओं से संबंधित कई समान अनुरोध भेजने के मामले में।
RequestDefinition - अनुरोध निकाय
हैंडलरप्रोसेस - पीआईडी हैंडलर। इस प्रक्रिया को सर्वर से एक प्रतिक्रिया प्राप्त होगी।
प्रतिक्रिया प्रसंस्करण
```
 handle_info(#'$msg'{exchange = EXCHANGE, tag = ResponseMatchingTag,message = ResponsePayload}, State) 
```
ResponsePayload - सर्वर प्रतिक्रिया।

सर्वर के लिए, इस प्रक्रिया में 2 चरण भी शामिल हैं:

एक्सचेंज प्वाइंट इनिशियलाइज़ेशन
आने वाले अनुरोधों को संसाधित करना

आइए इस टेम्पलेट को कोड के साथ चित्रित करते हैं। मान लें कि हमें एक सरल सेवा लागू करने की आवश्यकता है जो एकमात्र सटीक समय पद्धति प्रदान करती है।

सर्वर कोड

Api.hrl में सेवा API की परिभाषा निकालें:

 %% ===================================================== %% entities %% ===================================================== -record(time, { unixtime :: non_neg_integer(), datetime :: binary() }). -record(time_error, { code :: non_neg_integer(), error :: term() }). %% ===================================================== %% methods %% ===================================================== -record(time_req, { opts :: term() }). -record(time_resp, { result :: #time{} | #time_error{} }).

किसी सेवा नियंत्रक को time_controller.erl में परिभाषित करें

 %%      .     gen_server    . %%  gen_server init(Args) -> %%     messaging:monitor_exchange(req_resp, ?EXCHANGE, default, self()) {ok, #{}}. %%       .    ,      . handle_info(#exchange_die{exchange = ?EXCHANGE}, State) -> erlang:send(self(), monitor_exchange), {noreply, State}; %%  API handle_info(#time_req{opts = _Opts}, State) -> messaging:response_once(Client, #time_resp{ result = #time{ unixtime = time_utils:unixtime(now()), datetime = time_utils:iso8601_fmt(now())} }); {noreply, State}; %%   gen_server terminate(_Reason, _State) -> messaging:demonitor_exchange(req_resp, ?EXCHANGE, default, self()), ok.

ग्राहक कोड

किसी सेवा को अनुरोध भेजने के लिए, आप ग्राहक में कहीं भी मैसेजिंग अनुरोध एपीआई को कॉल कर सकते हैं:

 case messaging:request(?EXCHANGE, tag, #time_req{opts = #{}}, self()) of ok -> ok; _ -> %% repeat or fail logic end

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

 handle_info(#'$msg'{exchange = ?EXCHANGE, tag = tag, message = #time_resp{result = #time{unixtime = Utime}}}, State) -> ?debugVal(Utime), {noreply, State}; handle_info(#'$msg'{exchange = ?EXCHANGE, tag = tag, message = #time_resp{result = #time_error{code = ErrorCode}}}, State) -> ?debugVal({error, ErrorCode}), {noreply, State};

रिक्वेस्ट-चंक्ड रिस्पांस

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

मैं ऐसे मामलों के कुछ उदाहरण दूंगा:

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

मैं इन उत्तरों को एक लोकोमोटिव कहता हूं। किसी भी मामले में, एक 1 जीबी संदेश की तुलना में 1024 1 एमबी संदेश बेहतर हैं।

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

अनुरोध के साथ प्रतिक्रिया

यह इंटरैक्टिव सिस्टम बनाने के लिए RPC पैटर्न का एक काफी दुर्लभ संशोधन है।

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

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

ग्राहक कोड पर विचार करें:

 init(_Args) -> %%   ,  = key messaging:subscribe(?SUBSCRIPTION, key, tag, self()), {ok, #{}}. handle_info(#exchange_die{exchange = ?SUBSCRIPTION}, State) -> %%    ,    messaging:subscribe(?SUBSCRIPTION, key, tag, self()), {noreply, State}; %%    handle_info(#'$msg'{exchange = ?SUBSCRIPTION, message = Msg}, State) -> ?debugVal(Msg), {noreply, State}; %%    -     terminate(_Reason, _State) -> messaging:unsubscribe(?SUBSCRIPTION, key, tag, self()), ok.

स्रोत किसी भी सुविधाजनक स्थान पर पोस्ट प्रकाशन फ़ंक्शन को कॉल कर सकते हैं:

 messaging:publish_message(Exchange, Key, Message).

विनिमय - विनिमय बिंदु का नाम,
की - रूटिंग की
संदेश - पेलोड

पब-उप का विस्तार करके, आप एक पैटर्न प्राप्त कर सकते हैं जो लॉगिंग के लिए सुविधाजनक है। स्रोतों और उपभोक्ताओं का सेट पूरी तरह से अलग हो सकता है। आंकड़ा एक उपभोक्ता और कई स्रोतों के साथ एक मामला दिखाता है।

टास्क वितरण पैटर्न

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

3 हैंडलर के उदाहरण के साथ उत्पन्न होने वाली स्थितियों पर विचार करें। कार्य वितरण के चरण में भी, प्रोसेसर की वितरण और अतिप्रवाह की निष्पक्षता का सवाल उठता है। राउंड-रॉबिन वितरण न्याय के लिए जिम्मेदार होगा, और हैंडलर के अतिप्रवाह की स्थिति से बचने के लिए, हम prefetch_limit प्रतिबंध लागू करते हैं। क्षणिक मोड में, प्रीफ़ैच_लीमिट एक हैंडलर को सभी कार्यों को प्राप्त करने से रोकेगा।

मैसेजिंग कतारें और प्रसंस्करण प्राथमिकता का प्रबंधन करता है। उपलब्ध होते ही हैंडलर कार्यों को प्राप्त करते हैं। कार्य सफल या विफल हो सकता है:

messaging:ack(Tack) - सफल संदेश प्रसंस्करण के मामले में कहा जाता है
messaging:nack(Tack) - जिसे सभी आपातकालीन स्थितियों में कहा जाता है। टास्क रिटर्न के बाद, मैसेजिंग इसे दूसरे हैंडलर को ट्रांसफर कर देगा।

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

प्रारंभिक परिणाम

हमने वितरित प्रणालियों के बुनियादी निर्माण खंडों को अलग कर लिया और एरलांग / एलिक्सिर में उनके आवेदन की एक बुनियादी समझ प्राप्त की।

बुनियादी पैटर्न के संयोजन से, आप उभरती समस्याओं को हल करने के लिए जटिल प्रतिमानों का निर्माण कर सकते हैं।

चक्र के अंतिम भाग में, हम सेवाओं के संगठन के सामान्य मुद्दों पर विचार करेंगे, मार्ग और संतुलन, और साथ ही स्केलेबिलिटी और सिस्टम की गलती सहिष्णुता के व्यावहारिक पक्ष के बारे में भी बात करेंगे।

दूसरे भाग का अंत।

फोटो मारियस क्रिस्टेंसन
तैयार किए गए चित्र webfterencediagrams.com द्वारा तैयार किए गए हैं

वितरित अनुप्रयोगों के बिल्डिंग ब्लॉक। पहला तरीका