Kafka मा एक एसिन्क्रोनस API को साथ फिर्ता उपकरण सेवा को विकास मा अनुभव

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

तर यसको मतलब यो होइन कि तपाईं अतिरिक्त लाभहरूमा भरोसा गर्न सक्नुहुन्न। सर्गेई जाइकाले तपाईंलाई काफ्का (थोरै)। त्यहाँ निश्चित रूपमा ठूला शटहरू र चाखलाग्दो खोजहरूको बारेमा कुरा हुनेछ - प्रयोग तिनीहरू बिना गर्न सक्दैन।

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

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

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

घटना-संचालित API को साथ फिर्ता उपकरण

घटना-संचालित शब्द एकदम ह्याकनी गरिएको छ; अलि अगाडि हामी यसको अर्थ के हो भनेर थप विस्तारमा परिभाषित गर्नेछौं। म काफ्कामा घटना-संचालित API दृष्टिकोण प्रयास गर्ने निर्णय गरेको सन्दर्भबाट सुरु गर्नेछु।

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

तर ऐनमा भएको परिवर्तनका कारण फिर्ती झन् जटिल बन्दै गएको छ र त्यसको लागि छुट्टै माइक्रोसर्भिस लागू गर्नुपर्‍यो ।

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

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

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

BOB सँग धेरै धेरै विनिमयहरू पनि छन्: भुक्तानी प्रणाली, डेलिभरी प्रणाली, सूचना प्रणाली, आदि।

प्राविधिक रूपमा BOB हो:

• ~150k कोड लाइनहरू + ~100k परीक्षण लाइनहरू;
• php7.2 + Zend 1 र Symfony अवयव 3;
• >100 API र ~50 आउटबाउन्ड एकीकरण;
• आफ्नो व्यापार तर्क संग 4 देशहरु।

BOB को तैनाती महँगो र पीडादायी छ, यसले समाधान गर्ने कोड र समस्याहरूको मात्रा यस्तो छ कि कसैले पनि यो सबै आफ्नो टाउकोमा राख्न सक्दैन। सामान्यतया, यसलाई सरल बनाउन धेरै कारणहरू छन्।

फिर्ता प्रक्रिया

सुरुमा, दुई प्रणालीहरू प्रक्रियामा संलग्न छन्: BOB र भुक्तानी। अब दुई थप देखिन्छन्:

• वित्तीयकरण सेवा, जसले वित्तीयकरण र बाह्य सेवाहरूसँग सञ्चारमा समस्याहरूको हेरचाह गर्नेछ।
• रकम फिर्ता गर्ने उपकरण, जसमा नयाँ एक्सचेन्जहरू समावेश हुन्छन् ताकि BOB लाई फुलाउन नदिनुहोस्।

अब प्रक्रिया यस्तो देखिन्छ:

1. BOB ले फिर्ताको लागि अनुरोध प्राप्त गर्दछ।
2. BOB यस रिफन्ड उपकरणको बारेमा कुरा गर्छ।
3. फिर्ता गर्ने उपकरणले भुक्तानीलाई भन्छ: "पैसा फिर्ता गर्नुहोस्।"
4. भुक्तानीले पैसा फिर्ता गर्छ।
5. रिफन्ड टूल र BOB ले एकअर्कासँग स्थितिहरू सिङ्क्रोनाइज गर्दछ, किनकि अहिलेको लागि तिनीहरू दुवैलाई यसको आवश्यकता छ। BOB सँग UI, लेखाका लागि रिपोर्टहरू, र सामान्यतया धेरै डाटाहरू छन् जुन यति सजिलै हस्तान्तरण गर्न सकिँदैन। दुईवटा कुर्सीमा बस्नुपर्छ ।
6. वित्तीयकरणको लागि अनुरोध हट्छ।

नतिजाको रूपमा, हामीले काफ्कामा एक प्रकारको कार्यक्रम बस बनायौं - घटना-बस, जसमा सबै कुरा सुरु भयो। हुर्रे, अब हामीसँग असफलताको एकल बिन्दु छ (व्यंग्य)।

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

घटना-संचालित API के हो

यस प्रश्नको राम्रो जवाफ मार्टिन फाउलर (GOTO 2017) द्वारा रिपोर्टमा छ। "घटना-संचालित वास्तुकला को धेरै अर्थ".

संक्षेपमा हामीले के गर्यौं:

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

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

रिफन्ड उपकरण सेवा लोड गरिएको छैनत्यसैले काफ्कामा आवश्यकताभन्दा पनि कलमको स्वाद बढी छ । मलाई लाग्दैन कि यदि फिर्ता सेवा उच्च-लोड परियोजना भयो भने, व्यवसाय खुसी हुनेछ।

Async विनिमय AS IS

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

केही स्थानहरूमा ESB बसहरू प्रयोग गरिन्छ, केही सक्रियMQ मा बस्छन्, तर, सामान्यतया, RabbitMQ - मानक.

Async विनिमय TO BE

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

काफ्कामा घटना-सोर्सिङ एउटा सामान्य कुरा हो। त्यहाँ काफ्का कन्फ्लुएन्टको मुख्य उद्यम संस्करणबाट समाधान छ, त्यहाँ छ नकडी, हाम्रो डोमेन भाइहरू Zalando बाट एक समाधान। हाम्रो भ्यानिला काफ्काबाट सुरु गर्न प्रेरणा - यसको मतलब समाधानलाई सित्तैमा छाड्नु हो जबसम्म हामीले अन्ततः यसलाई जताततै प्रयोग गर्ने कि गर्दैनौं भन्ने निर्णय नगर्ने, र आफूलाई चालबाजी र सुधारको लागि ठाउँ छोड्ने: हामी हाम्रो लागि समर्थन चाहन्छौं। JSON RPC 2.0, दुई भाषाहरूको लागि जेनरेटरहरू र अरू के हेरौं।

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

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

घटनाक्रम-बस

वा घटना बस। यो केवल एक स्टेटलेस http गेटवे हो, जसले धेरै महत्त्वपूर्ण भूमिकाहरू लिन्छ:

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

किन

हामी सुव्यवस्थित प्रक्रियाको साथ ठूलो कम्पनीमा काम गर्छौं। किन केहि परिवर्तन? यो एक प्रयोग हो, र हामी धेरै लाभहरू कटनी आशा गर्छौं।

1:n+1 विनिमय (एक देखि धेरै)

काफ्काले नयाँ उपभोक्ताहरूलाई API मा जडान गर्न धेरै सजिलो बनाउँछ।

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

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

हामीसँग एक एकीकृत सूचना सेवा सिर्जना गर्ने योजना छ जसले ग्राहकलाई उसको अर्डर/रिटर्न सम्बन्धी समाचारहरूको बारेमा सूचित गर्नेछ। अब यो जिम्मेवारी प्रणालीहरू बीच फैलिएको छ। काफ्काबाट सान्दर्भिक जानकारी लिन र त्यसलाई प्रतिक्रिया दिन (र अन्य प्रणालीहरूमा यी सूचनाहरू असक्षम पार्न) सूचना सेवालाई सिकाउन हामीलाई पर्याप्त हुनेछ। कुनै नयाँ प्रत्यक्ष विनिमय आवश्यक पर्दैन।

डाटा चालित

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

प्रतिकृति लग

RabbitMQ मा जस्तै सन्देशहरू पढिसकेपछि हराउँदैनन्। जब घटनामा प्रशोधनका लागि पर्याप्त जानकारी हुन्छ, हामीसँग वस्तुमा हालैका परिवर्तनहरूको इतिहास हुन्छ, र यदि चाहियो भने, यी परिवर्तनहरू लागू गर्ने क्षमता हुन्छ।

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

अर्को, काफ्कासँग परिचित नभएकाहरूका लागि कागजातको थोरै रिटेलिङ (तस्विर पनि कागजातबाट हो)

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

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

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

घटना आवश्यकताहरु:

• डाटा पूर्णता। म घटनासँग पर्याप्त डेटा भएको चाहन्छु ताकि यसलाई प्रशोधन गर्न सकोस्।

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

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

हामीसँग तीन काफ्का स्थापनाहरू छन्:

1. लगहरू;
2. R&D;
3. घटनाक्रम-बस।

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

माथि आरपीएस ग्राफ छ। फिर्ता गर्ने प्रक्रियालाई फिरोज रेखा (हो, X अक्षमा रहेको) चिन्ह लगाइएको छ, र गुलाबी रेखा सामग्री अद्यावधिक प्रक्रिया हो।

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

गुलाबी चुचुराहरू उत्पादन अद्यावधिकहरू हुन्, त्यो हो, उत्पादनहरूमा परिवर्तनहरू। केटाहरूले तस्बिर खिचे, तस्बिर खिचे, र फेरि फेरि! — घटनाहरूको प्याक लोड गरियो।

Lamoda घटनाक्रम प्रयोग केसहरू

हामी निम्न कार्यहरूका लागि निर्माण गरिएको वास्तुकला प्रयोग गर्छौं:

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

अब ठूला बम्पहरू र चाखलाग्दो आविष्कारहरूको बारेमा थप चाखलाग्दो अंश जुन विगत छ महिनामा भएको छ।

डिजाइन समस्याहरू

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

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

डाटा स्ट्रिम

काफ्काको सन्दर्भमा, डाटा प्रवाह व्यवस्थित गर्ने प्रश्न उठ्छ। यो कार्यले धेरै बिन्दुहरूमा आधारित रणनीति छनोट समावेश गर्दछ; ती सबै मार्फत जाऔं।

एउटै विषयमा वा फरक विषयमा ?

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

सम्भवतः, तिनीहरू धेरै समान हुनेछन्, र एउटा विषय बनाउने प्रलोभन निराधार छैन, किनकि छुट्टै विषय भनेको अलग उपभोक्ताहरू, छुट्टै कन्फिगरेसनहरू, यी सबैको छुट्टै पुस्ता हो। तर तथ्य होइन ।

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

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

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

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

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

घटना संस्करण

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

विभाजनहरूको ग्यारेन्टी पढ्ने क्रम

काफ्का भित्रका विषयहरू विभाजनहरूमा विभाजित छन्। हामीले संस्था र विनिमयहरू डिजाइन गर्दा यो धेरै महत्त्वपूर्ण छैन, तर यसलाई कसरी उपभोग गर्ने र मापन गर्ने निर्णय गर्दा यो महत्त्वपूर्ण छ।

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

काफ्काले तिनीहरूलाई कसरी विभाजित गर्छन्? प्रत्येक सन्देशको मुख्य भाग (जसमा हामी JSON भण्डारण गर्छौं) र एउटा कुञ्जी हुन्छ। तपाईंले यो कुञ्जीमा ह्यास प्रकार्य संलग्न गर्न सक्नुहुन्छ, जसले सन्देश कुन विभाजनमा जानेछ भनेर निर्धारण गर्नेछ।

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

घटनाहरू बनाम आदेशहरू

यो हामीले सामना गरेको अर्को समस्या हो। घटना एक निश्चित घटना हो: हामी भन्छौं कि केहि कतै भयो (something_happened), उदाहरण को लागी, एक वस्तु रद्द भयो वा फिर्ता भयो। यदि कसैले यी घटनाहरू सुन्दछ भने, त्यसपछि "वस्तु रद्द गरियो" अनुसार, फिर्ता संस्था सिर्जना गरिनेछ, र सेटअपहरूमा "फिर्ती आयो" लेखिनेछ।

तर सामान्यतया, जब तपाइँ घटनाहरू डिजाइन गर्नुहुन्छ, तपाइँ तिनीहरूलाई व्यर्थमा लेख्न चाहनुहुन्न - तपाइँ यो तथ्यमा भरोसा गर्नुहुन्छ कि कसैले तिनीहरूलाई पढ्छ। त्यहाँ केहि_हुन्छ (item_canceled, refund_refunded), तर something_sould_be_done लेख्ने उच्च प्रलोभन छ। उदाहरणका लागि, वस्तु फिर्ता गर्न तयार छ।

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

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

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

नग्नता

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

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

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

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

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

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

निगरानी गर्दै

मलाई लाग्छ कि हामीले अनुगमन गर्ने तरिकाले अवस्थित दृष्टिकोणमा के समस्याहरू छन् भनेर अझ स्पष्ट हुनेछ।

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

थप रूपमा, तपाईंले उत्पादकले कसरी गरिरहेको छ, घटना-बसले सन्देशहरू प्राप्त गरेको छ, र उपभोक्ताले कसरी गरिरहेको छ भनेर निगरानी गर्न आवश्यक छ। उदाहरणका लागि, तलका चार्टहरूमा, फिर्ता गर्ने उपकरणले राम्रो काम गरिरहेको छ, तर BOB मा स्पष्ट रूपमा केही समस्याहरू छन् (नीलो चुचुराहरू)।

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

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

यो API प्रतिक्रिया जस्तो देखिन्छ। यहाँ छ समूह bob-live-fifa, partition refund.update.v1, स्थिति ठीक छ, lag 0 - अन्तिम अन्तिम अफसेट यस्तो र यस्तै।

निगरानी गर्दै update_at SLA (अडकिएको) मैले पहिले नै उल्लेख गरेको छु। उदाहरण को लागी, उत्पादन को स्थिति मा परिवर्तन भएको छ कि यो फिर्ता को लागी तयार छ। हामी क्रोन स्थापना गर्छौं, जसले भन्छ कि यदि 5 मिनेटमा यो वस्तु फिर्ताको लागि गएको छैन (हामी धेरै चाँडै भुक्तानी प्रणाली मार्फत पैसा फिर्ता गर्छौं), त्यसपछि निश्चित रूपमा केहि गलत भयो, र यो निश्चित रूपमा समर्थनको लागि मामला हो। त्यसकारण, हामी केवल क्रोन लिन्छौं, जसले त्यस्ता चीजहरू पढ्छ, र यदि तिनीहरू ० भन्दा ठूला छन् भने, यसले चेतावनी पठाउँछ।

संक्षेपमा, घटनाहरू प्रयोग गर्दा सुविधाजनक छ:

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

यस्तो देखिन्छ कि लेखमा एक धेरै विशिष्ट विषय छ - काफ्कामा एसिन्क्रोनस एपीआई, तर यसको सम्बन्धमा म एकैचोटि धेरै चीजहरू सिफारिस गर्न चाहन्छु।
पहिलो, अर्को हाईलोड++ हामीले नोभेम्बरसम्म पर्खनु पर्छ; अप्रिलमा त्यहाँ सेन्ट पीटर्सबर्ग संस्करण हुनेछ, र जुनमा हामी नोभोसिबिर्स्कमा उच्च भारको बारेमा कुरा गर्नेछौं।
दोस्रो, रिपोर्टका लेखक, सर्गेई जाइका, ज्ञान व्यवस्थापनमा हाम्रो नयाँ सम्मेलनको कार्यक्रम समितिका सदस्य हुन्। KnowledgeConf। सम्मेलन एकदिवसीय छ, अप्रिल २६ मा हुने छ तर यसको कार्यक्रम निकै तीव्र छ ।
र यो मे मा हुनेछ PHP रूस и RIT++ (DevOpsConf समावेश सहित) - तपाइँ त्यहाँ तपाइँको विषय पनि सुझाव दिन सक्नुहुन्छ, तपाइँको अनुभवको बारेमा कुरा गर्नुहोस् र तपाइँको भरिएका कोनहरूको बारेमा गुनासो गर्न सक्नुहुन्छ।

स्रोत: www.habr.com