"मेरो जुत्तामा हिंड्दै" - पर्खनुहोस्, के तिनीहरू चिन्हित छन्?

2019 देखि, रूस मा अनिवार्य लेबलिंग मा एक कानून छ। कानून सबै सामान समूहहरूमा लागू हुँदैन, र उत्पादन समूहहरूको लागि अनिवार्य लेबलिङ लागू हुने मितिहरू फरक छन्। तंबाकू, जुत्ता र औषधिहरू अनिवार्य लेबलिङको अधीनमा हुने पहिलो हुनेछन्; अन्य उत्पादनहरू पछि थपिनेछन्, उदाहरणका लागि, अत्तर, कपडा र दूध। यस विधायी आविष्कारले नयाँ आईटी समाधानहरूको विकासलाई प्रेरित गर्‍यो जसले उत्पादनको सम्पूर्ण जीवन श्रृंखलालाई उत्पादनदेखि अन्तिम उपभोक्ता द्वारा खरीद गर्न, प्रक्रियामा सहभागी सबै सहभागीहरूलाई ट्र्याक गर्न सम्भव बनाउँदछ: दुबै राज्य आफैं र सबै संस्थाहरूले सामान बेच्ने। अनिवार्य लेबलिंग।

X5 मा, लेबल गरिएका सामानहरू ट्र्याक गर्ने र राज्य र आपूर्तिकर्ताहरूसँग डाटा आदानप्रदान गर्ने प्रणालीलाई "मार्कस" भनिन्छ। यसलाई कसरी र कसले विकास गर्‍यो, यसको टेक्नोलोजी स्ट्याक के हो, र हामीसँग किन गर्व गर्नुपर्ने कुरा छ भनेर क्रमबद्ध रूपमा बताउनुहोस्।

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

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

टोली एम

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

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

कोरोनाभाइरस महामारीको कारण, हामीले सम्पूर्ण टोलीलाई टाढाको काममा स्थानान्तरण गर्‍यौं; विकास व्यवस्थापनका लागि सबै उपकरणहरूको उपलब्धता, जिरा र GitLab मा निर्मित कार्यप्रवाहले यो चरण सजिलै पार गर्न सम्भव बनायो। टाढाबाट बिताएका महिनाहरूले देखाएको छ कि टोलीको उत्पादकता नतिजाको रूपमा पीडित भएन; धेरैको लागि, काममा आराम बढ्यो, हराइरहेको एक मात्र चीज प्रत्यक्ष सञ्चार थियो।

टाढाको टोली बैठक

टाढाको कामको क्रममा बैठकहरू

समाधानको टेक्नोलोजी स्ट्याक

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

"मार्कस" द्वारा व्यावसायिक प्रक्रियाहरूको सफल कार्यान्वयनको लागि, हामीले प्रत्येक क्रमबद्ध रूपमा धेरै प्राविधिक समस्याहरू समाधान गर्नुपर्‍यो।

कार्य १. प्रणालीको तेर्सो स्केलेबिलिटीको आवश्यकता

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

हामी सबै सेवाहरू राज्यविहीन आधारमा कार्यान्वयन गर्छौं र हामीले काफ्का स्व-विषयहरू प्रयोग गरेर आन्तरिक कार्यहरूलाई चरणहरूमा विभाजन गर्ने प्रयास गर्छौं। यो तब हुन्छ जब एक माइक्रोसर्भिसले आफैलाई सन्देश पठाउँछ, जसले तपाईंलाई थप संसाधन-गहन सञ्चालनहरूमा भार सन्तुलन गर्न र उत्पादन मर्मतलाई सरल बनाउँदछ, तर पछि त्यसमा थप।

हामीले बाहिरी प्रणालीहरूसँग अन्तरक्रियाका लागि अलग-अलग सेवाहरूमा मोड्युलहरू अलग गर्ने निर्णय गर्यौं। यसले बाह्य प्रणालीहरूको बारम्बार एपीआईहरू परिवर्तन गर्ने समस्या समाधान गर्न सम्भव बनायो, व्यापार कार्यक्षमताका साथ सेवाहरूमा वस्तुतः कुनै प्रभाव नपर्ने।

सबै माइक्रोसर्भिसेसहरू OpenShift क्लस्टरमा तैनाथ गरिएका छन्, जसले प्रत्येक माइक्रोसर्भिसलाई स्केल गर्ने दुवै समस्या समाधान गर्छ र हामीलाई तेस्रो-पक्ष सेवा खोज उपकरणहरू प्रयोग नगर्न अनुमति दिन्छ।

कार्य 2. प्लेटफर्म सेवाहरू बीच उच्च भार र धेरै गहन डेटा आदानप्रदान कायम गर्न आवश्यकता: परियोजना प्रक्षेपण चरणमा मात्र, प्रति सेकेन्ड लगभग 600 अपरेशनहरू प्रदर्शन गरिन्छ। हामी यो मान 5000 ops/sec मा वृद्धि हुने आशा गर्छौं किनकि रिटेल आउटलेटहरू हाम्रो प्लेटफर्ममा जडान हुन्छन्।

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

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

कार्य 3. ठूलो मात्रामा डाटा भण्डारण गर्न आवश्यकता: तंबाकूको लागि मात्र प्रति वर्ष 1 बिलियन भन्दा बढी लेबलहरू X5 मा आउँछन्। तिनीहरूलाई निरन्तर र द्रुत पहुँच चाहिन्छ। कुलमा, प्रणालीले यी लेबल गरिएका सामानहरूको आन्दोलन इतिहासको लगभग 10 अरब रेकर्डहरू प्रशोधन गर्नुपर्छ।

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

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

कार्य 4: लाम पुन: प्रशोधन र निगरानी:

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

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

यदि सन्देश सबै पुन: प्रयास प्रयासहरू पछि प्रशोधन गर्न सकिएन भने, यो Spring DeadLetterPublishingRecoverer प्रयोग गरेर DLT (मृत पत्र विषय) मा जान्छ। समर्थनको अनुरोधमा, हामीले यो कार्यक्षमता विस्तार गर्यौं र एउटा छुट्टै सेवा सिर्जना गर्यौं जसले तपाईंलाई DLT, stackTrace, traceId र तिनीहरूको बारेमा अन्य उपयोगी जानकारीमा समावेश सन्देशहरू हेर्न अनुमति दिन्छ। थप रूपमा, सबै DLT विषयहरूमा निगरानी र अलर्टहरू थपिएका थिए, र अब, वास्तवमा, DLT शीर्षकमा सन्देश देखा पर्नु नै त्रुटिको विश्लेषण र समाधान गर्ने कारण हो। यो धेरै सुविधाजनक छ - विषयको नामबाट, हामी तुरुन्तै प्रक्रियाको कुन चरणमा समस्या उत्पन्न भयो भनेर बुझ्छौं, जसले महत्त्वपूर्ण रूपमा यसको मूल कारणको खोजीलाई गति दिन्छ।

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

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

प्लेटफर्म पहिले नै उत्पादक सञ्चालनमा छ, हरेक दिन हामी डेलिभरी र ढुवानी गर्छौं, नयाँ वितरण केन्द्रहरू र स्टोरहरू जडान गर्दछौं। पायलट को एक भाग को रूप मा, प्रणाली "तंबाकू" र "जूता" उत्पादन समूह संग काम गर्दछ।

हाम्रो सम्पूर्ण टोलीले पाइलटहरू सञ्चालनमा भाग लिन्छ, उदीयमान समस्याहरूको विश्लेषण गर्दछ र हाम्रो उत्पादन सुधार गर्नका लागि लगहरू सुधार गर्नदेखि प्रक्रियाहरू परिवर्तन गर्न सुझावहरू दिन्छ।

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

अब हामी हाम्रो प्लेटफर्मको विकास र सुधार गर्न जारी राख्छौं, र निरन्तर नयाँ चुनौतीहरूको सामना गर्दछौं। यदि तपाइँ इच्छुक हुनुहुन्छ भने, हामी निम्न लेखहरूमा हाम्रो समाधानहरूको बारेमा कुरा गर्नेछौं।

स्रोत: www.habr.com