არქიტექტურული სტილის არჩევა (ნაწილი 1)

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

შესავალი

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

პატარა ისტორიის

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

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

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

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

მონოლითი

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

Размер

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

დაკავშირება

მონოლითი არის "დიდი ტალახის ბურთი", რომლის ცვლილებებმა შეიძლება გამოიწვიოს არაპროგნოზირებადი შედეგები. ერთ ადგილას ცვლილებების შეტანით, შეგიძლიათ დააზიანოთ მონოლითი მეორეში (იგივე „ყური გახეხე, *@ ჩამოვარდა“). ეს გამოწვეულია იმით, რომ მონოლითის კომპონენტებს აქვთ ძალიან რთული და, რაც მთავარია, არა აშკარა ურთიერთობები.

განლაგება

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

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

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

კიდევ ერთი მაგალითი (უფრო კლასიკური): სერვისი A ბევრად უფრო პოპულარულია ვიდრე სერვისი B, ასე რომ თქვენ გინდათ რომ იყოს 100 სერვისი A და 10 სერვისი B. ისევ ორი ​​ვარიანტი: ან განვათავსოთ 100 სრულფასოვანი მონოლითი, ან ზოგიერთზე. სერვისები B უნდა გამორთოთ ხელით.

საიმედოობა

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

ინერცია

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

დასკვნა

შემდეგ ჯერზე ვისაუბრებთ იმაზე, თუ როგორ ცდილობდნენ ადამიანები ამ პრობლემების გადაჭრას კომპონენტებზე და SOA-ზე გადასვლით.

Წაიკითხე მეტი:

• რატომ არ იძლევა SQL Server შედეგების დახარისხების გარანტიას ORDER BY-ის გარეშე
• არქიტექტურა დეველოპერებისთვის და ადმინისტრატორებისთვის: ვის რა უნარები სჭირდება?

წყარო: www.habr.com