விநியோகிக்கப்பட்ட பயன்பாடுகளின் கட்டுமானத் தொகுதிகள். முதல் அணுகுமுறை

கடந்த காலத்தில் கட்டுரை எதிர்வினை கட்டமைப்பின் தத்துவார்த்த அடித்தளங்களை நாங்கள் ஆய்வு செய்தோம். தரவு ஓட்டங்கள், எதிர்வினை எர்லாங்/எலிக்சிர் அமைப்புகளை செயல்படுத்துவதற்கான வழிகள் மற்றும் அவற்றில் உள்ள செய்தியிடல் முறைகள் பற்றி பேச வேண்டிய நேரம் இது:

• கோரிக்கை-பதில்
• கோரிக்கை-துண்டான பதில்
• கோரிக்கையுடன் பதில்
• வெளியிடு-சந்தா
• தலைகீழாக வெளியிடு-சந்தா
• பணி விநியோகம்

SOA, MSA மற்றும் செய்தியிடல்

SOA, MSA ஆகியவை அமைப்பு கட்டமைப்புகள் ஆகும், அவை அமைப்புகளை உருவாக்குவதற்கான விதிகளை வரையறுக்கின்றன, அதே சமயம் செய்தி அனுப்புதல் அவற்றின் செயலாக்கத்திற்கான ஆதிநிலைகளை வழங்குகிறது.

இந்த அல்லது அந்த அமைப்பின் கட்டமைப்பை நான் விளம்பரப்படுத்த விரும்பவில்லை. ஒரு குறிப்பிட்ட திட்டத்திற்கும் வணிகத்திற்கும் மிகவும் பயனுள்ள மற்றும் பயனுள்ள நடைமுறைகளைப் பயன்படுத்துவதற்கு நான் இருக்கிறேன். நாம் எந்த முன்னுதாரணத்தை தேர்வு செய்தாலும், யூனிக்ஸ்-வேயில் ஒரு கண் கொண்டு கணினி தொகுதிகளை உருவாக்குவது நல்லது: குறைந்தபட்ச இணைப்பு கொண்ட கூறுகள், தனிப்பட்ட நிறுவனங்களுக்கு பொறுப்பு. ஏபிஐ முறைகள் நிறுவனங்களுடன் கூடிய எளிமையான செயல்களைச் செய்கின்றன.

மெசேஜிங் என்பது, பெயர் குறிப்பிடுவது போல, ஒரு செய்தி தரகர். செய்திகளைப் பெறுவதும் அனுப்புவதும் இதன் முக்கிய நோக்கம். தகவல்களை அனுப்புவதற்கான இடைமுகங்கள், கணினியில் தகவல்களை அனுப்புவதற்கான தருக்க சேனல்களை உருவாக்குதல், ரூட்டிங் மற்றும் சமநிலைப்படுத்துதல் மற்றும் கணினி மட்டத்தில் தவறு கையாளுதல் ஆகியவற்றிற்கு இது பொறுப்பாகும்.
நாங்கள் உருவாக்கும் செய்தியானது 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.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.

வாடிக்கையாளர் குறியீடு

சேவைக்கு கோரிக்கையை அனுப்ப, கிளையண்டில் எங்கு வேண்டுமானாலும் செய்தியிடல் கோரிக்கை 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, பணியைப் பெற்ற பிறகு, பரிமாற்ற புள்ளியில் எதையும் தெரிவிக்க நேரமில்லாமல் செயலிழந்தது. இந்தச் சந்தர்ப்பத்தில், பரிமாற்றப் புள்ளி காலாவதியான பிறகு பணியை மற்றொரு கையாளுபவருக்கு மாற்றும். சில காரணங்களால், ஹேண்ட்லர் 3 பணியை கைவிட்டு, நக்ஸாக அனுப்பினார்; இதன் விளைவாக, பணியை வெற்றிகரமாக முடித்த மற்றொரு கையாளுபவருக்கும் மாற்றப்பட்டது.

பூர்வாங்க சுருக்கம்

விநியோகிக்கப்பட்ட அமைப்புகளின் அடிப்படை கட்டுமானத் தொகுதிகளை நாங்கள் உள்ளடக்கியுள்ளோம் மற்றும் எர்லாங்/எலிக்சிரில் அவற்றின் பயன்பாட்டைப் பற்றிய அடிப்படை புரிதலைப் பெற்றுள்ளோம்.

அடிப்படை வடிவங்களை இணைப்பதன் மூலம், வளர்ந்து வரும் சிக்கல்களைத் தீர்க்க சிக்கலான முன்னுதாரணங்களை உருவாக்கலாம்.

தொடரின் இறுதிப் பகுதியில், சேவைகளை ஒழுங்கமைத்தல், ரூட்டிங் மற்றும் சமநிலைப்படுத்துதல் ஆகியவற்றின் பொதுவான சிக்கல்களைப் பார்ப்போம், மேலும் அளவிடுதல் மற்றும் அமைப்புகளின் தவறு சகிப்புத்தன்மையின் நடைமுறைப் பக்கத்தைப் பற்றியும் பேசுவோம்.

இரண்டாம் பாகத்தின் முடிவு.

புகைப்படம் மரியஸ் கிறிஸ்டென்சன்
websequencediagrams.com ஐப் பயன்படுத்தி தயாரிக்கப்பட்ட விளக்கப்படங்கள்

ஆதாரம்: www.habr.com