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

विगतमा लेख हामीले प्रतिक्रियात्मक वास्तुकलाको सैद्धान्तिक आधारहरू जाँच्यौं। यो डाटा प्रवाह, प्रतिक्रियात्मक Erlang/Elixir प्रणालीहरू र तिनीहरूमा सन्देश ढाँचाहरू लागू गर्ने तरिकाहरू बारे कुरा गर्ने समय हो:

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

SOA, MSA र सन्देश

SOA, MSA प्रणाली आर्किटेक्चरहरू हुन् जसले प्रणालीहरू निर्माणका लागि नियमहरू परिभाषित गर्दछ, जबकि सन्देशले तिनीहरूको कार्यान्वयनको लागि आदिमहरू प्रदान गर्दछ।

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

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

• वितरण।
  एक्सचेन्ज पोइन्टहरू सबै क्लस्टर नोडहरूमा सिर्जना गर्न सकिन्छ, तिनीहरूलाई प्रयोग गर्ने कोडसँग सम्भव भएसम्म।
• सरलता।
  बॉयलरप्लेट कोड र प्रयोगको सहजतामा ध्यान दिनुहोस्।
• राम्रो प्रदर्शन।
  हामी rabbitmq को कार्यक्षमता दोहोर्याउने प्रयास गर्दैनौं, तर केवल वास्तुकला र यातायात तह हाइलाइट गर्दछौं, जसलाई हामी OTP मा सकेसम्म सजिलै फिट गर्छौं, लागत कम गर्दै।
• लचकता।
  प्रत्येक सेवाले धेरै विनिमय टेम्प्लेटहरू संयोजन गर्न सक्छ।
• डिजाइन द्वारा लचीलापन।
• स्केलेबिलिटी।
  सन्देश अनुप्रयोग संग बढ्छ। लोड बढ्दै जाँदा, तपाईले एक्सचेन्ज पोइन्टहरूलाई व्यक्तिगत मेसिनहरूमा सार्न सक्नुहुन्छ।

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

प्रणाली घटकहरू प्रत्यक्ष वा दलाल मार्फत अन्तरक्रिया गर्छन्। सन्देश परिप्रेक्ष्यबाट, प्रत्येक सेवामा धेरै जीवन चरणहरू छन्:

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

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

आदानप्रदान

एक्सचेन्ज पोइन्ट एउटा सन्देश प्रक्रिया हो जसले सन्देश टेम्प्लेट भित्रका घटकहरूसँग अन्तरक्रियाको तर्क लागू गर्दछ। तल प्रस्तुत गरिएका सबै उदाहरणहरूमा, कम्पोनेन्टहरू विनिमय बिन्दुहरू मार्फत अन्तरक्रिया गर्छन्, जसको संयोजनले सन्देश पठाउँछ।

सन्देश आदानप्रदान ढाँचा (MEPs)

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

अनुरोध-प्रतिक्रिया वा RPC

हामीले अर्को प्रक्रियाबाट प्रतिक्रिया प्राप्त गर्न आवश्यक हुँदा RPC प्रयोग गरिन्छ। यो प्रक्रिया एउटै नोडमा चलिरहेको वा फरक महादेशमा अवस्थित हुन सक्छ। तल सन्देश मार्फत ग्राहक र सर्भर बीच अन्तरक्रिया को एक रेखाचित्र छ।

मेसेजिङ पूर्ण रूपमा एसिन्क्रोनस भएकोले, क्लाइन्टको लागि एक्सचेन्जलाई २ चरणहरूमा विभाजन गरिएको छ:

1. अनुरोध पेश गर्नुहोस्

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

   विनिमय - विनिमय बिन्दु को अद्वितीय नाम
   प्रतिक्रिया मिलान ट्याग - प्रतिक्रिया प्रशोधनका लागि स्थानीय लेबल। उदाहरणका लागि, विभिन्न प्रयोगकर्ताहरूसँग सम्बन्धित धेरै समान अनुरोधहरू पठाउने अवस्थामा।
   अनुरोध परिभाषा - शरीर अनुरोध गर्नुहोस्
   ह्यान्डलर प्रक्रिया - ह्यान्डलरको PID। यस प्रक्रियाले सर्भरबाट प्रतिक्रिया प्राप्त गर्नेछ।

2. प्रतिक्रिया प्रशोधन गर्दै

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

   प्रतिक्रिया पेलोड - सर्भर प्रतिक्रिया।

सर्भरको लागि, प्रक्रियाले २ चरणहरू समावेश गर्दछ:

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 को एकल सन्देश भन्दा राम्रो छन्।

Erlang क्लस्टरमा, हामीले अतिरिक्त लाभ पाउँछौं - एक्सचेन्ज पोइन्ट र नेटवर्कमा लोड घटाउने, किनभने प्रतिक्रियाहरू तुरुन्तै प्राप्तकर्तालाई पठाइन्छ, विनिमय बिन्दुलाई बाइपास गर्दै।

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

यो संवाद प्रणाली निर्माण गर्नको लागि 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