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

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

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

სიტუაცია საუკეთესოდ არის შეჯამებული ტვიტების შემდეგი სერიით, რომელიც მე დავწერე ივლისში:

სერვისის ქსელის დაბნეულობა #1: Linkerd ~ = Nginx ~ = Haproxy ~ = დესპანი. არც ერთი არ არის ისტიოს ტოლი. ისტიო სულ სხვა რამეა. 1 /

პირველი არის უბრალოდ მონაცემთა თვითმფრინავები. თავისთავად არაფერს აკეთებენ. მეტის განწყობაზე უნდა იყვნენ. 2/

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

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

რა არის სერვისის ბადე, ნამდვილად?

სურათი 1: სერვისის ბადის მიმოხილვა

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

მონაცემთა თვითმფრინავი

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

• სერვისის აღმოჩენა. რა სერვისები/აპლიკაციებია ხელმისაწვდომი თქვენი განაცხადისთვის?
• ჯანმრთელობის შემოწმება. სერვისის აღმოჩენით დაბრუნებული სერვისის ინსტანციები ჯანსაღი და მზად არიან ქსელის ტრაფიკის მისაღებად? ეს შეიძლება მოიცავდეს როგორც აქტიურ (მაგ. პასუხი/ჯანმრთელობის შემოწმება) ასევე პასიურ (მაგ. 3 ზედიზედ 5xx შეცდომის გამოყენება, როგორც არაჯანსაღი სერვისის მდგომარეობის მაჩვენებელი) ჯანმრთელობის შემოწმებებს.
• მარშრუტიზაცია. REST სერვისიდან "/foo"-ზე მოთხოვნის მიღებისას, რომელ სერვის კლასტერზე უნდა გაიგზავნოს მოთხოვნა?
• Დატვირთვის დაბალანსება. მას შემდეგ რაც შეირჩევა სერვისის კლასტერი მარშრუტიზაციის დროს, სერვისის რომელ ინსტანციაზე უნდა გაიგზავნოს მოთხოვნა? რა ტაიმაუტით? მიკროსქემის გაწყვეტის რა პარამეტრებით? თუ მოთხოვნა ვერ მოხერხდა, უნდა განმეორდეს?
• ავტორიზაცია და ავტორიზაცია. შემომავალი მოთხოვნებისთვის, შესაძლებელია თუ არა დარეკვის სერვისის კრიპტოგრაფიული იდენტიფიცირება/ავტორიზაცია mTLS ან სხვა მექანიზმის გამოყენებით? თუ ის აღიარებულია/ავტორიზებულია, დასაშვებია თუ არა სერვისზე მოთხოვნილი ოპერაციის (ბოლო წერტილის) გამოძახება თუ არაავთენტიფიცირებული პასუხი უნდა დაბრუნდეს?
• დაკვირვებადობა. დეტალური სტატისტიკა, ჟურნალები/ ჟურნალები და განაწილებული კვალის მონაცემები უნდა იყოს გენერირებული თითოეული მოთხოვნისთვის, რათა ოპერატორებმა გააცნობიერონ განაწილებული ტრაფიკის ნაკადი და გამართვის საკითხები, როდესაც ისინი წარმოიქმნება.

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

საკონტროლო თვითმფრინავი

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

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

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

სურათი 2: ადამიანის კონტროლის თვითმფრინავი

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

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

სურათი 3: მოწინავე ბადის მართვის თვითმფრინავი

წლის სურათი 3 გვიჩვენებს მომსახურების ბადის „გაფართოებულ“ საკონტროლო სიბრტყეს. იგი შედგება შემდეგი ნაწილებისგან:

• Ადამიანი: ჯერ კიდევ არის ადამიანი (იმედია ნაკლებად გაბრაზებული), რომელიც იღებს მაღალი დონის გადაწყვეტილებებს მთლიან სისტემასთან დაკავშირებით.
• საკონტროლო თვითმფრინავის UI: ადამიანი ურთიერთქმედებს გარკვეული ტიპის მომხმარებლის ინტერფეისთან სისტემის გასაკონტროლებლად. ეს შეიძლება იყოს ვებ პორტალი, ბრძანების ხაზის აპლიკაცია (CLI) ან სხვა ინტერფეისი. მომხმარებლის ინტერფეისის გამოყენებით, ოპერატორს აქვს წვდომა სისტემის გლობალური კონფიგურაციის პარამეტრებზე, როგორიცაა:
  • განლაგების კონტროლი, ლურჯი/მწვანე და/ან ტრაფიკის თანდათანობითი გადასვლა
  • ავთენტიფიკაციისა და ავტორიზაციის პარამეტრები
  • მარშრუტიზაციის ცხრილის სპეციფიკაციები, მაგალითად, როდესაც აპლიკაცია A ითხოვს ინფორმაციას იმის შესახებ, თუ რა ხდება "/foo".
  • დატვირთვის ბალანსერის პარამეტრები, როგორიცაა დროის ამოწურვა, განმეორებითი ცდები, მიკროსქემის გაწყვეტის პარამეტრები და ა.შ.
• დატვირთვის გრაფიკი: სერვისები ხორციელდება ინფრასტრუქტურაზე გარკვეული ტიპის დაგეგმვის/ორკესტრირების სისტემის მეშვეობით, როგორიცაა Kubernetes ან Nomad. გრაფიკის დამგეგმავი პასუხისმგებელია სერვისის ჩატვირთვაზე ადგილობრივ პროქსისთან ერთად.
• სერვისის აღმოჩენა. როდესაც დამგეგმავი იწყებს და აჩერებს სერვისის მაგალითებს, ის აცნობებს ჯანმრთელობის მდგომარეობას სერვისის აღმოჩენის სისტემას.
• Sidecar proxy-ის კონფიგურაციის API-ები : ლოკალური მარიონეტები დინამიურად ამოიღებენ მდგომარეობას სისტემის სხვადასხვა კომპონენტიდან საბოლოო თანმიმდევრული მოდელის გამოყენებით ოპერატორის ჩარევის გარეშე. მთელი სისტემა, რომელიც შედგება ყველა ამჟამინდელი სერვისის ინსტანციებისა და ლოკალური პროქსი სერვერებისგან, საბოლოოდ გადაიყრება ერთ ეკოსისტემაში. Envoy-ის უნივერსალური მონაცემთა თვითმფრინავის API არის ერთ-ერთი მაგალითი იმისა, თუ როგორ მუშაობს ეს პრაქტიკაში.

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

მონაცემთა თვითმფრინავი და საკონტროლო თვითმფრინავი. მონაცემთა სიბრტყე საკონტროლო სიბრტყის შეჯამება

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

მიმდინარე პროექტის ლანდშაფტი

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

• მონაცემთა თვითმფრინავები: Linkerd, NGINX, HAProxy, Envoy, Traefik
• საკონტროლო თვითმფრინავები: ისტიო, ნელსონი, SmartStack

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

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

ისტიო გამოცხადდა 2017 წლის მაისში. ისტიოს პროექტის მიზნები ძალიან ჰგავს გაფართოებულ საკონტროლო თვითმფრინავს, რომელიც ნაჩვენებია სურათი 3. ისტიოს დესპანი ნაგულისხმევი მარიონეტია. ამრიგად, ისტიო არის საკონტროლო თვითმფრინავი, ხოლო Envoy არის მონაცემთა თვითმფრინავი. მოკლე დროში, Istio-მ დიდი აღფრთოვანება გამოიწვია და სხვა მონაცემთა თვითმფრინავებმა დაიწყეს ინტეგრირება, როგორც Envoy-ის შემცვლელი (როგორც Linkerd-მა, ასევე NGINX-მა აჩვენეს ინტეგრაცია Istio-სთან). ის ფაქტი, რომ სხვადასხვა მონაცემთა სიბრტყე შეიძლება გამოყენებულ იქნას იმავე საკონტროლო სიბრტყეში, ნიშნავს, რომ საკონტროლო სიბრტყე და მონაცემთა სიბრტყე სულაც არ არის მჭიდროდ დაკავშირებული. API, როგორიცაა Envoy's generic data plane API, შეუძლია შექმნას ხიდი სისტემის ორ ნაწილს შორის.

ნელსონი და SmartStack გვეხმარება საკონტროლო სიბრტყისა და მონაცემთა სიბრტყის გამიჯვნის შემდგომ ილუსტრირებაში. ნელსონი იყენებს Envoy-ს თავის მარიონეტად და აშენებს საიმედო საკონტროლო თვითმფრინავს მომსახურების ქსელისთვის HashiCorp სტეკის საფუძველზე, ე.ი. მომთაბარე და ა.შ. SmartStack იყო ალბათ პირველი სერვისის ქსელების ახალი ტალღიდან. SmartStack აშენებს საკონტროლო სიბრტყეს HAProxy-ის ან NGINX-ის ირგვლივ, რაც აჩვენებს საკონტროლო სიბრტყის გამოყოფის უნარს მომსახურების ქსელიდან მონაცემთა სიბრტყიდან.

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

ძირითადი წაღებები

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

წყარო: www.habr.com