NDC ლონდონის კონფერენცია. მიკროსერვისის კატასტროფის პრევენცია. Ნაწილი 1

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

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

გამარჯობა ყველას, მე ჯიმი ვარ და დღეს თქვენ გესმით, როგორ შეგიძლიათ თავიდან აიცილოთ მეგა კატასტროფები მიკროსერვისების აშენებისას. ეს არის ამბავი იმ კომპანიის შესახებ, რომელშიც ვმუშაობდი დაახლოებით წელიწადნახევრის განმავლობაში, რათა დამეხმარა მათი გემის აისბერგთან შეჯახების თავიდან ასაცილებლად. ამ ამბის სწორად გადმოსაცემად, დროში უნდა დავბრუნდეთ და ვისაუბროთ იმაზე, თუ სად დაიწყო ეს კომპანია და როგორ გაიზარდა მისი IT ინფრასტრუქტურა დროთა განმავლობაში. ამ კატასტროფის დროს უდანაშაულო ადამიანების სახელების დასაცავად, მე შევცვალე ამ კომპანიის სახელი Bell Computers. შემდეგი სლაიდი გვიჩვენებს, როგორ გამოიყურებოდა ასეთი კომპანიების IT ინფრასტრუქტურა 90-იანი წლების შუა პერიოდში. ეს არის ტიპიური არქიტექტურა დიდი უნივერსალური ხარვეზებისადმი ტოლერანტული HP Tandem Mainframe სერვერისთვის კომპიუტერული ტექნიკის მაღაზიის მუშაობისთვის.

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

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

თავდაპირველი დიზაინი საკმაოდ ლამაზად გამოიყურებოდა და შედგებოდა უმაღლესი დონის საიტისგან bell.com და რამდენიმე ქვედომენისგან ინდივიდუალური აპლიკაციებისთვის: catalog.bell.com, accounts.bell.com, orders.bell.com, პროდუქტის ძებნა search.bell. com. თითოეული ქვედომენი იყენებდა ASP.Net 1.0 ჩარჩოს და საკუთარ მონაცემთა ბაზებს და ისინი ყველა ესაუბრებოდნენ სისტემის უკანა სისტემას. თუმცა, ყველა შეკვეთის დამუშავება და შესრულება გაგრძელდა ერთი უზარმაზარი მეინფრეიმის ფარგლებში, რომელშიც მთელი ნაგავი რჩებოდა, მაგრამ წინა ნაწილი იყო ცალკე ვებსაიტები ინდივიდუალური აპლიკაციებით და ცალკეული მონაცემთა ბაზებით.

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

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

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

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

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

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

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

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

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

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

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

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

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

მათემატიკა გავაკეთეთ. თითოეულ API ზარს ჰქონდა SLA არაუმეტეს 150 ms და 99,9% მუშაობის დრო. ერთმა მოთხოვნამ გამოიწვია 200 სხვადასხვა ზარი და საუკეთესო შემთხვევაში, გვერდის ჩვენება შესაძლებელი იყო 200 x 150 ms = 30 წამში. ბუნებრივია, ეს არ იყო კარგი. 99,9% მუშაობის დრო 200-ზე გამრავლებით, მივიღეთ 0% ხელმისაწვდომობა. თურმე ეს არქიტექტურა თავიდანვე წარუმატებლად იყო განწირული.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bounded Context-ის განმარტება აღებულია ერიკ ევანსის წიგნიდან Domain-Driven Design. ეს არის ძირითადი ნიმუში DDD-ში, არქიტექტურის დიზაინის ცენტრში, რომელიც მუშაობს მოცულობითი არქიტექტურული მოდელებით, ყოფს მათ სხვადასხვა შეზღუდულ კონტექსტებად და მკაფიოდ განსაზღვრავს მათ შორის ურთიერთქმედებას.

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

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

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

ასე რომ, ჩვენ ვუთხარით ბიჭებს Bell Computers-ში: „ჩვენ ვერ გამოვასწორებთ თქვენ მიერ შექმნილ ქაოსს, რადგან თქვენ უბრალოდ არ გაქვთ ამის გასაკეთებლად ფული, მაგრამ ჩვენ გამოვასწორებთ მხოლოდ ერთ სერვისს, რათა ეს ყველაფერი გამოვიდეს. გრძნობა.” ამ ეტაპზე დავიწყებ იმით, თუ როგორ დავაფიქსირეთ ჩვენი ერთადერთი სერვისი ისე, რომ მან უპასუხა თხოვნებს 9 და ნახევარ წუთზე უფრო სწრაფად.

22:30 წთ

გაგრძელება ძალიან მალე...

ცოტა რეკლამა

გმადლობთ, რომ დარჩით ჩვენთან. მოგწონთ ჩვენი სტატიები? გსურთ ნახოთ უფრო საინტერესო შინაარსი? მხარი დაგვიჭირეთ შეკვეთის განთავსებით ან მეგობრებისთვის რეკომენდაციით, ღრუბელი VPS დეველოპერებისთვის 4.99 დოლარიდან, საწყისი დონის სერვერების უნიკალური ანალოგი, რომელიც ჩვენ მიერ გამოგონილია თქვენთვის: მთელი სიმართლე VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps 19$-დან ან როგორ გავაზიარო სერვერი? (ხელმისაწვდომია RAID1 და RAID10-ით, 24 ბირთვამდე და 40 გბ-მდე DDR4).

Dell R730xd 2-ჯერ იაფია Equinix Tier IV მონაცემთა ცენტრში ამსტერდამში? Მხოლოდ აქ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ტელევიზორი $199-დან ნიდერლანდებში! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-დან! Წაიკითხო რაღაცის შესახებ როგორ ავაშენოთ ინფრასტრუქტურის კორპუსი. კლასი Dell R730xd E5-2650 v4 სერვერების გამოყენებით 9000 ევროს ღირებულების პენი?

წყარო: www.habr.com