घटना-प्रेरित कर्नेल

घटना चालित कर्नेल क्या है

इवेंट-ड्रिवेन कोर (EDC) वास्तुकला का "रीढ़" है, जिसमें व्यावसायिक तथ्यों को अपरिवर्तनीय घटनाओं के रूप में कैप्चर और वितरित किया जाता है, और बाकी कार्यक्षमता (पढ़ना, एकीकरण, कैश, सूचना) इन घटनाओं के प्रवाह पर बनाया जाता है। कर्नेल कमजोर कनेक्टिविटी और स्केलेबिलिटी प्रदान करते हुए इवेंट कॉन्ट्रैक्ट, डिलीवरी नियम और ऑर्डर/आइडेम्पोटेंसी इनवेरिएंट्स सेट करता है।

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

EDC लक्ष्य और गुण

तथ्यों का सत्य: प्रत्येक घटना "क्या हुआ" का एक अपरिवर्तनीय रिकॉर्ड है।

कमजोर कनेक्टिविटी: निर्माता उपभोक्ताओं को नहीं जानते हैं; सिस्टम विस्तार - ग्राहकों को जोड़ कर।

स्केलिंग: पार्टी/विषय, स्वतंत्र उपभोक्ताओं द्वारा क्षैतिज वृद्धि।

अवलोकन और ऑडिटिंग: एंड-टू-एंड पहचानकर्ता, प्रजनन योग्यता, प्रतिधारण और रीप्ले।

प्रबंधित विकास: स्कीमा संस्करण, संगतता, मूल्यह्रास।

वास्तुशिल्प घटक

1. बस/इवेंट ब्रोकर: काफ्का/एनएटीएस/पल्सर/एसएनएस + एसक्यूएस - चैनल, पार्टियां, प्रतिधारण।

2. स्कीमा रजिस्ट्री: संगतता और विकास के लिए JSON स्कीमा/एवरो/प्रोटोबुफ।

3. आउटबॉक्स/सीडीसी समोच्च: परमाणु तथ्य फिक्सिंग + "डबल राइट" के बिना प्रकाशन।

4. अनुमान/पढ़ें (CQRS): त्वरित प्रश्नों के लिए भौतिक दृश्य।

5. सागास/ऑर्केस्ट्रेशन: घटनाओं/टीमों के माध्यम से लंबे समय तक जीवित प्रक्रियाओं का समन्वय।

6. संवर्धन: व्यक्तिगत विषय '.enriched '/' .derived' without महत्वपूर्ण पथ को प्रभावित करते हैं।

7. अवलोकन: घटनाओं और लैग्स द्वारा ट्रेसिंग, लॉगिंग, मैट्रिक्स।

घटना मॉडल

घटना प्रकार

डोमेन इवेंट्स: बिजनेस फैक्ट्स ('भुगतान। अधिकृत ',' kyc। अनुमोदित ')।

एकीकरण घटनाएँ: बाहरी प्रणालियों (स्थिर, धीरे-धीरे बदलते) पर केंद्रित

डेटा कैप्चर बदलें (सीडीसी): रिकॉर्ड में तकनीकी परिवर्तन (प्रवासन/एकीकरण के लिए उपयोग)।

ऑडिट/टेलीमेट्री: अभिनेता कार्रवाई, सुरक्षा, एसएलए।

आवश्यक गुण (कोर)

json
{
"event_id": "uuid",
"event_type": "payment. authorized. v1",
"occurred_at": "2025-10-31T11:34:52Z",
"producer": "payments-service",
"subject": { "type": "payment", "id": "pay_123" },
"payload": { "amount": 1000, "currency": "EUR", "method": "card" },
"schema_version": 1,
"trace_id": "abc123",
"partition_key": "pay_123"
}

सिफारिशें: 'event _ id' वैश्विक रूप से अद्वितीय है, 'पार्टीशन _ कुंजी' इकाई के लिए क्रम निर्धारित करता है, 'ट्रेस _ आईडी' सहसंबंध प्रदान करता है।

डिलीवरी शब्दार्थ और पहचान

कम से कम एक बार (कई दलालों के लिए डिफ़ॉल्ट): उपभोक्ताओं को पहचानने की आवश्यकता होती है।

सबसे अधिक एक बार: केवल माध्यमिक टेलीमेट्री के लिए स्वीकार्य।

बिल्कुल एक बार: लेनदेन/पहचान कुंजी/पानी के डिब्बे (अधिक महंगे, एक अच्छे कारण की आवश्यकता) के माध्यम से प्रवाह और भंडारण स्तर पर प्राप्त किया।

उपभोक्ता पहचान पैटर्न

TTL ≥ विषय प्रतिधारण के साथ 'ईवेंट _ id '/' (event_id, consumer_id) द्वारा डीडअप तालिका।

सम्मिलित करने के बजाय अपसर्ट; 'अनुक्रम '/' hease _ at' द्वारा अनुमानों का संस्करण।

लेनदेन के भीतर लेनदेन: चिह्न "देखा" + राज्य परिवर्तन।

आदेश और विभाजन

पार्टी के भीतर गारंटीकृत आदेश।

'पार्टीशन _ key' चुनें ताकि एक ही समुच्चय इकाई की सभी घटनाएँ एक ही समूह में आएँ ('user _ id', 'payment _ id').

"हॉट कीज़" से बचें: यदि आपको लोड वितरित करने की आवश्यकता है तो नमक/उप-कुंजियों के साथ हैश करें।

योजनाएँ और विकास

एडिटिव-फर्स्ट: नए वैकल्पिक क्षेत्र, एक प्रमुख संस्करण के बिना बदलते प्रकार/शब्दार्थ पर

संगतता: स्कीमा रजिस्ट्री में बैकवर्ड/फॉरवर्ड; सीआई असंगत परिवर्तनों को अवरुद्ध करता है।

नामकरण: 'डोमेन। क्रिया। v {मेजर} '(' भुगतान। अधिकृत। v1 ')।

प्रवासन: जोड़े 'v1' and 'v2' in समानांतर प्रकाशित करें, आउटबॉक्स के माध्यम से दोहरे लेखन प्रदान करें, संक्रमण को शूट करें।

आउटबॉक्स и सीडीसी

आउटबॉक्स (ट्रांजेक्शनल सेवाओं के लिए अनुशंसित)

1. एक डेटाबेस लेनदेन में: डोमेन रिकॉर्ड और घटना को आउटबॉक्स में सहेजें।

2. पृष्ठभूमि प्रकाशक आउटबॉक्स पढ़ ता है, दलाल को प्रकाशित करता है, "भेजा गया" चिह्न।

3. गारंटी: फॉल में तथ्य का कोई "नुकसान" नहीं, कोई desynchronization नहीं।

सीडीसी (डाटा कैप्चर बदलें)

मौजूदा प्रणालियों/पलायन के लिए उपयुक्त; स्रोत - डीबी प्रतिकृति लॉग।

डोमेन घटनाओं में फ़िल्टरिंग/ट्रांसकोडिंग की आवश्यकता है (बाहर कच्चे टेबल का अनुवाद न करें)।

CQRS और अनुमान

कमांड स्थिति बदलते हैं (अक्सर तुल्यकालिक रूप से), घटनाएँ अनुमान बनाती हैं (अतुल्यकालिक रूप से)।

अनुमानों को ग्राहकों द्वारा अद्यतन प्रश्नों (खोज, सूची, रिपोर्ट) के लिए डिज़ाइन किया गया है।

अस्थायी desynchronization आदर्श है: एक स्थिर UX दिखाएं ("डेटा कुछ सेकंड में अपडेट किया जाएगा")।

सागास: प्रक्रिया समन्वय

ऑर्केस्ट्रेशन: एक समन्वयक कमांड भेजता है और घटनाओं का इंतजार करता है।

कोरियोग्राफी: प्रतिभागी एक-दूसरे की घटनाओं पर प्रतिक्रिया करते हैं (सरल, लेकिन अनुबंध में अनुशासन की आवश्यकता होती है)।

नियम: स्पष्ट मुआवजा और समय समाप्ति, दोहराए जाने योग्य कदम, पहचानने वाले हैंडलर।

अवलोकन क्षमता

ट्रेस/स्पैन: 'ट्रेस _ आईडी '/' स्पैन _ आईडी' को हेडर के माध्यम से ट्रेस करें जब घटनाएँ पैदा करें।

मेट्रिक्स: उपभोक्ता अंतराल, प्रकाशन/खपत दर, मृत-पत्र दर, डीडुप्लिकेशन शेयर।

DLQ/पार्किंग स्थल: असफल संदेश - अलर्ट के साथ एक अलग विषय के लिए; पुनर्संसाधन प्रदान करें।

सुरक्षा और अनुपालन

डेटा वर्गीकरण: कोर में केवल आवश्यक न्यूनतम पीआईआई/वित्तीय डेटा (रिवर्स पिरामिड मॉडल), विवरण - संवर्धन में शामिल हैं।

महत्वपूर्ण विशेषताओं का हस्ताक्षर/हैश, अखंडता नियंत्रण।

एन्क्रिप्शन इन-फ्लाइट और एट-रेस्ट, विषय/घाघ (IAM/ACL) द्वारा विभाजन अधिकार।

प्रतिधारण नीतियों और अधिकारों को भुलाया जाना चाहिए: प्रत्येक विषय के लिए स्पष्ट रूप से परि

निष्पादन और स्थिरता

Backpressure: उपभोक्ताओं की सीमित प्रतिस्पर्धा है, ब्रोकर के पास कोटा/सी

ओवरहेड को कम करने के लिए बैच और संपीड़न-समूह रिकॉर्ड।

अंतहीन प्रयासों के बजाय जिटर और डीएलक्यू के साथ रेट्राई।

पुनर्संतुलन-प्रतिरोध: ऑफसेट को लेन-देन/बाहरी रूप से स्टोर करें, स्नैपशॉट के साथ एक ठंडी शुरुआत को गति दें।

विशिष्ट घटना टेम्पलेट

भुगतान कोर

'भुगतान। आरंभ किया गया। v1 '→' भुगतान। अधिकृत। v1 '→' भुगतान। कब्जा कर लिया। v1 '→' भुगतान। बस गए। v1 '

इनकार: 'भुगतान। मना कर दिया। v1 ',' भुगतान। वापस लौटा दिया। v1 '

विभाजन: 'भुगतान _ id'

SLA: कोर लैग ≤ 2c p95; उपभोक्ता की पहचान अनिवार्य है।

CCM/सत्यापन

'kyc। शुरू किया। v1 '→' kyc। दस्तावेज़ प्राप्त v1 '→' kyc। अनुमोदित। v1 '/' kyc। अस्वीकार कर v1 '

पीआईआई - न्यूनतम; दस्तावेज़ विवरण - में 'kyc। समृद्ध। v1 'प्रतिबंधित पहुंच के साथ।

लेखा परीक्षा/सुरक्षा

'audit। रिकॉर्ड कि v1 'विशेषताओं के साथ' अभिनेता ',' विषय ',' क्रिया ',' hece _ at ',' ट्रेस _ id '।

निरंतर प्रतिधारण/संग्रह; संवर्धित अखंडता (WORM)

एंटीपैटर्न

फैट इवेंट: ओवरलोडेड पेलोड अनावश्यक रूप से, पीआईआई लीक।

घटनाओं के माध्यम से छिपा हुआ आरपीसी: तुल्यकालिक "यहाँ और अब" प्रतिक्रियाओं की प्रतीक्षा कर रहा है।

रॉ सीडीसी बाहर की ओर: डीबी स्कीमा से कनेक्टिविटी बंद करें।

उपभोक्ताओं में कोई पहचान नहीं: डबल्स से दोहरे दुष्प्रभाव होते हैं।

एक सामान्य विषय "सब कुछ के लिए": हितों का टकराव, समस्याग्रस्त क्रम, जटिल विकास।

चरण दर चरण EDC कार्यान्वयन

1. डोमेन मैपिंग: कुंजी समुच्चय और जीवनचक्र को हाइलाइट करें।

2. घटनाओं की सूची: नाम, अर्थ, अपरिवर्तनीय, आवश्यक क्षेत्र।

3. स्कीमा और रजिस्ट्री - एक प्रारूप चुनें, संगतता नियमों को सक्षम करें।

4. आउटबॉक्स/सीडीसी: प्रत्येक निर्माता के लिए, तथ्यों को प्रकाशित करने के लिए एक तंत्र को परिभाषित करें।

5. विभाजन: कुंजियाँ चुनें और गर्म कुंजी/पुनरावृत्ति का मूल्यांकन करें।

6. पहचान: डिडप्लिकेशन पैटर्न + उपभोक्ता लेनदेन।

7. अनुमान-परिभाषित भौतिक मॉडल और एसएलए अपडेट करें।

8. अवलोकन: ट्रेसिंग, लैग्स, डीएलक्यू, अलर्ट।

9. सुरक्षा/PII: डेटा वर्गीकरण, एन्क्रिप्शन, एसीएल।

10. एवोल्यूशन के लिए गाइड: संस्करण नीति, पदावनत, प्रवासन के लिए दोहरी लिखना।

उत्पादन जांच सूची

• प्रत्येक घटना में 'event _ id', 'trace _ id', 'hesed _ at', 'partion _ key' होता है।
• रजिस्ट्री में योजनाएं, संगतता जांच सक्षम।
• उपभोक्ता पहचान लागू और परीक्षण किया।
• DLQ/पार्किंग स्थल और अलर्ट प्रकाशित/उपभोग त्रुटियों के लिए कॉन्फ़िगर किए गए हैं।
• अनुमानों को एक स्वीकार्य समय के साथ लॉग (रीप्ले) से फिर से बनाया जाता है।
• पीआईआई तक सीमित पहुंच; कर्नेल में न्यूनतम पेलोड है।
• लैग्स/डिलीवरी द्वारा एसएलए को डैशबोर्ड पर मापा और दिखाई देता है।
• घटना संस्करणों को पलायन करने और खिड़कियों को हटाने की योजना है।

FAQ

EDC "सिर्फ एक बस" से कैसे अलग है?

कोर न केवल दलाल है, बल्कि घटना अनुबंध, आदेश/पहचान नियम, विकास प्रक्रियाओं और अवलोकन भी है।

क्या हम केवल सीडीसी पर निर्माण कर सकते हैं?

सीडीसी एकीकरण/प्रवासन के लिए उपयुक्त है, लेकिन डोमेन घटनाओं का अर्थ अधिक स्पष्ट रूप से है और अनुभव डेटाबेस अधिक स्थिर रूप से बदलता है।

स्थिरता के बारे में क्या?

हम इसके लिए अंतिम स्थिरता और डिजाइन UX/प्रक्रियाओं को स्वीकार करते हैं (अद्यतन, रिट्रे, मुआवजे के संकेतक)।

वास्तव में एक बार कब जरूरत है?

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

कुल

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