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

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

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

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

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

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

ईवेंट-संचालित API के साथ रिफ़ंड टूल

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

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

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

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

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

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

बीओबी में भी बहुत सारे आदान-प्रदान हैं: भुगतान प्रणाली, वितरण, सूचनाएं, आदि।

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

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

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

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

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

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

अब प्रक्रिया इस प्रकार है:

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

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

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

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

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

संक्षेप में, हमने जो किया वह यह है:

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

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

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

एसिंक्रोनस एक्सचेंज AS IS

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

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

असिंक्रोनस एक्सचेंज होना चाहिए

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

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

यह विडम्बना है कि इस भाग्यशाली मामले में भी, जबकि लगभग इसी प्रकार का व्यवसाय, ज़ालैंडो, ने लगभग इसी प्रकार का निर्णय लिया था, हम इसका प्रभावी ढंग से उपयोग नहीं कर सकते।

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

इवेंट-बस

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

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

क्यों

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

1:n+1 आदान-प्रदान (एक से अनेक)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• डेटा की पूर्णता. मैं चाहता हूं कि इवेंट में प्रोसेस करने के लिए पर्याप्त डेटा हो।

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

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

हमारे पास तीन काफ़्का इंस्टॉलेशन हैं:

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

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

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

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

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

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

हम निम्नलिखित कार्यों के लिए निर्मित वास्तुकला का उपयोग करते हैं:

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

अब अधिक दिलचस्प बात यह है कि पिछले छह महीनों में क्या-क्या उतार-चढ़ाव आए हैं और क्या-क्या दिलचस्प खोजें हुई हैं।

डिज़ाइन संबंधी मुद्दे

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

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

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

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

एक विषय पर या अलग-अलग विषयों पर?

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

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

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

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

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

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

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

इवेंट संस्करण

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

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

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

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

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

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

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

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

लेकिन आम तौर पर, जब आप ईवेंट डिज़ाइन करते हैं, तो आप उन्हें व्यर्थ में लिखना नहीं चाहते - आप किसी के द्वारा उन्हें पढ़े जाने पर भरोसा करते हैं। something_should_be_done लिखने के बजाय something_happened (item_canceled, refund_refunded) लिखना आकर्षक लगता है। उदाहरण के लिए, item रिफंड किए जाने के लिए तैयार है।

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

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

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

बारीकियों

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

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

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

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

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

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

निगरानी

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

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

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

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

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

API प्रतिक्रिया कुछ इस तरह दिखती है। यहाँ समूह बॉब-लाइव-फ़ीफ़ा, विभाजन रिफंड.अपडेट.v1, स्थिति ओके, लैग 0 है - अंतिम अंतिम ऑफ़सेट ऐसा-ऐसा है।

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

संक्षेप में कहें तो, घटनाएँ तब उपयोगी होती हैं जब:

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

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

स्रोत: www.habr.com