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

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

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

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

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

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

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

გადაწყვეტილებები

ამ მიდგომის რამდენიმე განხორციელება უკვე არსებობს: ისტიო и linkerd2. ისინი უზრუნველყოფენ უამრავ ფუნქციას ყუთიდან. მაგრამ ამავდროულად, დიდი ხარჯები მოდის რესურსებზე. უფრო მეტიც, რაც უფრო დიდია კლასტერი, რომელშიც მუშაობს ასეთი სისტემა, მით მეტი რესურსი იქნება საჭირო ახალი ინფრასტრუქტურის შესანარჩუნებლად. Avito-ში ჩვენ ვმუშაობთ kubernetes კლასტერებით, რომლებიც შეიცავს ათასობით სერვისის მაგალითს (და მათი რიცხვი სწრაფად იზრდება). მისი ამჟამინდელი განხორციელებისას, Istio მოიხმარს ~ 300 Mb RAM-ს თითო სერვისის ინსტანციაზე. შესაძლებლობების დიდი რაოდენობის გამო, გამჭვირვალე დაბალანსება ასევე გავლენას ახდენს სერვისების საერთო რეაგირების დროზე (10 ms-მდე).

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

შედეგად მივედით ჩვენს გადაწყვეტილებამდე:  ნეტრამეში.

ნეტრამეში

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

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

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

მოქმედება

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

ვნახოთ რა შედეგი მივიღეთ.

RAM

Netramesh მოიხმარს ~10Mb ტრაფიკის გარეშე და 50Mb მაქსიმუმს 10000 RPS-მდე დატვირთვით თითო შემთხვევაზე.

Istio envoy proxy ყოველთვის მოიხმარს ~ 300Mb ჩვენს კლასტერებში ათასობით ინსტანციით. ეს არ იძლევა საშუალებას მის მასშტაბირებას მთელ კლასტერზე.

Netramesh-ით მივიღეთ მეხსიერების მოხმარების ~10-ჯერ შემცირება.

CPU

CPU-ის გამოყენება დატვირთვის დროს შედარებით თანაბარია. ეს დამოკიდებულია მოთხოვნის რაოდენობაზე დროის ერთეულზე გვერდითი კარისთვის. მნიშვნელობები 3000 მოთხოვნა წამში პიკზე:

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

ჩვენ ვიყენებთ HTTP/1 სერვისებს შორის კომუნიკაციისთვის. Istio-სთვის რეაგირების დროის ზრდა დესპანის მეშვეობით პროქსის დროს იყო 5-10ms-მდე, რაც საკმაოდ ბევრია სერვისებისთვის, რომლებიც მზად არიან უპასუხონ მილიწამში. ნეტრამეშთან ერთად ეს დრო შემცირდა 0.5-2მმ-მდე.

მასშტაბურობა

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

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

Netramesh არ ამატებს სერვისის აღმოჩენის დამატებით მექანიზმებს. მთელი ტრაფიკი გამჭვირვალედ ხდება ნეტრა გვერდითი კარის მეშვეობით.

Netramesh მხარს უჭერს HTTP/1 აპლიკაციის პროტოკოლს. მის დასადგენად გამოიყენება პორტების კონფიგურირებადი სია. როგორც წესი, სისტემას აქვს რამდენიმე პორტი, რომლის მეშვეობითაც ხდება HTTP კომუნიკაცია. მაგალითად, ჩვენ ვიყენებთ 80, 8890, 8080 სერვისებსა და გარე მოთხოვნებს შორის ურთიერთქმედებისთვის. ამ შემთხვევაში, მათი დაყენება შესაძლებელია გარემოს ცვლადის გამოყენებით. NETRA_HTTP_PORTS.

თუ იყენებთ Kubernetes-ს, როგორც ორკესტრატორს და მის სერვისის ერთეულ მექანიზმს სერვისებს შორის კლასტერული კომუნიკაციისთვის, მაშინ მექანიზმი ზუსტად იგივე რჩება. პირველი, მიკროსერვისი იღებს სერვისის IP მისამართს kube-dns-ის გამოყენებით და ხსნის მას ახალ კავშირს. ეს კავშირი პირველად დამყარდა ადგილობრივ netra-sidecar-თან და ყველა TCP პაკეტი თავდაპირველად მივა ნეტრაზე. შემდეგი, netra-sidecar ამყარებს კავშირს თავდაპირველ დანიშნულებასთან. NAT pod IP-ზე კვანძზე ზუსტად იგივე რჩება, რაც ნეტრას გარეშე.

განაწილებული მიკვლევა და კონტექსტის გადაგზავნა

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

მაგრამ არის პრობლემა. სანამ სერვისები არ გამოიმუშავებენ და არ გამოგზავნიან სპეციალურ uber სათაურს, ჩვენ ვერ დავინახავთ დაკავშირებულ ტრასირების სპანებს სისტემაში. და ეს არის ის, რაც ჩვენ გვჭირდება, რომ სწრაფად მოვძებნოთ პრობლემების მიზეზი. აქ ისევ ნეტრამეშს აქვს გამოსავალი. პროქსიები კითხულობენ HTTP სათაურებს და, თუ ისინი არ შეიცავს uber trace id-ს, ქმნიან მას. Netramesh ასევე ინახავს ინფორმაციას შემომავალი და გამავალი მოთხოვნების შესახებ გვერდით კარში და ასახავს მათ საჭირო გამავალი მოთხოვნის სათაურებით გამდიდრებით. სერვისებში მხოლოდ ერთი სათაურის გაგზავნა გჭირდებათ X-Request-Id, რომლის კონფიგურაცია შესაძლებელია გარემოს ცვლადის გამოყენებით NETRA_HTTP_REQUEST_ID_HEADER_NAME. Netramesh-ში კონტექსტის ზომის გასაკონტროლებლად, შეგიძლიათ დააყენოთ შემდეგი გარემოს ცვლადები: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (დრო, რომლისთვისაც კონტექსტი შეინახება) და NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (კონტექსტის გასუფთავების სიხშირე).

ასევე შესაძლებელია თქვენს სისტემაში მრავალი ბილიკის გაერთიანება სპეციალური სესიის ჟეტონით მონიშვნით. Netra გაძლევთ საშუალებას დააინსტალიროთ HTTP_HEADER_TAG_MAP გადააქციოს HTTP სათაურები შესაბამის ტრასირების ტეგებად. ეს განსაკუთრებით სასარგებლოა ტესტირებისთვის. ფუნქციური ტესტის გავლის შემდეგ, თქვენ ხედავთ სისტემის რომელ ნაწილს შეეხო შესაბამისი სესიის კლავიშის გაფილტვრამ.

მოთხოვნის წყაროს განსაზღვრა

იმის დასადგენად, თუ საიდან მოვიდა მოთხოვნა, შეგიძლიათ გამოიყენოთ წყაროსთან სათაურის ავტომატურად დამატების ფუნქცია. გარემოს ცვლადის გამოყენება NETRA_HTTP_X_SOURCE_HEADER_NAME თქვენ შეგიძლიათ მიუთითოთ სათაურის სახელი, რომელიც ავტომატურად დაინსტალირდება. Გამოყენებით NETRA_HTTP_X_SOURCE_VALUE თქვენ შეგიძლიათ დააყენოთ მნიშვნელობა, რომელზეც დაყენდება X-Source სათაური ყველა გამავალი მოთხოვნისთვის.

ეს საშუალებას აძლევს ამ სასარგებლო სათაურის განაწილებას ერთნაირად განაწილდეს ქსელში. შემდეგ შეგიძლიათ გამოიყენოთ ის სერვისებში და დაამატოთ ჟურნალებსა და მეტრიკაში.

მოძრაობის მარშრუტიზაცია და ნეტრამეშის შიდა ნაწილები

ნეტრამეში შედგება ორი ძირითადი კომპონენტისგან. პირველი, netra-init, ადგენს ქსელის წესებს ტრაფიკის ჩასარიცხად. Ის იყენებს iptables გადამისამართების წესები სატრანსპორტო საშუალების მთლიანი ან ნაწილის ჩაჭრა გვერდით კარზე, რომელიც არის ნეტრამეშის მეორე მთავარი კომპონენტი. თქვენ შეგიძლიათ დააკონფიგურიროთ რომელი პორტები უნდა იყოს ჩასმული შემომავალი და გამავალი TCP სესიებისთვის: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.

ხელსაწყოს აქვს ასევე საინტერესო ფუნქცია - სავარაუდო მარშრუტიზაცია. თუ თქვენ იყენებთ Netramesh-ს ექსკლუზიურად ტრასირების ზონების შესაგროვებლად, მაშინ საწარმოო გარემოში შეგიძლიათ დაზოგოთ რესურსები და ჩართოთ ალბათური მარშრუტი ცვლადების გამოყენებით. NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (0-დან 1-მდე). ნაგულისხმევი მნიშვნელობა არის 1 (ყველა ტრაფიკი შეჩერებულია).

წარმატებული ჩარევის შემდეგ, netra sidecar იღებს ახალ კავშირს და იყენებს SO_ORIGINAL_DST სოკეტის ვარიანტი ორიგინალური დანიშნულების მისაღებად. შემდეგ ნეტრა ხსნის ახალ კავშირს თავდაპირველ IP მისამართთან და ამყარებს ორმხრივ TCP კომუნიკაციას მხარეებს შორის, უსმენს მთელ ტრაფიკს. თუ პორტი განისაზღვრება როგორც HTTP, Netra ცდილობს მის გაანალიზებას და მიკვლევას. თუ HTTP ანალიზი ვერ მოხერხდა, ნეტრა ბრუნდება TCP-ზე და გამჭვირვალედ აწარმოებს პროქსის ბაიტებს.

დამოკიდებულების გრაფიკის აგება

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

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

როგორ გამოვიყენოთ Netramesh

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

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

ნეტრამეშის მომავალი

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

მომავალში, Netramesh მხარს დაუჭერს სხვა აპლიკაციის ფენის პროტოკოლებს HTTP-ის გარდა. L7 მარშრუტი ხელმისაწვდომი იქნება უახლოეს მომავალში.

გამოიყენეთ Netramesh, თუ მსგავსი პრობლემები შეგხვდებათ და მოგვწერეთ შეკითხვებით და წინადადებებით.

წყარო: www.habr.com