"ჩემი ფეხსაცმლით გასეირნება" - მოიცადეთ, ისინი მონიშნულია?

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

X5-ში სისტემას, რომელიც თვალყურს ადევნებს ეტიკეტირებულ საქონელს და გაცვლის მონაცემებს სახელმწიფოსთან და მომწოდებლებთან, ეწოდება "Marcus". მოდი თანმიმდევრობით გითხრათ, როგორ და ვინ შეიმუშავა იგი, როგორია მისი ტექნოლოგიური წყობა და რატომ გვაქვს საამაყო.

რეალური მაღალი დატვირთვა

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

გუნდი M

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

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

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

გუნდის დისტანციური შეხვედრა

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

ხსნარის ტექნოლოგიური დასტა

სტანდარტული საცავი და CI/CD ინსტრუმენტი X5-ისთვის არის GitLab. ჩვენ ვიყენებთ მას კოდების შესანახად, უწყვეტი ტესტირებისთვის და სერვერების შესამოწმებლად და წარმოებისთვის. ჩვენ ასევე ვიყენებთ კოდის განხილვის პრაქტიკას, როდესაც მინიმუმ 2 კოლეგას უნდა დაამტკიცოს დეველოპერის მიერ კოდში შეტანილი ცვლილებები. სტატიკური კოდის ანალიზატორები SonarQube და JaCoCo გვეხმარებიან შევინარჩუნოთ ჩვენი კოდი სუფთა და უზრუნველვყოთ ერთეულის ტესტის დაფარვის საჭირო დონე. ყველა ცვლილება კოდში უნდა გაიაროს ეს შემოწმება. ყველა სატესტო სკრიპტი, რომელიც გაშვებულია ხელით, შემდგომში ავტომატიზირებულია.

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

ამოცანა 1. სისტემის ჰორიზონტალური მასშტაბურობის საჭიროება

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

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

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

ყველა მიკროსერვისი განლაგებულია OpenShift კლასტერში, რომელიც წყვეტს როგორც თითოეული მიკროსერვისის მასშტაბირების პრობლემას, ასევე საშუალებას გვაძლევს არ გამოვიყენოთ მესამე მხარის Service Discovery ინსტრუმენტები.

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

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

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

ამოცანა 3. დიდი რაოდენობით მონაცემთა შენახვის საჭიროება: მხოლოდ თამბაქოსთვის წელიწადში 1 მილიარდზე მეტი ეტიკეტი მოდის X5-ზე. ისინი საჭიროებენ მუდმივ და სწრაფ წვდომას. მთლიანობაში, სისტემამ უნდა დაამუშაოს ამ ეტიკეტირებული საქონლის გადაადგილების ისტორიის დაახლოებით 10 მილიარდი ჩანაწერი.

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

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

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

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

ასეთი სქემის განსახორციელებლად დაგვჭირდა შემდეგი: ამ გადაწყვეტის ინტეგრირება Spring-თან და თავიდან ავიცილოთ კოდის დუბლირება. ინტერნეტში სერფინგისას ჩვენ წავაწყდით Spring BeanPostProccessor-ზე დაფუძნებულ მსგავს გადაწყვეტას, მაგრამ ის ჩვენთვის ზედმეტად რთული ჩანდა. ჩვენმა გუნდმა შექმნა უფრო მარტივი გადაწყვეტა, რომელიც საშუალებას გვაძლევს გავერთიანდეთ გაზაფხულის ციკლში მომხმარებლების შესაქმნელად და დამატებით დავამატოთ ხელახალი მომხმარებლები. გაზაფხულის გუნდს შევთავაზეთ ჩვენი გადაწყვეტის პროტოტიპი, შეგიძლიათ ნახოთ აქ. ხელახლა ცდის მომხმარებლების რაოდენობა და თითოეული მომხმარებლისთვის მცდელობების რაოდენობა კონფიგურირებულია პარამეტრების მიხედვით, ბიზნეს პროცესის საჭიროებიდან გამომდინარე, და იმისთვის, რომ ყველაფერი იმუშაოს, რჩება მხოლოდ ანოტაციის დამატება org.springframework.kafka.annotation.KafkaListener. , რომელიც ცნობილია გაზაფხულის ყველა დეველოპერისთვის.

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

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

პლატფორმის ოპერაცია

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

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

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

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

წყარო: www.habr.com