Dodo IS არქიტექტურის ისტორია: ადრეული მონოლითი

ან მონოლითის მქონე ყველა უბედური კომპანია თავისებურად უბედურია.

Dodo IS სისტემის განვითარება დაუყოვნებლივ დაიწყო, ისევე როგორც Dodo Pizza ბიზნესი, 2011 წელს. იგი ეფუძნებოდა ბიზნეს პროცესების სრული და ტოტალური დიგიტალიზაციის იდეას და საკუთარი, რამაც მაშინაც 2011 წელს გამოიწვია უამრავი კითხვა და სკეპტიციზმი. მაგრამ უკვე 9 წელია ამ გზას მივყვებით – ჩვენივე განვითარებით, რომელიც დაიწყო მონოლით.

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

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

1. ადრეული მონოლითი დოდო ისტ-ში (2011-2015). (აქ ხარ)

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

3. კლიენტის გვერდითი ბილიკი: ფასადი ბაზაზე (2016-2017). (Პროგრესირებს...)

4. ნამდვილი მიკროსერვისების ისტორია. (2018-2019 წწ.). (Პროგრესირებს…)

5. დასრულდა მონოლითის ხერხი და არქიტექტურის სტაბილიზაცია. (Პროგრესირებს...)

საწყისი არქიტექტურა

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

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

• კლიენტი რეკავს პიცერიაში;

• მენეჯერი იღებს ტელეფონს;

• იღებს შეკვეთას ტელეფონით;

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

საინფორმაციო სისტემის ინტერფეისი ასე გამოიყურებოდა ...

პირველი ვერსია 2011 წლის ოქტომბრიდან:

ოდნავ გაუმჯობესდა 2012 წლის იანვარში

დოდო პიცა საინფორმაციო სისტემა მიწოდების პიცა რესტორანი

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

მათმა პირველმა გადაწყვეტილებამ განსაზღვრა ტექნოლოგიის დასტას ბედი:

• Backend ASP.NET MVC, C# ენაზე. დეველოპერები იყვნენ dotnetchiki, ეს დასტა მათთვის ნაცნობი და სასიამოვნო იყო.

• Frontend Bootstrap-ზე და JQuery-ზე: მომხმარებლის ინტერფეისები თვითნაწერ სტილებზე და სკრიპტებზე. 

• MySQL მონაცემთა ბაზა: ლიცენზიის ხარჯების გარეშე, მარტივი გამოსაყენებელი.

• სერვერები Windows Server-ზე, რადგან .NET მაშინ შეიძლება იყოს მხოლოდ Windows-ის ქვეშ (ჩვენ არ განვიხილავთ მონო).

ფიზიკურად ეს ყველაფერი გამოიხატებოდა „მასპინძლის დედში“. 

შეკვეთის მიღების აპლიკაციის არქიტექტურა

მაშინ უკვე ყველა საუბრობდა მიკროსერვისებზე და SOA 5 წლის განმავლობაში გამოიყენებოდა დიდ პროექტებში, მაგალითად, WCF გამოვიდა 2006 წელს. მაგრამ შემდეგ მათ აირჩიეს საიმედო და დადასტურებული გამოსავალი.

Აქ არის.

Asp.Net MVC არის Razor, რომელიც, ფორმის ან კლიენტის მოთხოვნით, ახდენს HTML გვერდს სერვერის რენდერით. კლიენტზე CSS და JS სკრიპტები უკვე აჩვენებს ინფორმაციას და საჭიროების შემთხვევაში ასრულებს AJAX მოთხოვნებს JQuery-ის საშუალებით.

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

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

• Receiving OrdersService მიიღო და გამოითვალა შეკვეთის შემადგენლობა.

• და SmsService-მა გაგზავნა SMS SMS-ის გასაგზავნად API სერვისების დარეკვით.

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

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

ეს ყველაფერი შეიძლება წარმოდგენილი იყოს ასეთი მოდელით:

შეკვეთის გზა

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

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

• კლიენტი სტუმრობს სტატიკურ საიტს ფასებით, ირჩევს პროდუქტებს და რეკავს საიტზე მითითებულ ნომერზე.

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

• მისამართს და სახელს აძლევს.

• ოპერატორი იღებს შეკვეთას.

• შეკვეთა ნაჩვენებია მიღებული შეკვეთების ინტერფეისში.

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

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

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

შემდეგი, შეიყვანეთ კლიენტის მისამართი და სახელი. 

როდესაც დააჭირეთ "შეკვეთის შექმნას":

• მოთხოვნა იგზავნება OrderController.SaveOrder().

• სესიიდან ვიღებთ კალათას, არის პროდუქტები იმ რაოდენობით, რაც გვჭირდება.

• კალათას ვამატებთ კლიენტის შესახებ ინფორმაციას და გადავცემთ ReceivingOrderService კლასის AddOrder მეთოდს, სადაც ის ინახება მონაცემთა ბაზაში. 

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

• შეკვეთის ჩვენების ინტერფეისი მიდის და ამოიღებს უახლეს შეკვეთებს და აჩვენებს მათ.

ახალი მოდულები

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

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

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

ტექნიკურად, მოდულები შეიქმნა, როგორც ფართობი (ასეთი იდეაც კი დარჩა asp.net ბირთვი). იყო ცალკე ფაილები ფრონტენტისთვის, მოდელებისთვის, ასევე საკუთარი კონტროლერების კლასებისთვის. შედეგად, სისტემა გარდაიქმნა ამ ...

...ამაში:

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

• საიტის - პირველი ვერსია საიტი dodopizza.ru.

• ექსპორტი: ატვირთეთ ანგარიშები Dodo IS-დან 1C-სთვის. 

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

• fs — სტატიკის ჰოსტინგის პროექტი. მოგვიანებით ჩვენ დავშორდით მას, გადავიტანეთ ყველა სტატიკა Akamai CDN-ზე. 

დანარჩენი ბლოკები იყო BackOffice აპლიკაციაში. 

სახელის ახსნა:

• მოლარე - რესტორნის მოლარე.

• ShiftManager - ინტერფეისები "Shift Manager" როლისთვის: ოპერატიული სტატისტიკა პიცერიის გაყიდვებზე, პროდუქტების გაჩერების სიაში მოთავსების შესაძლებლობა, შეკვეთის შეცვლა.

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

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

ისინი იყენებდნენ საერთო სერვისის ფენას, საერთო Dodo.Core დომენის კლასის ბლოკს და საერთო ბაზას. ზოგჯერ მათ მაინც შეეძლოთ ერთმანეთზე გადასვლების წინსვლა. ინდივიდუალური საიტების ჩათვლით, როგორიცაა dodopizza.ru ან personal.dodopizza.ru, გადავიდა ზოგად სერვისებზე.

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

სისტემაში დამზადებული მოდულების მასშტაბის უკეთ გასაგებად, აქ არის 2012 წლის დიაგრამა განვითარების გეგმებით:

2015 წლისთვის ყველაფერი იყო რუკაზე და კიდევ უფრო მეტი იყო წარმოებაში.

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

• პიცერიებში ეკიდა საჯარო ეკრანები მენიუებითა და ინფორმაციით.

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

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

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

პრობლემები

მათ შორის არქიტექტურის გამო (მაგრამ არა მხოლოდ).

ქაოსი ბაზაში

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

მაგრამ განვითარების 4 წლის განმავლობაში, მონაცემთა ბაზას ჰქონდა დაახლოებით 600 ცხრილი, 1500 შენახული პროცედურა, რომელთაგან ბევრს ასევე ჰქონდა ლოგიკა. სამწუხაროდ, შენახულ პროცედურებს დიდი უპირატესობა არ მოაქვს MySQL-თან მუშაობისას. ისინი არ ინახება ბაზის მიერ და მათში ლოგიკის შენახვა ართულებს განვითარებას და გამართვას. კოდის ხელახალი გამოყენება ასევე რთულია.

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

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

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

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

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

კოჰეზია და დაბნელება კოდში

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

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

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

ლოგიკა იყო ან კონტროლერებში ან სერვისის კლასებში. 

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

დიდი განვითარების სირთულე

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

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

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

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

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

როგორ აყენებს Power of the Mind ბლოგმა სალარო აპარატები რესტორნებში

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

ბლოგში "გონების ძალა” იყო ვიჯეტი, რომელიც აჩვენებდა მონაცემებს მთელი ქსელის წლის შემოსავალზე. ვიჯეტი შედიოდა Dodo-ს საჯარო API-ზე, რომელიც უზრუნველყოფს ამ მონაცემებს. ეს სტატისტიკა ამჟამად ხელმისაწვდომია http://dodopizzastory.com/. ვიჯეტი ნაჩვენები იყო ყველა გვერდზე და ყოველ 20 წამში ერთხელ ითხოვდა ტაიმერს. მოთხოვნა წავიდა api.dodopizza.ru-ზე და მოითხოვა:

• პიცერიების რაოდენობა ქსელში;

• ქსელის მთლიანი შემოსავალი წლის დასაწყისიდან;

• შემოსავალი დღეისთვის.

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

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

დიაგრამა ასე გამოიყურებოდა:

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

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

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

ამიერიდან იწყება ჩვენი ბრძოლა დატვირთვებთან და სისტემის სტაბილიზაციისთვის (2015 წლის შემოდგომიდან 2018 წლის შემოდგომამდე). სწორედ მაშინ მოხდა ეს"დიდი შემოდგომა". გარდა ამისა, წარუმატებლობებიც ზოგჯერ ხდებოდა, ზოგი ძალიან მგრძნობიარე იყო, მაგრამ არასტაბილურობის ზოგადი პერიოდი ახლა შეიძლება ჩაითვალოს წარსულში.

ბიზნესის სწრაფი ზრდა

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

ასევე 2014-2015 წლებში იყო გახსნა რუმინეთში და მზადდებოდა გახსნა აშშ-ში.

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

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

სწრაფი გადაწყვეტილებები, რომლებიც დაეხმარა

პრობლემები საჭიროებდა გადაწყვეტას. პირობითად, გადაწყვეტილებები შეიძლება დაიყოს 2 ჯგუფად:

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

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

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

გაზარდეთ ბაზის ოსტატი

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

2014 წლიდან ჩვენ გადავედით Azure-ში, ჩვენ ასევე დავწერეთ ამ თემაზე იმ დროს სტატიაში ”როგორ აწვდის Dodo Pizza პიცას Microsoft Azure Cloud-ის გამოყენებით". მაგრამ ბაზის სერვერის გაზრდის სერიის შემდეგ, ისინი შეეწინააღმდეგნენ ღირებულებას. 

ბაზის ასლები წასაკითხად

ბაზისთვის გაკეთდა ორი ასლი:

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

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

ქეშები კოდში

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

მრავალი backend სერვერი

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

შედეგად, არქიტექტურა უფრო გართულდა ...

... მაგრამ გარკვეული დაძაბულობა მოიხსნა.

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

წყარო: www.habr.com