სერვისის ბადე: რა უნდა იცოდეს ყველა პროგრამული უზრუნველყოფის ინჟინერმა ყველაზე ცხელი ტექნოლოგიის შესახებ

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

კომიქსიდან სებასტიან კასერესი

შესავალი

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

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

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

ვინ ვარ მე?

Სალამი ყველას! Მე მქვია უილიამ მორგანი. მე ვარ ერთ-ერთი შემქმნელი ლინკერდი - პირველივე სერვისის ქსელის პროექტი და პროექტი, რომელიც ტერმინის გარეგნობის ბრალია სერვისის ბადე როგორც ასეთი (ბოდიში ბიჭებო!). (შენიშვნა თარგმანი.: სხვათა შორის, ამ ტერმინის გამოჩენის გარიჟრაჟზე, 2,5 წელზე მეტი ხნის წინ, ჩვენ უკვე ვთარგმნეთ იგივე ავტორის ადრეული მასალა სახელწოდებით "რა არის სერვისული ქსელი და რატომ მჭირდება ის [მიკრსერვისებით ღრუბლოვანი აპლიკაციისთვის]?".) მეც ვხელმძღვანელობ მდიდარი არის სტარტაპი, რომელიც აყალიბებს მაგარი სერვისის ქსელს, როგორიცაა Linkerd და Dive.

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

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

რა არის სერვისის ბადე?

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

რა არის ეს პროქსი? ეს არის "Layer 7-aware" კატეგორიის TCP პროქსი (ანუ OSI მოდელის მე-7 ფენის „გათვალისწინება“) როგორიცაა HAProxy და NGINX. თქვენ შეგიძლიათ აირჩიოთ პროქსი თქვენი გემოვნებით; Linkerd იყენებს Rust პროქსის, გაურთულებლად დასახელებულ ლინკერდ-პროქსი. ჩვენ შევადგინეთ იგი სპეციალურად მომსახურების ქსელისთვის. სხვა ბადეები უპირატესობას ანიჭებენ სხვა მარიონეტებს (Envoy არის საერთო არჩევანი). თუმცა, პროქსის არჩევა მხოლოდ განხორციელების საკითხია.

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

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

ქვემოთ მოცემულია საკონტროლო სიბრტყისა და მონაცემთა სიბრტყის დიაგრამა Linkerd-ში. როგორც ხედავთ, საკონტროლო სიბრტყე მოიცავს რამდენიმე სხვადასხვა კომპონენტს, მათ შორის პრომეთეს მაგალითს, რომელიც აგროვებს მეტრიკას პროქსი სერვერებიდან, ისევე როგორც სხვა კომპონენტებს, როგორიცაა destination (მომსახურების აღმოჩენა), identity (სერთიფიკატის ორგანო, CA) და public-api (ბოლო წერტილები ვებსა და CLI-სთვის). ამის საპირისპიროდ, მონაცემთა სიბრტყე არის მარტივი ბმული-პროქსი აპლიკაციის ინსტანციის გვერდით. ეს მხოლოდ ლოგიკური დიაგრამაა; რეალურ სამყაროში განლაგებისას შეიძლება გქონდეთ საკონტროლო სიბრტყის თითოეული კომპონენტის სამი ასლი და მონაცემთა სიბრტყეში ასობით ან ათასობით პროქსი.

(ამ დიაგრამაში ლურჯი ველები წარმოადგენს Kubernetes pods-ის საზღვრებს. თქვენ ხედავთ, რომ კონტეინერები linkerd-proxy-ით არის იმავე პოდში, როგორც განაცხადის კონტეინერები. ეს სქემა ცნობილია როგორც გვერდითი კარის კონტეინერი.)

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

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

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

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

დადგა დრო კითხვაზე "რატომ?"

რისთვის არის სერვისული ბადე?

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

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

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

მაგალითად, Linkerd-ში (როგორც ბადეების უმეტესობაში) ფუნქციონირება ძირითადად ფოკუსირებულია HTTP ზარებზე, მათ შორის HTTP/2 და gRPC*. ფუნქციონირება საკმაოდ მდიდარია - ის შეიძლება დაიყოს სამ კლასად:

1. დაკავშირებული მახასიათებლები საიმედოობა. ხელახლა სცადეთ მოთხოვნები, ვადები, კანარის მიდგომა (ტრაფიკის გაყოფა/გადამისამართება) და ა.შ.
2. დაკავშირებული მახასიათებლები მონიტორინგი. წარმატების კოეფიციენტების აგრეგაცია, დაგვიანებები და მოთხოვნის მოცულობა თითოეული სერვისისთვის ან ცალკეული მიმართულებისთვის; სერვისების ტოპოლოგიური რუქების აგება და სხვ.
3. დაკავშირებული მახასიათებლები უსაფრთხოება. ორმხრივი TLS, წვდომის კონტროლი და ა.შ.

* Linkerd-ის თვალსაზრისით, gRPC პრაქტიკულად არაფრით განსხვავდება HTTP/2-ისგან: ის უბრალოდ იყენებს პროტობუფს payload-ში. დეველოპერის თვალსაზრისით, ეს ორი რამ, რა თქმა უნდა, განსხვავებულია.

ამ მექანიზმებიდან ბევრი მუშაობს მოთხოვნის დონეზე (აქედან "L7 პროქსი"). მაგალითად, თუ სერვისი Foo ახორციელებს HTTP ზარს სერვის ზოლზე, Linkerd-proxy-ს Foo-ს მხარეს შეუძლია გონივრული დატვირთვა-ბალანსი და მარშრუტირება ზარები Foo-დან Bar-ში დაკვირვების შეყოვნების საფუძველზე; მას შეუძლია გაიმეოროს მოთხოვნა საჭიროების შემთხვევაში (და თუ ის უძლურია); მას შეუძლია ჩაწეროს საპასუხო კოდი და ვადა და ა.შ. ანალოგიურად, Likerd-proxy-ს ბარის მხარეს შეუძლია უარყოს მოთხოვნა, თუ ის დაუშვებელია ან თუ მოთხოვნის ლიმიტი გადაჭარბებულია; შეუძლია დააფიქსიროს შეფერხება თავის მხრივ და ა.შ.

პროქსიებს შეუძლიათ "რაღაც გააკეთონ" კავშირის დონეზეც. მაგალითად, Linkerd-proxy-ს Foo-ს მხარეს შეუძლია დაუშვას TLS კავშირი, ხოლო Linkerd-proxy-ს ბარის მხარეს შეუძლია შეწყვიტოს იგი და ორივე მხარეს შეუძლია გადაამოწმოს ერთმანეთის TLS სერთიფიკატები*. ეს უზრუნველყოფს არა მხოლოდ სერვისებს შორის დაშიფვრას, არამედ სერვისების იდენტიფიცირების კრიპტოგრაფიულად უსაფრთხო გზას: Foo and Bar-ს შეუძლიათ „დამტკიცონ“, რომ ისინი არიან ის, ვინც ამბობენ, რომ არიან.

* „მეგობრის მეგობარი“ ნიშნავს, რომ კლიენტის სერტიფიკატიც დამოწმებულია (ურთიერთ TLS). "კლასიკურ" TLS-ში, მაგალითად, ბრაუზერსა და სერვერს შორის, ჩვეულებრივ მოწმდება მხოლოდ ერთი მხარის (სერვერის) სერთიფიკატი.

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

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

რატომ არის მომსახურების ბადე კარგი იდეა

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

მოდით გავაანალიზოთ ეს წინადადება.

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

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

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

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

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

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

ვის ეხმარება სერვისის ბადე?

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

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

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

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

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

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

მოკლედ, სერვისის ბადე, უფრო სწორად, არა ტექნიკური გადაწყვეტაა, არამედ სოციალურ-ტექნიკური პრობლემები. (Გმადლობთ სინდი შრიდჰარანი ამ ტერმინის შემოსატანად.

მოაგვარებს თუ არა სერვისის ბადე ჩემს ყველა პრობლემას?

დიახ. ვგულისხმობ, არა!

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

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

1. დამოუკიდებელი ბიზნეს ლოგიკისაგან. ზარის ჰისტოგრამების აგება Foo-სა და Bar-ს შორის სრულიად დამოუკიდებელია თუ არა რატომ Foo რეკავს ბარი.
2. ძნელია სწორად განხორციელება. Linkerd-ში განმეორებითი ცდები პარამეტრიზებულია ყველა სახის ლამაზი ნივთით, როგორიცაა ხელახალი ცდის ბიუჯეტი. (ხელახლა სცადეთ ბიუჯეტი), რადგან უბრალო მიდგომა ასეთი საქმის განხორციელებისადმი აუცილებლად გამოიწვევს ეგრეთ წოდებულ "მოთხოვნების ზვავს" (ხელახლა სცადე ქარიშხალი) და სხვა პრობლემები, რომლებიც სპეციფიკურია განაწილებული სისტემებისთვის.
3. ყველაზე ეფექტურია, როდესაც გამოიყენება თანმიმდევრულად. TLS მექანიზმს აქვს მხოლოდ აზრი, თუ ყველგან გამოიყენება.

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

მომსახურების ქსელის შესაძლებლობების მაგალითები

მოკლედ, სერვისული ბადე არ არის საიმედოობის, დაკვირვებადობის ან უსაფრთხოების სრული გადაწყვეტა. ამ სფეროების ფარგლები გულისხმობს მომსახურების მფლობელების, Ops/SRE გუნდების და კომპანიის სხვა დაინტერესებული მხარეების სავალდებულო მონაწილეობას. სერვისის ქსელი უზრუნველყოფს მხოლოდ "ნაჭერს" პლატფორმის დონეზე თითოეული ამ ზონისთვის.

რატომ გახდა სერვისის ბადე პოპულარული ახლავე?

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

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

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

Netflix-ს ჰყავდა Hysterix, Google-ს ჰქონდა Stubby, Twitter-ს ჰქონდა Finagle ბიბლიოთეკა. მაგალითად, Finagle სავალდებულო იყო Twitter-ის ყოველი ახალი სერვისისთვის. ის ამუშავებდა კავშირების როგორც კლიენტის, ასევე სერვერის მხარეს, ნებადართული იყო განმეორებითი მოთხოვნების, მხარდაჭერილი მოთხოვნის მარშრუტიზაცია, დატვირთვის დაბალანსება და გაზომვა. იგი უზრუნველყოფდა საიმედოობისა და დაკვირვების თანმიმდევრულ ფენას Twitter-ის მთელ დასტაზე, არ აქვს მნიშვნელობა რას აკეთებდა სერვისი. რა თქმა უნდა, ის მხოლოდ JVM ენებზე მუშაობდა და დაფუძნებული იყო პროგრამირების მოდელზე, რომელიც უნდა გამოეყენებინათ მთელი აპლიკაციისთვის. თუმცა, მისი ფუნქციონირება თითქმის იგივე იყო, რაც სერვისის ქსელის. (სინამდვილეში, Linkerd-ის პირველი ვერსია მხოლოდ Finagle იყო პროქსის სახით.)

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

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

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

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

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

რატომ? ჰოდა, დოკერი წყვეტს ერთ დიდ პრობლემას - შეფუთვის პრობლემას. აპლიკაციისა და მისი (არაქსელური) გაშვების დროის დამოკიდებულებების კონტეინერში შეფუთვით, Docker აქცევს აპლიკაციას ცვალებად ერთეულად, რომლის ჰოსტინგი და გაშვება შესაძლებელია ნებისმიერ ადგილას. ამავე დროს, ეს მნიშვნელოვნად ამარტივებს მუშაობას. მრავალენოვანი stack: ვინაიდან კონტეინერი არის შესრულების ატომური ერთეული, არ აქვს მნიშვნელობა რა არის შიგნით, იქნება ეს JVM, Node, Go, Python თუ Ruby აპლიკაცია, განლაგებისა და ოპერაციული მიზნებისთვის. თქვენ უბრალოდ აწარმოებთ და ეს არის ის.

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

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

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

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

რატომ არის ამდენი საუბარი სერვისის ბადეზე?

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

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

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

(ამ სამ კომპანიას ძალიან განსხვავებული როლები აქვს: Lyft-ის ჩართულობა, როგორც ჩანს, მხოლოდ დასახელებით შემოიფარგლება; ისინი აწერენ Envoy-ს, მაგრამ არ იყენებენ ან მონაწილეობენ Istio-ს განვითარებაში. IBM ჩართულია Istio-ს განვითარებაში და იყენებს მას. Google მძიმედ არის დაკავებული. მონაწილეობს ისტიოს განვითარებაში, მაგრამ რამდენადაც მე შემიძლია გითხრათ, ის რეალურად არ იყენებს მას.)

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

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

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

1. ისტიოს აკვიატებული პოპულარიზაცია Google-ის მიერ;
2. პროექტის მიმართ შესაბამისი უკმაყოფილო, კრიტიკული დამოკიდებულება;
3. Kubernetes-ის ბოლოდროინდელი მზარდი პოპულარობა, რომლის მეხსიერება ჯერ კიდევ სუფთაა.

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

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

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

მანამდე, ჩვენ ყველას მოგვიწევს მოთმინება.

სასარგებლო იქნება თუ არა სერვისის ბადე ჩემთვის, მოკრძალებული პროგრამული უზრუნველყოფის ინჟინერისთვის?

შემდეგი კითხვარი დაგეხმარებათ ამ კითხვაზე პასუხის გაცემაში:

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

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

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

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

დასკვნა

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

მინდა სცადოთ Linkerd - დააინსტალიროთ Kubernetes კლასტერში (ან თუნდაც Minikube ლეპტოპზე) დაახლოებით 60 წამი სჭირდებადა თქვენ თვითონ ხედავთ რაზეც ვსაუბრობ.

კითხვა-პასუხი

- სერვისის ბადეს რომ დავაიგნორო, გაქრება?
- იმედები უნდა გაგიცრუოთ: სერვისის ბადე ჩვენთან დიდი ხანია.

— მაგრამ მე არ მინდა სერვისის ბადის გამოყენება!
- კარგი, არ არის საჭირო! უბრალოდ წაიკითხეთ ჩემი კითხვარი ზემოთ, რათა ნახოთ, მაინც უნდა გაეცნოთ მის საფუძვლებს.

— არ არის კარგი ძველი ESB/Middleware ახალი სოუსით?
- სერვისის ქსელი ეხება ოპერაციულ ლოგიკას და არა სემანტიკას. ეს იყო მთავარი მინუსი საწარმოს მომსახურების ავტობუსი (ESB). ამ განცალკევების შენარჩუნება ეხმარება სერვისის ქსელს თავიდან აიცილოს იგივე ბედი.

- რით განსხვავდება სერვისის ქსელი API გეითვეიებისგან?
ამ თემაზე მილიონი სტატიაა. უბრალოდ გუგლი.

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

- Network Service Mesh - არის თუ არა სერვისის ბადე?
- არა. სახელის მიუხედავად, ეს არ არის მომსახურების ქსელი (როგორ მოგწონთ მარკეტინგის საოცრება?).

- დაეხმარება სერვისის ქსელი ჩემს რეაქტიულ ასინქრონულ სისტემაში შეტყობინებების რიგში?
- არა, სერვისის ბადე არ გიშველის.

- რომელი სერვისის ბადე გამოვიყენო?
- ლინკერდი, არა გონიერი.

- სტატია საზიზღარია! / ავტორი - საპონზე!
— გთხოვთ, გაუზიაროთ მისი ბმული ყველა თქვენს მეგობარს, რათა ისინი დარწმუნდნენ ამაში!

მადლობა

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

მიუხედავად იმისა, რომ მე მიყვარს საკუთარ თავს ვუწოდო "Linkerd დეველოპერი", რეალობა ის არის, რომ მე უფრო მეტად ვარ README.md ფაილის შემნახველი პროექტში. დღეს მუშაობს Linkerd-ზე ძალიან, ძალიან, ძალიან много ხალხი და ეს პროექტი შეუძლებელი იქნებოდა კონტრიბუტორებისა და მომხმარებლების საოცარი საზოგადოების გარეშე.

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

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

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

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

წყარო: www.habr.com