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

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

შესავალი

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

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

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

არქიტექტურების ურთიერთობა

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

მიკროსერვისის არქიტექტურის მახასიათებლები

მიკროსერვისის არქიტექტურის ძირითადი მახასიათებლებია:

• ორგანიზებული ბიზნეს შესაძლებლობების გარშემო
• პროდუქტები და არა პროექტები
• ჭკვიანი ბოლო წერტილები და მუნჯი მილები
• დეცენტრალიზებული მმართველობა
• მონაცემთა დეცენტრალიზებული მართვა
• ინფრასტრუქტურის ავტომატიზაცია
• დიზაინი წარუმატებლობისთვის
• არქიტექტურა ევოლუციური განვითარებით (ევოლუციური დიზაინი)

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

ორგანიზებული ბიზნეს შესაძლებლობების გარშემო

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

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

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

პროდუქტები და არა პროექტები

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

ჭკვიანი ბოლო წერტილები და მუნჯი მილები

SOA არქიტექტურამ დიდი ყურადღება დაუთმო საკომუნიკაციო არხებს, კერძოდ Enterprise Service Bus-ს. რაც ხშირად იწვევს არასწორი სპაგეტის ყუთს, ანუ მონოლითის სირთულე გადადის სერვისებს შორის კავშირების სირთულეში. მიკროსერვისის არქიტექტურა იყენებს მხოლოდ მარტივ საკომუნიკაციო მეთოდებს.

დეცენტრალიზებული მმართველობა

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

მონაცემთა დეცენტრალიზებული მართვა

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

ინფრასტრუქტურის ავტომატიზაცია

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

დიზაინი წარუმატებლობისთვის

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

არქიტექტურა ევოლუციური განვითარებით (ევოლუციური დიზაინი)

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

დასკვნა

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

წაიკითხეთ ნაწილი 2

წყარო: www.habr.com