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

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

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

एसओए, एमएसए और मैसेजिंग

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

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

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

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

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

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

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

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

एक्सचेंजों

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

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

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

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

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

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

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

सर्वर के लिए, प्रक्रिया में 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 में दोनों मामलों को संभालें:

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};

अनुरोध-खंडित प्रतिक्रिया

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

मैं आपको ऐसे मामलों के कुछ उदाहरण देता हूँ:

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

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

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

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

यह डायलॉग सिस्टम बनाने के लिए आरपीसी पैटर्न का एक दुर्लभ संशोधन है।

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

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

आइए सब्सक्राइबर कोड देखें:

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 हैंडलर के उदाहरण का उपयोग करके उत्पन्न होने वाली स्थितियों को देखें। कार्य वितरण के स्तर पर भी, वितरण की निष्पक्षता और संचालकों की अतिप्रवाह का प्रश्न उठता है। राउंड-रॉबिन वितरण निष्पक्षता के लिए जिम्मेदार होगा, और हैंडलरों के अतिप्रवाह की स्थिति से बचने के लिए, हम एक प्रतिबंध लगाएंगे प्रीफ़ेच_लिमिट. क्षणिक स्थितियों में प्रीफ़ेच_लिमिट एक हैंडलर को सभी कार्य प्राप्त करने से रोक देगा।

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

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

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

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

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

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

श्रृंखला के अंतिम भाग में, हम सेवाओं के आयोजन, रूटिंग और संतुलन के सामान्य मुद्दों पर गौर करेंगे, और सिस्टम की स्केलेबिलिटी और दोष सहनशीलता के व्यावहारिक पक्ष के बारे में भी बात करेंगे।

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

फ़ोटो मारियस क्रिस्टेंसन
Websequencediagrams.com का उपयोग करके चित्र तैयार किए गए

स्रोत: www.habr.com

वितरित अनुप्रयोगों के बिल्डिंग ब्लॉक. पहले दृष्टिकोण

एसओए, एमएसए और मैसेजिंग

एक्सचेंजों

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

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

सर्वर कोड

क्लाइंट कोड

अनुरोध-खंडित प्रतिक्रिया

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

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

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

एक टिप्पणी जोड़ें उत्तर रद्द

वितरित अनुप्रयोगों के बिल्डिंग ब्लॉक. पहले दृष्टिकोण

एसओए, एमएसए और मैसेजिंग

एक्सचेंजों

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

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

सर्वर कोड

क्लाइंट कोड

अनुरोध-खंडित प्रतिक्रिया

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

प्रकाशित-सदस्यता लें (डेटा वितरण वृक्ष)

उलटा प्रकाशित-सदस्यता लें

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

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

एक टिप्पणी जोड़ें उत्तर रद्द