მიკროსერვისები: ზომა მნიშვნელოვანია, მაშინაც კი, თუ თქვენ გაქვთ Kubernetes

19 სექტემბერს მოსკოვში მოხდა პირველი თემატური შეხვედრა HUG (Highload++ მომხმარებელთა ჯგუფი), რომელიც მიეძღვნა მიკროსერვისებს. გაიმართა პრეზენტაცია „ოპერაციული მიკროსერვისები: ზომა მნიშვნელოვანია, მაშინაც კი, თუ თქვენ გყავთ Kubernetes“, სადაც ჩვენ გავუზიარეთ Flan-ის დიდი გამოცდილება მიკროსერვისის არქიტექტურით პროექტების ექსპლუატაციაში. უპირველეს ყოვლისა, ეს სასარგებლო იქნება ყველა დეველოპერისთვის, ვინც ფიქრობს ამ მიდგომის გამოყენებაზე მიმდინარე თუ მომავალ პროექტში.

გაცნობა მოხსენების ვიდეო (50 წუთი, ბევრად უფრო ინფორმაციული ვიდრე სტატია), ასევე მთავარი ამონაწერი მისგან ტექსტის სახით.

შენიშვნა: ვიდეო და პრეზენტაცია ასევე ხელმისაწვდომია ამ პოსტის ბოლოს.

შესავალი

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

დავიწყებ ამ გრაფიკით, რომლის ავტორიც (2015 წ.) იყო მარტინ ფაულერი:

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

მე დავამატებ ამ გრაფიკს Kubernetes-ის გამოყენების შემთხვევისთვის:

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

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

სასარგებლო და მავნე მიკროსერვისები

და აქ არის მთავარი იდეა:

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

თუ მას დაუძახებ სასარგებლო, მაშინ გრაფის მეორე მხარეს იქნება მავნე მიკროსერვისები (ერევა მუშაობაში):

"მთავარ იდეას" დავუბრუნდეთ: საერთოდ უნდა ვენდო ჩემს გამოცდილებას? ამ წლის დასაწყისიდან ვუყურებ 85 პროექტი. ყველა მათგანი არ იყო მიკროსერვისი (დაახლოებით მესამედ-ნახევარს ჰქონდა ასეთი არქიტექტურა), მაგრამ ეს მაინც დიდი რიცხვია. ჩვენ (კომპანია Flant), როგორც აუთსორსერები ვახერხებთ ვიხილოთ აპლიკაციების მრავალფეროვნება, რომლებიც განვითარებულია როგორც მცირე კომპანიებში (5 დეველოპერებით), ასევე დიდ კომპანიებში (~500 დეველოპერები). დამატებითი სარგებელი ის არის, რომ ჩვენ ვხედავთ ამ აპლიკაციებს ცოცხალ და წლების განმავლობაში განვითარებას.

რატომ მიკროსერვისები?

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

1. მოდულარობის მკაფიო საზღვრები;
2. დამოუკიდებელი განლაგება;
3. ტექნოლოგიების არჩევის თავისუფლება.

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

თუ ჩვენ აღვწერთ ზოგიერთ პუნქტს "სენსაციებში", მაშინ:

• მოდულების მკაფიო საზღვრები: აქ გვაქვს საშინელი მონოლითი და ახლა ყველაფერი კარგად იქნება მოწყობილი Git-ის საცავებში, რომლებშიც ყველაფერი "თაროებზეა", თბილი და რბილი არ არის შერეული;
• განლაგების დამოუკიდებლობა: ჩვენ შევძლებთ სერვისების დამოუკიდებლად გაშვებას, რათა განვითარება უფრო სწრაფად წავიდეს (ახალი ფუნქციების პარალელურად გამოქვეყნება);
• განვითარების დამოუკიდებლობა: ჩვენ შეგვიძლია მივცეთ ეს მიკროსერვისი ერთ გუნდს/დეველოპერს და ის მეორეს, რის წყალობითაც ჩვენ შეგვიძლია უფრო სწრაფად განვვითარდეთ;
• боუფრო დიდი საიმედოობა: თუ მოხდება ნაწილობრივი დეგრადაცია (20-დან ერთი მიკროსერვისი დაეცემა), მაშინ მხოლოდ ერთი ღილაკი შეწყვეტს მუშაობას და სისტემა მთლიანად გააგრძელებს ფუნქციონირებას.

ტიპიური (მავნე) მიკროსერვისის არქიტექტურა

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

ამის მაგალითი იქნება აბსტრაქტული ონლაინ მაღაზია, რომელიც კონკურენციას გაუწევს Amazon-ს ან სულ მცირე OZON-ს. მისი მიკროსერვისის არქიტექტურა ასე გამოიყურება:

რამდენიმე მიზეზის გამო, ეს მიკროსერვისები იწერება სხვადასხვა პლატფორმაზე:

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

რა არის მისი შედეგები?

ფაულერსაც აქვს ეს არის სტატია — მიკროსერვისების გამოყენების „გადახდების“ შესახებ:

და ვნახოთ, გამართლდა თუ არა ჩვენი მოლოდინი.

მოდულების საზღვრების გასუფთავება...

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

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

განლაგების დამოუკიდებლობა...

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

ტექნოლოგიის არჩევის თავისუფლება...

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

განვითარების დამოუკიდებლობა...

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

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

ცალკე სკალირება...

დიახ, მაგრამ ის შეზღუდულია გამოყენებული DBMS-ის არეალში. მოცემულ არქიტექტურის მაგალითში კასანდრას პრობლემები არ ექნება, მაგრამ ექნება MySQL და PostgreSQL.

Боმეტი საიმედოობა...

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

დატვირთვის გაზომვა...

ეს ნამდვილად კარგია.

მიკროსერვისების „სიმსუბუქე“...

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

და აი, ჩვენი მოლოდინების დაკმაყოფილების შედეგი:

მაგრამ ეს ყველაფერი არ არის!

რადგან:

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

რა ვუყოთ ამ ყველაფერს?

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

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

მაგრამ რა მოხდება, თუ ჩვენ უკვე ვართ ამ სიტუაციაში?

ნებისმიერი პრობლემის გადასაჭრელად პირველი ნაბიჯი არის მასზე დათანხმება და იმის გაგება, რომ ეს პრობლემაა, რომ აღარ გვინდა ვიტანჯოთ.

თუ გადაჭარბებული მონოლითის შემთხვევაში (როცა ამისთვის დამატებითი რესურსების შეძენის შესაძლებლობა აღარ გვაქვს) დავჭრათ, მაშინ ამ შემთხვევაში საპირისპირო ამბავი გამოდის: როცა ზედმეტი მიკროსერვისები აღარ გვეხმარება, არამედ ხელს უშლის - ჭარბი ამოჭრა და გადიდება!

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

მოიშორეთ ყველაზე საეჭვო მიკროსერვისები:

გააერთიანეთ ყველა მიკროსერვისი, რომელიც პასუხისმგებელია ფრონტის გენერაციაზე:

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

მას ექნება ერთი ORM (ერთი DBMS) და ჯერ რამდენიმე აპლიკაცია:

... მაგრამ ზოგადად, თქვენ შეგიძლიათ იქ გადაიტანოთ ბევრად მეტი და მიიღოთ შემდეგი შედეგი:

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

Შეჯამება

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

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

და საბოლოო ფიქრისთვის, დავუბრუნდეთ თავდაპირველ სქემას:

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

ვიდეოები და სლაიდები

ვიდეო გამოსვლიდან (~50 წუთი; სამწუხაროდ, არ არის გადმოცემული ვიზიტორების მრავალრიცხოვანი ემოციები, რამაც დიდწილად განსაზღვრა რეპორტაჟის განწყობა, მაგრამ ასეა):

ანგარიშის პრეზენტაცია:

PS

სხვა მოხსენებები ჩვენს ბლოგზე:

• «მონიტორინგი და კუბერნეტები» (დმიტრი სტოლიაროვი; 28 წლის 2018 მაისი RootConf-ზე);
• «CI/CD საუკეთესო პრაქტიკა Kubernetes-თან და GitLab-თან» (დმიტრი სტოლიაროვი; 7 წლის 2017 ნოემბერი HighLoad++-ზე);
• «ჩვენი გამოცდილება Kubernetes-თან მცირე პროექტებში» (დმიტრი სტოლიაროვი; 6 წლის 2017 ივნისი RootConf-ზე);
• «ჩვენ ვაშენებთ Docker-ის სურათებს CI/CD-სთვის სწრაფად და მოხერხებულად დაფის საშუალებით» (დმიტრი სტოლიაროვი; 8 წლის 2016 ნოემბერი HighLoad++-ზე);
• «უწყვეტი მიწოდების პრაქტიკა Docker-თან ერთად» (დმიტრი სტოლიაროვი; 31 წლის 2016 მაისი RootConf-ზე).

თქვენ ასევე შეიძლება დაგაინტერესოთ შემდეგი პუბლიკაციები:

• «მიკროსერვისის სიგიჟის სიკვდილი 2018 წელს";
• «კონტეინერების გამოყენების 7 საუკეთესო პრაქტიკა Google-ის მიხედვით";
• «სტატისტიკა New Stack-დან Kubernetes-ის დანერგვის გამოწვევებზე".

წყარო: www.habr.com