බෙදා හරින ලද යෙදුම් ගොඩනැගීමේ කොටස්. පළමු ප්රවේශය

අන්තිමට ලිපියයි අපි ප්රතික්රියාශීලී ගෘහ නිර්මාණ ශිල්පයේ න්යායික පදනම් පරීක්ෂා කළා. දත්ත ප්‍රවාහයන්, ප්‍රතික්‍රියාශීලී Erlang/Elixir පද්ධති ක්‍රියාත්මක කිරීමේ ක්‍රම සහ ඒවා තුළ ඇති පණිවිඩකරණ රටා ගැන කතා කිරීමට කාලයයි.

• ඉල්ලීම-ප්රතිචාරය
• Request-Chunked Response
• ඉල්ලීම සමඟ ප්‍රතිචාර දක්වන්න
• ප්‍රකාශන-දායක වන්න
• ප්‍රතිලෝම ප්‍රකාශන-දායක වන්න
• කාර්යය බෙදා හැරීම

SOA, MSA සහ පණිවිඩ යැවීම

SOA, MSA යනු පද්ධති ගොඩනැගීම සඳහා නීති නිර්වචනය කරන පද්ධති ගෘහ නිර්මාණ ශිල්පය වන අතර, පණිවිඩ යැවීම ඒවා ක්‍රියාත්මක කිරීම සඳහා ප්‍රාථමිකයන් සපයයි.

මට මේ හෝ එම පද්ධති ගෘහ නිර්මාණ ශිල්පය ප්‍රවර්ධනය කිරීමට අවශ්‍ය නැත. මම විශේෂිත ව්‍යාපෘතියක් සහ ව්‍යාපාරයක් සඳහා වඩාත් ඵලදායි සහ ප්‍රයෝජනවත් භාවිතයන් භාවිතා කිරීම සඳහා වෙමි. අප තෝරා ගන්නා සුසමාදර්ශය කුමක් වුවත්, Unix-way මත ඇසින් පද්ධති කුට්ටි නිර්මාණය කිරීම වඩා හොඳය: අවම සම්බන්ධතාවයක් සහිත සංරචක, තනි ආයතන සඳහා වගකිව යුතුය. API ක්‍රම මඟින් ආයතන සමඟ කළ හැකි සරලම ක්‍රියා සිදු කරයි.

පණිවිඩ යැවීම, නමට අනුව, පණිවිඩ තැරැව්කරුවෙකි. එහි ප්‍රධාන අරමුණ වන්නේ පණිවිඩ ලැබීම සහ යැවීමයි. තොරතුරු යැවීම සඳහා අතුරුමුහුණත්, පද්ධතිය තුළ තොරතුරු සම්ප්‍රේෂණය කිරීම සඳහා තාර්කික නාලිකා ගොඩනැගීම, මාර්ගගත කිරීම සහ සමතුලිත කිරීම මෙන්ම පද්ධති මට්ටමින් දෝෂ හැසිරවීම සඳහා එය වගකිව යුතුය.
අප සංවර්ධනය කරන පණිවිඩ යැවීම rabbitmq සමඟ තරඟ කිරීමට හෝ ප්‍රතිස්ථාපනය කිරීමට උත්සාහ නොකරයි. එහි ප්රධාන ලක්ෂණ:

• බෙදා හැරීම.
  සියලුම පොකුරු නෝඩ් මත හුවමාරු ලක්ෂ්‍ය සෑදිය හැක, ඒවා භාවිතා කරන කේතයට හැකි තරම් සමීප වේ.
• සරල බව.
  බොයිලර් ප්ලේට් කේතය අවම කිරීම සහ භාවිතයේ පහසුව කෙරෙහි අවධානය යොමු කරන්න.
• වඩා හොඳ කාර්ය සාධනය.
  අපි rabbitmq හි ක්‍රියාකාරීත්වය පුනරුච්චාරණය කිරීමට උත්සාහ නොකරමු, නමුත් අපි හැකි තරම් සරලව OTP වලට ගැලපෙන වාස්තු විද්‍යාත්මක සහ ප්‍රවාහන ස්තරය පමණක් ඉස්මතු කර, පිරිවැය අවම කරමු.
• නම්යශීලී බව.
  සෑම සේවාවකටම බොහෝ හුවමාරු සැකිලි ඒකාබද්ධ කළ හැකිය.
• නිර්මාණය අනුව ඔරොත්තු දීමේ හැකියාව.
• පරිමාණය
  යෙදුම සමඟ පණිවිඩ යැවීම වර්ධනය වේ. බර වැඩි වන විට, ඔබට හුවමාරු ස්ථාන තනි යන්ත්‍ර වෙත ගෙන යා හැකිය.

අදහස් දක්වන්න. කේත සංවිධානය අනුව, සංකීර්ණ Erlang/Elixir පද්ධති සඳහා meta-ව්‍යාපෘති හොඳින් ගැලපේ. සියලුම ව්‍යාපෘති කේතය එක් ගබඩාවක පිහිටා ඇත - කුඩ ව්‍යාපෘතියක්. ඒ අතරම, ක්ෂුද්ර සේවා උපරිම වශයෙන් හුදකලා වන අතර වෙනම ආයතනයක් සඳහා වගකිව යුතු සරල මෙහෙයුම් සිදු කරයි. මෙම ප්රවේශය සමඟ, සමස්ත පද්ධතියේ API නඩත්තු කිරීම පහසුය, වෙනස්කම් සිදු කිරීම පහසුය, ඒකක සහ ඒකාබද්ධතා පරීක්ෂණ ලිවීමට පහසුය.

පද්ධති සංරචක සෘජුව හෝ තැරැව්කරුවකු හරහා අන්තර්ක්‍රියා කරයි. පණිවිඩ යැවීමේ දෘෂ්ටිකෝණයකින්, සෑම සේවාවකටම ජීවිත අදියර කිහිපයක් ඇත:

• සේවා ආරම්භ කිරීම.
  මෙම අදියරේදී, සේවාව ක්රියාත්මක කිරීමේ ක්රියාවලිය සහ පරායත්තයන් වින්යාස කර දියත් කරනු ලැබේ.
• හුවමාරු ලක්ෂ්යයක් නිර්මාණය කිරීම.
  සේවාවට නෝඩ් වින්‍යාසයේ දක්වා ඇති ස්ථිතික හුවමාරු ලක්ෂ්‍යයක් භාවිතා කළ හැකිය, නැතහොත් ගතිකව හුවමාරු ලක්ෂ්‍ය සෑදිය හැක.
• සේවා ලියාපදිංචිය.
  සේවාව ඉල්ලීම් ඉටු කිරීම සඳහා, එය හුවමාරු ස්ථානයේ ලියාපදිංචි විය යුතුය.
• සාමාන්ය ක්රියාකාරීත්වය.
  සේවාව ප්රයෝජනවත් කාර්යයක් නිෂ්පාදනය කරයි.
• වසා දමන්න.
  වසා දැමීමේ වර්ග 2 ක් ඇත: සාමාන්‍ය සහ හදිසි අවස්ථා. සාමාන්‍ය ක්‍රියාකාරිත්වය අතරතුර, සේවාව හුවමාරු ස්ථානයෙන් විසන්ධි වී නතර වේ. හදිසි අවස්ථා වලදී, පණිවිඩ යැවීම අසාර්ථක ස්ක්‍රිප්ට් වලින් එකක් ක්‍රියාත්මක කරයි.

එය තරමක් සංකීර්ණ බව පෙනේ, නමුත් කේතය එතරම් බියජනක නොවේ. අදහස් සහිත කේත උදාහරණ මඳ වේලාවකට පසුව සැකිලි විශ්ලේෂණයේදී ලබා දෙනු ඇත.

හුවමාරු

හුවමාරු ලක්ෂ්‍යය යනු පණිවිඩකරණ අච්චුව තුළ ඇති සංරචක සමඟ අන්තර්ක්‍රියා කිරීමේ තර්කනය ක්‍රියාත්මක කරන පණිවිඩ යැවීමේ ක්‍රියාවලියකි. පහත ඉදිරිපත් කර ඇති සියලුම උදාහරණ වලදී, සංරචක හුවමාරු ස්ථාන හරහා අන්තර්ක්‍රියා කරයි, ඒවායේ එකතුව පණිවිඩ යැවීම සාදයි.

පණිවිඩ හුවමාරු රටා (MEPs)

ගෝලීය වශයෙන්, හුවමාරු රටා ද්වි-මාර්ග සහ එක්-මාර්ග ලෙස බෙදිය හැකිය. පළමුවැන්න එන පණිවිඩයකට ප්‍රතිචාරයක් අදහස් කරයි, දෙවැන්න එසේ නොවේ. සේවාදායක-සේවාදායක ගෘහ නිර්මාණ ශිල්පයේ ද්වි-මාර්ග රටාවක සම්භාව්‍ය උදාහරණයක් වන්නේ ඉල්ලීම්-ප්‍රතිචාර රටාවයි. අච්චුව සහ එහි වෙනස් කිරීම් දෙස බලමු.

ඉල්ලීම-ප්රතිචාරය හෝ RPC

අපට වෙනත් ක්‍රියාවලියකින් ප්‍රතිචාරයක් ලැබීමට අවශ්‍ය වූ විට RPC භාවිතා වේ. මෙම ක්‍රියාවලිය එකම නෝඩයක හෝ වෙනත් මහාද්වීපයක පිහිටා තිබිය හැක. පහත දැක්වෙන්නේ පණිවිඩ යැවීම හරහා සේවාලාභියා සහ සේවාදායකය අතර අන්තර්ක්‍රියාවේ රූප සටහනකි.

පණිවිඩ යැවීම සම්පූර්ණයෙන්ම අසමමිතික බැවින්, සේවාදායකයා සඳහා හුවමාරුව අදියර 2 කට බෙදා ඇත:

1. ඉල්ලීම් ඉදිරිපත් කරන්න

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

   හුවමාරුව හුවමාරු ලක්ෂ්‍යයේ අද්විතීය නම
   ResponseMatchingTag ප්‍රතිචාරය සැකසීම සඳහා දේශීය ලේබලය. උදාහරණයක් ලෙස, විවිධ පරිශීලකයින්ට අයත් සමාන ඉල්ලීම් කිහිපයක් යැවීමේදී.
   RequestDefinition - ඉල්ලීම ශරීරය
   හැසිරවීමේ ක්‍රියාවලිය - හසුරුවන්නාගේ 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};

Request-Chunked Response

විශාල පණිවිඩ යැවීමෙන් වැළකී සිටීම හොඳය. සමස්ත පද්ධතියේ ප්‍රතිචාරාත්මක බව සහ ස්ථාවර ක්‍රියාකාරිත්වය මේ මත රඳා පවතී. විමසුමකට ලැබෙන ප්‍රතිචාරය මතකය විශාල ප්‍රමාණයක් ගනී නම්, එය කොටස් වලට බෙදීම අනිවාර්ය වේ.

එවැනි අවස්ථා සඳහා උදාහරණ කිහිපයක් මම ඔබට දෙන්නම්:

• සංරචක ගොනු වැනි ද්විමය දත්ත හුවමාරු කරයි. ප්‍රතිචාරය කුඩා කොටස්වලට කැඩීම ඔබට ඕනෑම ප්‍රමාණයක ගොනු සමඟ කාර්යක්ෂමව ක්‍රියා කිරීමට සහ මතකය පිටාර ගැලීම වළක්වා ගැනීමට උපකාරී වේ.
• ලැයිස්තුගත කිරීම්. උදාහරණයක් ලෙස, අපි දත්ත ගබඩාවේ ඇති විශාල වගුවකින් සියලුම වාර්තා තෝරාගෙන ඒවා වෙනත් සංරචකයකට මාරු කළ යුතුය.

මම මෙම ප්‍රතිචාර වලට දුම්රිය එන්ජිමක් ලෙස කියමි. ඕනෑම අවස්ථාවක, 1024 GB පණිවිඩ 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).

හුවමාරුව - හුවමාරු ස්ථානයේ නම,
යතුර - මාර්ගගත යතුර
පණිවුඩය - ගෙවීම

ප්‍රතිලෝම ප්‍රකාශන-දායක වන්න

pub-sub පුළුල් කිරීමෙන්, ඔබට ලොග් කිරීම සඳහා පහසු රටාවක් ලබා ගත හැකිය. මූලාශ්ර සහ පාරිභෝගිකයින්ගේ කට්ටලය සම්පූර්ණයෙන්ම වෙනස් විය හැකිය. රූපයේ දැක්වෙන්නේ එක් පාරිභෝගිකයෙකු සහ බහු මූලාශ්‍ර සහිත නඩුවකි.

කාර්යය බෙදා හැරීමේ රටාව

සෑම ව්‍යාපෘතියකටම පාහේ වාර්තා උත්පාදනය කිරීම, දැනුම්දීම් ලබා දීම සහ තෙවන පාර්ශවීය පද්ධති වලින් දත්ත ලබා ගැනීම වැනි කල් දැමූ සැකසුම් කාර්යයන් ඇතුළත් වේ. මෙම කාර්යයන් සිදු කරන පද්ධතියේ ප්‍රතිදානය හසුරුවන්න එකතු කිරීමෙන් පහසුවෙන් පරිමාණය කළ හැක. අපට ඉතිරිව ඇත්තේ ප්‍රොසෙසර පොකුරක් සාදා ඒවා අතර කාර්යයන් ඒකාකාරව බෙදා හැරීමයි.

හසුරුවන්නන් 3 දෙනෙකුගේ උදාහරණය භාවිතා කරමින් පැන නගින තත්වයන් දෙස බලමු. කාර්යය බෙදා හැරීමේ අදියරේදී පවා බෙදා හැරීමේ සාධාරණත්වය සහ හසුරුවන්නන්ගේ පිටාර ගැලීම පිළිබඳ ප්රශ්නය පැන නගී. රවුන්ඩ් රොබින් බෙදා හැරීම සාධාරණත්වය සඳහා වගකිව යුතු අතර, හසුරුවන්නන්ගේ පිටාර ගැලීමේ තත්වයක් වළක්වා ගැනීම සඳහා, අපි සීමාවක් හඳුන්වා දෙන්නෙමු prefetch_limit. තාවකාලික තත්වයන් තුළ prefetch_limit එක් හසුරුවන්නෙකුට සියලු කාර්යයන් ලැබීමෙන් වලක්වනු ඇත.

පණිවිඩ යැවීම පෝලිම් සහ සැකසුම් ප්‍රමුඛතාවය කළමනාකරණය කරයි. ප්‍රොසෙසරයට කාර්යයන් ලැබෙන විට ඒවා ලැබේ. කාර්යය සාර්ථකව සම්පූර්ණ කළ හැකි හෝ අසාර්ථක විය හැක:

• messaging:ack(Tack) - පණිවිඩය සාර්ථකව සකසන්නේ නම් අමතන්න
• messaging:nack(Tack) - සියලුම හදිසි අවස්ථා වලදී කැඳවනු ලැබේ. කාර්යය ආපසු ලැබුණු පසු, පණිවිඩ යැවීම එය වෙනත් හසුරුවන්නෙකුට ලබා දෙනු ඇත.

කාර්යයන් තුනක් සැකසීමේදී සංකීර්ණ අසමත් වීමක් සිදු වූ බව සිතමු: ප්‍රොසෙසරය 1, කාර්යය ලැබීමෙන් පසු, හුවමාරු ස්ථානයට කිසිවක් වාර්තා කිරීමට කාලය නොමැතිව බිඳ වැටුණි. මෙම අවස්ථාවෙහිදී, හුවමාරු ස්ථානය කල් ඉකුත්වීමෙන් පසු කාර්යය වෙනත් හසුරුවන්නෙකු වෙත මාරු කරනු ඇත. කිසියම් හේතුවක් නිසා, හසුරුවන්නා 3 කාර්යය අතහැර දමා නිරුවතින් යවා ඇත; එහි ප්‍රතිඵලයක් ලෙස, එය සාර්ථකව නිම කළ වෙනත් හසුරුවන්නෙකුට කාර්යය මාරු කරන ලදී.

මූලික සාරාංශය

අපි බෙදා හරින ලද පද්ධතිවල මූලික ගොඩනැඟිලි කොටස් ආවරණය කර ඇති අතර Erlang/Elixir හි ඒවායේ භාවිතය පිළිබඳ මූලික අවබෝධයක් ලබා ගෙන ඇත.

මූලික රටා ඒකාබද්ධ කිරීමෙන්, නැගී එන ගැටළු විසඳීම සඳහා ඔබට සංකීර්ණ ආදර්ශ ගොඩනගා ගත හැකිය.

මාලාවේ අවසාන කොටසේදී, අපි සේවා සංවිධානය කිරීම, මාර්ගගත කිරීම සහ සමතුලිත කිරීම යන පොදු ගැටළු දෙස බලමු, තවද පද්ධතිවල පරිමාණය සහ වැරදි ඉවසීමේ ප්‍රායෝගික පැත්ත ගැන කතා කරමු.

දෙවන කොටසේ අවසානය.

ඡායාරූප මාරියස් ක්‍රිස්ටෙන්සන්
websequencediagrams.com භාවිතයෙන් සකස් කරන ලද නිදර්ශන

මූලාශ්රය: www.habr.com