इव्हेंट-चालित सिस्टम मार्गदर्शक: इव्हेंटसह चांगले सॉफ्टवेअर

आज बहुतेक सॉफ्टवेअर हे एक साधे ॲप नाही. हे सहसा इतर भागांशी बोलते. उदाहरणार्थ, ऑनलाइन स्टोअर अनेकदा पेमेंट, स्टॉक, ग्राहक प्रोफाइल, शिपिंग, अलर्ट, रिपोर्टिंग आणि जोखीम तपासण्यांना लिंक करते. व्हिडिओ साइट लॉगिन, सामग्री वितरण, सुचविलेले व्हिडिओ, बिलिंग आणि पाहण्याची क्रियाकलाप देखील समन्वयित करू शकते. जसजसे सिस्टीम अधिक पसरत जातात, तसतसे सेवा ज्या प्रकारे एकमेकांशी बोलतात त्या मूळ डिझाइनचा भाग बनतात.

सेवा कनेक्ट करण्याचा एक मार्ग म्हणजे थेट, सिंक्रोनस कॉल वापरणे. सेवेला विनंती मिळते आणि नंतर दुसऱ्या सेवेपर्यंत पोहोचते. ते उत्तराची वाट पाहते, मग ते पुढे जात राहते. हे अशा प्रकरणांमध्ये बसू शकते जेथे त्वरित उत्तर आवश्यक आहे. तरीही, ते सेवा एकत्र बांधू शकते. एका सेवेतील बदल इतरांना तरंगू शकतात.

दुसरा पर्याय इव्हेंट-चालित डिझाइन आहे. येथे, प्रत्येक पुढच्या पायरीवर एका घटकाला कमांड देण्याची गरज नाही. एखादी सेवा एखादी घटना उत्सर्जित करू शकते जी सांगते की काहीतरी घडले आहे. इतर सेवा तो कार्यक्रम स्वतः वाचू शकतात. मग पुढे काय करायचे ते प्रत्येकजण ठरवतो.

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

मायक्रोसॉफ्ट इव्हेंट-चालित आर्किटेक्चरचे वर्णन इव्हेंट उत्पादक, इव्हेंट ग्राहक आणि इव्हेंट चॅनेल किंवा ब्रोकर यांच्या संदर्भात करते. उत्पादक आणि ग्राहक इतके घट्ट बांधलेले नाहीत. कठोर क्रमाने वाट न पाहता, ग्राहक नंतरच्या कार्यक्रमांना देखील हाताळू शकतात.

ही शैली प्रणाली समायोजित करणे सोपे आणि वाढण्यास सक्षम बनवू शकते. त्याच वेळी, ते व्यवस्थापित करण्यासाठी नवीन समस्या आणते. कार्यसंघांनी डेटा सुसंगतता, अयशस्वी हाताळणी, प्रवाह निरीक्षण आणि इव्हेंट डिझाइन यांचा विचार केला पाहिजे.

इव्हेंट-चालित प्रणाली म्हणजे काय?

इव्हेंट-चालित डिझाइनसह, एक सॉफ्टवेअर भाग इव्हेंट वापरून दुसऱ्याशी बोलू शकतो. इव्हेंट म्हणजे आधीपासून घडलेल्या क्रियेचा लॉग आहे. उदाहरणार्थ, वापरकर्ता खाते तयार करतो. पेमेंट पूर्ण होते. एखादी वस्तू कार्टमध्ये टाकली जाते. फाइल अपलोड समाप्त होते. शिपमेंट गोदामातून निघते. जेव्हा यापैकी कोणतीही घटना घडते, तेव्हा सिस्टम एक संदेश उत्सर्जित करते. इतर भाग ऐकू शकतात. मग ते प्रतिसाद देऊ शकतात आणि त्यांचे स्वतःचे तर्क चालवू शकतात.

AWS वर, एखाद्या इव्हेंटला स्थितीतील बदल किंवा लक्षात घेण्याजोगी घटना मानली जाते. इव्हेंटमध्ये काय घडले याबद्दल अतिरिक्त तपशील समाविष्ट करू शकतात. यात की किंवा आयडी सारखी मूल्ये देखील असू शकतात. संदेश आल्यानंतर, प्राप्तकर्त्याला आवश्यक असल्यासच अधिक डेटा शोधू शकतो.

हे आदेशासारखे नाही. कमांड एका घटकाला पुढे काय करायचे ते सांगते. एखादी घटना आधीच घडलेली वस्तुस्थिती सांगते.

या कल्पनांना वेगळे ठेवणे इव्हेंट-चालित प्रणालींना घट्ट जोडणी टाळण्यास मदत करते.

मूलभूत आर्किटेक्चर

इव्हेंट-चालित सेटअपमध्ये सहसा तीन तुकडे असतात. उत्पादक आहेत. एक कार्यक्रम चॅनेल आहे. ग्राहक आहेत. निर्माता कार्यक्रम करतो. स्त्रोत ॲपमधील सेवा, डेटाबेस बदल, वापरकर्ता क्रिया, डिव्हाइस किंवा काही बाहेरील प्रणाली असू शकते.

इव्हेंट चॅनेल इव्हेंट हलवते किंवा नंतरसाठी ठेवते. तुम्हाला इव्हेंट ब्रोकर, मेसेज रांग किंवा स्ट्रीमिंग सेवा दिसू शकते. ग्राहकाला इव्हेंट मिळतो. मग ते कार्य करते कारण घटना घडली.

एक कार्यक्रम एकापेक्षा जास्त ग्राहकांपर्यंत जाऊ शकतो. उदाहरणार्थ, ऑर्डर दिल्यावर, इन्व्हेंटरी सेवा वस्तू आरक्षित करू शकते. त्याच वेळी, सूचना सेवा पावती पाठवू शकते. विश्लेषण सेवा ऑर्डर देखील लॉग करू शकते. कार्यक्रम कोण हाताळणार याची यादी निर्मात्याला लागत नाही. हे नकळत राहू शकते. इव्हेंट-चालित सिस्टीमचे हे मुख्य वैशिष्ट्य आहे.

असिंक्रोनस कम्युनिकेशन स्पष्ट केले

जुन्या विनंती-प्रतिसाद डिझाइनमध्ये, कॉल अनेकदा समकालिक असतात. एक सेवा दुसऱ्याला काहीतरी विचारते आणि प्रतीक्षा करते. जेव्हा कॉलरला लगेच निकाल मिळणे आवश्यक असते तेव्हा तो नमुना बसतो. पेमेंट कार्य झाले हे खरेदीदाराला सांगण्यापूर्वी स्टोअर ॲपला पेमेंट सेवेकडून द्रुत उत्तराची आवश्यकता असू शकते.

पण काही कामांना अशा वेळेची गरज नसते. ऑर्डर सेव्ह केल्यानंतर पाठवलेला ईमेल ही सामान्य बाब आहे. ईमेल पायरीची वाट न पाहता ऑर्डर प्रवाह पूर्ण होऊ शकतो. असिंक्रोनस कम्युनिकेशनसह, ऑर्डर सेवा इव्हेंट प्रकाशित करू शकते आणि पुढे जाऊ शकते. चॅनेलमध्ये इव्हेंट आऊट झाल्यानंतर नोटिफिकेशनचे काम स्वतःच चालू शकते.

लूज कपलिंग आणि हे महत्त्वाचे का आहे

इव्हेंट-चालित प्रणालींमध्ये लूज कपलिंग हा एक महत्त्वाचा विजय आहे. जेव्हा गोष्टी घट्ट जोडल्या जातात तेव्हा तुकडे एकमेकांवर थेट अवलंबून असतात. एक सेवा बदलल्यास, दुसऱ्या सेवेला जुळणारे बदल आवश्यक असू शकतात. एक भाग अयशस्वी झाल्यास, कॉलरला ते लगेच जाणवू शकते. तेच लूज कपलिंग कमी होण्यास मदत होते.

सैल कपलिंगसह, निर्माता फक्त एक कार्यक्रम पाठवतो. हे इव्हेंट आकारासाठी सामायिक कराराचे अनुसरण करते. कोण ऐकतंय याचा मागोवा निर्मात्याला लागत नाही. प्रत्येक ग्राहक कसे कार्य करतो हे देखील माहित असणे आवश्यक नाही.

त्यामुळे नवीन ग्राहक अनेकदा नंतर सामील होऊ शकतात.

ते सहसा मूळ निर्मात्याला संपादनाची सक्ती करत नाही. AWS नोट करते की हे सेटअप भाग वेळेनुसार बदलत राहू देते. हे मोठ्या नॉक-ऑन इफेक्ट्सशिवाय अंमलबजावणीमध्ये स्केलिंग आणि स्वॅपचे समर्थन करते. सतत वाढत जाणाऱ्या सॉफ्टवेअरसाठी, अशा प्रकारचे स्वातंत्र्य अधिक महत्त्वाचे असू शकते.

एक व्यावहारिक ई-कॉमर्स उदाहरण

ऑनलाइन दुकानाचा विचार करा. ग्राहक ऑर्डर पूर्ण करतो. ऑर्डर सेवा ऑर्डर तपासते, सेव्ह करते आणि नंतर ऑर्डरप्लेस केलेला इव्हेंट उत्सर्जित करते.

त्यानंतर, एकाधिक सेवा स्वतःहून प्रतिक्रिया देऊ शकतात. इन्व्हेंटरी सेवा इव्हेंट मिळवते आणि आयटम बाजूला ठेवते. अधिसूचना सेवा देखील समान कार्यक्रम प्राप्त करते आणि एक पुष्टीकरण पाठवते.

विश्लेषण प्रणाली खरेदी डेटा लॉग करते.

नंतर, एक ग्राहक निष्ठा सेवा देखील समान कार्यक्रम वाचू शकते. ते नंतर रिवॉर्ड पॉइंट अपडेट करू शकते. या दृष्टिकोनामध्ये, ऑर्डर सेवेला प्रत्येक सिस्टीमवर स्वतंत्र कॉल चालवण्याची आवश्यकता नाही.

प्रत्येक ग्राहक हा कार्यक्रम स्वतंत्रपणे हाताळतो.

उत्पादनाचा विस्तार होत असताना, हा नमुना नवीन वैशिष्ट्ये जोडणे सोपे करू शकतो.

प्रकाशित करा- आर्किटेक्चरची सदस्यता घ्या

घटना-आधारित प्रणालींमध्ये, लोक एक साधा नमुना वापरतात. ते प्रकाशित करतात आणि सदस्यता घेतात. बऱ्याचदा तुम्हाला ते pub/sub म्हणतात. निर्माता एखाद्या विषयावर किंवा चॅनेलला इव्हेंट पाठवतो. त्यानंतर, इतर सेवा कार्यक्रम घेऊ शकतात. निर्मात्याला प्रत्येक सेवेवर त्याचा परिणाम होऊ शकतो असे कनेक्ट करण्याची गरज नाही.

जेव्हा एका व्यवसायातील बदलासाठी अनेक फॉलोअपची आवश्यकता असते तेव्हा हे मदत करते. तुम्हाला एक AccountCreated इव्हेंट मिळेल म्हणा. ते स्वागत ईमेल सुरू करू शकते. हे विश्लेषण देखील फीड करू शकते. प्रोफाइल सेवा समान कार्यक्रम वापरू शकते. फसवणूक धनादेश देखील ते वाचू शकतात.

मायक्रोसॉफ्ट याला प्रकाशन-सदस्यता एक मानक इव्हेंट-चालित शैली म्हणतो. त्या दृष्टिकोनातून, उत्पादक आणि ग्राहक इव्हेंट चॅनेलद्वारे भेटतात. सेटअप कालांतराने वाढू शकते. तुम्ही पहिल्या उत्पादकाला स्पर्श न करता नंतर आणखी ग्राहक जोडू शकता.

संदेश रांग आणि कार्यक्रम प्रवाह

इव्हेंट सिस्टम सर्व डेटा सारख्याच ठेवत नाहीत. संदेशाच्या रांगेसह, कार्यक्रम रांगेत बसतात. ते तयार झाल्यावर कामगार त्यांना घेऊन जातो. जेव्हा त्याच्याकडे जागा असते तेव्हाच ग्राहक खेचतो.

रहदारीच्या रांगा फिट होतात

जेव्हा भार वेगाने वाढतो तेव्हा ते मदत करतात. पुढील ॲप्सना इजा न करता शॉर्ट स्पाइक्स शोषले जाऊ शकतात. इमेज प्रोसेसिंग ॲप घ्या. हे एका छोट्या विंडोमध्ये बरेच अपलोड पाहू शकतात. जर प्रत्येक अपलोड एकाच वेळी सुरू झाला असेल, तर गोष्टी अयशस्वी होऊ शकतात. त्यामुळे ॲप नोकऱ्यांना रांगेत उभे करते. गर्दी संपली की कामगार नंतर नोकरी चालवतात.

इव्हेंट प्रवाह वेगळ्या प्रकारे कार्य करतात.

बऱ्याच सिस्टम इव्हेंट्स व्यवस्थित ठेवतात आणि लॉगमध्ये ठेवतात. प्रत्येक ग्राहक त्या लॉगमध्ये स्वतःच्या जागेचा मागोवा ठेवतो. एखाद्या ग्राहकाला जुन्या वस्तू हव्या असतील तर तो त्या पुन्हा वाचू शकतो. तुकडे वेगळ्या पद्धतीने वागतात म्हणून, आपल्याला काळजीपूर्वक निवडण्याची आवश्यकता आहे.

तुमच्या वर्कलोडला बसणारा पर्याय निवडा.

इव्हेंट-चालित सॉफ्टवेअरचे भविष्य

अधिक कार्यसंघ अशी उत्पादने तयार करत आहेत जी बऱ्याच ठिकाणी चालतात आणि त्यांना वेगवान प्रतिक्रिया वेळेची आवश्यकता असते. त्या प्रकारच्या सेटअपमध्ये, इव्हेंट-चालित डिझाइन चांगले बसते. तुम्ही ते क्लाउड सेवा, सर्व्हरलेस कोड, रिअल-टाइम रिपोर्टिंग, IoT डिव्हाइसेस आणि AI पाइपलाइनसह वापरू शकता. या प्रणाली सहसा एक सामान्य नमुना सामायिक करतात. एक बदल घडतो आणि इतर भागांनी प्रतिक्रिया दिली पाहिजे.

AWS चे सर्व्हरलेस AI वर मार्गदर्शन हे एक स्पष्ट उदाहरण आहे. हे वापरकर्त्याच्या विनंत्या, फाइल अपलोड, सेन्सर रीडिंग आणि मॉडेल आउटपुट यासारख्या गोष्टींना इव्हेंट म्हणून हाताळते. त्या घटना पाठपुरावा काम सुरू करू शकता. मुख्य मुद्दा असा आहे की भागांना एकमेकांशी घट्ट दुवे आवश्यक नाहीत.

तरीही, हे मॉडेल प्रत्येक प्रकारचे संप्रेषण घेणार नाही. काही कार्यप्रवाहांना अद्याप थेट कॉलची आवश्यकता आहे. इतर विलंबित आणि असिंक्रोनस प्रवाहांसह चांगले कार्य करतात. त्यामुळे संभाव्य दिशा मिश्रण आहे. हायब्रीड डिझाईन्स विनंती-प्रतिसाद कॉल आणि इव्हेंट प्रवाह दोन्ही वापरतात, प्रत्येक कार्याला खरोखर काय आवश्यक आहे यावर आधारित.

निष्कर्ष

इव्हेंट-चालित प्रणाली व्यावहारिक उद्दिष्टांसाठी मदत करतात. ते सेवांना कार्यक्रम प्रकाशित करू देतात आणि ते स्वतः हाताळू देतात. यामुळे सेवांमधील थेट संबंध कमी होऊ शकतात. हे स्केलिंग नितळ देखील करू शकते. जेव्हा रहदारी उडी मारते, तेव्हा तुम्ही भार अधिक सहजपणे शोषून घेऊ शकता. तुम्ही जुन्या सेवांमध्ये कमी संपादनांसह नवीन वैशिष्ट्ये देखील जोडू शकता.

तरीही, हे केवळ इव्हेंट ब्रोकरमध्ये टाकण्याबद्दल नाही. खरे काम तपशीलात आहे. संघांना अंतिम सुसंगतता, डुप्लिकेट इव्हेंट्स, इव्हेंट ऑर्डर, पुन्हा प्रयत्न, वेळेनुसार इव्हेंटचे स्वरूप कसे बदलते, सुरक्षितता आणि देखरेख यासाठी योजना आखणे आवश्यक आहे.

वापरकर्त्यांना फक्त एकच पर्याय निवडण्याची गरज नाही. क्षणाला योग्य ते निवडा. द्रुत उत्तर हवे आहे? सिंक मेसेजिंग वापरा. तुम्ही प्रतीक्षा करत असताना तुम्ही इतर काम करू शकत असाल, तर async इव्हेंट निवडा. हे प्रत्येक भाग त्याच्या स्वतःच्या वेळेनुसार चालू ठेवू देते. इव्हेंट-चालित सॉफ्टवेअर काळजीपूर्वक तयार केले आहे; ते वाढ हाताळू शकते. हे गोष्टी स्थिर ठेवण्यास देखील मदत करते. नंतरचे बदल कमी वेदनादायक असतात. लहान अद्यतने नेहमीच संपूर्ण सिस्टमला एकाच वेळी हलविण्यास भाग पाडत नाहीत.

(स्त्रोत)