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

शेवटी लेख आम्ही प्रतिक्रियाशील आर्किटेक्चरच्या सैद्धांतिक पायाचे परीक्षण केले. डेटा प्रवाह, प्रतिक्रियात्मक एर्लांग/एलिक्सिर सिस्टीम आणि संदेशन पद्धती लागू करण्याच्या पद्धतींबद्दल बोलण्याची ही वेळ आहे:

• विनंती-प्रतिसाद
• विनंती-खंडित प्रतिसाद
• विनंतीसह प्रतिसाद
• प्रकाशित-सदस्यत्व घ्या
• उलटे प्रकाशित-सदस्यत्व घ्या
• कार्य वितरण

SOA, MSA आणि संदेशन

SOA, MSA ही सिस्टीम आर्किटेक्चर्स आहेत जी बिल्डिंग सिस्टमसाठी नियम परिभाषित करतात, तर मेसेजिंग त्यांच्या अंमलबजावणीसाठी आदिम प्रदान करते.

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

नावाप्रमाणेच मेसेजिंग म्हणजे मेसेज ब्रोकर. त्याचा मुख्य उद्देश संदेश प्राप्त करणे आणि पाठवणे हा आहे. माहिती पाठवण्यासाठी इंटरफेस, सिस्टममध्ये माहिती प्रसारित करण्यासाठी लॉजिकल चॅनेलची निर्मिती, राउटिंग आणि बॅलन्सिंग तसेच सिस्टम स्तरावर फॉल्ट हाताळणी यासाठी जबाबदार आहे.
आम्ही विकसित करत असलेले मेसेजिंग rabbitmq शी स्पर्धा करण्याचा किंवा बदलण्याचा प्रयत्न करत नाही. त्याची मुख्य वैशिष्ट्ये:

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

टिप्पणी. कोड ऑर्गनायझेशनच्या दृष्टीने, मेटा-प्रोजेक्ट जटिल एर्लांग/एलिक्सिर सिस्टमसाठी योग्य आहेत. सर्व प्रकल्प कोड एका भांडारात स्थित आहे - एक छत्री प्रकल्प. त्याच वेळी, मायक्रोसर्व्हिसेस जास्तीत जास्त वेगळ्या असतात आणि सोप्या ऑपरेशन्स करतात जे वेगळ्या घटकासाठी जबाबदार असतात. या दृष्टिकोनामुळे, संपूर्ण प्रणालीचे API राखणे सोपे आहे, बदल करणे सोपे आहे, युनिट आणि एकत्रीकरण चाचण्या लिहिणे सोयीचे आहे.

सिस्टम घटक थेट किंवा ब्रोकरद्वारे संवाद साधतात. संदेशवहनाच्या दृष्टीकोनातून, प्रत्येक सेवेचे जीवनाचे अनेक टप्पे असतात:

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

हे खूपच क्लिष्ट दिसते, परंतु कोड इतके भयानक नाही. टिप्पण्यांसह कोड उदाहरणे थोड्या वेळाने टेम्पलेट्सच्या विश्लेषणामध्ये दिली जातील.

बाजार

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

संदेश विनिमय नमुने (MEPs)

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

विनंती-प्रतिसाद किंवा RPC

जेव्हा आम्हाला दुसर्‍या प्रक्रियेकडून प्रतिसाद मिळणे आवश्यक असते तेव्हा RPC वापरले जाते. ही प्रक्रिया कदाचित एकाच नोडवर चालत असेल किंवा वेगळ्या खंडावर असेल. खाली मेसेजिंगद्वारे क्लायंट आणि सर्व्हरमधील परस्परसंवादाचा एक आकृती आहे.

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

1. विनंती सबमिट करा

   messaging:request(Exchange, ResponseMatchingTag, RequestDefinition, HandlerProcess).

   विनिमय - एक्सचेंज पॉइंटचे अनन्य नाव
   ResponseMatchingTag - प्रतिसादावर प्रक्रिया करण्यासाठी स्थानिक लेबल. उदाहरणार्थ, वेगवेगळ्या वापरकर्त्यांच्या अनेक समान विनंत्या पाठवण्याच्या बाबतीत.
   विनंती व्याख्या - विनंती शरीर
   हँडलरप्रोसेस - हँडलरचा PID. या प्रक्रियेला सर्व्हरकडून प्रतिसाद मिळेल.

2. प्रतिसादावर प्रक्रिया करत आहे

   handle_info(#'$msg'{exchange = EXCHANGE, tag = ResponseMatchingTag,message = ResponsePayload}, State)

   प्रतिसाद पेलोड - सर्व्हर प्रतिसाद.

सर्व्हरसाठी, प्रक्रियेमध्ये 2 टप्पे देखील असतात:

1. एक्सचेंज पॉइंट सुरू करत आहे
2. प्राप्त विनंत्यांची प्रक्रिया

चला हा टेम्प्लेट कोडसह स्पष्ट करू. समजा आम्हाला एक साधी सेवा लागू करण्याची आवश्यकता आहे जी एकच अचूक वेळ पद्धत प्रदान करते.

सर्व्हर कोड

चला सेवा API api.hrl मध्ये परिभाषित करू:

%% =====================================================
%%  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.

क्लायंट कोड

सेवेला विनंती पाठवण्यासाठी, तुम्ही क्लायंटमध्ये कुठेही मेसेजिंग विनंती API ला कॉल करू शकता:

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 MB चे 1 संदेश 1 GB च्या एका संदेशापेक्षा चांगले आहेत.

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

विनंतीसह प्रतिसाद

डायलॉग सिस्टीम तयार करण्यासाठी 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. क्षणिक परिस्थितीत prefetch_limit एका हँडलरला सर्व कार्ये प्राप्त करण्यापासून प्रतिबंधित करेल.

मेसेजिंग रांग आणि प्रक्रिया प्राधान्य व्यवस्थापित करते. प्रोसेसर आल्यावर कार्ये प्राप्त करतात. कार्य यशस्वीरित्या पूर्ण किंवा अयशस्वी होऊ शकते:

• messaging:ack(Tack) - संदेशावर यशस्वीरित्या प्रक्रिया केली असल्यास कॉल करा
• messaging:nack(Tack) - सर्व आपत्कालीन परिस्थितीत कॉल केला जातो. एकदा कार्य परत केले की, संदेशवहन ते दुसर्‍या हँडलरकडे पाठवेल.

समजा तीन कार्यांवर प्रक्रिया करताना एक जटिल बिघाड झाला: प्रोसेसर 1, कार्य प्राप्त केल्यानंतर, एक्सचेंज पॉईंटला काहीही कळवण्यास वेळ न देता क्रॅश झाला. या प्रकरणात, एक्स्चेंज पॉइंट ack टाइमआउट कालबाह्य झाल्यानंतर कार्य दुसर्या हँडलरकडे हस्तांतरित करेल. काही कारणास्तव, हँडलर 3 ने कार्य सोडले आणि नॅक पाठवले; परिणामी, कार्य दुसर्या हँडलरकडे हस्तांतरित केले गेले ज्याने ते यशस्वीरित्या पूर्ण केले.

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

आम्ही वितरित प्रणालींचे मूलभूत बिल्डिंग ब्लॉक्स कव्हर केले आहेत आणि Erlang/Elixir मधील त्यांच्या वापराची मूलभूत माहिती मिळवली आहे.

मूलभूत नमुने एकत्र करून, आपण उदयोन्मुख समस्यांचे निराकरण करण्यासाठी जटिल प्रतिमान तयार करू शकता.

मालिकेच्या शेवटच्या भागात, आम्ही सेवांचे आयोजन, राउटिंग आणि बॅलन्सिंगच्या सामान्य समस्यांबद्दल पाहू आणि स्केलेबिलिटी आणि सिस्टमच्या फॉल्ट टॉलरन्सच्या व्यावहारिक बाजूबद्दल देखील बोलू.

दुसऱ्या भागाचा शेवट.

फोटो मारियस क्रिस्टेनसेन
websequencediagrams.com वापरून तयार केलेली चित्रे

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