რატომ ვაკეთებთ Enterprise Service Mesh-ს?

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

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

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

პროქსის დონეზე (მონაცემთა სიბრტყე):

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

საკონტროლო თვითმფრინავის დონეზე:

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

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

რატომ არის საჭირო Service Mesh კორპორატიულ სექტორში?

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

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

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

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

უნდა აღინიშნოს, რომ განაწილებული აპლიკაციების განახლება სერვისის ქსელურ გარემოში უფრო ადვილი ხდება. მაგალითად, ლურჯი/მწვანე განლაგება, რომელშიც ინსტალაციისთვის ხელმისაწვდომია ორი აპლიკაციის გარემო, რომელთაგან ერთი არ არის განახლებული და ლოდინის რეჟიმშია. წარუმატებელი გამოშვების შემთხვევაში წინა ვერსიაზე დაბრუნება ხორციელდება სპეციალური როუტერით, რომლის როლსაც Service Mesh კარგად უმკლავდება.. ახალი ვერსიის შესამოწმებლად შეგიძლიათ გამოიყენოთ კანარის გამოშვება — ახალ ვერსიაზე გადაერთეთ ტრაფიკის მხოლოდ 10% ან კლიენტთა საპილოტე ჯგუფის მოთხოვნები. ძირითადი ტრაფიკი მიდის ძველ ვერსიაზე, არაფერი იშლება.

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

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

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

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

რატომ გჭირდებათ Service Mesh პერსონალიზაცია?

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

ღონისძიების დამუშავების სერვისი

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

საკმაოდ უცნაურია, რომ Remote Procedure Call (RPC) მხარდაჭერილია Service Mesh-ის ყველა ვერსიით, მაგრამ ისინი არ არიან მეგობრული EDA-სთან. იმის გამო, რომ Service Mesh არის ერთგვარი თანამედროვე განაწილებული ინტეგრაცია და EDA არის ძალიან შესაბამისი არქიტექტურული ნიმუში, რომელიც საშუალებას გაძლევთ გააკეთოთ უნიკალური რამ მომხმარებლის გამოცდილების თვალსაზრისით.

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

ფაილების გადაცემის სერვისი

EDA-ს გარდა, კარგი იქნებოდა ფაილების გადატანა: Enterprise-ის მასშტაბით, ძალიან ხშირად შესაძლებელია მხოლოდ ფაილების ინტეგრაცია. კერძოდ, გამოიყენება ETL (Extract, Transform, Load) არქიტექტურული ნიმუში. მასში, როგორც წესი, ყველა ცვლის ფაილებს ექსკლუზიურად: გამოიყენება დიდი მონაცემები, რაც არაპრაქტიკულია ცალკეული მოთხოვნების დაყენება. Enterprise Service Mesh-ში ფაილების გადაცემის მხარდაჭერის შესაძლებლობა გაძლევთ მოქნილობას, რომელსაც თქვენი ბიზნესი სჭირდება.

საორკესტრო მომსახურება

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

AI და ML

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

API Gateway სერვისი

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

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

მხარდაჭერის სერვისი კონკრეტული პროტოკოლებისა და მონაცემთა ფორმატებისთვის (AS კარიბჭე)

ამჟამად Service Mesh გადაწყვეტილებების უმეტესობას შეუძლია იმუშავოს მხოლოდ HTTP და HTTP2 ტრაფიკით ან შემცირებულ რეჟიმში TCP/IP დონეზე. Enterprise Service Mesh ჩნდება მრავალი სხვა ძალიან სპეციფიკური მონაცემთა გადაცემის პროტოკოლით. ზოგიერთ სისტემას შეუძლია გამოიყენოს შეტყობინებების ბროკერები, სხვები ინტეგრირებულია მონაცემთა ბაზის დონეზე. თუ კომპანიას აქვს SAP, მაშინ მას ასევე შეუძლია გამოიყენოს საკუთარი ინტეგრაციის სისტემა. უფრო მეტიც, ეს ყველაფერი მუშაობს და არის ბიზნესის მნიშვნელოვანი ნაწილი.

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

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

წყარო: www.habr.com