इंफ्रास्ट्रक्चर माइक्रोसर्विसेज में रेडिस का उपयोग कैसे करें

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

माइक्रोसर्विसेज, इंफ्रास्ट्रक्चर सर्विसेज और डिस्ट्रिब्यूटेड सिस्टम्स पर एक त्वरित नजर

संदेश कतार और इवेंट स्टोर जैसी बुनियादी ढांचा सेवाएं बनाने के लिए रेडिस एक बेहतरीन समाधान है, लेकिन एक वितरित प्रणाली बनाने के लिए माइक्रोसर्विस आर्किटेक्चर का उपयोग करते समय आपको कुछ चीजों को ध्यान में रखना होगा। संबंधपरक डेटाबेस अक्सर अखंड अनुप्रयोगों के लिए अच्छे थे, लेकिन केवल Redis जैसे NoSQL डेटाबेस ही एक माइक्रोसर्विस आर्किटेक्चर के लिए आवश्यक मापनीयता और उपलब्धता आवश्यकताओं को प्रदान कर सकते हैं।

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

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

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

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

ऑर्डरशॉप:एक नमूना ई-कॉमर्स कार्यान्वयन

माइक्रोसर्विस आर्किटेक्चर का "हैलो वर्ल्ड" ऑर्डरशॉप है, जो इवेंट-आधारित दृष्टिकोण का उपयोग करके ई-कॉमर्स सिस्टम का एक सरल कार्यान्वयन है। यह नमूना एप्लिकेशन एक साधारण डोमेन मॉडल का उपयोग करता है, लेकिन यह एप्लिकेशन के उद्देश्य को पूरा करता है।

ऑर्डरशॉप डॉकर कंपोज़ का उपयोग करके ऑर्केस्ट्रेटेड है। सभी नेटवर्क संचार gRPC पर किया जाता है। केंद्रीय घटक इवेंट स्टोर और संदेश कतार हैं:प्रत्येक सेवा केवल और केवल उनसे जीआरपीसी से जुड़ी होती है। ऑर्डरशॉप पायथन में एक नमूना कार्यान्वयन है। आप GitHub पर ऑर्डरशॉप सोर्स कोड देख सकते हैं।

(नोट: यह कोड नहीं है उत्पादन के लिए तैयार है और केवल डेमो उद्देश्यों के लिए है!)

दौड़ें और मस्ती करें

• गिटहब रिपॉजिटरी को क्लोन करें:https://github.com/redis-demos/ordershop-v2
• आर्डरशॉप v2 को पांच चरणों वाली आसान प्रक्रिया में चलाएं:

1. एप्लिकेशन को docker-compose up से शुरू करें
2. अपना ब्राउज़र खोलें और https://localhost:5000/ पर जाएं
   1. इवेंट देखें और राज्य ब्राउज़ करें
3. क्लाइंट को python -m unittest test/unit.py के साथ चलाएं
4. अपने ब्राउज़र में एक और टैब खोलें https://localhost:8001/
   1. रेडिस:6379 का प्रयोग करें परीक्षण डेटाबेस से कनेक्ट करने के लिए
5. एप्लिकेशन को docker-compose down के साथ रोकें

ऑर्डरशॉप v2 आर्किटेक्चर

इस स्थिति में, सर्वर आर्किटेक्चर में कई सेवाएँ होती हैं। राज्य को कई डोमेन सेवाओं में वितरित किया जाता है लेकिन एक ही ईवेंट स्टोर में संग्रहीत किया जाता है। पढ़ें मॉडल घटक राज्य को पढ़ने और कैशिंग के लिए तर्क केंद्रित करता है, जैसा कि यहां दिखाया गया है:

संदेश कतार . के माध्यम से कमांड और क्वेरी का संचार किया जाता है घटक, जबकि ईवेंट को ईवेंट स्टोर . के माध्यम से संप्रेषित किया जाता है घटक, जो एक इवेंट बस के रूप में भी कार्य करता है।

इन्फ्रास्ट्रक्चर सेवाएं

ऑर्डरशॉप v2 में, सभी यूनिकास्ट संचार संदेश कतार . पर होते हैं अवयव। इसके लिए, मैं Redis Lists का उपयोग करूंगा, और विशेष रूप से, दो सूचियों को तथाकथित "विश्वसनीय कतार" में संयोजित किया जाएगा। यह सरल आदेशों (जैसे एकल इकाई संचालन) को समकालिक रूप से संसाधित करता है, लेकिन लंबे समय तक चलने वाले (जैसे बैच, मेल) अतुल्यकालिक रूप से और बॉक्स से बाहर सिंक्रोनस संदेशों की प्रतिक्रियाओं का समर्थन करता है।

इवेंट स्टोर रेडिस स्ट्रीम पर आधारित है। डोमेन सेवाएं (जो ऑर्डरशॉप की कार्यक्षमता को प्रदर्शित करने के लिए केवल डमी हैं) ईवेंट विषय (यानी इकाई का नाम) के नाम पर ईवेंट स्ट्रीम की सदस्यता लेती हैं और इन स्ट्रीम पर ईवेंट प्रकाशित करती हैं। प्रत्येक ईवेंट एक स्ट्रीम-एंट्री है जिसमें ईवेंट टाइमस्टैम्प आईडी के रूप में कार्य करता है। स्ट्रीम में प्रकाशित घटनाओं का योग समग्र प्रणाली की स्थिति में परिणाम देता है।

एप्लिकेशन सेवाएं

पढ़ें मॉडल इवेंट स्टोर . से संस्थाओं को कैश करता है रेडिस में डोमेन मॉडल का उपयोग करना। कैश की परवाह किए बिना, यह स्टेटलेस है।

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

डोमेन सेवाएं

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

सीआरएम सेवा (ग्राहक संबंध प्रबंधन सेवा) स्टेटलेस है—यह इवेंट स्टोर से डोमेन ईवेंट की सदस्यता लेती है और मेल सेवा का उपयोग करके ग्राहकों को ईमेल भेजती है। ।

केंद्रीय डोमेन इकाई आदेश है। इसमें 'स्टेटस' नाम का एक फील्ड होता है, जिसे स्टेट मशीन का उपयोग करके ट्रांजिशन किया जाता है, जैसा कि नीचे दिए गए चित्र में दिखाया गया है।

ये बदलाव कई इवेंट हैंडलर में किए जाते हैं, जो डोमेन इवेंट (SAGA पैटर्न) के लिए सब्सक्राइब किए जाते हैं, उदाहरण के लिए:

ग्राहक

ग्राहकों को पायथन से यूनिट परीक्षण ढांचे का उपयोग करके सिम्युलेटेड किया जाता है। वर्तमान में 10 यूनिट परीक्षण लागू किए गए हैं। tests/unit.py पर एक नज़र डालें अधिक जानकारी के लिए।

घटनाओं को देखने और स्थिति (वेबसॉकेट का उपयोग करके) ब्राउज़ करने के लिए पोर्ट 5000 पर एक साधारण यूआई परोसा जाता है।

Redis इंस्टेंस का निरीक्षण करने के लिए एक RedisInsight कंटेनर भी उपलब्ध है। वेब ब्राउज़र को https://localhost:8001/ पर खोलें और redis:6379 . का उपयोग करें परीक्षण डेटाबेस से कनेक्ट करने के लिए।

निष्कर्ष

Redis न केवल डोमेन लेयर (जैसे कैटलॉग सर्च) और एप्लिकेशन लेयर (जैसे HTTP सेशन स्टोर) में एक शक्तिशाली टूल है, बल्कि इन्फ्रास्ट्रक्चर लेयर (जैसे इवेंट स्टोर या मैसेज कतार) में भी है। इन सभी परतों में Redis का उपयोग करने से ऑपरेशनल ओवरहेड कम हो जाता है और डेवलपर्स को उन तकनीकों का पुन:उपयोग करने देता है जिन्हें वे पहले से जानते हैं।

कोड पर एक नज़र डालें और इसे लागू करने के लिए अपना हाथ आजमाएं। मुझे उम्मीद है कि यह डोमेन और बुनियादी ढांचा सेवाओं में रेडिस की बहुमुखी प्रतिभा और लचीलेपन को प्रदर्शित करने में मदद करता है और यह साबित करता है कि कैशिंग से परे इसका उपयोग कैसे किया जा सकता है।

मुझे बताएं कि यह ट्विटर पर कैसा चल रहा है:@martinez099।