System Design

पारंपरिक अखंड अनुप्रयोगों में, कई संस्थाओं में डेटा स्थिरता बनाए रखना सीधा है। रिलेशनल डेटाबेस इंजन स्थानीय SQL लेनदेन के अंदर ACID (परमाणुता, संगति, अलगाव, स्थायित्व) गारंटी प्रदान करते हैं। यदि कोई ऑर्डर प्लेसमेंट, भुगतान कटौती, या इन्वेंट्री रिजर्व आधे रास्ते में विफल हो जाता है, तो ROLLBACK को कॉल करने से प्रत्येक डेटाबेस संशोधन तुरंत वापस आ जाता है।

आधुनिक इवेंट-संचालित माइक्रोसर्विसेज आर्किटेक्चर (Event-Driven Architecture) में, सेवाएं राज्यों के परिवर्तनों को सूचित करने के लिए नियमित रूप से इवेंट्स (जैसे OrderCreated या PaymentProcessed) जारी करती हैं। लेकिन एक चुनौती यह है: आप यह कैसे सुनिश्चित कर सकते हैं कि डेटाबेस अपडेट और इवेंट पब्लिशिंग दोनों एक साथ सफल हों या दोनों विफल हों?

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

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

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

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

आधुनिक सॉफ्टवेयर इंजीनियरिंग में, विरासत अखंड अनुप्रयोग एक आम चुनौती है। समय के साथ, एक सफल कोडबेस इतना बड़ा और परस्पर जुड़ा हुआ हो जाता है कि साधारण परिवर्तन करना जोखिम भरा हो जाता है, तैनाती में घंटों लग जाते हैं, और व्यक्तिगत सुविधाओं को स्केल करना लगभग असंभव हो जाता है।

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

एकल, अखंड एप्लिकेशन से माइक्रोसर्विसेज आर्किटेक्चर में संक्रमण कई समस्याओं का समाधान करता है। यह टीमों को स्वतंत्र रूप से काम करने, सेवाओं को अलग से तैनात करने और आवश्यकतानुसार सिस्टम के हिस्सों को स्केल करने की अनुमति देता है। हालाँकि, यह एक नई चुनौती भी पेश करता है: ग्राहक इन सभी स्वतंत्र सेवाओं के साथ कैसे इंटरैक्ट करते हैं?

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