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

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

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



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

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

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

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

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



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

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



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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

इस सवाल का एक अच्छा जवाब मार्टिन फॉवलर (जीओटीओ 2017) की रिपोर्ट में है "द इवनिंग द मीनिंग ऑफ इवेंट-ड्रिवेन आर्किटेक्चर" ।

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

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

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

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

Async विनिमय के रूप में है

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

यहां और वहां, एसब बसों का उपयोग किया जाता है, कोई सक्रिय एमक्यूक्यू पर रहता है, लेकिन सामान्य तौर पर, रैबिटएमक्यू मानक है ।

Async एक्सचेंज से बी.ई.

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

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

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

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

घटनाक्रम बस

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

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

क्यों

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

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

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

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

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



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

डेटा चालित

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

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

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

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



फिर प्रलेखन की थोड़ी सी वापसी, उन लोगों के लिए जो काफ्का से परिचित नहीं हैं (चित्र भी प्रलेखन से है)

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

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

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

घटना की आवश्यकताएँ:

• डेटा की पूर्णता। मैं चाहता हूं कि घटना में पर्याप्त डेटा था ताकि इसे संसाधित किया जा सके।

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

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

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

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

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



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

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

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

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

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

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

अब, अधिक दिलचस्प हिस्सा भरवां शंकु और दिलचस्प खोजों के बारे में है जो छह महीनों में हुए थे।

डिजाइन मुद्दों

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

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

डेटा स्ट्रीम

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

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

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

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

नया क्षेत्र या नई घटना?

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

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

— . , - , , , , . — . — , . JSON .

refunds . -, refund update, type, , update . «» , , type.

Kafka Avro , Confluent. . replication log, «». , , : , . , , , .

partitions

Kafka partitions. , , , .

Kafka . partition, . . , , , . , , , Kafka partition, Kafka — , .

Kafka ? ( JSON) key. -, , partition .

refunds , partition, , . - , partition.

Events vs commands

, . Event — : , - - (something_happened), , item refund. - , «item » refund , « refund» - .

, , — , - . something_happened (item_canceled, refund_refunded), something_should_be_done. , item .

, , . , . , do_something. , - ; , ; , -, - . , do_something, , .



RabbitMQ, , http, response — , . Kafka, , Kafka, , , .

, - , - . , , - . , «item_ready_to_refund», , refund , , «money_refunded». , .

बारीकियों

: , - , , . , offset , .

, , . , events-bus, , PostgreSQL, MySQL UNSIGNED INT, PostgreSQL INT. , Id . Symfony . , , , , offset, , . , Symfony , offset.

- — , Kafka , . . .

Kafka tooling offset. , — , , redeployments. Kafka tooling offset, .

— replication log vs rdkafka.so — . PHP, PHP, , , Kafka rdkafka.so, - . , , , - . , .

partitions, consumers >= topic partitions . , . , partitions. , partition, 20 , , . , , partitions.

, , , , .

, , , , , , . Kafka , . , .



, , , events-bus , . , Refund Tool , BOB - ( ).



consumer-group lag. , . , 0, . Kafka , .

Burrow , Kafka. API consumer-group , . Failed warning, , — , . , .



API. bob-live-fifa, partition refund.update.v1, , lag 0 — offset -.



updated_at SLA (stuck) . , , . Cron, , 5 refund ( ), - , . Cron, , 0, .

, , :

• ;
• ;
• .

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