სერვისის ქსელის გამოყენების სცენარები

Შენიშვნა. თარგმნაამ სტატიის ავტორი (ლუკ პერკინსი) CNCF-ში დეველოპერების ადვოკატია, რომელიც ისეთი ღია კოდის პროექტების სათავეშია, როგორიცაა Linkerd, SMI (Service Mesh Interface) და Kuma (სხვათა შორის, თქვენც გიფიქრიათ, რატომ არ არის Istio ამ სიაში?..). DevOps საზოგადოებაში „service mesh“-ის სახელით ცნობილი მოდური აჟიოტაჟის უკეთ გასაგებად, ის ჩამოთვლის 16 დამახასიათებელ შესაძლებლობას, რომლებსაც ასეთი გადაწყვეტილებები გვთავაზობს.

დღეს სერვისის ბადე ― პროგრამული ინჟინერიის ერთ-ერთი ყველაზე აქტუალური თემაა (და სამართლიანადაც!). ვფიქრობ, რომ ეს წარმოუდგენლად პერსპექტიული ტექნოლოგიაა და ვოცნებობ, რომ ის ფართოდ იქნას გავრცელებული (რა თქმა უნდა, როცა აზრი აქვს). თუმცა, ადამიანების უმეტესობისთვის ის მაინც იდუმალებითაა მოცული. მათაც კი, ვინც მე მას კარგად ვიცნობ მასთან ერთად, ხშირად უჭირთ მისი უპირატესობების და ზუსტად რა არის ის (მათ შორის თქვენი თავმდაბალი მსახურის). ამ სტატიაში შევეცდები სიტუაციის გამოსწორებას სხვადასხვა ჩამოთვლით გამოყენების სცენარები „მომსახურების ბადეები“*.

* მთარგმნელის შენიშვნა: ამ სტატიიდან, ეს თარგმანი („სერვისის ბადე“) გამოყენებული იქნება ჯერ კიდევ ახალი ტერმინისთვის „სერვისის ბადე“.

მაგრამ ჯერ რამდენიმე კომენტარის გაკეთება მინდა:

• მე არასდროს მიმუშავია და არ გამომიყენებია სერვისების ბადეებთან, გარდა ჩემივე საგანმანათლებლო პროექტებისა. მეორეს მხრივ, 2015 წელს დავწერე უამრავი დოკუმენტაცია Twitter-ის შიდა სერვისების ბადისთვის (მაშინ მას „სერვის ბადე“ არც კი ერქვა) და წვლილი შევიტანე საიტზე და დოკუმენტაციაში. ლინკერდი, ასე რომ, ეს რაღაცას ნიშნავს.
• ჩემი სია სავარაუდო და არასრულია. სავარაუდოდ, იქნება გამოყენების შემთხვევები, რომელთა შესახებაც არ ვიცი და, სავარაუდოდ, დროთა განმავლობაში, ტექნოლოგიის განვითარებასა და პოპულარობის ზრდასთან ერთად, ახალი შემთხვევებიც გამოჩნდება.
• ამავდროულად, ყველა არსებული სერვის მეშის იმპლემენტაცია არ უჭერს მხარს ჩამოთვლილ ყველა შემთხვევას. ამიტომ, ჩემი განცხადებები, როგორიცაა „სერვის მეშის შეუძლია...“, უნდა წაიკითხოთ როგორც „ზოგიერთ და შესაძლოა ყველა პოპულარულ სერვის მეშის იმპლემენტაციას შეუძლია...“.
• მაგალითების თანმიმდევრობას მნიშვნელობა არ აქვს.

მოკლე სია:

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

1. სერვისის აღმოჩენა

TL;DR: ქსელში სხვა სერვისებთან დაკავშირება მარტივი სახელების გამოყენებით.

სერვისებს უნდა შეეძლოთ ერთმანეთის ავტომატურად „პოვნა“ შესაბამისი სახელების გამოყენებით, მაგალითად service.api.production, pets/staging ან cassandraღრუბლოვანი გარემო ხასიათდება ელასტიურობით და ერთი სახელით შესაძლებელია მრავალი სერვისის ინსტანციის დამალვა. ცხადია, რომ ასეთ სიტუაციაში ფიზიკურად შეუძლებელია ყველა IP მისამართის მყარი კოდირება.

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

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

2. დაშიფვრა

TL;DR: მოიშორეთ სერვისებს შორის დაუშიფრავი ტრაფიკი და გახადეთ ეს პროცესი ავტომატიზირებული და მასშტაბირებადი.

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

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

3. ავთენტიფიკაცია და ავტორიზაცია

TL;DR: დაადგინეთ, ვინ იწყებს მოთხოვნის შეტანას და რა უფლება აქვთ მათ, სანამ მოთხოვნა სერვისამდე მიაღწევს.

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

1. სხვა სერვისები. ამას ეწოდება „ავთენტიფიკაცია“ პირა„მაგალითად, მომსახურება web სურს სერვისზე წვდომა dbსერვისის ბადეები, როგორც წესი, ასეთ პრობლემებს mTLS-ის გამოყენებით წყვეტენ: ამ შემთხვევაში სერთიფიკატები აუცილებელი იდენტიფიკატორის როლს ასრულებენ.
2. ზოგიერთი ადამიანი მომხმარებელი. ამას „ავთენტიფიკაცია“ ეწოდება. მოთხოვნები„მაგალითად, მომხმარებელი haxor69 სურს ახალი ნათურის ყიდვა. მომსახურების ბადეები სხვადასხვა მექანიზმებს უზრუნველყოფენ, მაგალითად JSON ვებ ტოკენები.

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

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

4. დატვირთვის დაბალანსება

TL;DR: დატვირთვის განაწილება სერვისის ინსტანციებს შორის კონკრეტული ნიმუშის მიხედვით.

„მომსახურება“ მომსახურების განყოფილებაში ხშირად მრავალი იდენტური ასლისგან შედგება. მაგალითად, დღეს მომსახურება cache შედგება 5 ეგზემპლარისგან და ხვალ მათი რიცხვი შეიძლება 11-მდე გაიზარდოს. მოთხოვნები გაიგზავნა cache, უნდა განაწილდეს კონკრეტული მიზნის მიხედვით. მაგალითად, შეყოვნების მინიმიზაციისთვის ან სამუშაო ინსტანციამდე მისვლის ალბათობის მაქსიმიზაციისთვის. ყველაზე ხშირად გამოყენებული ალგორითმია Round-robin სერვისის ალგორითმი, მაგრამ არსებობს მრავალი სხვა, მაგალითად, შეწონილი (შეწონილი) შეკითხვები (შეგიძლიათ აირჩიოთ სასურველი სამიზნეები), ზარი (რგოლი) ჰეშინგი (გამოიყენეთ თანმიმდევრული ჰეშინგი ზედა ნაკადის ჰოსტებისთვის) ან ყველაზე ნაკლები შეკითხვის მეთოდი (უპირატესობა ენიჭება ყველაზე ნაკლები შეკითხვის მქონე ინსტანციას).

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

5. სქემის გათიშვა

TL;DR: პრობლემურ სერვისზე მოძრაობის შეჩერება და უარეს შემთხვევაში ზიანის კონტროლი.

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

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

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

6. ავტომატური მასშტაბირება

TL;DR: სერვისის ეგზემპლარების რაოდენობის გაზრდა ან შემცირება მითითებული კრიტერიუმების მიხედვით.

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

მაგალითად, Kubernetes აფასებს სერვისებს პოდების CPU-სა და მეხსიერების გამოყენების მიხედვით. (იხილეთ ჩვენი ანგარიში)ავტომატური მასშტაბირება და რესურსების მართვა Kubernetes-ში" - დაახლ. თარგმანი.), მაგრამ თუ გადაწყვეტთ მასშტაბირებას სხვა მეტრიკის (ჩვენს შემთხვევაში, ტრაფიკთან დაკავშირებული) მიხედვით, დაგჭირდებათ სპეციალური მეტრიკა. რაღაც ამის მსგავსი აჩვენებს, თუ როგორ უნდა გავაკეთოთ ეს დესპანი, ისტიო и პრომეთე, თუმცა თავად პროცესი საკმაოდ რთულია. ჩვენ გვსურს, რომ სერვისების ბადემ გაამარტივოს ის, რაც საშუალებას მოგვცემს უბრალოდ დავაყენოთ ისეთი პირობები, როგორიცაა „სერვისების ინსტანციების რაოდენობის გაზრდა“. auth, თუ შესასრულებლად მომლოდინე მოთხოვნების რაოდენობა ერთი წუთით აღემატება ზღვარს."

7. კანარის განლაგება

TL;DR: სერვისის ახალი ფუნქციების ან ვერსიების ტესტირება მომხმარებელთა ქვეჯგუფზე.

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

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

8. ლურჯ-მწვანე განლაგებები

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

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

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

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

9. ჯანმრთელობის შემოწმება

TL;DR: აკონტროლეთ, რომელი სერვისის ინსტანციებია ჯანსაღი და უპასუხეთ იმ ინსტანციებს, რომლებიც აღარ არის ჯანსაღი.

Ჯანმრთელობის შემოწმება (ჯანმრთელობის შემოწმება) ეხმარება იმის დადგენაში, მზად არიან თუ არა სერვისის ინსტანციები ტრაფიკის მისაღებად და დასამუშავებლად. მაგალითად, HTTP სერვისების შემთხვევაში, ჯანმრთელობის შემოწმება შეიძლება გამოიყურებოდეს როგორც GET მოთხოვნა საბოლოო წერტილის მიმართ. /healthპასუხი 200 OK ნიშნავს, რომ ეგზემპლარი გამართულია, ნებისმიერი სხვა - რომ ის არ არის მზად ტრაფიკის მისაღებად. სერვისის ბადეები საშუალებას გაძლევთ მიუთითოთ როგორც მდგომარეობის შემოწმების გზა, ასევე ამ შემოწმების შესრულების სიხშირე. ეს ინფორმაცია შემდეგ შეიძლება გამოყენებულ იქნას სხვა მიზნებისთვის - მაგალითად, დატვირთვის დაბალანსებისა და წრედის გათიშვისთვის.

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

10. ტვირთის გადატანა

TL;DR: ტრაფიკის გადამისამართება გამოყენების დროებითი ზრდის საპასუხოდ.

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

11. მოძრაობის პარალელიზაცია/ასახვა

TL;DR: ერთი მოთხოვნის ერთდროულად რამდენიმე ადგილას გაგზავნა.

ზოგჯერ საჭიროა მოთხოვნის (ან მოთხოვნების ნაკრების) ერთდროულად რამდენიმე სერვისისთვის გაგზავნა. ტიპიური მაგალითია საწარმოო ტრაფიკის ნაწილის გაგზავნა ეტაპობრივ სერვისზე. მთავარი საწარმოო ვებ სერვერი აგზავნის მოთხოვნას ქვედა დონის სერვისზე. products.production და მხოლოდ მას. და სერვისის ბადე ინტელექტუალურად კოპირებს ამ მოთხოვნას და აგზავნის მას products.staging, რომლის შესახებაც ვებ სერვერმა არც კი იცის.

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

12. საიზოლაციო

TL;DR: დაყავით თქვენი სერვისის ბადე მინი ქსელებად.

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

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

13. მოთხოვნის სიხშირის შეზღუდვა, ხელახალი მცდელობები და ტაიმ-აუტები

TL;DR: აღარ არის საჭირო თქვენს კოდის ბაზაში დროის მომთხოვნი მოთხოვნების მართვის ამოცანების ჩართვა.

ყველა ეს რამ შეიძლება ჩაითვალოს ცალკეულ გამოყენების შემთხვევებად, მაგრამ მე გადავწყვიტე მათი დაჯგუფება ერთი რამის გამო, რაც მათ საერთო აქვთ: ისინი ათავისუფლებენ მოთხოვნის სასიცოცხლო ციკლის მართვის ამოცანებს, რომლებსაც ჩვეულებრივ აპლიკაციების ბიბლიოთეკები ამუშავებენ. თუ თქვენ ქმნით Ruby on Rails ვებ სერვერს (რომელიც არ არის ინტეგრირებული სერვისების ბადესთან), რომელიც მოთხოვნებს უგზავნის ბექენდ სერვისებს gRPCაპლიკაციას თავად მოუწევს გადაწყვიტოს, რა უნდა გააკეთოს, თუ N მოთხოვნა ვერ შესრულდება. მას ასევე მოუწევს გაარკვიოს, რამდენი ტრაფიკის დამუშავება შეუძლიათ ამ სერვისებს და სპეციალური ბიბლიოთეკის გამოყენებით დააკოდიროს ეს პარამეტრები. გარდა ამისა, აპლიკაციას მოუწევს გადაწყვიტოს, როდის უნდა დანებდეს და მოთხოვნა გაუფუჭდეს (ტაიმ-აუტის მიხედვით). ზემოთ ჩამოთვლილი პარამეტრებიდან რომელიმეს შესაცვლელად, ვებ სერვერი უნდა გაჩერდეს, ხელახლა დააკონფიგურიროთ და გადატვირთოთ.

ამ ამოცანების სერვის ბადზე დელეგირება არა მხოლოდ იმას ნიშნავს, რომ სერვისების შემქმნელებს არ უწევთ მათზე ფიქრი, არამედ იმასაც, რომ მათი განხილვა უფრო გლობალურად შეიძლება. თუ თქვენ გაქვთ სერვისების რთული ჯაჭვი, ვთქვათ A –> B –> C –> D –> E, თქვენ უნდა გაითვალისწინოთ მოთხოვნის მთელი სასიცოცხლო ციკლი. თუ გჭირდებათ სერვის C-ში ვადების გახანგრძლივება, აზრი აქვს ამის გაკეთებას ერთდროულად, და არა ეტაპობრივად: სერვისის კოდის განახლება და ლოდინი, სანამ pull მოთხოვნა მიიღება და CI სისტემა განახლებულ სერვისს განათავსებს.

14. ტელემეტრია

სრული აღწერა: შეაგროვეთ ყველა საჭირო (და არც ისე აუცილებელი) ინფორმაცია სერვისებიდან.

ტელემეტრია არის ქოლგა ტერმინი, რომელიც მოიცავს მეტრიკას, განაწილებულ ტრასირებას და ჟურნალებს. სერვისების ბადეები გვთავაზობენ მექანიზმებს სამივე ტიპის მონაცემების შეგროვებისა და დამუშავებისთვის. სწორედ აქ ხდება ყველაფერი ცოტა ბუნდოვანი, რადგან შესაძლო ვარიანტების რაოდენობა ძალიან დიდია. მეტრიკისთვის არსებობს პრომეთე და სხვა ინსტრუმენტები, რომელთა გამოყენება შესაძლებელია ჟურნალების შესაგროვებლად გამართული, ლოკი, Vector ა.შ. (მაგალითად, ClickHouse ჩვენი ხის სახლი K8s-ისთვის — მთარგმნელის შენიშვნა), განაწილებული ტრასირებისთვის არსებობს Jaeger და ა.შ. თითოეულ სერვის ბადეს შეუძლია ზოგიერთი ინსტრუმენტის მხარდაჭერა და სხვების არა. საინტერესო იქნება იმის ნახვა, შეძლებს თუ არა პროექტი ამას ღია ტელემეტრია გარკვეულ კონვერგენციას უზრუნველყოფენ.

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

• CLI-ში გარკვეული სერვისიდან მიღებული კუდის ჟურნალები;
• მოთხოვნის მოცულობის თვალყურის დევნება სერვისის ბადისებრი დაფიდან;
• განაწილებული კვალის შეგროვება და მათი Jaeger-ის მსგავს სისტემაში გადაგზავნა.

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

15. აუდიტი

TL;DR: ისინი, ვინც ისტორიის გაკვეთილებს ივიწყებენ, განწირულნი არიან მათი გამეორებისთვის.

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

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

16. ვიზუალიზაცია

TL;DR: გაუმარჯოს React.js-ს, უცნაური ინტერფეისების შადრევანს.

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

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

სიაში არ იყვნენ შეყვანილი

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

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

დასკვნა

ჯერჯერობით სულ ეს იყო! კიდევ ერთხელ, ეს სია ძალიან პირობითია და, სავარაუდოდ, არასრული. თუ ფიქრობთ, რომ რამე გამომრჩა ან შეცდომა დავუშვი, დამიკავშირდით Twitter-ზე (@ლუსპერკინსი). გთხოვთ, დაიცვათ ზნეობის წესები.

PS მთარგმნელისგან

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

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «სერვისის ბადე: რა უნდა იცოდეს ყველა პროგრამული უზრუნველყოფის ინჟინერმა ყველაზე ცხელი ტექნოლოგიის შესახებ";
• «რა არის სერვისული ქსელი და რატომ მჭირდება ის [მიკრსერვისებით ღრუბლოვანი აპლიკაციისთვის]?";
• «დაუბრუნდით მიკროსერვისებს Istio-სთან ერთად. Მე -1 ნაწილი".

წყარო: www.habr.com