ინტერნეტში bunch სტატიები о სერვისის ბადე (მომსახურების ბადე) და აი კიდევ ერთი. ჰოო! Მაგრამ რატომ? შემდეგ, მინდა გამოვთქვა ჩემი აზრი, რომ უკეთესი იქნებოდა, სერვისის ბადეები გამოჩენილიყო 10 წლის წინ, კონტეინერების პლატფორმების მოსვლამდე, როგორიცაა Docker და Kubernetes. მე არ ვამბობ, რომ ჩემი თვალსაზრისი სხვებზე უკეთესია ან უარესია, მაგრამ რადგან სერვისის ბადეები საკმაოდ რთული ცხოველებია, მრავალი თვალსაზრისი დაეხმარება მათ უკეთ გაგებაში.

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

dotCloud-ის ისტორია

მე დავწერე dotCloud-ის ისტორიაზე და ამ პლატფორმის არქიტექტურის არჩევანზე, მაგრამ ბევრი არ მითქვამს ქსელის ფენაზე. თუ არ გინდა კითხვაში ჩაძირვა ბოლო სტატია dotCloud-ის შესახებ, მოკლედ აქ არის არსი: ეს არის PaaS პლატფორმა-როგორც სერვისი, რომელიც მომხმარებელს საშუალებას აძლევს გაუშვან აპლიკაციების ფართო სპექტრი (Java, PHP, Python...), მონაცემთა ფართო სპექტრის მხარდაჭერით. სერვისები (MongoDB, MySQL, Redis...) და სამუშაო პროცესი, როგორიცაა Heroku: თქვენ ატვირთავთ თქვენს კოდს პლატფორმაზე, ის აშენებს კონტეინერების სურათებს და ავრცელებს მათ.

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

ტრაფიკის მარშრუტი ჰოსტინგული აპლიკაციებისთვის

dotCloud-ზე აპლიკაციებს შეუძლიათ HTTP და TCP ბოლო წერტილების გამოვლენა.

HTTP ბოლო წერტილები დინამიურად დაემატა დატვირთვის ბალანსერის კლასტერის კონფიგურაციას ჰიპაჩე. ეს არის ის, რასაც დღეს რესურსები აკეთებენ Ingress Kubernetes-ში და დატვირთვის ბალანსერი მოსწონს ტრაეფიკი.

კლიენტები უკავშირდებიან HTTP ბოლო წერტილებს შესაბამისი დომენების მეშვეობით, იმ პირობით, რომ დომენის სახელი მიუთითებს dotCloud დატვირთვის ბალანსერებზე. Არაფერი განსაკუთრებული.

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

კლიენტებს შეუძლიათ TCP ბოლო წერტილებთან დაკავშირება შესაბამისი ჰოსტის სახელის (რაღაც gateway-X.dotcloud.com) და პორტის ნომრის გამოყენებით.

ეს ჰოსტის სახელი გადადის „nats“ სერვერის კლასტერში (არ არის დაკავშირებული NATS), რომელიც გადასცემს შემომავალ TCP კავშირებს სწორ კონტეინერამდე (ან, დატვირთვის დაბალანსებული სერვისების შემთხვევაში, სწორ კონტეინერებამდე).

თუ იცნობთ Kubernetes-ს, ეს ალბათ სერვისებს გაგახსენებთ NodePort.

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

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

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

რით განსხვავდება ეს თანამედროვე სერვისის ქსელისგან?

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

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

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

თანამედროვე სერვისის ბადეები უკეთესად უმკლავდებიან ასეთ პრობლემებს. უპირველეს ყოვლისა, ისინი ამოწმებენ კავშირების მარშრუტიზაციას წყაროში. ლოგიკური ნაკადი იგივეა: клиент → меш → сервис, მაგრამ ახლა ქსელი მუშაობს ადგილობრივად და არა დისტანციურ კვანძებზე, ამიტომ კავშირი клиент → меш არის ლოკალური და ძალიან სწრაფი (მილიწამების ნაცვლად მიკროწამები).

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

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

ტრაფიკის მარშრუტირება პლატფორმის სერვისებისთვის

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

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

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

ეს დაბალი დონის, მისიისთვის კრიტიკული სერვისები განლაგდა კონტეინერების გაშვებით პირდაპირ რამდენიმე საკვანძო კვანძზე. ამ შემთხვევაში არ იყო გამოყენებული სტანდარტული პლატფორმის სერვისები: ლინკერი, გრაფიკი და რნერი. თუ გსურთ შეადარო კონტეინერების თანამედროვე პლატფორმებს, ეს ჰგავს საკონტროლო თვითმფრინავის მართვას docker run პირდაპირ კვანძებზე, დავალების კუბერნეტისთვის დელეგირების ნაცვლად. კონცეფციით საკმაოდ მსგავსია სტატიკური მოდულები (pods), რომელსაც იყენებს kubeadm ან bootkube დამოუკიდებელი კლასტერის ჩატვირთვისას.

ეს სერვისები მარტივი და უხეშად გამოიკვეთა: YAML ფაილში მითითებული იყო მათი სახელები და მისამართები; და თითოეულ კლიენტს უნდა აეღო ამ YAML ფაილის ასლი განლაგებისთვის.

ერთის მხრივ, ის უკიდურესად საიმედოა, რადგან არ საჭიროებს გარე გასაღების/ღირებულების მაღაზიის მხარდაჭერას, როგორიცაა Zookeeper (გახსოვდეთ, etcd ან Consul არ არსებობდა იმ დროს). მეორე მხრივ, ართულებდა სერვისების გადაადგილებას. ყოველ ჯერზე გადატანის დროს, ყველა კლიენტი მიიღებდა განახლებულ YAML ფაილს (და პოტენციურად გადატვირთავდა). არ არის ძალიან კომფორტული!

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

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

ეს ძალიან ჰგავს SmartStack Airbnb-დან, მაგრამ მნიშვნელოვანი განსხვავება ისაა, რომ SmartStack დანერგილია და განლაგებულია წარმოებაში, ხოლო dotCloud-ის შიდა მარშრუტიზაციის სისტემა თაროზე დარჩა, როდესაც dotCloud გახდა Docker.

მე პირადად ვთვლი, რომ SmartStack არის სისტემების ერთ-ერთი წინამორბედი, როგორიცაა Istio, Linkerd და Consul Connect, რადგან ისინი ყველა ერთნაირ ნიმუშს მიჰყვება:

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

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

თუ დღეს გვჭირდებოდა მსგავსი ბადის დანერგვა, შეგვეძლო მსგავსი პრინციპების გამოყენება. მაგალითად, შიდა DNS ზონის კონფიგურაცია სერვისის სახელების მისამართებზე სივრცეში 127.0.0.0/8. შემდეგ გაუშვით HAProxy კლასტერის თითოეულ კვანძზე, მიიღებთ კავშირებს თითოეულ სერვისის მისამართზე (ამ ქვექსელში 127.0.0.0/8) და დატვირთვის გადამისამართება/დაბალანსება შესაბამის ბალანსებზე. HAProxy კონფიგურაციის კონტროლი შესაძლებელია confd, რომელიც საშუალებას გაძლევთ შეინახოთ backend ინფორმაცია etcd-ში ან Consul-ში და ავტომატურად გადაიტანოთ განახლებული კონფიგურაცია HAProxy-ზე საჭიროების შემთხვევაში.

დაახლოებით ასე მუშაობს ისტიო! მაგრამ გარკვეული განსხვავებებით:

• იყენებს დესპანის პროქსი HAProxy-ის ნაცვლად.
• ინახავს backend-ის კონფიგურაციას Kubernetes API-ის მეშვეობით etcd-ის ან Consul-ის ნაცვლად.
• სერვისებს ენიჭება მისამართები შიდა ქვექსელზე (Kubernetes ClusterIP მისამართები) ნაცვლად 127.0.0.0/8.
• აქვს დამატებითი კომპონენტი (ციტადელი) კლიენტსა და სერვერებს შორის ურთიერთ TLS ავთენტიფიკაციის დასამატებლად.
• მხარს უჭერს ახალ ფუნქციებს, როგორიცაა მიკროსქემის გაწყვეტა, განაწილებული მიკვლევა, კანარის განლაგება და ა.შ.

მოდით გადავხედოთ ზოგიერთ განსხვავებას.

დესპანის პროქსი

Envoy Proxy დაწერა Lyft-მა [Uber-ის კონკურენტი ტაქსის ბაზარზე - დაახლ. შესახვევი]. ის მრავალი თვალსაზრისით ჰგავს სხვა პროქსიებს (მაგ. HAProxy, Nginx, Traefik...), მაგრამ Lyft-მა დაწერა მათი, რადგან მათ სჭირდებოდათ ფუნქციები, რომლებიც სხვა პროქსიებს აკლდათ და უფრო გონივრული ჩანდა ახლის შექმნა, ვიდრე არსებულის გაფართოება.

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

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

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

საკონტროლო თვითმფრინავისთვის, ისტიო ეყრდნობა Kubernetes API-ს. ეს დიდად არ განსხვავდება confd-ის გამოყენებისგან, რომელიც ეყრდნობა etcd-ს ან Consul-ს მონაცემთა საცავში გასაღებების ნაკრების სანახავად. Istio იყენებს Kubernetes API-ს Kubernetes რესურსების ნაკრების სანახავად.

ამას შორის: მე პირადად ეს სასარგებლო აღმოჩნდა Kubernetes API აღწერარომელიც წერია:

Kubernetes API სერვერი არის „მუნჯი სერვერი“, რომელიც გთავაზობთ API რესურსების შენახვას, ვერსიებს, ვალიდაციას, განახლებას და სემანტიკას.

Istio შექმნილია Kubernetes-თან მუშაობისთვის; და თუ გსურთ მისი გამოყენება Kubernetes-ის მიღმა, მაშინ უნდა გაუშვათ Kubernetes API სერვერის ეგზემპლარი (და etcd დამხმარე სერვისი).

სერვისის მისამართები

Istio ეყრდნობა ClusterIP მისამართებს, რომლებსაც Kubernetes გამოყოფს, ამიტომ Istio სერვისები იღებენ შიდა მისამართს (არა დიაპაზონში 127.0.0.0/8).

ტრაფიკი ClusterIP მისამართის კონკრეტული სერვისისთვის Kubernetes კლასტერში Istio-ს გარეშე იჭრება kube-proxy-ის მიერ და იგზავნება ამ პროქსის backend-ში. თუ ტექნიკური დეტალები გაინტერესებთ, kube-proxy ადგენს iptables წესებს (ან IPVS დატვირთვის ბალანსერებს, იმისდა მიხედვით, თუ როგორ არის კონფიგურირებული), რათა გადაწეროთ ClusterIP მისამართისკენ მიმავალი კავშირების დანიშნულების IP მისამართები.

მას შემდეგ, რაც Istio დაინსტალირდება Kubernetes კლასტერზე, არაფერი შეიცვლება, სანამ ის აშკარად არ გააქტიურდება მოცემული მომხმარებლისთვის, ან თუნდაც მთელი სახელების სივრცისთვის, კონტეინერის შემოღებით. sidecar საბაჟო ბუდეებში. ეს კონტეინერი დაატრიალებს Envoy-ის მაგალითს და დააყენებს iptables წესების ერთობლიობას სხვა სერვისებზე მიმავალი ტრაფიკის დასაჭერად და ამ ტრაფიკის გადამისამართებას Envoy-ზე.

როდესაც ინტეგრირებულია Kubernetes DNS-თან, ეს ნიშნავს, რომ ჩვენს კოდს შეუძლია დაუკავშირდეს სერვისის სახელით და ყველაფერი „უბრალოდ მუშაობს“. სხვა სიტყვებით რომ ვთქვათ, ჩვენი კოდი აყენებს შეკითხვებს, როგორიცაა http://api/v1/users/4242შემდეგ api მოთხოვნის გადაჭრა 10.97.105.48, iptables-ის წესები წყვეტს კავშირებს 10.97.105.48-დან და გადასცემს მათ ადგილობრივ Envoy proxy-ს, ხოლო ადგილობრივი პროქსი გადაგზავნის მოთხოვნას ფაქტობრივ backend API-ზე. ფუ!

დამატებითი ფრთები

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

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

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

შეიმუშავეთ ან იყიდეთ

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

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

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

უნდა ავირჩიო Istio, Linkerd თუ Consul Connect?

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

რა უნდა აირჩიოს?

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

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

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

წყარო: www.habr.com