"मेरे जूते पहनकर चलना" - रुको, क्या उन पर निशान हैं?

2019 से, रूस में अनिवार्य लेबलिंग पर एक कानून है। कानून वस्तुओं के सभी समूहों पर लागू नहीं होता है, और उत्पाद समूहों के लिए अनिवार्य लेबलिंग के लागू होने की तारीखें अलग-अलग हैं। तम्बाकू, जूते और दवाइयाँ सबसे पहले अनिवार्य लेबलिंग के अधीन होंगी; अन्य उत्पाद बाद में जोड़े जाएंगे, उदाहरण के लिए, इत्र, कपड़ा और दूध। इस विधायी नवाचार ने नए आईटी समाधानों के विकास को प्रेरित किया जो किसी उत्पाद के उत्पादन से लेकर अंतिम उपभोक्ता द्वारा खरीद तक ​​की पूरी जीवन श्रृंखला को प्रक्रिया में सभी प्रतिभागियों को ट्रैक करना संभव बना देगा: दोनों राज्य और सामान बेचने वाले सभी संगठन अनिवार्य लेबलिंग.

X5 में, वह प्रणाली जो लेबल किए गए सामानों को ट्रैक करेगी और सरकार और आपूर्तिकर्ताओं के साथ डेटा का आदान-प्रदान करेगी, उसे "मार्कस" कहा जाता है। आइए आपको क्रम से बताएं कि इसे कैसे और किसने विकसित किया, इसकी प्रौद्योगिकी स्टैक क्या है और हमारे पास गर्व करने लायक कुछ क्यों है।

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

"मार्कस" कई समस्याओं का समाधान करता है, जिनमें से मुख्य है लेबल किए गए उत्पादों की आवाजाही को ट्रैक करने के लिए X5 सूचना प्रणाली और लेबल किए गए उत्पादों (जीआईएस एमपी) के लिए राज्य सूचना प्रणाली के बीच एकीकरण इंटरैक्शन। प्लेटफ़ॉर्म हमारे द्वारा प्राप्त सभी लेबलिंग कोड और वस्तुओं में इन कोडों के संचलन के पूरे इतिहास को भी संग्रहीत करता है, और लेबल किए गए उत्पादों की पुन: ग्रेडिंग को खत्म करने में मदद करता है। तंबाकू उत्पादों के उदाहरण का उपयोग करते हुए, जो लेबल किए गए सामानों के पहले समूहों में शामिल थे, सिगरेट के सिर्फ एक ट्रक में लगभग 600 पैक होते हैं, जिनमें से प्रत्येक का अपना अनूठा कोड होता है। और हमारे सिस्टम का कार्य गोदामों और दुकानों के बीच ऐसे प्रत्येक पैक की गतिविधियों की वैधता को ट्रैक करना और सत्यापित करना है, और अंततः अंतिम खरीदार को उनकी बिक्री की स्वीकार्यता को सत्यापित करना है। और हम प्रति घंटे लगभग 000 नकद लेनदेन रिकॉर्ड करते हैं, और हमें यह भी रिकॉर्ड करने की आवश्यकता है कि ऐसा प्रत्येक पैक स्टोर में कैसे आया। इस प्रकार, वस्तुओं के बीच सभी गतिविधियों को ध्यान में रखते हुए, हम प्रति वर्ष दसियों अरब रिकॉर्ड की उम्मीद कर रहे हैं।

टीम एम

इस तथ्य के बावजूद कि मार्कस को X5 के भीतर एक परियोजना माना जाता है, इसे उत्पाद दृष्टिकोण का उपयोग करके कार्यान्वित किया जा रहा है। टीम स्क्रम के अनुसार काम करती है। परियोजना पिछली गर्मियों में शुरू हुई थी, लेकिन पहला परिणाम अक्टूबर में ही आया - हमारी अपनी टीम पूरी तरह से इकट्ठी हो गई थी, सिस्टम आर्किटेक्चर विकसित किया गया था और उपकरण खरीदे गए थे। अब टीम में 16 लोग हैं, जिनमें से छह बैकएंड और फ्रंटएंड विकास में शामिल हैं, जिनमें से तीन सिस्टम विश्लेषण में शामिल हैं। छह और लोग मैनुअल, लोड, स्वचालित परीक्षण और उत्पाद रखरखाव में शामिल हैं। इसके अलावा, हमारे पास एक एसआरई विशेषज्ञ है।

हमारी टीम में न केवल डेवलपर्स कोड लिखते हैं; लगभग सभी लोग ऑटोटेस्ट, लोड स्क्रिप्ट और ऑटोमेशन स्क्रिप्ट को प्रोग्राम करना और लिखना जानते हैं। हम इस पर विशेष ध्यान देते हैं, क्योंकि उत्पाद समर्थन के लिए भी उच्च स्तर के स्वचालन की आवश्यकता होती है। हम हमेशा उन सहकर्मियों को सलाह देने और उनकी मदद करने का प्रयास करते हैं जिन्होंने पहले प्रोग्राम नहीं किया है, और उन्हें काम करने के लिए कुछ छोटे कार्य देते हैं।

कोरोनोवायरस महामारी के कारण, हमने पूरी टीम को दूरस्थ कार्य में स्थानांतरित कर दिया; विकास प्रबंधन के लिए सभी उपकरणों की उपलब्धता, जीरा और गिटलैब में निर्मित वर्कफ़्लो ने इस चरण को आसानी से पारित करना संभव बना दिया। दूर से बिताए गए महीनों से पता चला कि इसके परिणामस्वरूप टीम की उत्पादकता प्रभावित नहीं हुई; कई लोगों के लिए, काम पर आराम बढ़ गया, केवल लाइव संचार की कमी थी।

दूरस्थ टीम की बैठक

दूरस्थ कार्य के दौरान बैठकें

समाधान का प्रौद्योगिकी ढेर

X5 के लिए मानक रिपॉजिटरी और CI/CD टूल GitLab है। हम इसका उपयोग कोड भंडारण, निरंतर परीक्षण और परीक्षण और उत्पादन सर्वर पर तैनाती के लिए करते हैं। हम कोड समीक्षा की प्रथा का भी उपयोग करते हैं, जब कम से कम 2 सहकर्मियों को डेवलपर द्वारा कोड में किए गए परिवर्तनों को अनुमोदित करने की आवश्यकता होती है। स्टेटिक कोड विश्लेषक सोनारक्यूब और जैकोको हमें अपने कोड को साफ रखने और यूनिट परीक्षण कवरेज के आवश्यक स्तर को सुनिश्चित करने में मदद करते हैं। कोड में सभी बदलावों को इन जांचों से गुजरना होगा। मैन्युअल रूप से चलने वाली सभी परीक्षण स्क्रिप्ट बाद में स्वचालित हो जाती हैं।

"मार्कस" द्वारा व्यावसायिक प्रक्रियाओं के सफल कार्यान्वयन के लिए, हमें कई तकनीकी समस्याओं को हल करना था, प्रत्येक के बारे में क्रम से।

कार्य 1. सिस्टम की क्षैतिज मापनीयता की आवश्यकता

इस समस्या को हल करने के लिए, हमने आर्किटेक्चर के लिए एक माइक्रोसर्विस दृष्टिकोण चुना। साथ ही, सेवाओं की जिम्मेदारी के क्षेत्रों को समझना भी बहुत महत्वपूर्ण था। हमने प्रक्रियाओं की बारीकियों को ध्यान में रखते हुए उन्हें व्यावसायिक संचालन में विभाजित करने का प्रयास किया। उदाहरण के लिए, एक गोदाम में स्वीकृति बहुत बार-बार नहीं होती है, लेकिन बहुत बड़े पैमाने पर ऑपरेशन होती है, जिसके दौरान राज्य नियामक से स्वीकार की जाने वाली वस्तुओं की इकाइयों के बारे में तुरंत जानकारी प्राप्त करना आवश्यक होता है, जिनकी संख्या एक डिलीवरी में 600000 तक पहुंच जाती है। , इस उत्पाद को गोदाम में स्वीकार करने की स्वीकार्यता की जांच करें और गोदाम स्वचालन प्रणाली के लिए सभी आवश्यक जानकारी लौटाएं। लेकिन गोदामों से शिपमेंट की तीव्रता बहुत अधिक होती है, लेकिन साथ ही यह कम मात्रा में डेटा के साथ संचालित होता है।

हम सभी सेवाओं को स्टेटलेस आधार पर लागू करते हैं और यहां तक ​​कि जिसे हम काफ्का स्व-विषय कहते हैं, उसका उपयोग करके आंतरिक संचालन को चरणों में विभाजित करने का प्रयास करते हैं। ऐसा तब होता है जब एक माइक्रोसर्विसेज खुद को एक संदेश भेजता है, जो आपको अधिक संसाधन-गहन संचालन पर लोड को संतुलित करने और उत्पाद रखरखाव को सरल बनाने की अनुमति देता है, लेकिन बाद में उस पर और अधिक।

हमने बाहरी प्रणालियों के साथ बातचीत के लिए मॉड्यूल को अलग-अलग सेवाओं में विभाजित करने का निर्णय लिया। इससे बाहरी प्रणालियों के बार-बार बदलते एपीआई की समस्या को हल करना संभव हो गया, जिसका व्यावसायिक कार्यक्षमता वाली सेवाओं पर लगभग कोई प्रभाव नहीं पड़ा।

सभी माइक्रोसर्विसेज को ओपनशिफ्ट क्लस्टर में तैनात किया गया है, जो प्रत्येक माइक्रोसर्विस को स्केल करने की समस्या को हल करता है और हमें थर्ड-पार्टी सर्विस डिस्कवरी टूल का उपयोग नहीं करने की अनुमति देता है।

कार्य 2. प्लेटफ़ॉर्म सेवाओं के बीच उच्च भार और बहुत गहन डेटा विनिमय बनाए रखने की आवश्यकता: अकेले प्रोजेक्ट लॉन्च चरण के दौरान, प्रति सेकंड लगभग 600 ऑपरेशन किए जाते हैं। हमें उम्मीद है कि जैसे-जैसे खुदरा दुकानें हमारे प्लेटफॉर्म से जुड़ेंगी, यह मूल्य बढ़कर 5000 ऑप्स/सेकंड हो जाएगा।

इस समस्या को काफ्का क्लस्टर को तैनात करके और प्लेटफ़ॉर्म के माइक्रोसर्विसेज के बीच सिंक्रोनस इंटरैक्शन को लगभग पूरी तरह से छोड़कर हल किया गया था। इसके लिए सिस्टम आवश्यकताओं का बहुत सावधानीपूर्वक विश्लेषण आवश्यक है, क्योंकि सभी ऑपरेशन एसिंक्रोनस नहीं हो सकते हैं। साथ ही, हम न केवल ब्रोकर के माध्यम से घटनाओं को प्रसारित करते हैं, बल्कि संदेश में सभी आवश्यक व्यावसायिक जानकारी भी प्रसारित करते हैं। इस प्रकार, संदेश का आकार कई सौ किलोबाइट तक पहुंच सकता है। काफ्का में संदेश आकार सीमा के लिए हमें संदेश आकार की सटीक भविष्यवाणी करने की आवश्यकता होती है, और यदि आवश्यक हो, तो हम उन्हें विभाजित करते हैं, लेकिन विभाजन तार्किक है, जो व्यावसायिक संचालन से संबंधित है।
उदाहरण के लिए, कार में आने वाले सामान को हम डिब्बों में बांट देते हैं। सिंक्रोनस संचालन के लिए, अलग-अलग माइक्रोसर्विसेज आवंटित किए जाते हैं और संपूर्ण लोड परीक्षण किया जाता है। काफ्का का उपयोग करने से हमें एक और चुनौती मिली - काफ्का एकीकरण को ध्यान में रखते हुए हमारी सेवा के संचालन का परीक्षण करना हमारे सभी यूनिट परीक्षणों को अतुल्यकालिक बनाता है। हमने एंबेडेड काफ्का ब्रोकर का उपयोग करके अपनी स्वयं की उपयोगिता विधियाँ लिखकर इस समस्या का समाधान किया। यह अलग-अलग तरीकों के लिए यूनिट परीक्षण लिखने की आवश्यकता को समाप्त नहीं करता है, लेकिन हम काफ्का का उपयोग करके जटिल मामलों का परीक्षण करना पसंद करते हैं।

लॉग को ट्रेस करने पर बहुत अधिक ध्यान दिया गया ताकि सेवाओं के संचालन के दौरान या काफ्का बैच के साथ काम करते समय अपवाद होने पर उनका ट्रेसआईडी खो न जाए। और यदि पहले वाले के साथ कोई विशेष समस्या नहीं थी, तो दूसरे मामले में हमें बैच के साथ आए सभी ट्रेसआईडी को लॉग करने और ट्रेसिंग जारी रखने के लिए एक का चयन करने के लिए मजबूर होना पड़ता है। फिर, मूल ट्रेसआईडी द्वारा खोजते समय, उपयोगकर्ता आसानी से पता लगा लेगा कि ट्रेसिंग किसके साथ जारी रही।

कार्य 3. बड़ी मात्रा में डेटा संग्रहीत करने की आवश्यकता: अकेले तम्बाकू के लिए प्रति वर्ष 1 बिलियन से अधिक लेबल X5 पर आते हैं। उन्हें निरंतर और त्वरित पहुंच की आवश्यकता होती है। कुल मिलाकर, सिस्टम को इन लेबल किए गए सामानों के संचलन इतिहास के लगभग 10 बिलियन रिकॉर्ड को संसाधित करना होगा।

तीसरी समस्या को हल करने के लिए, NoSQL डेटाबेस MongoDB को चुना गया। हमने 5 नोड्स का एक शार्ड बनाया है और प्रत्येक नोड में 3 सर्वरों का एक रेप्लिका सेट है। यह आपको सिस्टम को क्षैतिज रूप से स्केल करने, क्लस्टर में नए सर्वर जोड़ने और इसकी दोष सहनशीलता सुनिश्चित करने की अनुमति देता है। यहां हमें एक और समस्या का सामना करना पड़ा - क्षैतिज रूप से स्केलेबल माइक्रोसर्विसेज के उपयोग को ध्यान में रखते हुए, मोंगो क्लस्टर में लेन-देन सुनिश्चित करना। उदाहरण के लिए, हमारे सिस्टम का एक कार्य समान लेबलिंग कोड वाले उत्पादों को दोबारा बेचने के प्रयासों की पहचान करना है। यहां, कैशियर द्वारा गलत स्कैन या गलत संचालन के साथ ओवरले दिखाई देते हैं। हमने पाया कि ऐसे डुप्लिकेट संसाधित होने वाले एक काफ्का बैच के भीतर और समानांतर में संसाधित होने वाले दो बैचों के भीतर हो सकते हैं। इस प्रकार, डेटाबेस से पूछताछ करके डुप्लिकेट की जांच करने से कुछ नहीं मिला। प्रत्येक माइक्रोसर्विस के लिए, हमने इस सेवा के व्यावसायिक तर्क के आधार पर समस्या को अलग से हल किया। उदाहरण के लिए, चेक के लिए, हमने बैच के अंदर एक चेक जोड़ा और सम्मिलित करते समय डुप्लिकेट की उपस्थिति के लिए अलग प्रसंस्करण जोड़ा।

यह सुनिश्चित करने के लिए कि संचालन के इतिहास के साथ उपयोगकर्ताओं का काम किसी भी तरह से सबसे महत्वपूर्ण चीज़ को प्रभावित नहीं करता है - हमारी व्यावसायिक प्रक्रियाओं की कार्यप्रणाली, हमने सभी ऐतिहासिक डेटा को एक अलग डेटाबेस के साथ एक अलग सेवा में अलग कर दिया है, जो काफ्का के माध्यम से भी जानकारी प्राप्त करता है . इस तरह, उपयोगकर्ता चल रहे संचालन के लिए डेटा संसाधित करने वाली सेवाओं को प्रभावित किए बिना एक अलग सेवा के साथ काम करते हैं।

कार्य 4: कतार पुनर्प्रसंस्करण और निगरानी:

वितरित प्रणालियों में, डेटाबेस, कतार और बाहरी डेटा स्रोतों की उपलब्धता में समस्याएं और त्रुटियां अनिवार्य रूप से उत्पन्न होती हैं। मार्कस के मामले में, ऐसी त्रुटियों का स्रोत बाहरी प्रणालियों के साथ एकीकरण है। ऐसा समाधान ढूंढना आवश्यक था जो कुछ निर्दिष्ट समयबाह्य के साथ गलत प्रतिक्रियाओं के लिए बार-बार अनुरोध करने की अनुमति दे, लेकिन साथ ही मुख्य कतार में सफल अनुरोधों को संसाधित करना बंद न करे। इस उद्देश्य के लिए, तथाकथित "विषय आधारित पुनः प्रयास" अवधारणा को चुना गया था। प्रत्येक मुख्य विषय के लिए, एक या अधिक पुन: प्रयास विषय बनाए जाते हैं जिन पर गलत संदेश भेजे जाते हैं और साथ ही मुख्य विषय से संदेशों को संसाधित करने में होने वाली देरी समाप्त हो जाती है। इंटरेक्शन योजना -

ऐसी योजना को लागू करने के लिए, हमें निम्नलिखित की आवश्यकता है: इस समाधान को स्प्रिंग के साथ एकीकृत करना और कोड दोहराव से बचना। वेब पर सर्फिंग करते समय, हमें स्प्रिंग बीनपोस्टप्रोसेसर पर आधारित एक समान समाधान मिला, लेकिन यह हमें अनावश्यक रूप से बोझिल लगा। हमारी टीम ने एक सरल समाधान बनाया है जो हमें उपभोक्ताओं को बनाने के लिए स्प्रिंग चक्र में एकीकृत करने और इसके अतिरिक्त रिट्री उपभोक्ताओं को जोड़ने की अनुमति देता है। हमने स्प्रिंग टीम को अपने समाधान का एक प्रोटोटाइप पेश किया, आप इसे देख सकते हैं यहां. पुन: प्रयास करने वाले उपभोक्ताओं की संख्या और प्रत्येक उपभोक्ता के लिए प्रयासों की संख्या को व्यावसायिक प्रक्रिया की जरूरतों के आधार पर मापदंडों के माध्यम से कॉन्फ़िगर किया गया है, और सब कुछ काम करने के लिए, जो कुछ बचा है वह एनोटेशन org.springframework.kafka.annotation.KafkaListener जोड़ना है। , जो सभी स्प्रिंग डेवलपर्स से परिचित है।

यदि सभी पुनः प्रयास प्रयासों के बाद भी संदेश संसाधित नहीं किया जा सका, तो यह स्प्रिंग डेडलेटरपब्लिशिंगरिकवरर का उपयोग करके डीएलटी (डेड लेटर विषय) पर जाता है। समर्थन के अनुरोध पर, हमने इस कार्यक्षमता का विस्तार किया और एक अलग सेवा बनाई जो आपको डीएलटी, स्टैकट्रेस, ट्रेसआईडी और उनके बारे में अन्य उपयोगी जानकारी में शामिल संदेशों को देखने की अनुमति देती है। इसके अलावा, सभी डीएलटी विषयों में निगरानी और अलर्ट जोड़े गए थे, और अब, वास्तव में, डीएलटी विषय में एक संदेश की उपस्थिति एक दोष का विश्लेषण करने और उसे ठीक करने का एक कारण है। यह बहुत सुविधाजनक है - विषय के नाम से, हम तुरंत समझ जाते हैं कि प्रक्रिया के किस चरण में समस्या उत्पन्न हुई, जिससे इसके मूल कारण की खोज में काफी तेजी आती है।

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

प्लेटफार्म संचालन

प्लेटफ़ॉर्म पहले से ही उत्पादक संचालन में है, हर दिन हम डिलीवरी और शिपमेंट करते हैं, नए वितरण केंद्रों और स्टोरों को जोड़ते हैं। पायलट के हिस्से के रूप में, सिस्टम "तंबाकू" और "जूते" उत्पाद समूहों के साथ काम करता है।

हमारी पूरी टीम पायलटों के संचालन में भाग लेती है, उभरती समस्याओं का विश्लेषण करती है और लॉग में सुधार से लेकर बदलती प्रक्रियाओं तक हमारे उत्पाद को बेहतर बनाने के लिए सुझाव देती है।

हमारी गलतियों को न दोहराने के लिए, पायलट के दौरान पाए गए सभी मामले स्वचालित परीक्षणों में परिलक्षित होते हैं। बड़ी संख्या में ऑटोटेस्ट और यूनिट परीक्षणों की उपस्थिति आपको प्रतिगमन परीक्षण करने और कुछ ही घंटों में हॉटफ़िक्स स्थापित करने की अनुमति देती है।

अब हम अपने प्लेटफ़ॉर्म का विकास और सुधार करना जारी रखते हैं, और लगातार नई चुनौतियों का सामना करते हैं। यदि आप रुचि रखते हैं, तो हम निम्नलिखित लेखों में अपने समाधानों के बारे में बात करेंगे।

स्रोत: www.habr.com