Dodo IS არქიტექტურის ისტორია: Back Office Path

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

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

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

სტატიების სერია "რა არის Dodo IS?" მოგვითხრობს:

1. ადრეული მონოლითი დოდო ისტ-ში (2011-2015). (Პროგრესირებს…)
2. უკანა ოფისის გზა: ცალკე ბაზები და ავტობუსი. (აქ ხარ)
3. კლიენტის გვერდითი ბილიკი: ფასადი ბაზაზე (2016-2017). (Პროგრესირებს...)
4. ნამდვილი მიკროსერვისების ისტორია. (2018-2019 წწ.). (Პროგრესირებს…)
5. დასრულდა მონოლითის ხერხი და არქიტექტურის სტაბილიზაცია. (Პროგრესირებს...)

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

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

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

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

2011 წელს დოდო IS არქიტექტურა ასე გამოიყურებოდა:

2020 წლისთვის ის ცოტათი გართულდა და ასე გახდა:

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

2016 წლის პირველი პრობლემები: რატომ უნდა დატოვონ სერვისებმა მონოლითი?

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

ერთი MySql მონაცემთა ბაზა, რომელშიც ყველა აპლიკაცია, რომელიც იმ დროს არსებობდა Dodo IS-ში, წერდა ჩანაწერებს. შედეგები იყო:

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

პრობლემა თავად მონოლითის არსებობა იყო. შედეგები იყო:

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

ბაზისა და მონოლითის პრობლემები არაერთხელ იყო აღწერილი, მაგალითად, 2018 წლის დასაწყისში ავარიების კონტექსტში (იყავით როგორც მუნკი, ან რამდენიმე სიტყვა ტექნიკური დავალიანების შესახებ, იმ დღეს, როდესაც დოდო IS შეჩერდა. ასინქრონული სკრიპტი и დოდო ფრინველის ისტორია ფენიქსის ოჯახიდან. დოდოს დიდი დაცემა არის), ასე რომ, ზედმეტად არ გავჩერდები. ნება მომეცით უბრალოდ ვთქვა, რომ ჩვენ გვინდოდა მეტი მოქნილობა მიგვეღო სერვისების შემუშავებისას. უპირველეს ყოვლისა, ეს ეხებოდა მათ, ვინც იყო ყველაზე დატვირთული და root მთელ სისტემაში - Auth და Tracker.

უკანა ოფისის გზა: ცალკეული ბაზები და ავტობუსი

თავის ნავიგაცია

1. 2016 წლის მონოლითის სქემა
2. მონოლითის განტვირთვის დაწყება: ავტორიზაციის და ტრეკერის განცალკევება
   
3. რას აკეთებს Auth?
4. საიდან მოდის დატვირთვები?
5. გადმოტვირთვა ავტორიზაცია
6. რას აკეთებს ტრეკერი?
7. საიდან მოდის დატვირთვები?
8. ტრეკერის გადმოტვირთვა

2016 წლის მონოლითის სქემა

აქ მოცემულია 2016 წლის Dodo IS მონოლითის ძირითადი ბლოკები და ქვემოთ მოცემულია მათი ძირითადი ამოცანების ახსნა.

სალაროს მიწოდება. კურიერების აღრიცხვა, კურიერებზე შეკვეთების გაცემა.
Საკონტაქტო ცენტრი. შეკვეთების მიღება ოპერატორის მეშვეობით.
საიტის. ჩვენი ვებსაიტები (dodopizza.ru, dodopizza.co.uk, dodopizza.by და ა.შ.).
ავტორიზაცია. ავტორიზაციის და ავთენტიფიკაციის სერვისი backoffice-ისთვის.
ტრეკერი. სამზარეულოს შეკვეთის ტრეკერი. შეკვეთის მომზადებისას მზადყოფნის სტატუსის აღნიშვნის სერვისი.
რესტორნის სალარო. შეკვეთების მიღება რესტორანში, სალაროს ინტერფეისი.
ექსპორტი. ანგარიშების ატვირთვა 1C-ში ბუღალტრული აღრიცხვისთვის.
შეტყობინებები და ინვოისები. ხმოვანი ბრძანებები სამზარეულოში (მაგალითად, „ახალი პიცა ჩამოვიდა“) + ინვოისის ბეჭდვა კურიერებისთვის.
ცვლის მენეჯერი. ინტერფეისები ცვლის მენეჯერის მუშაობისთვის: შეკვეთების სია, პროდუქტიულობის სქემები, თანამშრომლების ცვლაში მიყვანა.
Ოფისის მენეჯერი. ინტერფეისები ფრენჩაიზებისა და მენეჯერების მუშაობისთვის: თანამშრომლების მიღება, ანგარიშები პიცერიის მუშაობის შესახებ.
რესტორნის შედეგები. პიცერიებში ტელევიზორებზე მენიუს ჩვენება.
ადმინ. პარამეტრები კონკრეტულ პიცერიაში: მენიუ, ფასები, ბუღალტერია, პრომო კოდები, აქციები, ვებსაიტების ბანერები და ა.შ.
თანამშრომლის პირადი ანგარიში. თანამშრომლების სამუშაო განრიგი, ინფორმაცია თანამშრომლების შესახებ.
სამზარეულოს მოტივაციის დაფა. ცალკე ეკრანი, რომელიც კიდია სამზარეულოში და აჩვენებს პიცის შემქმნელების სიჩქარეს.
ურთიერთობა. sms და ელ.ფოსტის გაგზავნა.
ფაილების შენახვა. სტატიკური ფაილების მიღებისა და გაცემის საკუთარი სერვისი.

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

მონოლითის განტვირთვის დაწყება: ავტორიზაციის და ტრეკერის განცალკევება

ძირითადი სერვისები, რომლებიც შემდეგ ჩაწერეს და წაიკითხეს მონაცემთა ბაზიდან, ვიდრე სხვები:

1. ავტორიზაცია ავტორიზაციის და ავთენტიფიკაციის სერვისი backoffice-ისთვის.
2. ტრეკერი. სამზარეულოს შეკვეთის ტრეკერი. შეკვეთის მომზადებისას მზადყოფნის სტატუსის აღნიშვნის სერვისი.

რას აკეთებს Auth?

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

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

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

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

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

გადმოტვირთვა ავტორიზაცია

Auth-ს აქვს იზოლირებული დომენი, ანუ მონაცემები მომხმარებლების, შესვლის ან მოწყობილობების შესახებ შედის სერვისში (ამ დროისთვის) და რჩება იქ. თუ ვინმეს სჭირდება ისინი, მაშინ ის წავა ამ სერვისში მონაცემებისთვის.

იყო. მუშაობის ორიგინალური სქემა იყო შემდეგი:

მინდა ავხსნა ცოტა როგორ მუშაობდა:

1. მოთხოვნა გარედან მოდის backend-ში (არსებობს Asp.Net MVC), თან მოაქვს სესიის ქუქი, რომელიც გამოიყენება Redis(1-დან სესიის მონაცემების მისაღებად). ის ან შეიცავს ინფორმაციას წვდომის შესახებ და შემდეგ კონტროლერზე წვდომა ღიაა (3,4) ან არა.
2. თუ არ არის წვდომა, თქვენ უნდა გაიაროთ ავტორიზაციის პროცედურა. აქ, სიმარტივისთვის, ის ნაჩვენებია, როგორც იმავე ატრიბუტის ბილიკის ნაწილი, თუმცა ეს არის შესვლის გვერდზე გადასვლა. დადებითი სცენარის შემთხვევაში, ჩვენ მივიღებთ სწორად დასრულებულ სესიას და გადავალთ Backoffice Controller-ში.
3. თუ არსებობს მონაცემები, მაშინ თქვენ უნდა შეამოწმოთ ისინი შესაბამისობისთვის მომხმარებლის ბაზაში. შეიცვალა მისი როლი, არ უნდა დაუშვან ახლა გვერდზე? ამ შემთხვევაში, სესიის (1) მიღების შემდეგ, თქვენ უნდა გადახვიდეთ პირდაპირ მონაცემთა ბაზაში და შეამოწმოთ მომხმარებლის წვდომა ავტორიზაციის ლოგიკური ფენის (2) გამოყენებით. შემდეგი, ან შესვლის გვერდზე, ან გადადით კონტროლერზე. ასეთი მარტივი სისტემა, მაგრამ არც ისე სტანდარტული.
4. თუ ყველა პროცედურა დასრულებულია, მაშინ ჩვენ გამოვტოვებთ ლოგიკას კონტროლერებსა და მეთოდებში.

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

გახდი. ასე რომ, მათ გააკეთეს:

ამ მიდგომას აქვს მთელი რიგი პრობლემები. მაგალითად, პროცესის შიგნით მეთოდის გამოძახება არ არის იგივე, რაც გარე სერვისის გამოძახება http-ით. ოპერაციის ლატენტურობა, საიმედოობა, მხარდაჭერის უნარი და გამჭვირვალობა სრულიად განსხვავებულია. ზუსტად ამ პრობლემებზე უფრო დეტალურად ისაუბრა ანდრეი მორევსკიმ თავის მოხსენებაში "50 Shades of Microservice".

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

რატომ გაგრძელდა ამდენი დრო დაშორება?
გზაზე ბევრი პრობლემა იყო, რამაც დაგვანელა:

1. ჩვენ გვინდოდა მომხმარებლის, მოწყობილობისა და ავთენტიფიკაციის მონაცემების გადატანა კონკრეტული ქვეყნის მონაცემთა ბაზებიდან ერთში. ამისათვის ჩვენ უნდა გადაგვეთარგმნა ყველა ცხრილი და გამოყენება int იდენტიფიკატორიდან გლობალურ UUId იდენტიფიკატორზე (ეს კოდი ახლახან გადამუშავდა რომან ბუკინი "უიდი - პატარა სტრუქტურის დიდი ამბავი" და ღია კოდის პროექტი პრიმიტივები). მომხმარებლის მონაცემების შენახვას (რადგან ეს არის პერსონალური ინფორმაცია) აქვს თავისი შეზღუდვები და ზოგიერთი ქვეყნისთვის აუცილებელია მათი ცალკე შენახვა. მაგრამ მომხმარებლის გლობალური ID უნდა იყოს.
2. მონაცემთა ბაზაში ბევრ ცხრილს აქვს აუდიტორული ინფორმაცია მომხმარებლის შესახებ, რომელმაც შეასრულა ოპერაცია. ამას თანმიმდევრულობისთვის დამატებითი მექანიზმი მოითხოვდა.
3. api-სერვისების შექმნის შემდეგ იყო სხვა სისტემაზე გადასვლის ხანგრძლივი და თანდათანობითი პერიოდი. გადართვა უნდა ყოფილიყო უპრობლემოდ მომხმარებლებისთვის და საჭიროებდა ხელით მუშაობას.

პიცერიაში მოწყობილობის რეგისტრაციის სქემა:

ზოგადი არქიტექტურა Auth და Devices სერვისის ამოღების შემდეგ:

შენიშვნა. 2020 წლისთვის ჩვენ ვმუშაობთ Auth-ის ახალ ვერსიაზე, რომელიც დაფუძნებულია OAuth 2.0 ავტორიზაციის სტანდარტზე. ეს სტანდარტი საკმაოდ რთულია, მაგრამ სასარგებლოა გავლის ავტორიზაციის სერვისის შემუშავებისთვის. სტატიაში "ავტორიზაციის დახვეწილობა: OAuth 2.0 ტექნოლოგიის მიმოხილვა» ჩვენ ალექსეი ჩერნიაევი შევეცადეთ გვესაუბრა სტანდარტზე რაც შეიძლება მარტივად და ნათლად, რათა დაზოგოთ დრო მის შესწავლაზე.

რას აკეთებს ტრეკერი?

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

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

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

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

ასე გამოიყურება პლანშეტის ეკრანი ტრეკერის "რასკატკას" სადგურზე

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

თითოეულ პიცერიას აქვს დაახლოებით ხუთი ტაბლეტი ტრეკერით. 2016 წელს გვქონდა 100-ზე მეტი პიცერია (ახლა კი 600-ზე მეტია). თითოეული ტაბლეტი ყოველ 10 წამში ერთხელ უგზავნის მოთხოვნას ბექენდს და აგროვებს მონაცემებს შეკვეთის ცხრილიდან (ბმული კლიენტთან და მისამართთან), შეკვეთის შემადგენლობიდან (ბმული პროდუქტთან და რაოდენობის მითითებით) და მოტივაციის ცხრილიდან (იგი თვალს ადევნებს დაჭერის დრო). როდესაც პიცის მწარმოებელი დააჭერს პროდუქტს ტრეკერზე, ყველა ამ ცხრილის ჩანაწერები განახლდება. შეკვეთების ცხრილი ზოგადია; ის ერთდროულად შეიცავს შეკვეთების მიღებისას, განახლებებს სისტემის სხვა ნაწილებიდან და უამრავ კითხვას, მაგალითად, ტელევიზორზე, რომელიც კიდია პიცერიაში და აჩვენებს მზა შეკვეთებს მომხმარებლებს.

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

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

იყო. ორიგინალური არქიტექტურა იყო:

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

ტრეკერის გადმოტვირთვა

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

ჩვენ ვღებულობთ შეკვეთებს რესტორნის გამოტანაში (ეს არის სერვისი), ის ინახება მონაცემთა ბაზაში "მიღებული" სტატუსში. ამის შემდეგ ის უნდა გადავიდეს ტრეკერზე, სადაც კიდევ რამდენჯერმე შეიცვლის სტატუსს: „სამზარეულოდან“ „შეფუთულში“. ამ შემთხვევაში, სალაროს ან Shift Manager ინტერფეისის გარკვეული გარე გავლენა შეიძლება მოხდეს შეკვეთასთან ერთად. მე მივცემ შეკვეთების სტატუსებს მათი აღწერით ცხრილში:

შეკვეთის სტატუსის შეცვლის სქემა ასე გამოიყურება:

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

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

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

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

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

1. შეკვეთა სრულად მზადაა Checkout-ზე და დროა გაგზავნოთ იგი ტრეკერზე. ღონისძიება, რომელზეც ტრეკერი არის გამოწერილი, ისროლება.
2. ტრეკერი, რომელიც იღებს შეკვეთას თავისთვის, ინახავს მას საკუთარ მონაცემთა ბაზაში, აკეთებს მოვლენას „შეკვეთა მიღებულია ტრეკერის მიერ“ და აგზავნის მას RMQ-ში.
3. რამდენიმე დამმუშავებელი უკვე გამოწერილია მორგებული ღონისძიების ავტობუსზე. ჩვენთვის მნიშვნელოვანია ის, რომელიც სინქრონიზებულია მონოლითურ მონაცემთა ბაზასთან.
4. დამმუშავებელი იღებს მოვლენას, მისგან ირჩევს მისთვის მნიშვნელოვან მონაცემებს: ჩვენს შემთხვევაში, ეს არის შეკვეთის სტატუსი „მიღებულია ტრეკერის მიერ“ და განაახლებს შეკვეთის ერთეულს მთავარ მონაცემთა ბაზაში.

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

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

თუ გარკვეული პერიოდის შემდეგ შეკვეთა მიიღება წარმოებაში, მისი სტატუსი ჯერ იცვლება მის მონაცემთა ბაზაში (Tracker database), შემდეგ კი დაუყოვნებლივ წარმოიქმნება ღონისძიება "OrderInWork". ის ასევე შედის RMQ-ში, საიდანაც სინქრონიზებულია მონოლითურ მონაცემთა ბაზაში და მიეწოდება სხვა სერვისებს. ამ გზაზე შეიძლება იყოს სხვადასხვა პრობლემა; მათ შესახებ მეტი დეტალები შეგიძლიათ იხილოთ ჟენია ფეშკოვის მოხსენებაში ტრეკერში Eventual Consistency-ის განხორციელების დეტალების შესახებ.

საბოლოო არქიტექტურა Auth-სა და Tracker-ში ცვლილებების შემდეგ

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

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

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

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

Dodo IS-ის რომელი ნაწილის შესახებ გსურთ იცოდეთ შემდეგ სტატიაში?

• 24,1%ადრეული მონოლითი დოდო ისტ-ში (2011-2015)14

• 24,1%პირველი პრობლემები და მათი გადაწყვეტილებები (2015-2016)14

• 20,7%დამკვეთის ნაწილის ბილიკი: ფასადი ბაზის ზემოთ (2016-2017)12

• 36,2%ნამდვილი მიკროსერვისების ისტორია (2018-2019)21

• 44,8%მონოლითის სრული ხერხი და არქიტექტურის სტაბილიზაცია26

• 29,3%სისტემის განვითარების შემდგომი გეგმების შესახებ17

• 19,0%არ მინდა არაფერი ვიცოდე დოდო IS11-ის შესახებ

მისცა ხმა 58 მომხმარებელმა. 6-მა მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com