Refund Tool სერვისის შემუშავების გამოცდილება ასინქრონული API-ით Kafka-ზე

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

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

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

პროცესის შესახებ

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

თანხის დაბრუნების ინსტრუმენტი მოვლენებზე ორიენტირებული API-ით

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

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

მაგრამ დაბრუნება უფრო გართულდა კანონმდებლობის ცვლილებების გამო და ამისთვის ცალკე მიკროსერვისის დანერგვა მოგვიწია.

ჩვენი მოტივაცია:

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

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

BOB-ს ასევე აქვს საკმაოდ ბევრი გაცვლა: გადახდის სისტემები, მიწოდების სისტემები, შეტყობინებების სისტემები და ა.შ.

ტექნიკურად BOB არის:

• კოდის ~ 150 ათასი ხაზი + ტესტების ~ 100 ათასი ხაზი;
• php7.2 + Zend 1 & Symfony Components 3;
• >100 API და ~50 გამავალი ინტეგრაცია;
• 4 ქვეყანა თავისი ბიზნეს ლოგიკით.

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

დაბრუნების პროცესი

თავდაპირველად, პროცესში ჩართულია ორი სისტემა: BOB და Payment. ახლა კიდევ ორი ​​გამოჩნდება:

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

ახლა პროცესი ასე გამოიყურება:

1. BOB იღებს მოთხოვნას თანხის დაბრუნების შესახებ.
2. BOB საუბრობს ამ თანხის დაბრუნების ხელსაწყოზე.
3. თანხის დაბრუნების ინსტრუმენტი ეუბნება გადახდას: „დააბრუნე ფული“.
4. გადახდა აბრუნებს ფულს.
5. Refund Tool და BOB სინქრონიზებს სტატუსებს ერთმანეთთან, რადგან ახლა ორივეს ეს სჭირდება. ჩვენ ჯერ არ ვართ მზად სრულად გადავიდეთ თანხის დაბრუნების ინსტრუმენტზე, რადგან BOB-ს აქვს UI, ანგარიშები აღრიცხვისთვის და ზოგადად ბევრი მონაცემი, რომლის გადაცემაც ასე მარტივად შეუძლებელია. ორ სკამზე უნდა იჯდე.
6. ფისკალიზაციის მოთხოვნა მიდის.

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

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

რა არის მოვლენებზე ორიენტირებული API

ამ კითხვაზე კარგი პასუხია მარტინ ფაულერის მოხსენებაში (GOTO 2017) "მოვლენებზე ორიენტირებული არქიტექტურის მრავალი მნიშვნელობა".

მოკლედ რა გავაკეთეთ:

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

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

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

Async გაცვლა როგორც არის

ასინქრონული გაცვლისთვის, PHP დეპარტამენტი ჩვეულებრივ იყენებს RabbitMQ. ჩვენ შევკრიბეთ მოთხოვნის მონაცემები, დავდგით რიგში და ამავე სერვისის მომხმარებელმა წაიკითხა და გაგზავნა (ან არ გაუგზავნა). თავად API-სთვის Lamoda აქტიურად იყენებს Swagger-ს. ჩვენ ვქმნით API-ს, აღვწერთ მას Swagger-ში და ვქმნით კლიენტისა და სერვერის კოდს. ჩვენ ასევე ვიყენებთ ოდნავ გაძლიერებულ JSON RPC 2.0-ს.

ზოგან გამოიყენება ESB ავტობუსები, ზოგი ცხოვრობს activeMQ-ზე, მაგრამ, ზოგადად, RabbitMQ - სტანდარტი.

Async გაცვლა TO BE

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

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

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

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

ივენთები-ავტობუსი

ან ღონისძიების ავტობუსი. ეს არის უბრალოდ უსახელო http კარიბჭე, რომელიც რამდენიმე მნიშვნელოვან როლს ასრულებს:

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

რატომ

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

1:n+1 გაცვლა (ერთიდან ბევრამდე)

კაფკა ძალიან აადვილებს ახალი მომხმარებლების API-სთან დაკავშირებას.

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

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

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

მონაცემთა საფუძველზე

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

რეპლიკაციის ჟურნალი

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

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

შემდეგი, დოკუმენტაციის მცირე მოთხრობა მათთვის, ვინც კაფკას არ იცნობს (სურათი ასევე დოკუმენტაციაა)

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

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

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

ღონისძიების მოთხოვნები:

• მონაცემთა სისრულე. ვისურვებდი, რომ ღონისძიებას ჰქონდეს საკმარისი მონაცემები, რათა მოხდეს მისი დამუშავება.

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

კაფკა ლამოდაში

ჩვენ გვაქვს კაფკას სამი ინსტალაცია:

1. ჟურნალები;
2. R&D;
3. ივენთები-ავტობუსი.

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

ზემოთ არის rps გრაფიკი. თანხის დაბრუნების პროცესი მონიშნულია ფირუზისფერი ხაზით (დიახ, X ღერძზე), ხოლო ვარდისფერი ხაზი არის შინაარსის განახლების პროცესი.

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

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

Lamoda Events გამოყენების შემთხვევები

ჩვენ ვიყენებთ აშენებულ არქიტექტურას შემდეგი ოპერაციებისთვის:

• დაბრუნების სტატუსის თვალყურის დევნება: ქმედებისკენ მოწოდება და სტატუსის თვალყურის დევნება ყველა ჩართული სისტემიდან. გადახდა, სტატუსები, ფისკალიზაცია, შეტყობინებები. აქ ჩვენ გამოვცადეთ მიდგომა, შევქმენით ინსტრუმენტები, შევაგროვეთ ყველა ხარვეზი, დავწერეთ დოკუმენტაცია და ვუთხარით ჩვენს კოლეგებს როგორ გამოეყენებინათ იგი.
• პროდუქტის ბარათების განახლება: კონფიგურაცია, მეტა-მონაცემები, მახასიათებლები. ერთი სისტემა კითხულობს (რომელიც აჩვენებს) და რამდენიმე წერს.
• ფოსტა, პუშ და sms: შეკვეთა შეგროვდა, შეკვეთა მოვიდა, დაბრუნება მიღებულია და ა.შ., ბევრია.
• მარაგი, საწყობის განახლება — ნივთების რაოდენობრივი განახლება, მხოლოდ ნომრები: ჩამოსვლა საწყობში, დაბრუნება. აუცილებელია, რომ საქონლის დაჯავშნასთან დაკავშირებული ყველა სისტემა მუშაობდეს უახლესი მონაცემებით. ამჟამად, აქციების განახლების სისტემა საკმაოდ რთულია, კაფკა გაამარტივებს მას.
• მონაცემთა ანალიზი (R&D დეპარტამენტი), ML ინსტრუმენტები, ანალიტიკა, სტატისტიკა. ჩვენ გვინდა, რომ ინფორმაცია იყოს გამჭვირვალე - კაფკას ეს კარგად შეეფერება.

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

დიზაინის პრობლემები

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

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

მონაცემთა ნაკადი

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

ერთ თემაში თუ სხვადასხვაში?

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

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

ახალი სფერო თუ ახალი მოვლენა?

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

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

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

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

ღონისძიების ვერსია

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

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

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

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

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

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

მოვლენები ბრძანებების წინააღმდეგ

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

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

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

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

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

ნიუანსი

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

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

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

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

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

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

მონიტორინგი

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

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

გარდა ამისა, თქვენ უნდა აკონტროლოთ, როგორ მუშაობს მწარმოებელი, მიიღო თუ არა მოვლენები-ავტობუსმა შეტყობინებები და როგორ აკეთებს მომხმარებელი. მაგალითად, ქვემოთ მოცემულ დიაგრამებში Refund Tool კარგად მუშაობს, მაგრამ BOB-ს აშკარად აქვს გარკვეული პრობლემები (ლურჯი მწვერვალები).

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

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

ასე გამოიყურება API პასუხი. აქ არის ჯგუფი bob-live-fifa, partition refund.update.v1, სტატუსი OK, lag 0 - ბოლო საბოლოო ოფსეტი ასეთი და ასეთი.

მონიტორინგი updated_at SLA (ჩარჩა) უკვე აღვნიშნე. მაგალითად, პროდუქტი შეიცვალა სტატუსით, რომ ის მზად არის დასაბრუნებლად. ჩვენ ვაინსტალირებთ Cron-ს, რომელიც ამბობს, რომ თუ 5 წუთში ეს ობიექტი არ წავიდა თანხის დასაბრუნებლად (ჩვენ ძალიან სწრაფად ვაბრუნებთ ფულს გადახდის სისტემებით), მაშინ რაღაც შეცდომა ნამდვილად მოხდა და ეს ნამდვილად მხარდაჭერის შემთხვევაა. ამიტომ, ჩვენ უბრალოდ ვიღებთ კრონს, რომელიც კითხულობს ასეთ რაღაცეებს ​​და თუ ისინი 0-ზე მეტია, მაშინ ის აგზავნის გაფრთხილებას.

შეჯამებისთვის, მოვლენების გამოყენება მოსახერხებელია, როდესაც:

• ინფორმაცია საჭიროებს რამდენიმე სისტემას;
• დამუშავების შედეგი არ არის მნიშვნელოვანი;
• არის რამდენიმე მოვლენა ან მცირე მოვლენა.

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

წყარო: www.habr.com