Redis में महारत हासिल करना: उन्नत मैसेजिंग के साथ माइक्रोसर्विसेज इंफ्रास्ट्रक्चर को बढ़ाना

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

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

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

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

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

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

(अधिक जानकारी के लिए, हमारे पोस्ट What to Choose for Your Synchronous and Asynchronous Communication Needs—Redis Streams, Redis Pub/Sub, Kafka, etc. देखें।)

OrderShop: एक नमूना ई-कॉमर्स कार्यान्वयन

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

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

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

चलाएं और आनंद लें

• GitHub रिपॉजिटरी क्लोन करें: https://github.com/redis-demos/ordershop-v2
• OrderShop v2 को एक सरल पांच-चरण प्रक्रिया में चलाएं:

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

OrderShop v2 आर्किटेक्चर

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

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

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

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

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

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

रीड मॉडल डोमेन मॉडल का उपयोग करके इवेंट स्टोर से अनुमानित इकाइयों को Redis में कैश करता है। कैश को छोड़कर, यह स्टेटलेस है।

API गेटवे भी स्टेटलेस है, और पोर्ट 5000 पर REST-API परोसता है। यह HTTP कनेक्शन को समाप्त करता है और उन्हें या तो स्थिति पढ़ने के लिए रीड मॉडल (क्वेरी) या स्थिति लिखने के लिए समर्पित डोमेन सेवा (कमांड) पर रूट करता है। पढ़ने और लिखने के संचालन के बीच यह वैचारिक अलगाव Command Query Responsibility Segregation (CQRS) नामक एक पैटर्न है।

डोमेन सेवाएं

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

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

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

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

क्लाइंट्स

क्लाइंट्स को Python से यूनिट टेस्टिंग फ्रेमवर्क का उपयोग करके सिम्युलेट किया जाता है। वर्तमान में 10 यूनिट टेस्ट लागू हैं। आगे के विवरण के लिए tests/unit.py देखें।

पोर्ट 5000 पर एक सरल UI परोसा जाता है ताकि घटनाओं को देखा जा सके और स्थिति ब्राउज़ की जा सके (WebSockets का उपयोग करके)।

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

निष्कर्ष

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

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

मुझे Twitter पर बताएं कि यह कैसा रहा: @martinez099।