“माझ्या शूजमध्ये चालत आहे” - थांबा, ते चिन्हांकित आहेत?

2019 पासून, रशियामध्ये अनिवार्य लेबलिंगचा कायदा आहे. कायदा सर्व वस्तूंच्या गटांना लागू होत नाही आणि उत्पादन गटांसाठी अनिवार्य लेबलिंग लागू करण्याच्या तारखा भिन्न आहेत. तंबाखू, शूज आणि औषधे हे अनिवार्य लेबलिंगच्या अधीन असतील; इतर उत्पादने नंतर जोडली जातील, उदाहरणार्थ, परफ्यूम, कापड आणि दूध. या वैधानिक नवकल्पनेने नवीन आयटी सोल्यूशन्स विकसित करण्यास प्रवृत्त केले ज्यामुळे उत्पादनाच्या संपूर्ण जीवन साखळीचा मागोवा घेणे शक्य होईल उत्पादनापासून ते अंतिम ग्राहकाद्वारे खरेदी करण्यापर्यंत, प्रक्रियेतील सर्व सहभागींना: स्वतः राज्य आणि सर्व संस्था यासह वस्तू विकणाऱ्या अनिवार्य लेबलिंग.

X5 मध्ये, लेबल केलेल्या वस्तूंचा मागोवा घेणारी आणि राज्य आणि पुरवठादारांसह डेटाची देवाणघेवाण करणारी प्रणाली "मार्कस" असे म्हणतात. ते कसे आणि कोणी विकसित केले, त्याचे तंत्रज्ञान स्टॅक काय आहे आणि आम्हाला अभिमान वाटावा असे काहीतरी का आहे ते क्रमाने सांगू.

वास्तविक हायलोड

"मार्कस" अनेक समस्यांचे निराकरण करते, मुख्य म्हणजे लेबल केलेल्या उत्पादनांच्या हालचालीचा मागोवा घेण्यासाठी X5 माहिती प्रणाली आणि लेबल केलेल्या उत्पादनांसाठी (GIS MP) राज्य माहिती प्रणाली यांच्यातील एकीकरण संवाद. प्लॅटफॉर्म आम्हाला प्राप्त झालेले सर्व लेबलिंग कोड आणि या कोडच्या सर्व वस्तूंच्या हालचालीचा संपूर्ण इतिहास देखील संग्रहित करते आणि लेबल केलेल्या उत्पादनांची पुनर्प्रतवारी काढून टाकण्यास मदत करते. तंबाखू उत्पादनांचे उदाहरण वापरून, जे लेबल केलेल्या वस्तूंच्या पहिल्या गटांमध्ये समाविष्ट होते, सिगारेटच्या फक्त एका ट्रकमध्ये सुमारे 600 पॅक असतात, ज्यापैकी प्रत्येकाचा स्वतःचा विशिष्ट कोड असतो. आणि आमच्या सिस्टमचे कार्य हे आहे की वेअरहाऊस आणि स्टोअरमधील अशा प्रत्येक पॅकच्या हालचालींच्या कायदेशीरतेचा मागोवा घेणे आणि सत्यापित करणे आणि शेवटी अंतिम खरेदीदाराला त्यांची विक्री मान्यतेची पडताळणी करणे. आणि आम्ही प्रति तास सुमारे 000 रोख व्यवहार रेकॉर्ड करतो आणि आम्हाला हे देखील रेकॉर्ड करणे आवश्यक आहे की असे प्रत्येक पॅक स्टोअरमध्ये कसे आले. अशा प्रकारे, वस्तूंमधील सर्व हालचाली लक्षात घेऊन, आम्ही प्रति वर्ष कोट्यावधी रेकॉर्ड्सची अपेक्षा करतो.

संघ एम

मार्कस हा X5 मध्ये प्रकल्प मानला जात असूनही, तो उत्पादन दृष्टिकोन वापरून अंमलात आणला जात आहे. संघ Scrum नुसार काम करतो. प्रकल्प गेल्या उन्हाळ्यात सुरू झाला, परंतु पहिला परिणाम केवळ ऑक्टोबरमध्ये आला - आमची स्वतःची टीम पूर्णपणे एकत्र केली गेली, सिस्टम आर्किटेक्चर विकसित केले गेले आणि उपकरणे खरेदी केली गेली. आता टीममध्ये 16 लोक आहेत, त्यापैकी सहा बॅकएंड आणि फ्रंटएंड डेव्हलपमेंटमध्ये गुंतलेले आहेत, त्यापैकी तीन सिस्टम विश्लेषणात गुंतलेले आहेत. मॅन्युअल, लोड, स्वयंचलित चाचणी आणि उत्पादन देखभाल यामध्ये आणखी सहा लोक गुंतलेले आहेत. याव्यतिरिक्त, आमच्याकडे एक SRE विशेषज्ञ आहे.

आमच्या टीममध्ये फक्त डेव्हलपरच कोड लिहित नाहीत; ऑटोटेस्ट, लोड स्क्रिप्ट्स आणि ऑटोमेशन स्क्रिप्ट्स कसे प्रोग्राम करायचे आणि कसे लिहायचे हे जवळजवळ सर्व लोकांना माहित आहे. आम्ही याकडे विशेष लक्ष देतो, कारण उत्पादन समर्थनासाठी उच्च पातळीवरील ऑटोमेशन आवश्यक आहे. ज्या सहकाऱ्यांनी याआधी प्रोग्रॅम केलेले नाही त्यांना आम्ही नेहमी सल्ला देण्याचा आणि मदत करण्याचा प्रयत्न करतो आणि त्यांना काम करण्यासाठी काही छोटी कामे देतो.

कोरोनाव्हायरस साथीच्या आजारामुळे, आम्ही संपूर्ण टीमला रिमोट वर्कवर स्थानांतरित केले; विकास व्यवस्थापनासाठी सर्व साधनांची उपलब्धता, जिरा आणि गिटलॅबमधील बिल्ट वर्कफ्लोमुळे हा टप्पा सहज पार करणे शक्य झाले. दूरस्थपणे घालवलेल्या महिन्यांनी दर्शविले की परिणामी संघाच्या उत्पादकतेला त्रास झाला नाही; अनेकांसाठी, कामावरील आराम वाढला, एकमेव गोष्ट गहाळ आहे ती म्हणजे थेट संप्रेषण.

रिमोट टीम मीटिंग

दूरस्थ कामाच्या दरम्यान बैठका

समाधानाचे तंत्रज्ञान स्टॅक

X5 साठी मानक भांडार आणि CI/CD टूल GitLab आहे. आम्ही त्याचा वापर कोड स्टोरेज, सतत चाचणी आणि चाचणी आणि उत्पादन सर्व्हरवर तैनात करण्यासाठी करतो. आम्ही कोड पुनरावलोकनाचा सराव देखील वापरतो, जेव्हा कमीतकमी 2 सहकार्‍यांनी कोडमध्ये विकासकाने केलेले बदल मंजूर करणे आवश्यक असते. स्टॅटिक कोड विश्लेषक SonarQube आणि JaCoCo आम्हाला आमचा कोड स्वच्छ ठेवण्यास आणि युनिट चाचणी कव्हरेजची आवश्यक पातळी सुनिश्चित करण्यात मदत करतात. कोडमधील सर्व बदल या तपासण्यांमधून जाणे आवश्यक आहे. मॅन्युअली चालवल्या जाणार्‍या सर्व चाचणी स्क्रिप्ट्स नंतर स्वयंचलित केल्या जातात.

"मार्कस" द्वारे व्यवसाय प्रक्रियेच्या यशस्वी अंमलबजावणीसाठी, आम्हाला अनेक तांत्रिक समस्या सोडवाव्या लागल्या, प्रत्येक क्रमाने.

कार्य 1. प्रणालीच्या क्षैतिज स्केलेबिलिटीची आवश्यकता

या समस्येचे निराकरण करण्यासाठी, आम्ही आर्किटेक्चरसाठी मायक्रोसर्व्हिस दृष्टीकोन निवडला. त्याच वेळी, सेवांच्या जबाबदारीची क्षेत्रे समजून घेणे खूप महत्वाचे होते. आम्ही प्रक्रियांचे तपशील लक्षात घेऊन त्यांना व्यवसाय ऑपरेशन्समध्ये विभागण्याचा प्रयत्न केला. उदाहरणार्थ, वेअरहाऊसमध्ये स्वीकृती खूप वारंवार नसते, परंतु खूप मोठ्या प्रमाणात ऑपरेशन असते, ज्या दरम्यान स्वीकारल्या जाणार्‍या वस्तूंच्या युनिट्सबद्दल राज्य नियामकांकडून त्वरीत माहिती मिळवणे आवश्यक असते, ज्याची संख्या एका वितरणात 600000 पर्यंत पोहोचते. , हे उत्पादन वेअरहाऊसमध्ये स्वीकारण्याची परवानगी तपासा आणि वेअरहाऊस ऑटोमेशन सिस्टमसाठी सर्व आवश्यक माहिती परत करा. परंतु वेअरहाऊसमधून शिपमेंटची तीव्रता खूप जास्त असते, परंतु त्याच वेळी ते लहान प्रमाणात डेटासह कार्य करते.

आम्ही सर्व सेवा राज्यविहीन आधारावर कार्यान्वित करतो आणि आम्ही ज्याला काफ्का स्वयं-विषय म्हणतो त्याचा वापर करून अंतर्गत ऑपरेशन्सचे चरणांमध्ये विभाजन करण्याचा प्रयत्न करतो. जेव्हा मायक्रोसर्व्हिस स्वतःला संदेश पाठवते, जे तुम्हाला अधिक संसाधन-केंद्रित ऑपरेशन्सवरील भार संतुलित करण्यास अनुमती देते आणि उत्पादनाची देखभाल सुलभ करते, परंतु नंतर त्याबद्दल अधिक.

आम्ही वेगळ्या सेवांमध्ये बाह्य प्रणालींसह परस्परसंवादासाठी मॉड्यूल वेगळे करण्याचा निर्णय घेतला. यामुळे व्यवसाय कार्यक्षमतेसह सेवांवर अक्षरशः कोणताही परिणाम न होता बाह्य प्रणालींच्या वारंवार बदलणाऱ्या API च्या समस्येचे निराकरण करणे शक्य झाले.

सर्व मायक्रोसर्व्हिसेस ओपनशिफ्ट क्लस्टरमध्ये तैनात केल्या आहेत, जे प्रत्येक मायक्रोसर्व्हिस स्केल करण्याच्या दोन्ही समस्यांचे निराकरण करते आणि आम्हाला तृतीय-पक्ष सेवा डिस्कव्हरी टूल्स न वापरण्याची परवानगी देते.

कार्य 2. प्लॅटफॉर्म सेवांमध्ये उच्च भार आणि अतिशय गहन डेटा एक्सचेंज राखण्याची गरज: केवळ प्रकल्प प्रक्षेपण टप्प्यात, प्रति सेकंद सुमारे 600 ऑपरेशन्स केल्या जातात. रिटेल आउटलेट्स आमच्या प्लॅटफॉर्मशी कनेक्ट झाल्यामुळे हे मूल्य 5000 ops/सेकंद पर्यंत वाढण्याची आम्हाला अपेक्षा आहे.

काफ्का क्लस्टर तैनात करून आणि प्लॅटफॉर्मच्या मायक्रोसर्व्हिसेसमधील समकालिक परस्परसंवाद जवळजवळ पूर्णपणे सोडून देऊन ही समस्या सोडवली गेली. यासाठी सिस्टम आवश्यकतांचे अत्यंत काळजीपूर्वक विश्लेषण करणे आवश्यक आहे, कारण सर्व ऑपरेशन्स एसिंक्रोनस असू शकत नाहीत. त्याच वेळी, आम्ही ब्रोकरद्वारे केवळ इव्हेंट प्रसारित करत नाही तर संदेशामध्ये आवश्यक असलेली सर्व व्यवसाय माहिती देखील प्रसारित करतो. अशा प्रकारे, संदेशाचा आकार अनेक शंभर किलोबाइट्सपर्यंत पोहोचू शकतो. काफ्कामधील संदेश आकार मर्यादेसाठी आम्हाला संदेश आकाराचा अचूक अंदाज लावणे आवश्यक आहे आणि आवश्यक असल्यास, आम्ही त्यांची विभागणी करतो, परंतु विभागणी तार्किक आहे, व्यवसाय ऑपरेशन्सशी संबंधित आहे.
उदाहरणार्थ, कारमध्ये येणारा माल आम्ही बॉक्समध्ये विभागतो. सिंक्रोनस ऑपरेशन्ससाठी, स्वतंत्र मायक्रो सर्व्हिसेसचे वाटप केले जाते आणि कसून लोड चाचणी केली जाते. काफ्का वापरून आम्हाला आणखी एक आव्हान दिले - काफ्का एकत्रीकरण लक्षात घेऊन आमच्या सेवेच्या कार्याची चाचणी करणे आमच्या सर्व युनिट चाचण्या अतुल्यकालिक बनवते. आम्ही एम्बेडेड काफ्का ब्रोकर वापरून आमच्या स्वतःच्या उपयुक्तता पद्धती लिहून ही समस्या सोडवली. यामुळे वैयक्तिक पद्धतींसाठी युनिट चाचण्या लिहिण्याची गरज नाहीशी होत नाही, परंतु आम्ही काफ्का वापरून जटिल प्रकरणांची चाचणी घेण्यास प्राधान्य देतो.

ट्रेसिंग लॉगवर बरेच लक्ष दिले गेले जेणेकरून सेवांच्या ऑपरेशन दरम्यान किंवा काफ्का बॅचसह काम करताना अपवाद आढळल्यास त्यांचा ट्रेसआयडी गमावला जाऊ नये. आणि जर पहिल्यामध्ये काही विशेष समस्या नसतील, तर दुसऱ्या प्रकरणात आम्हाला बॅचसह आलेले सर्व ट्रेसआयड लॉग करणे आणि ट्रेसिंग सुरू ठेवण्यासाठी एक निवडणे भाग पडते. त्यानंतर, मूळ TraceId द्वारे शोधताना, वापरकर्त्याला सहजपणे कळेल की ट्रेसिंग कशासह चालू आहे.

कार्य 3. मोठ्या प्रमाणात डेटा संचयित करण्याची आवश्यकता: केवळ तंबाखूसाठी प्रतिवर्षी 1 अब्जाहून अधिक लेबले X5 वर येतात. त्यांना सतत आणि द्रुत प्रवेश आवश्यक आहे. एकूण, सिस्टमने या लेबल केलेल्या वस्तूंच्या हालचालींच्या इतिहासाच्या सुमारे 10 अब्ज रेकॉर्डवर प्रक्रिया करणे आवश्यक आहे.

तिसऱ्या समस्येचे निराकरण करण्यासाठी, NoSQL डेटाबेस MongoDB निवडला गेला. आम्ही 5 नोड्सचा एक शार्ड तयार केला आहे आणि प्रत्येक नोडमध्ये 3 सर्व्हरचा प्रतिकृती संच आहे. हे तुम्हाला सिस्टमला क्षैतिजरित्या स्केल करण्यास अनुमती देते, क्लस्टरमध्ये नवीन सर्व्हर जोडून, ​​आणि त्याची दोष सहिष्णुता सुनिश्चित करते. येथे आम्हाला आणखी एक समस्या आली - मोंगो क्लस्टरमध्ये व्यवहाराची खात्री करणे, क्षैतिज स्केलेबल मायक्रोसर्व्हिसेसचा वापर लक्षात घेऊन. उदाहरणार्थ, समान लेबलिंग कोडसह उत्पादने पुन्हा विकण्याचे प्रयत्न ओळखणे हे आमच्या सिस्टमच्या कार्यांपैकी एक आहे. येथे, आच्छादन चुकीच्या स्कॅनसह किंवा कॅशियरच्या चुकीच्या ऑपरेशनसह दिसतात. आम्हाला आढळले की अशा डुप्लिकेट्सवर प्रक्रिया केल्या जाणाऱ्या एका काफ्का बॅचमध्ये आणि समांतर प्रक्रिया केल्या जाणार्‍या दोन बॅचमध्ये दोन्ही असू शकतात. अशा प्रकारे, डेटाबेसची चौकशी करून डुप्लिकेट तपासण्याने काहीही मिळाले नाही. प्रत्येक मायक्रोसेवेसाठी, आम्ही या सेवेच्या व्यावसायिक तर्कावर आधारित समस्या स्वतंत्रपणे सोडवली. उदाहरणार्थ, चेकसाठी, आम्ही बॅचमध्ये एक चेक जोडला आणि टाकताना डुप्लिकेट दिसण्यासाठी वेगळी प्रक्रिया केली.

ऑपरेशन्सच्या इतिहासासह वापरकर्त्यांचे कार्य कोणत्याही प्रकारे सर्वात महत्वाच्या गोष्टीवर परिणाम करत नाही याची खात्री करण्यासाठी - आमच्या व्यवसाय प्रक्रियेच्या कार्यप्रणालीवर, आम्ही सर्व ऐतिहासिक डेटा वेगळ्या डेटाबेससह वेगळ्या सेवेमध्ये विभक्त केला आहे, ज्याला काफ्काद्वारे माहिती देखील प्राप्त होते. . अशा प्रकारे, वापरकर्ते चालू ऑपरेशन्ससाठी डेटावर प्रक्रिया करणार्‍या सेवांना प्रभावित न करता एका वेगळ्या सेवेसह कार्य करतात.

कार्य 4: रांगेत पुन्हा प्रक्रिया करणे आणि देखरेख करणे:

वितरित प्रणालींमध्ये, डेटाबेस, रांगा आणि बाह्य डेटा स्रोतांच्या उपलब्धतेमध्ये समस्या आणि त्रुटी अपरिहार्यपणे उद्भवतात. मार्कसच्या बाबतीत, अशा त्रुटींचा स्त्रोत बाह्य प्रणालींसह एकत्रीकरण आहे. काही निर्दिष्ट कालबाह्यतेसह चुकीच्या प्रतिसादांसाठी वारंवार विनंती करण्यास अनुमती देणारा उपाय शोधणे आवश्यक होते, परंतु त्याच वेळी मुख्य रांगेत यशस्वी विनंत्यांवर प्रक्रिया करणे थांबवू नका. या उद्देशासाठी, तथाकथित "विषय आधारित पुन्हा प्रयत्न" संकल्पना निवडली गेली. प्रत्येक मुख्य विषयासाठी, एक किंवा अधिक पुन्हा प्रयत्न करण्याचे विषय तयार केले जातात ज्यावर चुकीचे संदेश पाठवले जातात आणि त्याच वेळी मुख्य विषयावरील संदेशांवर प्रक्रिया करण्यात होणारा विलंब दूर केला जातो. संवाद योजना -

अशी योजना अंमलात आणण्यासाठी, आम्हाला पुढील गोष्टींची आवश्यकता आहे: हे समाधान स्प्रिंगसह समाकलित करण्यासाठी आणि कोड डुप्लिकेशन टाळण्यासाठी. वेब सर्फिंग करताना, आम्ही Spring BeanPostProccessor वर आधारित असेच समाधान शोधले, परंतु ते आम्हाला अनावश्यकपणे अवजड वाटले. आमच्या टीमने एक सोपा उपाय तयार केला आहे जो आम्हाला ग्राहक तयार करण्यासाठी स्प्रिंग सायकलमध्ये समाकलित करण्याची परवानगी देतो आणि त्याव्यतिरिक्त पुन्हा प्रयत्न करा ग्राहक जोडू शकतो. आम्ही स्प्रिंग टीमला आमच्या सोल्यूशनचा प्रोटोटाइप ऑफर केला आहे, तुम्ही तो पाहू शकता येथे. व्यवसाय प्रक्रियेच्या गरजेनुसार, पुन्हा प्रयत्न करणाऱ्या ग्राहकांची संख्या आणि प्रत्येक ग्राहकासाठी प्रयत्नांची संख्या पॅरामीटर्सद्वारे कॉन्फिगर केली जाते आणि सर्वकाही कार्य करण्यासाठी, फक्त org.springframework.kafka.annotation.KafkaListener जोडणे बाकी आहे. , जे सर्व स्प्रिंग विकसकांना परिचित आहे.

सर्व पुन्हा प्रयत्न केल्यानंतर संदेशावर प्रक्रिया करणे शक्य नसल्यास, तो Spring DeadLetterPublishingRecoverer वापरून DLT (डेड लेटर विषय) वर जातो. समर्थनाच्या विनंतीनुसार, आम्ही ही कार्यक्षमता वाढवली आहे आणि एक वेगळी सेवा तयार केली आहे जी तुम्हाला DLT, स्टॅकट्रेस, ट्रेसआयडी आणि त्यांच्याबद्दलची इतर उपयुक्त माहितीमध्ये समाविष्ट केलेले संदेश पाहण्याची परवानगी देते. याव्यतिरिक्त, सर्व डीएलटी विषयांवर देखरेख आणि सूचना जोडल्या गेल्या आहेत आणि आता, खरं तर, डीएलटी विषयामध्ये संदेश दिसणे हे दोषांचे विश्लेषण आणि निराकरण करण्याचे एक कारण आहे. हे खूप सोयीस्कर आहे - विषयाच्या नावावरून, प्रक्रियेच्या कोणत्या टप्प्यावर समस्या उद्भवली हे आम्हाला लगेच समजते, जे त्याच्या मूळ कारणाचा शोध लक्षणीयरीत्या वेगवान करते.

अगदी अलीकडे, आम्ही एक इंटरफेस लागू केला आहे जो आम्हाला संदेशांची कारणे काढून टाकल्यानंतर (उदाहरणार्थ, बाह्य प्रणालीची कार्यक्षमता पुनर्संचयित करणे) आणि अर्थातच, विश्लेषणासाठी संबंधित दोष स्थापित केल्यानंतर आमच्या समर्थनाचा वापर करून संदेश पुन्हा पाठविण्याची परवानगी देतो. येथेच आमचे स्वयं-विषय कामी येतात: दीर्घ प्रक्रिया शृंखला रीस्टार्ट न होण्यासाठी, तुम्ही इच्छित पायरीवरून रीस्टार्ट करू शकता.

प्लॅटफॉर्म ऑपरेशन

प्लॅटफॉर्म आधीच उत्पादक कार्यात आहे, दररोज आम्ही वितरण आणि शिपमेंट करतो, नवीन वितरण केंद्रे आणि स्टोअर कनेक्ट करतो. पायलटचा भाग म्हणून, सिस्टम "तंबाखू" आणि "शूज" उत्पादन गटांसह कार्य करते.

आमची संपूर्ण टीम पायलट आयोजित करण्यात भाग घेते, उदयोन्मुख समस्यांचे विश्लेषण करते आणि लॉग सुधारण्यापासून प्रक्रिया बदलण्यापर्यंत आमचे उत्पादन सुधारण्यासाठी सूचना देते.

आमच्या चुकांची पुनरावृत्ती होऊ नये म्हणून, पायलट दरम्यान आढळलेली सर्व प्रकरणे स्वयंचलित चाचण्यांमध्ये दिसून येतात. मोठ्या संख्येने ऑटोटेस्ट आणि युनिट चाचण्यांची उपस्थिती आपल्याला रीग्रेशन चाचणी आयोजित करण्यास आणि काही तासांमध्ये अक्षरशः हॉटफिक्स स्थापित करण्यास अनुमती देते.

आता आम्ही आमचे प्लॅटफॉर्म विकसित करणे आणि सुधारणे सुरू ठेवतो आणि सतत नवीन आव्हानांना तोंड देत असतो. आपल्याला स्वारस्य असल्यास, आम्ही पुढील लेखांमध्ये आमच्या उपायांबद्दल बोलू.

स्त्रोत: www.habr.com