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