द स्ट्रैंगलर फ़िग पैटर्न: मोनोलिथिक अनुप्रयोगों को स्थानांतरित करने का एक सुरक्षित तरीका

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

जब टीमें माइक्रोसर्विसेज की ओर पलायन करके अपने सिस्टम को आधुनिक बनाने का निर्णय लेती हैं, तो उन्हें एक महत्वपूर्ण प्रश्न का सामना करना पड़ता है: हम अपने वर्तमान व्यवसाय को तोड़े बिना सिस्टम को फिर से कैसे लिख सकते हैं?

एक विकल्प “बिग बैंग” को फिर से लिखना है - बंद दरवाजों के पीछे से नए सिस्टम का निर्माण करना और एक ही दिन में सब कुछ बदल देना। हालाँकि, यह अविश्वसनीय रूप से जोखिम भरा है और अक्सर विफलता की ओर ले जाता है।

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

वास्तविक दुनिया सादृश्य: स्ट्रैंगलर अंजीर का पौधा

पैटर्न का नाम स्ट्रैंगलर फ़िग के नाम पर रखा गया है, जो उष्णकटिबंधीय वर्षावनों का मूल निवासी पौधा है।

एक अजनबी अंजीर का बीज मौजूदा “मेजबान” पेड़ की ऊपरी शाखाओं में अंकुरित होता है। अंजीर ज़मीन से ऊपर बढ़ने के बजाय नीचे की ओर बढ़ता है:

1. यह जड़ों को मेजबान पेड़ के तने तक नीचे भेजता है जब तक कि वे जंगल के फर्श तक नहीं पहुंच जाते और मिट्टी में स्थिर नहीं हो जाते।
2. समय के साथ, अधिक जड़ें बढ़ती हैं, मेजबान के चारों ओर लपेटती हैं, और एक साथ जुड़ जाती हैं।
3. अंजीर में पत्तियाँ उगती हैं जो प्रकाश को मेज़बान पेड़ तक पहुँचने से रोकती हैं।
4. अंततः, मेज़बान पेड़ मर जाता है और सड़ जाता है, जिससे एक खोखला गला घोंटने वाला अंजीर का पेड़ अपनी जगह पर मजबूती से खड़ा रह जाता है।

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

“बिग बैंग” का पुनर्लेखन विफल क्यों हो गया

स्ट्रैंगलर फ़िग पैटर्न के यांत्रिकी में गोता लगाने से पहले, आइए समझें कि विकल्प - एक पूर्ण पुनर्लेखन - इतना खतरनाक क्यों है:

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

स्ट्रैंगलर फ़िग पैटर्न कैसे काम करता है

स्ट्रैंगलर फ़िग पैटर्न का मूल विचार वृद्धिशील प्रवासन है। पूरे सिस्टम को माइग्रेट करने के बजाय, आप एक समय में एक छोटी सुविधा या “स्लाइस” को माइग्रेट करते हैं।

माइग्रेशन प्रक्रिया पाँच प्रमुख चरणों में निष्पादित की जाती है:

1. एक बंधे हुए संदर्भ को पहचानें

अपने मोनोलिथ को देखें और एक एकल, स्व-निहित व्यावसायिक क्षमता की पहचान करें जिसे निकालना आसान हो। अच्छे उम्मीदवारों में शामिल हैं:

• विशेषताएँ जो बार-बार बदलती रहती हैं (इसलिए स्वतंत्र तैनाती से टीम को शीघ्र लाभ होता है)।
• माइग्रेशन पाइपलाइन का परीक्षण करने के लिए सरल, कम जोखिम वाली सुविधाएँ (जैसे स्थिर FAQ या उपयोगकर्ता प्राथमिकताएँ अनुभाग)।
• स्वच्छ, अच्छी तरह से परिभाषित डेटाबेस सीमाओं वाली सुविधाएँ।

2. नई माइक्रोसर्विस लागू करें

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

3. अवरोधन परत का परिचय दें

अपने उपयोगकर्ताओं के लिए माइग्रेशन को पारदर्शी बनाने के लिए, आप एप्लिकेशन के सामने एक इंटरसेप्शन लेयर (जैसे एपीआई गेटवे या रिवर्स प्रॉक्सी) पेश करते हैं। अब सारा ग्राहक ट्रैफ़िक सबसे पहले इसी गेटवे पर जाता है।

प्रारंभ में, गेटवे सभी अनुरोधों का 100% लीगेसी मोनोलिथ तक पहुंचाता है।

4. यातायात में वृद्धिशील परिवर्तन

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

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

5. डीकमीशन और दोहराव

नई माइक्रोसर्विस कुछ समय तक स्थिर रूप से चलने के बाद, आप लीगेसी मोनोलिथ के अंदर संबंधित कोड को सुरक्षित रूप से हटा सकते हैं।

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

इंटरसेप्शन लेयर: एक्सप्रेस रूटिंग उदाहरण

स्ट्रैंगलर फ़िग पैटर्न का हृदय इंटरसेप्शन परत है। यह आपको क्लाइंट एप्लिकेशन (वेब ​​ऐप्स, मोबाइल ऐप्स) को संशोधित किए बिना अनुरोधों को पुनर्निर्देशित करने की अनुमति देता है।

यहां एक्सप्रेस-आधारित गेटवे प्रॉक्सी का उपयोग करके एक व्यावहारिक Node.js उदाहरण दिया गया है। यह अनुरोधों को गतिशील रूप से रूट करता है: आने वाले अनुरोध नई सेवाओं पर जाते हैं यदि वे माइग्रेट किए गए पथों से मेल खाते हैं; अन्यथा, वे विरासती मोनोलिथ में वापस आ जाते हैं।

const express = require('express');
const { createProxyMiddleware } = require('http-proxy-middleware');
const app = express();
const PORT = 8080;

// Configuration: Target server URLs
const LEGACY_MONOLITH_URL = 'http://legacy-monolith-server:3000';
const NEW_USER_SERVICE_URL = 'http://new-user-service:3001';
const NEW_PAYMENT_SERVICE_URL = 'http://new-payment-service:3002';

// Simple logging middleware to track traffic distribution
app.use((req, res, next) => {
    console.log(`[ROUTE LOG] Incoming request: ${req.method} ${req.url}`);
    next();
});

// 1. MIGRATED: User registration & profile requests route to the new microservice
app.use('/api/users', createProxyMiddleware({
    target: NEW_USER_SERVICE_URL,
    changeOrigin: true,
    pathRewrite: {
        '^/api/users': '/v1/users', // Translate path format if necessary
    }
}));

// 2. MIGRATED: Payment transactions route to the new payment microservice
app.use('/api/payments', createProxyMiddleware({
    target: NEW_PAYMENT_SERVICE_URL,
    changeOrigin: true
}));

// 3. FALLBACK: All other legacy routes automatically default to the Monolith
app.use('/', createProxyMiddleware({
    target: LEGACY_MONOLITH_URL,
    changeOrigin: true
}));

app.listen(PORT, () => {
    console.log(`Interception Gateway routing traffic successfully on port ${PORT}`);
});

डेटाबेस को संभालना: सबसे कठिन हिस्सा

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

जब आप कोई सेवा निकालते हैं, तो आपको उसका डेटा भी निकालना होगा। इसे संभालने के दो सामान्य दृष्टिकोण हैं:

1. दोहरा लेखन: इंटरसेप्शन परत या एप्लिकेशन संक्रमण चरण के दौरान पुराने डेटाबेस और नए सेवा डेटाबेस दोनों पर एक साथ डेटा लिखता है। यह दोनों डेटाबेस को सिंक में रखता है।
2. डेटा कैप्चर बदलें (सीडीसी): डेबेज़ियम जैसा उपकरण पुराने डेटाबेस लेनदेन लॉग की निगरानी करता है और वास्तविक समय में नए माइक्रोसर्विस डेटाबेस में परिवर्तनों को स्वचालित रूप से स्ट्रीम करता है।

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

तुलना: बिग बैंग रीराइट बनाम स्ट्रैंगलर चित्र

निष्कर्ष

स्ट्रैंगलर फिग पैटर्न मोनोलिथ को माइक्रोसर्विसेज में स्थानांतरित करने के लिए उद्योग मानक है। लीगेसी कोड को एक साथ बदलने के बजाय धीरे-धीरे बदलकर, आप “बिग बैंग” विफलता के जोखिम को समाप्त कर देते हैं।

यह तैनाती को छोटा रखता है, वास्तविक उत्पादन ट्रैफ़िक से त्वरित प्रतिक्रिया प्रदान करता है, और आपकी टीम को प्रवासन जीवनचक्र के दौरान व्यावसायिक मूल्य प्रदान करना जारी रखने की अनुमति देता है।

डेटाबेस माइग्रेशन को प्रबंधित करने और दो समानांतर सिस्टम चलाने से परिचालन जटिलता बढ़ जाती है, इसके द्वारा प्रदान की जाने वाली सुरक्षा, पूर्वानुमान और स्थिरता इसे आधुनिक क्लाउड माइग्रेशन के लिए पसंदीदा विकल्प बनाती है।

ग़ज़निक्स ब्लॉग पर अधिक सॉफ़्टवेयर विकास और बैकएंड इंजीनियरिंग अंतर्दृष्टि का अन्वेषण करें →