काफ्का पर एसिंक्रोनस एपीआई के साथ रिफंड टूल सेवा विकसित करने का अनुभव

सुव्यवस्थित प्रक्रिया और दर्जनों परस्पर जुड़ी सेवाओं वाली लामोडा जैसी बड़ी कंपनी को अपना दृष्टिकोण महत्वपूर्ण रूप से बदलने के लिए क्या मजबूर कर सकता है? प्रेरणा पूरी तरह से अलग हो सकती है: विधायी से लेकर सभी प्रोग्रामर में निहित प्रयोग करने की इच्छा तक।

लेकिन इसका मतलब यह नहीं है कि आप अतिरिक्त लाभों पर भरोसा नहीं कर सकते। सर्गेई ज़ैका आपको बताएंगे कि यदि आप काफ्का पर इवेंट-संचालित एपीआई लागू करते हैं तो आप वास्तव में क्या जीत सकते हैं (फ़ेफ़ल्ड). बड़े शॉट्स और दिलचस्प खोजों के बारे में भी निश्चित रूप से बात होगी - प्रयोग उनके बिना नहीं चल सकता।

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

प्रक्रिया के बारे में

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

इवेंट-संचालित एपीआई के साथ रिफंड टूल

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

किसी भी स्टोर में, उन ऑर्डरों के अलावा, जिनके लिए ग्राहक भुगतान करते हैं, कई बार स्टोर को पैसे वापस करने की आवश्यकता होती है क्योंकि उत्पाद ग्राहक को पसंद नहीं आता है। यह अपेक्षाकृत छोटी प्रक्रिया है: यदि आवश्यक हो तो हम जानकारी को स्पष्ट करते हैं और धन हस्तांतरित करते हैं।

लेकिन कानून में बदलाव के कारण रिटर्न अधिक जटिल हो गया और हमें इसके लिए एक अलग माइक्रोसर्विस लागू करना पड़ा।

हमारी प्रेरणा:

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

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

बीओबी के पास बहुत सारे एक्सचेंज भी हैं: भुगतान प्रणाली, वितरण प्रणाली, अधिसूचना प्रणाली इत्यादि।

तकनीकी रूप से बीओबी है:

• कोड की ~150k पंक्तियाँ + परीक्षण की ~100k पंक्तियाँ;
• php7.2 + Zend 1 और सिम्फनी कंपोनेंट्स 3;
• >100 एपीआई और ~50 आउटबाउंड एकीकरण;
• अपने स्वयं के व्यावसायिक तर्क वाले 4 देश।

बीओबी को तैनात करना महंगा और दर्दनाक है, इसके द्वारा हल किए जाने वाले कोड और समस्याओं की मात्रा इतनी है कि कोई भी इसे अपने दिमाग में नहीं डाल सकता है। सामान्य तौर पर, इसे सरल बनाने के कई कारण हैं।

वापसी प्रक्रिया

प्रारंभ में, दो प्रणालियाँ इस प्रक्रिया में शामिल हैं: बीओबी और भुगतान। अब दो और दिखाई देते हैं:

• राजकोषीयकरण सेवा, जो राजकोषीयकरण और बाहरी सेवाओं के साथ संचार की समस्याओं का ध्यान रखेगी।
• रिफंड टूल, जिसमें बस नए एक्सचेंज शामिल हैं ताकि बीओबी को बढ़ाया न जाए।

अब प्रक्रिया इस प्रकार दिखती है:

1. बीओबी को रिफंड के लिए अनुरोध प्राप्त होता है।
2. बीओबी इस रिफंड टूल के बारे में बात करता है।
3. रिफंड टूल भुगतान को बताता है: "पैसे लौटाएं।"
4. भुगतान से पैसा वापस आ जाता है.
5. रिफंड टूल और बीओबी स्थितियों को एक-दूसरे के साथ सिंक्रनाइज़ करते हैं, क्योंकि फिलहाल उन दोनों को इसकी आवश्यकता है। हम अभी तक पूरी तरह से रिफंड टूल पर स्विच करने के लिए तैयार नहीं हैं, क्योंकि बीओबी के पास यूआई, लेखांकन के लिए रिपोर्ट और सामान्य तौर पर बहुत सारा डेटा है जिसे इतनी आसानी से स्थानांतरित नहीं किया जा सकता है। आपको दो कुर्सियों पर बैठना होगा.
6. राजकोषीयकरण का अनुरोध दूर हो जाता है।

परिणामस्वरूप, हमने काफ्का पर एक प्रकार की इवेंट बस बनाई - इवेंट-बस, जिस पर सब कुछ शुरू हुआ। हुर्रे, अब हमारे पास विफलता का एक ही बिंदु है (व्यंग्य)।

फायदे और नुकसान बिल्कुल स्पष्ट हैं। हमने एक बस बनाई, जिसका मतलब है कि अब सभी सेवाएं इस पर निर्भर हैं। यह डिज़ाइन को सरल बनाता है, लेकिन सिस्टम में विफलता का एक बिंदु प्रस्तुत करता है। काफ्का क्रैश हो जाएगा, प्रक्रिया रुक जाएगी।

इवेंट-संचालित एपीआई क्या है?

इस प्रश्न का एक अच्छा उत्तर मार्टिन फाउलर की रिपोर्ट (GOTO 2017) में है "घटना-संचालित वास्तुकला के कई अर्थ".

संक्षेप में हमने क्या किया:

1. के माध्यम से सभी अतुल्यकालिक एक्सचेंजों को समाप्त करें घटनाओं का भंडारण. प्रत्येक इच्छुक उपभोक्ता को नेटवर्क पर स्थिति परिवर्तन के बारे में सूचित करने के बजाय, हम एक केंद्रीकृत भंडारण में स्थिति परिवर्तन के बारे में एक घटना लिखते हैं, और विषय में रुचि रखने वाले उपभोक्ता वहां से दिखाई देने वाली हर चीज को पढ़ते हैं।
2. इस मामले में घटना एक अधिसूचना है (सूचनाएं) कि कहीं कुछ बदल गया है। उदाहरण के लिए, ऑर्डर की स्थिति बदल गई है. एक उपभोक्ता जो स्थिति परिवर्तन के साथ जुड़े कुछ डेटा में रुचि रखता है जो अधिसूचना में शामिल नहीं है, वह स्वयं इसकी स्थिति का पता लगा सकता है।
3. अधिकतम विकल्प पूर्ण ईवेंट सोर्सिंग है, राज्य स्थानांतरण, किस घटना में प्रसंस्करण के लिए आवश्यक सभी जानकारी शामिल है: यह कहां से आई और किस स्थिति में गई, डेटा वास्तव में कैसे बदल गया, आदि। एकमात्र प्रश्न व्यवहार्यता और जानकारी की मात्रा है जिसे आप संग्रहीत कर सकते हैं।

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

धनवापसी उपकरण सेवा लोड नहीं, तो काफ्का में जरूरत से ज्यादा कलम का स्वाद है। मुझे नहीं लगता कि यदि रिफंड सेवा एक उच्च-लोड परियोजना बन जाती, तो व्यवसाय खुश होता।

Async एक्सचेंज AS IS है

अतुल्यकालिक एक्सचेंजों के लिए, PHP विभाग आमतौर पर RabbitMQ का उपयोग करता है। हमने अनुरोध के लिए डेटा एकत्र किया, उसे एक कतार में रखा, और उसी सेवा के उपभोक्ता ने इसे पढ़ा और भेजा (या नहीं भेजा)। एपीआई के लिए, लैमोडा सक्रिय रूप से स्वैगर का उपयोग करता है। हम एक एपीआई डिज़ाइन करते हैं, स्वैगर में इसका वर्णन करते हैं, और क्लाइंट और सर्वर कोड उत्पन्न करते हैं। हम थोड़े उन्नत JSON RPC 2.0 का भी उपयोग करते हैं।

कुछ स्थानों पर ईएसबी बसों का उपयोग किया जाता है, कुछ एक्टिवएमक्यू पर रहते हैं, लेकिन, सामान्य तौर पर, रैबिटएमक्यू - मानक.

Async एक्सचेंज TO BE

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

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

यह विडम्बना है कि ऐसे सुखद मामले में भी, जब लगभग समान व्यवसाय, ज़ालैंडो है, जिसने लगभग समान समाधान बनाया है, हम इसका प्रभावी ढंग से उपयोग नहीं कर सकते हैं।

लॉन्च के समय वास्तुशिल्प पैटर्न इस प्रकार है: हम सीधे काफ्का से पढ़ते हैं, लेकिन केवल इवेंट-बस के माध्यम से लिखते हैं। काफ्का में पढ़ने के लिए बहुत कुछ तैयार है: दलाल, बैलेंसर, और यह कमोबेश क्षैतिज स्केलिंग के लिए तैयार है, मैं इसे रखना चाहता था। हम एक गेटवे उर्फ ​​इवेंट्स-बस के माध्यम से रिकॉर्डिंग पूरी करना चाहते थे, और यहाँ क्यों है।

घटनाएँ-बस

या एक इवेंट बस. यह बस एक स्टेटलेस http गेटवे है, जो कई महत्वपूर्ण भूमिकाएँ निभाता है:

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

क्यों

हम एक बड़ी कंपनी में सुव्यवस्थित प्रक्रिया के साथ काम करते हैं। कुछ भी क्यों बदलें? यह एक प्रयोग है, और हमें कई लाभ मिलने की उम्मीद है।

1:n+1 एक्सचेंज (एक से अनेक)

काफ्का नए उपभोक्ताओं को एपीआई से जोड़ना बहुत आसान बनाता है।

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

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

हमारी एक एकीकृत अधिसूचना सेवा बनाने की योजना है जो ग्राहक को उसके ऑर्डर/रिटर्न से संबंधित समाचारों के बारे में सूचित करेगी। अब यह जिम्मेदारी प्रणालियों के बीच फैल गई है। हमारे लिए अधिसूचना सेवा को काफ्का से प्रासंगिक जानकारी पकड़ना और उस पर प्रतिक्रिया देना (और अन्य प्रणालियों में इन सूचनाओं को अक्षम करना) सिखाना पर्याप्त होगा। किसी नए प्रत्यक्ष आदान-प्रदान की आवश्यकता नहीं होगी.

डेटा पर ही आधारित

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

प्रतिकृति लॉग

संदेश पढ़ने के बाद गायब नहीं होते, जैसा कि RabbitMQ में होता है। जब किसी ईवेंट में प्रसंस्करण के लिए पर्याप्त जानकारी होती है, तो हमारे पास ऑब्जेक्ट में हाल के परिवर्तनों का इतिहास होता है, और, यदि वांछित हो, तो इन परिवर्तनों को लागू करने की क्षमता होती है।

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

इसके बाद, जो लोग काफ्का से परिचित नहीं हैं, उनके लिए दस्तावेज़ीकरण का एक छोटा सा पुनर्कथन (चित्र भी दस्तावेज़ीकरण से है)

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

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

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

इवेंट आवश्यकताएँ:

• डेटा पूर्णता. मैं चाहूंगा कि इवेंट में पर्याप्त डेटा हो ताकि इसे संसाधित किया जा सके।

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

लमोडा में काफ्का

हमारे पास तीन काफ्का संस्थापन हैं:

1. लॉग;
2. अनुसंधान एवं विकास;
3. घटनाएँ-बस।

आज हम आखिरी बिंदु के बारे में ही बात कर रहे हैं. इवेंट-बस में, हमारे पास बहुत बड़े इंस्टॉलेशन नहीं हैं - 3 ब्रोकर (सर्वर) और केवल 27 विषय। एक नियम के रूप में, एक विषय एक प्रक्रिया है। लेकिन यह एक सूक्ष्म बिंदु है, और अब हम इस पर बात करेंगे।

ऊपर आरपीएस ग्राफ है. रिफंड प्रक्रिया को फ़िरोज़ा रेखा (हाँ, एक्स अक्ष पर एक) के साथ चिह्नित किया गया है, और गुलाबी रेखा सामग्री अद्यतन प्रक्रिया है।

लैमोडा कैटलॉग में लाखों उत्पाद शामिल हैं, और डेटा हर समय अपडेट किया जाता है। कुछ संग्रह फैशन से बाहर हो जाते हैं, उनके स्थान पर नए संग्रह जारी किए जाते हैं, और नए मॉडल लगातार कैटलॉग में दिखाई देते रहते हैं। हम यह अनुमान लगाने की कोशिश करते हैं कि कल हमारे ग्राहकों के लिए क्या दिलचस्प होगा, इसलिए हम लगातार नई चीजें खरीदते हैं, उनकी तस्वीरें लेते हैं और डिस्प्ले केस को अपडेट करते हैं।

गुलाबी चोटियाँ उत्पाद अद्यतन हैं, अर्थात उत्पादों में परिवर्तन। यह देखा जा सकता है कि लोगों ने तस्वीरें लीं, तस्वीरें लीं और फिर दोबारा! - घटनाओं का एक पैकेट लोड किया गया।

लैमोडा इवेंट्स मामलों का उपयोग करते हैं

हम निम्नलिखित कार्यों के लिए निर्मित आर्किटेक्चर का उपयोग करते हैं:

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

अब पिछले छह महीनों में हुई बड़ी उछालों और दिलचस्प खोजों के बारे में अधिक दिलचस्प हिस्सा।

डिज़ाइन की समस्याएँ

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

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

आकड़ों का प्रवाह

काफ्का के मामले में, डेटा प्रवाह को व्यवस्थित करने का प्रश्न उठता है। इस कार्य में कई बिंदुओं के आधार पर एक रणनीति चुनना शामिल है; आइए उन सभी पर गौर करें।

एक ही विषय में या अलग-अलग में?

हमारे पास एक ईवेंट विशिष्टता है. बीओबी में हम लिखते हैं कि इस तरह के ऑर्डर को वितरित करने की आवश्यकता है, और इंगित करें: ऑर्डर संख्या, इसकी संरचना, कुछ एसकेयू और बार कोड, आदि। जब माल गोदाम में पहुंचेगा, तो डिलीवरी स्टेटस, टाइमस्टैम्प और वह सब कुछ प्राप्त करने में सक्षम होगी जो आवश्यक है। लेकिन फिर हम बीओबी में इस डेटा पर अपडेट प्राप्त करना चाहते हैं। हमारे पास डिलीवरी से डेटा प्राप्त करने की एक विपरीत प्रक्रिया है। क्या यह वही घटना है? या क्या यह एक अलग आदान-प्रदान है जो अपने स्वयं के विषय का हकदार है?

सबसे अधिक संभावना है, वे बहुत समान होंगे, और एक विषय बनाने का प्रलोभन निराधार नहीं है, क्योंकि एक अलग विषय का अर्थ है अलग उपभोक्ता, अलग कॉन्फ़िगरेशन, इन सभी की एक अलग पीढ़ी। लेकिन तथ्य नहीं.

नया क्षेत्र या नया आयोजन?

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

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

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

रिफंड के मामले में हम आधे साल में इवेंट के मौके पर पहुंचे। हमारे पास रिफंड अपडेट नामक एक मेटा-इवेंट था, जिसमें एक प्रकार का फ़ील्ड था जो बताता था कि यह अपडेट वास्तव में क्या था। इस वजह से, हमारे पास सत्यापनकर्ताओं के साथ "अद्भुत" स्विच थे जिन्होंने हमें बताया कि इस घटना को इस प्रकार से कैसे सत्यापित किया जाए।

घटना संस्करण

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

विभाजनों के पढ़ने के क्रम की गारंटी

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

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

काफ्का उन्हें कैसे विभाजित करता है? प्रत्येक संदेश में एक मुख्य भाग (जिसमें हम JSON संग्रहीत करते हैं) और एक कुंजी होती है। आप इस कुंजी में एक हैश फ़ंक्शन संलग्न कर सकते हैं, जो यह निर्धारित करेगा कि संदेश किस विभाजन में जाएगा।

रिफंड के हमारे मामले में, यह महत्वपूर्ण है, अगर हम दो विभाजन लेते हैं, तो एक मौका है कि एक समानांतर उपभोक्ता पहले से पहले दूसरी घटना को संसाधित करेगा और परेशानी होगी। हैश फ़ंक्शन यह सुनिश्चित करता है कि समान कुंजी वाले संदेश समान विभाजन में समाप्त हों।

घटनाएँ बनाम आदेश

यह एक और समस्या है जिसका हमें सामना करना पड़ा। घटना एक निश्चित घटना है: हम कहते हैं कि कहीं कुछ हुआ (कुछ_हुआ), उदाहरण के लिए, कोई आइटम रद्द कर दिया गया या धनवापसी हुई। यदि कोई इन घटनाओं को सुनता है, तो "आइटम रद्द" के अनुसार, रिफंड इकाई बनाई जाएगी, और सेटअप में कहीं "रिफंड हुआ" लिखा जाएगा।

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

एक ओर, यह सुझाव देता है कि ईवेंट का उपयोग कैसे किया जाएगा। दूसरी ओर, यह किसी सामान्य घटना के नाम जैसा बहुत कम लगता है। इसके अलावा, यह do_something कमांड से ज्यादा दूर नहीं है। लेकिन आपको इसकी कोई गारंटी नहीं है कि किसी ने इस घटना को पढ़ा है; और यदि आपने इसे पढ़ा, तो आपने इसे सफलतापूर्वक पढ़ा; और यदि आपने इसे सफलतापूर्वक पढ़ा, तो आपने कुछ किया, और वह कुछ सफल हुआ। जिस क्षण कोई घटना कुछ करने लायक हो जाती है, प्रतिक्रिया आवश्यक हो जाती है, और यह एक समस्या है।

RabbitMQ में एसिंक्रोनस एक्सचेंज में, जब आप संदेश पढ़ते हैं, http पर जाते हैं, तो आपके पास एक प्रतिक्रिया होती है - कम से कम यह कि संदेश प्राप्त हो गया था। जब आप काफ्का को लिखते हैं, तो एक संदेश होता है कि आपने काफ्का को लिखा था, लेकिन आप इस बारे में कुछ नहीं जानते कि इसे कैसे संसाधित किया गया था।

इसलिए, हमारे मामले में, हमें एक प्रतिक्रिया घटना शुरू करनी थी और निगरानी स्थापित करनी थी ताकि यदि इतनी सारी घटनाएं भेजी गईं, तो इतने समय के बाद उतनी ही संख्या में प्रतिक्रिया घटनाएं आनी चाहिए। अगर ऐसा नहीं हुआ तो लगता है कि कुछ गलत हो गया है.' उदाहरण के लिए, यदि हमने "आइटम_रेडी_टू_रिफंड" ईवेंट भेजा है, तो हम उम्मीद करते हैं कि रिफंड बनाया जाएगा, ग्राहक को पैसा वापस कर दिया जाएगा, और "मनी_रिफंडेड" ईवेंट हमें भेजा जाएगा। लेकिन यह निश्चित नहीं है, इसलिए निगरानी की जरूरत है.

बारीकियों

एक बिल्कुल स्पष्ट समस्या है: यदि आप किसी विषय को क्रमबद्ध रूप से पढ़ते हैं, और आपके पास कुछ बुरा संदेश है, तो उपभोक्ता निराश हो जाएगा, और आप आगे नहीं बढ़ेंगे। आप की जरूरत है सभी उपभोक्ताओं को रोकें, पढ़ना जारी रखने के लिए आगे ऑफसेट प्रतिबद्ध करें।

हम इसके बारे में जानते थे, हमने इस पर भरोसा किया और फिर भी यह हुआ। और ऐसा इसलिए हुआ क्योंकि इवेंट इवेंट-बस के दृष्टिकोण से मान्य था, इवेंट एप्लिकेशन वैलिडेटर के दृष्टिकोण से मान्य था, लेकिन यह PostgreSQL के दृष्टिकोण से मान्य नहीं था, क्योंकि हमारे सिस्टम में MySQL UNSIGNED INT के साथ सिस्टम में सिर्फ INT के साथ PostgreSQL था। उसका आकार थोड़ा छोटा है, और आईडी फिट नहीं बैठती। एक अपवाद के साथ सिम्फनी की मृत्यु हो गई। बेशक, हमने अपवाद को पकड़ लिया क्योंकि हम इस पर भरोसा करते थे, और यह ऑफसेट करने जा रहे थे, लेकिन इससे पहले हम समस्या काउंटर को बढ़ाना चाहते थे, क्योंकि संदेश असफल रूप से संसाधित हुआ था। इस प्रोजेक्ट में काउंटर भी डेटाबेस में हैं, और सिम्फनी ने पहले ही डेटाबेस के साथ संचार बंद कर दिया है, और दूसरे अपवाद ने ऑफसेट करने का मौका दिए बिना पूरी प्रक्रिया को समाप्त कर दिया है।

सेवा कुछ समय के लिए बंद हो गई - सौभाग्य से, काफ्का के साथ यह इतना बुरा नहीं है, क्योंकि संदेश बने रहते हैं। जब काम बहाल हो जाए, तो आप उन्हें पढ़ना समाप्त कर सकते हैं। यह आरामदायक है।

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

एक और बारीकियाँ - प्रतिकृति लॉग बनाम rdkafka.so - हमारे प्रोजेक्ट की बारीकियों से संबंधित है। हम PHP का उपयोग करते हैं, और PHP में, एक नियम के रूप में, सभी पुस्तकालय rdkafka.so रिपॉजिटरी के माध्यम से काफ्का के साथ संचार करते हैं, और फिर किसी प्रकार का आवरण होता है। हो सकता है कि ये हमारी व्यक्तिगत कठिनाइयाँ हों, लेकिन यह पता चला कि जो हम पहले ही पढ़ चुके हैं उसके एक अंश को दोबारा पढ़ना इतना आसान नहीं है। सामान्य तौर पर, सॉफ़्टवेयर समस्याएँ थीं।

विभाजन के साथ काम करने की बारीकियों पर लौटते हुए, यह सीधे दस्तावेज़ में लिखा गया है उपभोक्ता >=विषय विभाजन. लेकिन मुझे इसके बारे में जितना मैं चाहता था उससे बहुत बाद में पता चला। यदि आप स्केल करना चाहते हैं और आपके पास दो उपभोक्ता हैं, तो आपको कम से कम दो विभाजनों की आवश्यकता होगी। यानी, यदि आपके पास एक विभाजन था जिसमें 20 हजार संदेश जमा हो गए थे, और आपने एक नया विभाजन किया था, तो संदेशों की संख्या जल्द ही बराबर नहीं होगी। इसलिए, दो समानांतर उपभोक्ता रखने के लिए, आपको विभाजन से निपटने की आवश्यकता है।

निगरानी

मुझे लगता है कि जिस तरह से हम इसकी निगरानी करेंगे, उससे यह और भी स्पष्ट हो जाएगा कि मौजूदा दृष्टिकोण में क्या समस्याएं हैं।

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

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

मैंने पहले ही उपभोक्ता-समूह अंतराल का उल्लेख किया है। मोटे तौर पर कहें तो यह अपठित संदेशों की संख्या है। सामान्य तौर पर, हमारे उपभोक्ता तेजी से काम करते हैं, इसलिए अंतराल आमतौर पर 0 होता है, लेकिन कभी-कभी अल्पकालिक शिखर हो सकता है। काफ्का इसे बॉक्स से बाहर कर सकता है, लेकिन आपको एक निश्चित अंतराल निर्धारित करने की आवश्यकता है।

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

एपीआई प्रतिक्रिया इस तरह दिखती है। यहां समूह है बॉब-लाइव-फीफा, पार्टीशन रिफंड.अपडेट.वी1, स्टेटस ओके, लैग 0 - अंतिम अंतिम ऑफसेट इत्यादि।

निगरानी SLA पर अपडेट किया गया (अटक गया) मैंने पहले ही उल्लेख किया है. उदाहरण के लिए, उत्पाद इस स्थिति में बदल गया है कि वह वापसी के लिए तैयार है। हम क्रॉन स्थापित करते हैं, जो कहता है कि यदि 5 मिनट में यह वस्तु रिफंड के लिए नहीं गई है (हम भुगतान प्रणालियों के माध्यम से बहुत जल्दी पैसा लौटाते हैं), तो निश्चित रूप से कुछ गलत हुआ है, और यह निश्चित रूप से समर्थन का मामला है। इसलिए, हम बस क्रॉन लेते हैं, जो ऐसी चीज़ों को पढ़ता है, और यदि वे 0 से अधिक हैं, तो यह एक अलर्ट भेजता है।

संक्षेप में, घटनाओं का उपयोग करना तब सुविधाजनक होता है जब:

• कई प्रणालियों को जानकारी की आवश्यकता होती है;
• प्रसंस्करण का परिणाम महत्वपूर्ण नहीं है;
• कुछ कार्यक्रम या छोटे आयोजन होते हैं।

ऐसा लगता है कि लेख में एक बहुत ही विशिष्ट विषय है - काफ्का पर अतुल्यकालिक एपीआई, लेकिन इसके संबंध में मैं एक साथ कई चीजों की सिफारिश करना चाहूंगा।
पहला, अगला HighLoad ++ हमें नवंबर तक इंतजार करना होगा; अप्रैल में सेंट पीटर्सबर्ग संस्करण होगा, और जून में हम नोवोसिबिर्स्क में उच्च भार के बारे में बात करेंगे।
दूसरे, रिपोर्ट के लेखक, सर्गेई ज़ैका, ज्ञान प्रबंधन पर हमारे नए सम्मेलन की कार्यक्रम समिति के सदस्य हैं नॉलेजकॉन्फ. सम्मेलन एक दिवसीय है, 26 अप्रैल को होगा, लेकिन इसका कार्यक्रम बहुत सघन है.
और यह मई में होगा पीएचपी रूस и आरआईटी++ (DevOpsConf के साथ) - आप वहां अपना विषय भी प्रस्तावित कर सकते हैं, अपने अनुभव के बारे में बात कर सकते हैं और अपने स्टफ्ड कोन्स के बारे में शिकायत कर सकते हैं।

स्रोत: www.habr.com