მთავარი დასკვნა
კონტეინერების ეფექტიანობა VM‑ის დონის იზოლაციას ნუ გაუტოლებთ; ცალ-ცალკე დაიცავით ჰოსტი, ჰიპერვიზორი, იმიჯი, სერვისის იდენტობა და ქსელური საზღვრები.
ჰიპერვიზორი ფიზიკურ რესურსებს VM‑ებზე ანაწილებს
ჰიპერვიზორი, ანუ ვირტუალური მანქანების მონიტორი, CPU‑ის, მეხსიერების, დისკისა და ქსელის რესურსებს რამდენიმე VM‑ს უნაწილებს; თითოეულს საკუთარი ოპერაციული სისტემა და პროცესები აქვს. ტიპი 1‑ის ჰიპერვიზორი უშუალოდ აპარატურაზე მუშაობს, ტიპი 2‑ის კი ჰოსტის ოპერაციულ სისტემაზე. ტიპი 1 გავრცელებულია საწარმოო მონაცემთა ცენტრებში, ტიპი 2 კი ადგილობრივი განვითარებისა და ტესტირებისთვის გამოდგება. საერთო რესურსები სერვერების გაერთიანებასა და გარემოების სწრაფ შექმნას უწყობს ხელს, თუმცა ჰიპერვიზორი თავადაც მართვის კრიტიკულ შრედ რჩება.
| ტიპი | სად მუშაობს | ტიპური გამოყენება |
|---|---|---|
| ტიპი 1 | უშუალოდ ფიზიკურ აპარატურაზე | სერვერი, მონაცემთა ცენტრი, ღრუბლოვანი ჰოსტი |
| ტიპი 2 | ჰოსტის ოპერაციულ სისტემაზე | განვითარება, ტესტირება, სამუშაო მაგიდის ვირტუალიზაცია |
VM‑ები და კონტეინერები სხვადასხვა იზოლაციას უზრუნველყოფს
VM ვირტუალურ აპარატურას ჰიპერვიზორით იღებს და სრულ სტუმარ ოპერაციულ სისტემას ამუშავებს. ჩვეულებრივი OS‑დონის კონტეინერი აპლიკაციასა და მის დამოკიდებულებებს აერთიანებს, ჰოსტის ბირთვს იზიარებს და გამიჯვნისთვის OS‑ის მექანიზმებს, მაგალითად namespaces‑სა და cgroups‑ს იყენებს. ეს კონტეინერებს მსუბუქსა და სწრაფს ხდის, თუმცა ბირთვისა და შესრულების გარემოს რისკებს არ აქრობს. ცალკე კონტეინერის იმიჯები ცალკე ოპერაციული სისტემის საზღვრებს არ ნიშნავს. VM შეიძლება გამოდგეს დატვირთვისთვის, რომელსაც სპეციალური ბირთვი, ძველი დამოკიდებულებები ან კლიენტების გარემოების უფრო ძლიერი გამიჯვნა სჭირდება; კონტეინერები კი მრავალი თავსებადი კომპონენტის სწრაფი მიწოდებისთვის გამოდგება.
მიკროსერვისი დამოუკიდებლად დასანერგი საქმიანი ფუნქციაა
მიკროსერვისი ცალკე პროცესია, რომელიც ვიწრო საქმიან ფუნქციას ასრულებს და API‑ებით ან შეტყობინებებით უკავშირდება სხვებს. გადახდები, ავთენტიფიკაცია და შეტყობინებები შეიძლება ცალკე სერვისები იყოს; თითოეულ გუნდს თავისი კომპონენტის დამოუკიდებლად ტესტირება და დანერგვა შეუძლია. მონოლითმა შეიძლება დანერგვა და საერთო კოდი გაამარტივოს, მიკროსერვისებმა კი გუნდებს შერჩეული კომპონენტების დამოუკიდებლად მასშტაბირებისა და განახლების საშუალება მისცეს. სანაცვლოდ მეტი ქსელური კომუნიკაციის, დანერგვის, იდენტობის, ჟურნალისა და მონაცემთა ნაკადის მართვაა საჭირო. არქიტექტურა მხოლოდ ტენდენციის გამო არ დაყოთ; შეაფასეთ გუნდის ოპერაციული შესაძლებლობები და სერვისების საზღვრების რეალური ღირებულება.
| ასპექტი | მონოლითი | მიკროსერვისი |
|---|---|---|
| გამოშვება | აპლიკაცია ერთ მთლიანობად | დამოუკიდებლად თითოეული სერვისისთვის |
| მასშტაბირება | შეიძლება მთლიანად აპლიკაციის მასშტაბირება მოხდეს | დატვირთულ სერვისს დამოუკიდებლად მასშტაბირება შეუძლია |
| ოპერაციული სირთულე | საწყის ეტაპზე ნაკლები კომპონენტი | მეტი კავშირის ზედამხედველობას მოითხოვს |
სამუშაო დატვირთვებს შორის ნდობა მკაფიოდ განსაზღვრეთ
ერთ ქსელში ყოფნა სერვისს ავტომატურად სანდოს არ უნდა ხდიდეს. სერვისის მოთხოვნებისთვის გამოიყენეთ ორმხრივი ავთენტიფიკაცია და დაშიფვრა, დატვირთვების ხანმოკლე იდენტობები და მინიმალური უფლებები. აგებისას დაასკანირეთ კონტეინერის იმიჯები და დამოკიდებულებები, დაიცავით იმიჯების სანდო წყაროები, განაახლეთ ჰოსტები და ჰიპერვიზორები. ქსელური პოლიტიკებით მხოლოდ საჭირო პოდებისა და პორტების კავშირები დაუშვით. შეაგროვეთ შესრულებისა და სერვისის ჟურნალები და მეტრიკები, რათა კომპონენტის გატეხვისას საეჭვო კომუნიკაცია და მონაცემთა ნაკადები ხილული დარჩეს.
დანერგვა და დაკვირვებადობა ერთად შეარჩიეთ
კონტეინერები გარემოებს შორის გადაადგილდება, თუმცა მდგომარეობის შემნახველ სერვისებს, აპარატურის მოთხოვნებსა და მუდმივ საცავს გააზრებული დიზაინი სჭირდება. მიკროსერვისების რაოდენობის ზრდასთან ერთად ხილული გახადეთ თითოეულის მფლობელი, ვერსია, დამოკიდებულებები და მონაცემების საზღვარი. ცენტრალიზებული ჟურნალები, მეტრიკები და ტრასები სერვისებს შორის მოთხოვნების აღდგენაში გვეხმარება; ჟურნალებსა და მეტრიკის ეტიკეტებში მგრძნობიარე მონაცემები არ შეიტანოთ. CI/CD‑ით აკონტროლეთ თითოეული იმიჯის უკან მდგომი კომიტი და შემოწმებები და ინციდენტებისას წინა ვერსიაზე დაბრუნება ივარჯიშეთ.