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

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

შესავალი

დაპროექტებული სისტემის ზომიდან და მასზე მოთხოვნებიდან გამომდინარე, ჩვენ, დეველოპერები, ვირჩევთ სისტემაში ინფორმაციის გაცვლის მეთოდს. უმეტეს შემთხვევაში, სერვისების ურთიერთქმედების ორგანიზებისთვის, სამუშაო ვარიანტი შეიძლება იყოს სქემა ბროკერთან, მაგალითად, RabbitMQ ან კაფკაზე დაფუძნებული. მაგრამ ზოგჯერ მოვლენების ნაკადი, SLA და სისტემაზე კონტროლის დონე ისეთია, რომ მზა შეტყობინებები ჩვენთვის არ არის შესაფერისი. რა თქმა უნდა, თქვენ შეგიძლიათ ცოტა გაართულოთ სისტემა სატრანსპორტო ფენისა და კლასტერის ფორმირებაზე პასუხისმგებლობის აღებით, მაგალითად, ZeroMQ ან nanomsg გამოყენებით. მაგრამ თუ სისტემას აქვს საკმარისი გამტარუნარიანობა და სტანდარტული Erlang კლასტერის შესაძლებლობები, მაშინ დამატებითი ერთეულის შემოღების საკითხი მოითხოვს დეტალურ შესწავლას და ეკონომიკურ დასაბუთებას.

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

თეორიული საფუძველი

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

მოდით გამოვყოთ 4 ძირითადი მოთხოვნა საბოლოო სისტემისთვის:

• Сმოვლენებზე ორიენტირებული.
  სისტემა ყოველთვის მზადაა, გაიაროს მოვლენების ნაკადი და განახორციელოს საჭირო ქმედებები;
• Мმასშტაბურობა.
  ცალკეული ბლოკების მასშტაბირება შესაძლებელია როგორც ვერტიკალურად, ასევე ჰორიზონტალურად. მთელ სისტემას უნდა შეეძლოს უსასრულო ჰორიზონტალური ზრდა;
• Оშეცდომის ტოლერანტობა.
  ყველა დონეს და ყველა სერვისს უნდა შეეძლოს ავტომატურად აღდგეს წარუმატებლობისგან;
• Гგარანტირებული რეაგირების დრო.
  დრო ღირებულია და მომხმარებლებმა დიდხანს არ უნდა დაელოდონ.

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

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

მოვლენებზე ორიენტირებული

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

მასშტაბურობა

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

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

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

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

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

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

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

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

რეაგირება

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

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

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

პირველი ნაწილის დასასრული.

სურათი @lucabravo.

წყარო: www.habr.com