ការកសាងប្លុកនៃកម្មវិធីដែលបានចែកចាយ។ វិធីសាស្រ្តដំបូង

ក្នុង​អតីតកាល អត្ថបទ យើងបានពិនិត្យមើលមូលដ្ឋានគ្រឹះទ្រឹស្តីនៃស្ថាបត្យកម្មប្រតិកម្ម។ វាដល់ពេលហើយដើម្បីនិយាយអំពីលំហូរទិន្នន័យ វិធីដើម្បីអនុវត្តប្រព័ន្ធ Erlang/Elixir ដែលមានប្រតិកម្ម និងលំនាំផ្ញើសារនៅក្នុងពួកវា៖

• សំណើ - ការឆ្លើយតប
• ការ​ឆ្លើយ​តប​តាម​ការ​ស្នើ​សុំ
• ឆ្លើយតបជាមួយសំណើ
• បោះពុម្ព-ជាវ
• បោះពុម្ពបញ្ច្រាស - ជាវ
• ការចែកចាយភារកិច្ច

SOA, MSA និងការផ្ញើសារ

SOA, MSA គឺជាស្ថាបត្យកម្មប្រព័ន្ធដែលកំណត់ច្បាប់សម្រាប់ប្រព័ន្ធអគារ ខណៈដែលការផ្ញើសារផ្តល់នូវបុព្វបទសម្រាប់ការអនុវត្តរបស់ពួកគេ។

ខ្ញុំមិនចង់ផ្សព្វផ្សាយនេះ ឬស្ថាបត្យកម្មប្រព័ន្ធនោះទេ។ ខ្ញុំគឺសម្រាប់ការប្រើប្រាស់ការអនុវត្តដែលមានប្រសិទ្ធភាព និងមានប្រយោជន៍បំផុតសម្រាប់គម្រោង និងអាជីវកម្មជាក់លាក់មួយ។ អ្វីក៏ដោយដែលយើងជ្រើសរើសគំរូ វាជាការប្រសើរក្នុងការបង្កើតប្លុកប្រព័ន្ធដោយសម្លឹងមើលលើ Unix-way: សមាសធាតុដែលមានការតភ្ជាប់តិចតួច ដែលទទួលខុសត្រូវចំពោះអង្គភាពនីមួយៗ។ វិធីសាស្ត្រ API អនុវត្តសកម្មភាពសាមញ្ញបំផុតដែលអាចធ្វើទៅបានជាមួយអង្គភាព។

ការផ្ញើសារគឺដូចដែលឈ្មោះបានបង្ហាញ ឈ្មួញកណ្តាលសារ។ គោលបំណងសំខាន់របស់វាគឺទទួល និងផ្ញើសារ។ វាទទួលខុសត្រូវចំពោះចំណុចប្រទាក់សម្រាប់ការបញ្ជូនព័ត៌មាន ការបង្កើតឆានែលឡូជីខលសម្រាប់ការបញ្ជូនព័ត៌មាននៅក្នុងប្រព័ន្ធ ការកំណត់ផ្លូវ និងតុល្យភាព ក៏ដូចជាការដោះស្រាយកំហុសនៅកម្រិតប្រព័ន្ធ។
ការផ្ញើសារដែលយើងកំពុងអភិវឌ្ឍគឺមិនមែនព្យាយាមប្រកួតប្រជែងជាមួយ ឬជំនួស rabbitmq នោះទេ។ លក្ខណៈពិសេសចម្បងរបស់វា:

• ការចែកចាយ។
  ចំណុចប្តូរប្រាក់អាចត្រូវបានបង្កើតនៅលើថ្នាំងចង្កោមទាំងអស់ ឲ្យជិតបំផុតតាមដែលអាចធ្វើទៅបានចំពោះកូដដែលប្រើពួកវា។
• ភាពសាមញ្ញ។
  ផ្តោតលើការកាត់បន្ថយកូដ boilerplate និងភាពងាយស្រួលនៃការប្រើប្រាស់។
• ការសម្តែងកាន់តែប្រសើរ។
  យើងមិនព្យាយាមធ្វើមុខងាររបស់ rabbitmq ឡើងវិញទេ ប៉ុន្តែរំលេចតែស្រទាប់ស្ថាបត្យកម្ម និងការដឹកជញ្ជូន ដែលយើងសមនឹង OTP តាមដែលអាចធ្វើបាន កាត់បន្ថយការចំណាយតិចបំផុត។
• ភាពបត់បែន។
  សេវាកម្មនីមួយៗអាចរួមបញ្ចូលគ្នានូវគំរូផ្លាស់ប្តូរជាច្រើន។
• ភាពធន់នឹងការរចនា។
• លទ្ធភាពធ្វើមាត្រដ្ឋាន។
  ការផ្ញើសាររីកចម្រើនជាមួយកម្មវិធី។ នៅពេលដែលបន្ទុកកើនឡើង អ្នកអាចផ្លាស់ទីចំណុចប្តូរទៅម៉ាស៊ីននីមួយៗ។

សុន្ទរកថា។ នៅក្នុងលក្ខខណ្ឌនៃការរៀបចំកូដ គម្រោងមេតាគឺសមល្អសម្រាប់ប្រព័ន្ធ Erlang/Elixir ស្មុគស្មាញ។ លេខកូដគម្រោងទាំងអស់មានទីតាំងនៅក្នុងឃ្លាំងមួយ - គម្រោងឆ័ត្រ។ ក្នុងពេលជាមួយគ្នានេះ សេវាមីក្រូត្រូវបានញែកដាច់ពីគ្នាជាអតិបរមា និងអនុវត្តប្រតិបត្តិការសាមញ្ញដែលទទួលខុសត្រូវចំពោះអង្គភាពដាច់ដោយឡែកមួយ។ ជាមួយនឹងវិធីសាស្រ្តនេះវាងាយស្រួលក្នុងការរក្សា API នៃប្រព័ន្ធទាំងមូលវាងាយស្រួលក្នុងការធ្វើការផ្លាស់ប្តូរវាងាយស្រួលក្នុងការសរសេរឯកតានិងការធ្វើតេស្តរួមបញ្ចូល។

ធាតុផ្សំនៃប្រព័ន្ធមានអន្តរកម្មដោយផ្ទាល់ ឬតាមរយៈឈ្មួញកណ្តាល។ តាមទស្សនៈនៃការផ្ញើសារ សេវាកម្មនីមួយៗមានដំណាក់កាលជីវិតជាច្រើន៖

• ការចាប់ផ្តើមសេវាកម្ម។
  នៅដំណាក់កាលនេះ ដំណើរការ និងភាពអាស្រ័យដែលប្រតិបត្តិសេវាកម្មត្រូវបានកំណត់រចនាសម្ព័ន្ធ និងចាប់ផ្តើម។
• ការបង្កើតចំណុចផ្លាស់ប្តូរ។
  សេវាកម្មអាចប្រើចំណុចផ្លាស់ប្តូរឋិតិវន្តដែលបានបញ្ជាក់នៅក្នុងការកំណត់រចនាសម្ព័ន្ធថ្នាំង ឬបង្កើតចំណុចផ្លាស់ប្តូរថាមវន្ត។
• ការចុះឈ្មោះសេវាកម្ម។
  ដើម្បីឱ្យសេវាកម្មបម្រើការស្នើសុំវាត្រូវតែចុះឈ្មោះនៅចំណុចប្តូរប្រាក់។
• ដំណើរការធម្មតា។
  សេវាកម្មបង្កើតការងារមានប្រយោជន៍។
• បិទ។
  មាន 2 ប្រភេទនៃការបិទដែលអាចធ្វើទៅបាន: ធម្មតានិងសង្គ្រោះបន្ទាន់។ កំឡុងពេលប្រតិបត្តិការធម្មតា សេវាត្រូវបានផ្តាច់ចេញពីចំណុចប្តូរ ហើយឈប់។ ក្នុង​ស្ថានភាព​អាសន្ន ការ​ផ្ញើ​សារ​ដំណើរការ​ស្គ្រីប​មួយ​ដែល​បរាជ័យ។

វាមើលទៅស្មុគស្មាញណាស់ ប៉ុន្តែកូដមិនគួរឱ្យខ្លាចទាំងអស់នោះទេ។ ឧទាហរណ៍កូដជាមួយមតិយោបល់នឹងត្រូវបានផ្តល់ឱ្យនៅក្នុងការវិភាគនៃគំរូនៅពេលក្រោយបន្តិច។

ការផ្លាស់ប្តូរ

ចំណុចផ្លាស់ប្តូរគឺជាដំណើរការផ្ញើសារដែលអនុវត្តតក្កវិជ្ជានៃអន្តរកម្មជាមួយសមាសធាតុនៅក្នុងគំរូផ្ញើសារ។ នៅក្នុងឧទាហរណ៍ទាំងអស់ដែលបានបង្ហាញខាងក្រោម សមាសធាតុមានអន្តរកម្មតាមរយៈចំណុចផ្លាស់ប្តូរ ដែលជាការរួមបញ្ចូលគ្នានៃទម្រង់នៃការផ្ញើសារ។

គំរូផ្លាស់ប្តូរសារ (MEPs)

ជាសកល គំរូនៃការផ្លាស់ប្តូរអាចបែងចែកជាពីរផ្លូវ និងផ្លូវមួយ។ អតីត​តំណាង​ឱ្យ​ការ​ឆ្លើយ​តប​ទៅ​នឹង​សារ​ចូល​មួយ, បន្ទាប់​មក​មិន​ធ្វើ​។ ឧទាហរណ៍បុរាណនៃលំនាំពីរផ្លូវនៅក្នុងស្ថាបត្យកម្មម៉ាស៊ីនភ្ញៀវ-ម៉ាស៊ីនមេ គឺជាគំរូឆ្លើយតបសំណើ។ សូមក្រឡេកមើលគំរូ និងការកែប្រែរបស់វា។

សំណើរឆ្លើយតប ឬ RPC

RPC ត្រូវបានប្រើនៅពេលដែលយើងត្រូវការទទួលការឆ្លើយតបពីដំណើរការផ្សេងទៀត។ ដំណើរការនេះអាចដំណើរការនៅលើ node ដូចគ្នា ឬនៅលើទ្វីបផ្សេងទៀត។ ខាងក្រោមនេះគឺជាដ្យាក្រាមនៃអន្តរកម្មរវាងអតិថិជន និង ម៉ាស៊ីនបម្រើ តាមរយៈសារ។

ដោយសារការផ្ញើសារគឺមិនសមកាលកម្មទាំងស្រុង សម្រាប់អតិថិជន ការផ្លាស់ប្តូរត្រូវបានបែងចែកជា 2 ដំណាក់កាល៖

1. កំពុងផ្ញើសំណើ

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

   ការផ្លាស់ប្តូរ - ឈ្មោះតែមួយគត់នៃចំណុចផ្លាស់ប្តូរ
   ResponseMatchingTag - ស្លាកមូលដ្ឋានសម្រាប់ដំណើរការការឆ្លើយតប។ ឧទាហរណ៍ នៅក្នុងករណីនៃការផ្ញើសំណើដូចគ្នាបេះបិទជាច្រើនដែលជាកម្មសិទ្ធិរបស់អ្នកប្រើផ្សេងគ្នា។
   និយមន័យសំណើ - ស្នើសុំរាងកាយ
   ដំណើរការអ្នកដោះស្រាយ - PID របស់អ្នកដោះស្រាយ។ ដំណើរការនេះនឹងទទួលបានការឆ្លើយតបពីម៉ាស៊ីនមេ។

2. កំពុងដំណើរការការឆ្លើយតប

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

   ResponsePayload - ការឆ្លើយតបរបស់ម៉ាស៊ីនមេ។

សម្រាប់ម៉ាស៊ីនមេ ដំណើរការក៏មាន 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 នៃ 1 MB គឺល្អជាងសារតែមួយនៃ 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 អ្នកអាចទទួលបានលំនាំដែលងាយស្រួលសម្រាប់ការកត់ត្រា។ សំណុំនៃប្រភព និងអ្នកប្រើប្រាស់អាចខុសគ្នាទាំងស្រុង។ តួរលេខបង្ហាញពីករណីដែលមានអ្នកប្រើប្រាស់ម្នាក់ និងប្រភពច្រើន។

គំរូចែកចាយភារកិច្ច

ស្ទើរតែគ្រប់គម្រោងទាំងអស់ពាក់ព័ន្ធនឹងកិច្ចការដំណើរការដែលបានពន្យារពេល ដូចជាការបង្កើតរបាយការណ៍ ការផ្តល់ការជូនដំណឹង និងការទាញយកទិន្នន័យពីប្រព័ន្ធភាគីទីបី។ ដំណើរការនៃប្រព័ន្ធដែលបំពេញភារកិច្ចទាំងនេះអាចត្រូវបានធ្វើមាត្រដ្ឋានយ៉ាងងាយស្រួលដោយបន្ថែមឧបករណ៍ដោះស្រាយ។ អ្វីដែលនៅសេសសល់សម្រាប់យើងគឺបង្កើតជាចង្កោមនៃ processors និងចែកចាយភារកិច្ចឱ្យស្មើគ្នារវាងពួកគេ។

សូមក្រឡេកមើលស្ថានភាពដែលកើតឡើងដោយប្រើឧទាហរណ៍នៃ 3 handlers ។ សូម្បីតែនៅដំណាក់កាលនៃការចែកចាយភារកិច្ចក៏ដោយ ក៏សំណួរនៃភាពយុត្តិធម៌នៃការចែកចាយ និងការហូរហៀររបស់អ្នកដោះស្រាយកើតឡើង។ ការចែកចាយជុំវិលជុំនឹងទទួលខុសត្រូវចំពោះភាពយុត្តិធម៌ ហើយដើម្បីជៀសវាងស្ថានភាពនៃការលើសចំណុះនៃអ្នកដោះស្រាយ យើងនឹងណែនាំការរឹតបន្តឹង prefetch_limit. នៅក្នុងលក្ខខណ្ឌបណ្តោះអាសន្ន prefetch_limit នឹងរារាំងអ្នកដោះស្រាយម្នាក់ពីការទទួលកិច្ចការទាំងអស់។

ការផ្ញើសារគ្រប់គ្រងជួរ និងដំណើរការអាទិភាព។ អ្នកដំណើរការទទួលបានភារកិច្ចនៅពេលពួកគេមកដល់។ កិច្ចការអាចបញ្ចប់ដោយជោគជ័យ ឬបរាជ័យ៖

• messaging:ack(Tack) - បានហៅប្រសិនបើសារត្រូវបានដំណើរការដោយជោគជ័យ
• messaging:nack(Tack) - បានហៅក្នុងស្ថានភាពអាសន្នទាំងអស់។ នៅពេលដែលកិច្ចការត្រូវបានប្រគល់មកវិញ ការផ្ញើសារនឹងបញ្ជូនវាទៅអ្នកដោះស្រាយផ្សេងទៀត។

ឧបមាថាការបរាជ័យស្មុគ្រស្មាញមួយបានកើតឡើងខណៈពេលដែលដំណើរការភារកិច្ចបី: ខួរក្បាល 1 បន្ទាប់ពីទទួលបានភារកិច្ចបានគាំងដោយមិនមានពេលវេលាដើម្បីរាយការណ៍អ្វីទៅចំណុចផ្លាស់ប្តូរ។ ក្នុងករណីនេះ ចំណុចផ្លាស់ប្តូរនឹងផ្ទេរភារកិច្ចទៅអ្នកដោះស្រាយផ្សេងទៀត បន្ទាប់ពីអស់ពេល ack បានផុតកំណត់។ សម្រាប់ហេតុផលមួយចំនួន អ្នកគ្រប់គ្រងទី 3 បានបោះបង់កិច្ចការនោះ ហើយបានបញ្ជូន nack ជាលទ្ធផល ភារកិច្ចក៏ត្រូវបានផ្ទេរទៅឱ្យអ្នកដោះស្រាយផ្សេងទៀតដែលបានបញ្ចប់វាដោយជោគជ័យ។

សង្ខេបបឋម

យើងបានគ្របដណ្តប់លើប្លុកអគារជាមូលដ្ឋាននៃប្រព័ន្ធចែកចាយ និងទទួលបានការយល់ដឹងជាមូលដ្ឋានអំពីការប្រើប្រាស់របស់ពួកគេនៅក្នុង Erlang/Elixir ។

តាមរយៈការរួមបញ្ចូលគ្នានៃគំរូមូលដ្ឋាន អ្នកអាចបង្កើតគំរូស្មុគស្មាញ ដើម្បីដោះស្រាយបញ្ហាដែលកំពុងកើតមាន។

នៅក្នុងផ្នែកចុងក្រោយនៃស៊េរី យើងនឹងពិនិត្យមើលបញ្ហាទូទៅនៃសេវាកម្មរៀបចំ ការកំណត់ផ្លូវ និងតុល្យភាព ហើយក៏និយាយអំពីផ្នែកជាក់ស្តែងនៃមាត្រដ្ឋាន និងការអត់ឱនចំពោះកំហុសនៃប្រព័ន្ធ។

ចុងបញ្ចប់នៃផ្នែកទីពីរ។

រូបថត Marius Christensen
រូបភាពដែលបានរៀបចំដោយប្រើ websequencediagrams.com

ប្រភព: www.habr.com