मोनोलिथ को विभाजित करना

एक मोनोलिथिक अनुप्रयोग एकल, एकीकृत इकाई के रूप में बनाया जाता है। इसके सभी घटक—उपयोगकर्ता इंटरफ़ेस, व्यावसायिक तर्क और डेटा एक्सेस परत—आपस में घनिष्ठ रूप से जुड़े होते हैं और एक ही प्रक्रिया में चलते हैं।

इसे एक ऐसी बड़ी इमारत की तरह समझिए जिसमें सब कुछ शामिल हो। इन्हें शुरू में विकसित करना आसान होता है, लेकिन बढ़ने के साथ इनका प्रबंधन और स्केल करना कठिन हो सकता है।

इसके विपरीत, माइक्रोसर्विस आर्किटेक्चर किसी अनुप्रयोग को छोटी, स्वतंत्र सेवाओं के समूह में बाँटता है। प्रत्येक सेवा अपनी प्रक्रिया में चलती है और आमतौर पर एपीआई जैसे हल्के माध्यमों से अन्य सेवाओं के साथ संचार करती है।

• स्वतंत्र: सेवाओं को अलग-अलग विकसित, परिनियोजित और स्केल किया जा सकता है।
• विशिष्ट: प्रत्येक सेवा एकल व्यावसायिक क्षमता पर केंद्रित होती है।
• लचीली: एक सेवा की विफलता से पूरी प्रणाली का बंद होना आवश्यक नहीं है।

मोनोलिथ को माइक्रोसर्विस में विभाजित करने से कई प्रमुख लाभ मिलते हैं, विशेषकर तब जब आपका अनुप्रयोग बढ़ता है:

• स्केलेबिलिटी: पूरे अनुप्रयोग के बजाय मांग के आधार पर अलग-अलग सेवाओं को स्केल करें।
• लचीलापन: अलग-अलग सेवाओं के लिए अलग-अलग तकनीकों (भाषाओं और डेटाबेस) का उपयोग करें।
• तेज़ विकास: छोटे कोडबेस को टीमों के लिए स्वतंत्र रूप से प्रबंधित और परिनियोजित करना आसान होता है।
• बेहतर दोष-सहिष्णुता: एक सेवा में मौजूद बग से पूरी प्रणाली बंद नहीं होगी।

"स्ट्रैंगलर फ़िग पैटर्न" मोनोलिथ को धीरे-धीरे विभाजित करने की एक लोकप्रिय रणनीति है। इसमें मौजूदा मोनोलिथ के आसपास नई माइक्रोसर्विस बनाना और धीरे-धीरे ट्रैफ़िक को उनकी ओर मोड़ना शामिल है।

अंततः नई सेवाएँ पुरानी कार्यक्षमता को "जकड़" लेती हैं, जब तक कि मोनोलिथ वाले हिस्से को हटाया न जा सके। क्रमिक बदलावों की अनुमति देकर यह जोखिम कम करता है।

विभाजन का एक महत्वपूर्ण चरण सीमाबद्ध संदर्भों की पहचान करना है। Domain-Driven Design (DDD) की यह अवधारणा आपकी नई माइक्रोसर्विस की स्वाभाविक सीमाएँ निर्धारित करने में सहायता करती है।

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

मोनोलिथ को विभाजित करने के सबसे कठिन भागों में से एक उसके डेटाबेस को बाँटना है। आदर्श रूप से प्रत्येक माइक्रोसर्विस के पास अपना डेटा स्कीमा होना चाहिए, अर्थात उसका अपना समर्पित डेटाबेस या साझा डेटाबेस के भीतर समर्पित स्कीमा होना चाहिए।

• क्यों: सेवाओं को अलग करता है और डेटा को स्वतंत्र रूप से विकसित करने की अनुमति देता है।
• चुनौतियाँ: सेवाओं के बीच डेटा की संगति बनाए रखना और जटिल लेन-देन प्रबंधित करना।
• रणनीति: नई सेवा से संबंधित तालिकाओं को धीरे-धीरे उसके अपने डेटाबेस में निकालना।

आइए उपयोगकर्ता प्रबंधन वाले एक मोनोलिथिक अनुप्रयोग पर विचार करें। UserService निकालने के लिए:

1. मोनोलिथ में उपयोगकर्ता से संबंधित सभी कोड (पंजीकरण, लॉगिन और प्रोफ़ाइल अपडेट) की पहचान करें।
2. एक नई, अलग UserService माइक्रोसर्विस बनाएँ।
3. उपयोगकर्ता डेटा (जैसे users तालिका) को नई सेवा के स्वामित्व वाले अपने डेटाबेस में स्थानांतरित करें।
4. मोनोलिथ को उपयोगकर्ता डेटा तक सीधे पहुँचने के बजाय UserService एपीआई को कॉल करने के लिए संशोधित करें।

यह एक क्रमिक प्रक्रिया है, जिसमें अक्सर स्ट्रैंगलर फ़िग पैटर्न का उपयोग किया जाता है।

एक बार आपके पास अनेक माइक्रोसर्विस होने पर, उन्हें आपस में संचार करना पड़ता है। प्रारंभिक विभाजन के लिए सीधे एपीआई कॉल (जैसे HTTP पर REST) सामान्य होते हैं। कोई उपयोगकर्ता सेवा अन्य सेवाओं के लिए उपयोगकर्ता विवरण प्राप्त करने वाले एंडपॉइंट उपलब्ध करा सकती है।

जैसे-जैसे प्रणालियाँ बढ़ती हैं, अतुल्यकालिक संचार के लिए संदेश कतार जैसे अधिक उन्नत पैटर्न आवश्यक हो जाते हैं। हम अगले पाठ में इनका अध्ययन करेंगे!

आज हमने जाना कि मोनोलिथिक अनुप्रयोगों को छोटे, प्रबंधनीय माइक्रोसर्विस में कैसे बाँटा जाता है। हमने इन विषयों के बारे में सीखा:

• मोनोलिथ और माइक्रोसर्विस के बीच मुख्य अंतर।
• बेहतर स्केलेबिलिटी, लचीलापन और दोष-सहिष्णुता जैसे लाभ।
• स्ट्रैंगलर फ़िग पैटर्न और सीमाबद्ध संदर्भों की पहचान जैसी रणनीतियाँ।
• डेटाबेस विभाजन और प्रारंभिक सेवा संचार की चुनौतियाँ।

अब हम इस बात का अधिक गहराई से अध्ययन करेंगे कि ये सेवाएँ प्रभावी रूप से कैसे संचार करती हैं!