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

ანონსი

კოლეგებო, ზაფხულის შუა რიცხვებში ვგეგმავ სტატიების კიდევ ერთი სერიის გამოშვებას რიგის სისტემების დიზაინზე: "VTrade Experiment" - სავაჭრო სისტემებისთვის ჩარჩოს დაწერის მცდელობა. სერია შეისწავლის ბირჟის, აუქციონისა და მაღაზიის მშენებლობის თეორიასა და პრაქტიკას. სტატიის დასასრულს გეპატიჟებით ხმა მისცეთ იმ თემებს, რომლებიც ყველაზე მეტად გაინტერესებთ.

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

დღეს ჩვენ დავაყენებთ კოდების ბაზის და ზოგადად პროექტების განვითარების საკითხებს.

სერვისების ორგანიზება

რეალურ ცხოვრებაში, სერვისის შემუშავებისას, ხშირად გიწევთ ერთ კონტროლერში რამდენიმე ურთიერთქმედების ნიმუშის გაერთიანება. მაგალითად, მომხმარებელთა სერვისი, რომელიც წყვეტს პროექტის მომხმარებელთა პროფილების მართვის პრობლემას, უნდა უპასუხოს req-resp-ის მოთხოვნებს და მოახსენოს პროფილის განახლებები pub-sub-ის საშუალებით. ეს საქმე საკმაოდ მარტივია: შეტყობინებების მიღმა არის ერთი კონტროლერი, რომელიც ახორციელებს სერვისის ლოგიკას და აქვეყნებს განახლებებს.

სიტუაცია უფრო რთულდება, როდესაც ჩვენ გვჭირდება შეცდომის ტოლერანტული განაწილებული სერვისის განხორციელება. წარმოვიდგინოთ, რომ მომხმარებლის მოთხოვნები შეიცვალა:

1. ახლა სერვისმა უნდა დაამუშავოს მოთხოვნები 5 კლასტერულ კვანძზე,
2. შეძლოს ფონური დამუშავების ამოცანების შესრულება,
3. და ასევე შეუძლია დინამიურად მართოს გამოწერების სიები პროფილის განახლებისთვის.

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

მომხმარებლის სერვისის ოფიციალური აღწერა უფრო გართულდა. პროგრამისტის თვალსაზრისით, ცვლილებები მინიმალურია შეტყობინებების გამოყენების გამო. პირველი მოთხოვნის დასაკმაყოფილებლად, ჩვენ გვჭირდება დაბალანსების კონფიგურაცია req-resp გაცვლის წერტილში.

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

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

შედეგად, პრობლემის დაშლამ აჩვენა, რომ მოთხოვნების დასაკმაყოფილებლად, ჩვენ გვჭირდება სერვისის 5 ინსტანციის გაშვება სხვადასხვა კვანძზე და შევქმნათ დამატებითი ერთეული - pub-sub controller, რომელიც პასუხისმგებელია გამოწერაზე.
5 დამმუშავებლის გასაშვებად, თქვენ არ გჭირდებათ სერვისის კოდის შეცვლა. ერთადერთი დამატებითი მოქმედება გაცვლის პუნქტში დაბალანსების წესების დაწესებაა, რაზეც ცოტა მოგვიანებით ვისაუბრებთ.
ასევე არის დამატებითი სირთულე: pub-sub controller და custom task scheduler უნდა მუშაობდეს ერთ ეგზემპლარად. ისევ და ისევ, შეტყობინებების სერვისმა, როგორც ფუნდამენტურმა, უნდა უზრუნველყოს ლიდერის შერჩევის მექანიზმი.

ლიდერის შერჩევა

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

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

გაცვლის პუნქტთან დაწყებისა და დაკავშირების შემდეგ ყველა სერვისი იღებს სისტემურ შეტყობინებას #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. თუ LeaderPid ემთხვევა pid მიმდინარე პროცესით, იგი ინიშნება ლიდერად და სიაში Servers მოიცავს ყველა კვანძს და მათ პარამეტრებს.
იმ მომენტში, როდესაც გამოჩნდება ახალი და სამუშაო კლასტერული კვანძი გათიშულია, ყველა სერვისის კონტროლერი იღებს #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} შესაბამისად.

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

მედიატორები

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

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

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

წარმოვიდგინოთ, რომ ჩვენ გვყავს 50000 5 აბონენტი "ახალი ამბების" თემაზე. აბონენტები თანაბრად ნაწილდება 50000 სერვერზე. შედეგად, ყოველი განახლება, რომელიც მოდის გაცვლის პუნქტში, განმეორდება 10000-ჯერ: XNUMX-ჯერ თითოეულ სერვერზე, მასზე აბონენტების რაოდენობის მიხედვით. არ არის ძალიან ეფექტური სქემა, არა?
სიტუაციის გასაუმჯობესებლად, შემოვიღოთ პროქსი, რომელსაც აქვს იგივე სახელი, როგორც გაცვლის წერტილი. სახელების გლობალურ რეგისტრატორს უნდა შეეძლოს უახლოესი პროცესის სახელით დაბრუნება, ეს მნიშვნელოვანია.

მოდით გავუშვათ ეს პროქსი წვდომის ფენის სერვერებზე და ყველა ჩვენი პროცესი, რომელიც ემსახურება websocket api-ს, გამოიწერს მას და არა ბირთვში არსებული pub-sub-ის ორიგინალური გაცვლის პუნქტს. Proxy იწერს ბირთვს მხოლოდ უნიკალური გამოწერის შემთხვევაში და იმეორებს შემომავალ შეტყობინებას მის ყველა აბონენტს.
შედეგად, 5-ის ნაცვლად, ბირთვსა და წვდომის სერვერებს შორის გაიგზავნება 50000 შეტყობინება.

მარშრუტირება და დაბალანსება

Req-Resp

შეტყობინებების ამჟამინდელ განხორციელებაში, არსებობს მოთხოვნის განაწილების 7 სტრატეგია:

• default. მოთხოვნა ეგზავნება ყველა კონტროლერს.
• round-robin. მოთხოვნები ჩამოთვლილია და ციკლურად ნაწილდება კონტროლერებს შორის.
• consensus. კონტროლერები, რომლებიც ემსახურებიან სამსახურს, იყოფა ლიდერებად და მონებად. მოთხოვნები იგზავნება მხოლოდ ლიდერთან.
• consensus & round-robin. ჯგუფს ჰყავს ლიდერი, მაგრამ მოთხოვნები ნაწილდება ყველა წევრზე.
• sticky. ჰეშის ფუნქცია გამოითვლება და ენიჭება კონკრეტულ დამმუშავებელს. შემდგომი მოთხოვნები ამ ხელმოწერით მიდის იმავე დამმუშავებელზე.
• sticky-fun. გაცვლის წერტილის ინიციალიზაციისას, ჰეშის გამოთვლის ფუნქცია sticky დაბალანსება.
• fun. როგორც sticky-fun, მხოლოდ თქვენ შეგიძლიათ მისი დამატებით გადამისამართება, უარყოფა ან წინასწარ დამუშავება.

განაწილების სტრატეგია დგინდება გაცვლის წერტილის ინიციალიზაციისას.

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

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

პაბი-ქვე

pub-sub-ისთვის ყველაფერი ცოტა უფრო მარტივია. ჩვენ გვაქვს გაცვლის წერტილი, სადაც ქვეყნდება შეტყობინებები. გაცვლის წერტილი ავრცელებს შეტყობინებებს აბონენტებს შორის, რომლებმაც გამოიწერეს მათთვის საჭირო მარშრუტიზაციის გასაღებები (შეიძლება ვთქვათ, რომ ეს თემების ანალოგია).

მასშტაბურობა და ხარვეზების ტოლერანტობა

სისტემის მასშტაბურობა მთლიანად დამოკიდებულია სისტემის ფენებისა და კომპონენტების მასშტაბურობის ხარისხზე:

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

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

დაჯავშნა

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

ჩემს პროექტებში ვიყენებ დამატებით კვანძებს, რომლებიც იღებენ დატვირთვას დაცემის შემთხვევაში. Erlang-ს აქვს სტანდარტული განაწილებული რეჟიმის დანერგვა OTP აპლიკაციებისთვის. განაწილებული რეჟიმი ახორციელებს აღდგენას წარუმატებლობის შემთხვევაში წარუმატებელი აპლიკაციის გაშვებით სხვა ადრე გაშვებულ კვანძზე. პროცესი გამჭვირვალეა; წარუმატებლობის შემდეგ, აპლიკაცია ავტომატურად გადადის მარცხის კვანძში. ამ ფუნქციის შესახებ მეტი შეგიძლიათ წაიკითხოთ აქ.

მოქმედება

შევეცადოთ უხეშად მაინც შევადაროთ rabbitmq-ის შესრულება და ჩვენი პერსონალური შეტყობინებები.
მე ვიპოვე ოფიციალური შედეგები rabbitmq ტესტირება openstack გუნდისგან.

6.14.1.2.1.2.2 პუნქტში. ორიგინალური დოკუმენტი გვიჩვენებს RPC CAST-ის შედეგს:

ჩვენ წინასწარ არ გავაკეთებთ დამატებით პარამეტრებს OS-ის ბირთვს ან erlang VM-ს. ტესტირების პირობები:

• erl არჩევს: +A1 +sbtu.
• ტესტი ერთ erlang კვანძში ტარდება ლეპტოპზე ძველი i7 მობილური ვერსიით.
• კლასტერული ტესტები ტარდება სერვერებზე 10G ქსელით.
• კოდი მუშაობს დოკერის კონტეინერებში. ქსელი NAT რეჟიმში.

ტესტის კოდი:

req_resp_bench(_) ->
  W = perftest:comprehensive(10000,
    fun() ->
      messaging:request(?EXCHANGE, default, ping, self()),
      receive
        #'$msg'{message = pong} -> ok
      after 5000 ->
        throw(timeout)
      end
    end
  ),
  true = lists:any(fun(E) -> E >= 30000 end, W),
  ok.

სცენარი 1: ტესტი ტარდება ლეპტოპზე ძველი i7 მობილური ვერსიით. ტესტი, შეტყობინებები და სერვისი შესრულებულია ერთ კვანძზე ერთ Docker კონტეინერში:

Sequential 10000 cycles in ~0 seconds (26987 cycles/s)
Sequential 20000 cycles in ~1 seconds (26915 cycles/s)
Sequential 100000 cycles in ~4 seconds (26957 cycles/s)
Parallel 2 100000 cycles in ~2 seconds (44240 cycles/s)
Parallel 4 100000 cycles in ~2 seconds (53459 cycles/s)
Parallel 10 100000 cycles in ~2 seconds (52283 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (49317 cycles/s)

სცენარი 2: 3 კვანძი მუშაობს სხვადასხვა მანქანებზე დოკერის ქვეშ (NAT).

Sequential 10000 cycles in ~1 seconds (8684 cycles/s)
Sequential 20000 cycles in ~2 seconds (8424 cycles/s)
Sequential 100000 cycles in ~12 seconds (8655 cycles/s)
Parallel 2 100000 cycles in ~7 seconds (15160 cycles/s)
Parallel 4 100000 cycles in ~5 seconds (19133 cycles/s)
Parallel 10 100000 cycles in ~4 seconds (24399 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (34517 cycles/s)

ყველა შემთხვევაში, CPU-ის გამოყენება არ აღემატებოდა 250%-ს

შედეგები

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

სურათი @chuttersnap

გამოკითხვაში მონაწილეობა შეუძლიათ მხოლოდ დარეგისტრირებულ მომხმარებლებს. Შებრძანდითგთხოვთ

რა თემები უნდა გავაშუქო უფრო დეტალურად, როგორც VTrade Experiment სერიის ნაწილი?

• თეორია: ბაზრები, შეკვეთები და მათი დრო: DAY, GTD, GTC, IOC, FOK, MOO, MOC, LOO, LOC

• შეკვეთების წიგნი. დაჯგუფებებით წიგნის განხორციელების თეორია და პრაქტიკა

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

• Უკან ოფისში. დაგეგმვა და განვითარება. თანამშრომლების მონიტორინგი და ინციდენტის გამოძიება

• API. მოდით გაერკვნენ, რა ინტერფეისებია საჭირო და როგორ განვახორციელოთ ისინი

• ინფორმაციის შენახვა: PostgreSQL, Timescale, Tarantool სავაჭრო სისტემებში

• რეაქტიულობა სავაჭრო სისტემებში

• სხვა. კომენტარებში დავწერ

მისცა ხმა 6 მომხმარებელმა. 4 მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com