განაწილებული აპლიკაციების სამშენებლო ბლოკები. პირველი მიდგომა

Ბოლოს მუხლი ჩვენ განვიხილეთ რეაქტიული არქიტექტურის თეორიული საფუძვლები. დროა ვისაუბროთ მონაცემთა ნაკადებზე, რეაქტიული Erlang/Elixir სისტემების დანერგვის გზებზე და მათში შეტყობინებების შაბლონებზე:

• მოთხოვნა-პასუხი
• მოთხოვნის დაშლილი პასუხი
• პასუხი მოთხოვნით
• გამოქვეყნება-გამოწერა
• Inverted Publish-გამოწერა
• დავალების განაწილება

SOA, MSA და შეტყობინებები

SOA, MSA არის სისტემური არქიტექტურები, რომლებიც განსაზღვრავენ შენობის სისტემების წესებს, ხოლო შეტყობინებები უზრუნველყოფს პრიმიტივებს მათი განხორციელებისთვის.

არ მინდა ამა თუ იმ სისტემის არქიტექტურის პოპულარიზაცია. მე ვარ კონკრეტული პროექტისა და ბიზნესისთვის ყველაზე ეფექტური და სასარგებლო პრაქტიკის გამოყენების მომხრე. როგორი პარადიგმაც არ უნდა ავირჩიოთ, უმჯობესია შევქმნათ სისტემის ბლოკები Unix-ის მიმართულებით: კომპონენტები მინიმალური კავშირით, პასუხისმგებელი ცალკეულ ერთეულებზე. API მეთოდები ასრულებენ უმარტივეს მოქმედებებს ერთეულებთან.

შეტყობინებები არის, როგორც სახელიდან ჩანს, შეტყობინებების ბროკერი. მისი მთავარი მიზანია შეტყობინებების მიღება და გაგზავნა. ის პასუხისმგებელია ინფორმაციის გაგზავნის ინტერფეისებზე, სისტემაში ინფორმაციის გადაცემის ლოგიკური არხების ფორმირებაზე, მარშრუტიზაციასა და დაბალანსებაზე, ასევე სისტემის დონეზე შეცდომების დამუშავებაზე.
მესიჯი, რომელსაც ჩვენ ვავითარებთ, არ ცდილობს კონკურენციას გაუწიოს ან შეცვალოს rabbitmq. მისი ძირითადი მახასიათებლები:

• დისტრიბუცია.
  გაცვლის წერტილები შეიძლება შეიქმნას ყველა კლასტერულ კვანძზე, რაც შეიძლება ახლოს იმ კოდთან, რომელიც მათ იყენებს.
• Სიმარტივე.
  ფოკუსირება ქვაბის კოდის მინიმუმამდე შემცირებაზე და გამოყენების მარტივობაზე.
• უკეთესი შესრულება.
  ჩვენ არ ვცდილობთ გავიმეოროთ rabbitmq-ის ფუნქციონალობა, არამედ გამოვყოთ მხოლოდ არქიტექტურული და სატრანსპორტო ფენა, რომელიც მაქსიმალურად მარტივად ვჯდებით OTP-ში და მინიმუმამდე ვაყენებთ ხარჯებს.
• მოქნილობა
  თითოეულ სერვისს შეუძლია მრავალი გაცვლის შაბლონის გაერთიანება.
• გამძლეობა დიზაინის მიხედვით.
• მასშტაბურობა.
  შეტყობინებები იზრდება აპლიკაციასთან ერთად. დატვირთვის მატებასთან ერთად, შეგიძლიათ გადაიტანოთ გაცვლის წერტილები ცალკეულ მანქანებზე.

კომენტარი კოდის ორგანიზების თვალსაზრისით, მეტა-პროექტები კარგად შეეფერება კომპლექსურ Erlang/Elixir სისტემებს. პროექტის ყველა კოდი განთავსებულია ერთ საცავში - ქოლგის პროექტი. ამავდროულად, მიკროსერვისები მაქსიმალურად იზოლირებულია და ახორციელებენ მარტივ ოპერაციებს, რომლებიც პასუხისმგებელია ცალკეულ სუბიექტზე. ამ მიდგომით ადვილია მთელი სისტემის API-ის შენარჩუნება, მარტივია ცვლილებების შეტანა, მოსახერხებელია ერთეულის და ინტეგრაციის ტესტების ჩაწერა.

სისტემის კომპონენტები ურთიერთქმედებენ უშუალოდ ან ბროკერის მეშვეობით. შეტყობინებების პერსპექტივიდან, თითოეულ სერვისს აქვს ცხოვრების რამდენიმე ეტაპი:

• სერვისის ინიციალიზაცია.
  ამ ეტაპზე სერვისის განმახორციელებელი პროცესი და დამოკიდებულებები კონფიგურირებული და გაშვებულია.
• გაცვლის წერტილის შექმნა.
  სერვისს შეუძლია გამოიყენოს სტატიკური გაცვლის წერტილი, რომელიც მითითებულია კვანძის კონფიგურაციაში, ან შექმნას გაცვლის წერტილები დინამიურად.
• სერვისის რეგისტრაცია.
  იმისათვის, რომ სერვისმა მოახდინოს მოთხოვნები, ის უნდა დარეგისტრირდეს გაცვლის პუნქტში.
• ნორმალური ფუნქციონირება.
  სერვისი აწარმოებს სასარგებლო სამუშაოს.
• სამუშაოს დასრულება.
  შესაძლებელია 2 ტიპის გამორთვა: ნორმალური და გადაუდებელი. ნორმალური მუშაობისას სერვისი გათიშულია გაცვლის პუნქტიდან და ჩერდება. საგანგებო სიტუაციებში, შეტყობინებები ახორციელებს ერთ-ერთ წარუმატებელ სკრიპტს.

საკმაოდ რთულად გამოიყურება, მაგრამ კოდი არც ისე საშინელია. კოდის მაგალითები კომენტარებით მოცემულია შაბლონების ანალიზში ცოტა მოგვიანებით.

გაცვლების

გაცვლის წერტილი არის შეტყობინებების პროცესი, რომელიც ახორციელებს შეტყობინებების შაბლონის კომპონენტებთან ურთიერთქმედების ლოგიკას. ქვემოთ მოყვანილ ყველა მაგალითში კომპონენტები ურთიერთქმედებენ გაცვლის წერტილების მეშვეობით, რომელთა კომბინაცია ქმნის შეტყობინებებს.

შეტყობინებების გაცვლის ნიმუშები (MEPs)

გლობალურად, გაცვლის ნიმუშები შეიძლება დაიყოს ორმხრივ და ცალმხრივად. პირველი გულისხმობს პასუხს შემოსულ შეტყობინებაზე, მეორე არა. კლიენტ-სერვერის არქიტექტურაში ორმხრივი ნიმუშის კლასიკური მაგალითია მოთხოვნა-პასუხის ნიმუში. მოდით შევხედოთ შაბლონს და მის ცვლილებებს.

მოთხოვნა-პასუხი ან RPC

RPC გამოიყენება მაშინ, როდესაც გვჭირდება პასუხის მიღება სხვა პროცესისგან. ეს პროცესი შეიძლება მიმდინარეობდეს იმავე კვანძზე ან განლაგებული იყოს სხვა კონტინენტზე. ქვემოთ მოცემულია კლიენტსა და სერვერს შორის ურთიერთქმედების დიაგრამა შეტყობინებების საშუალებით.

ვინაიდან შეტყობინებები სრულიად ასინქრონულია, კლიენტისთვის გაცვლა დაყოფილია 2 ფაზად:

1. მოთხოვნის გაგზავნა

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

   გაცვლა ‒ გაცვლის წერტილის უნიკალური სახელი
   ResponseMatchingTag ‒ ადგილობრივი ეტიკეტი პასუხის დასამუშავებლად. მაგალითად, სხვადასხვა მომხმარებლის კუთვნილი რამდენიმე იდენტური მოთხოვნის გაგზავნის შემთხვევაში.
   მოთხოვნის განმარტება - მოითხოვეთ ორგანო
   HandlerProcess ‒ დამმუშავებლის 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 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).

გაცვლა - გაცვლის წერტილის დასახელება,
ძირითადი - მარშრუტიზაციის გასაღები
Message - ტვირთამწეობა

Inverted Publish-გამოწერა

pub-sub-ის გაფართოებით, შეგიძლიათ მიიღოთ ხე-ტყვისთვის მოსახერხებელი ნიმუში. წყაროებისა და მომხმარებლების ნაკრები შეიძლება სრულიად განსხვავებული იყოს. ფიგურა გვიჩვენებს შემთხვევას ერთ მომხმარებელთან და რამდენიმე წყაროსთან.

დავალების განაწილების ნიმუში

თითქმის ყველა პროექტი მოიცავს გადადებულ დამუშავების ამოცანებს, როგორიცაა ანგარიშების გენერირება, შეტყობინებების მიწოდება და მესამე მხარის სისტემებიდან მონაცემების მოძიება. ამ ამოცანების შემსრულებელი სისტემის გამტარუნარიანობა მარტივად შეიძლება მასშტაბირდეს დამმუშავებლების დამატებით. ჩვენთვის რჩება მხოლოდ პროცესორების კლასტერის ჩამოყალიბება და დავალებების თანაბრად გადანაწილება მათ შორის.

მოდით შევხედოთ სიტუაციებს, რომლებიც წარმოიქმნება 3 დამმუშავებლის მაგალითის გამოყენებით. დავალების განაწილების ეტაპზეც კი დგება საკითხი განაწილების სამართლიანობისა და დამმუშავებლების გადაჭარბების შესახებ. ორმხრივი განაწილება იქნება პასუხისმგებელი სამართლიანობაზე და დამმუშავებლების გადატვირთვის სიტუაციის თავიდან აცილების მიზნით, შემოგთავაზებთ შეზღუდვას prefetch_limit. გარდამავალ პირობებში prefetch_limit ხელს შეუშლის ერთ დამმუშავებელს ყველა დავალების მიღებაში.

შეტყობინებები მართავს რიგებს და დამუშავების პრიორიტეტს. პროცესორები იღებენ დავალებებს ჩასვლისთანავე. დავალება შეიძლება წარმატებით ან წარუმატებლად დასრულდეს:

• messaging:ack(Tack) - გამოიძახა, თუ შეტყობინება წარმატებით დამუშავდა
• messaging:nack(Tack) - იძახდა ყველა საგანგებო სიტუაციაში. დავალების დაბრუნების შემდეგ, შეტყობინებები მას სხვა დამმუშავებელს გადასცემს.

დავუშვათ, კომპლექსური მარცხი მოხდა სამი ამოცანის დამუშავებისას: პროცესორი 1, დავალების მიღების შემდეგ, ავარიაში მოჰყვა გაცვლის პუნქტს რაიმეს შეტყობინების დრო. ამ შემთხვევაში, გაცვლის წერტილი გადასცემს დავალებას სხვა დამმუშავებელს მას შემდეგ, რაც ამოწურვის ვადა ამოიწურება. რატომღაც, დამმუშავებელმა 3-მა მიატოვა დავალება და გაგზავნა ნაკი; შედეგად, დავალება ასევე გადაეცა სხვა დამმუშავებელს, რომელმაც წარმატებით დაასრულა იგი.

წინასწარი რეზიუმე

ჩვენ გავაშუქეთ განაწილებული სისტემების ძირითადი სამშენებლო ბლოკები და მივიღეთ მათი გამოყენების ძირითადი გაგება Erlang/Elixir-ში.

ძირითადი შაბლონების კომბინაციით, თქვენ შეგიძლიათ შექმნათ რთული პარადიგმები წარმოშობილი პრობლემების გადასაჭრელად.

სერიის დასკვნით ნაწილში განვიხილავთ სერვისების ორგანიზების, მარშრუტიზაციისა და დაბალანსების ზოგად საკითხებს, ასევე ვისაუბრებთ მასშტაბურობის პრაქტიკულ მხარეზე და სისტემების ხარვეზების ტოლერანტობაზე.

მეორე ნაწილის დასასრული.

სურათი მარიუს კრისტენსენი
ილუსტრაციები მომზადებული websequencediagrams.com-ის გამოყენებით

წყარო: www.habr.com