Strangler Fig پیٹرن: یک سنگی ایپلی کیشنز کو منتقل کرنے کا ایک محفوظ طریقہ
جدید سافٹ ویئر انجینئرنگ میں، میراثی یک سنگی ایپلی کیشنز ایک مشترکہ چیلنج ہیں۔ وقت گزرنے کے ساتھ، ایک کامیاب کوڈبیس اتنا بڑا اور باہم جڑ جاتا ہے کہ سادہ تبدیلیاں کرنا خطرناک ہو جاتا ہے، تعیناتی میں گھنٹے لگتے ہیں، اور انفرادی خصوصیات کو پیمانہ کرنا عملی طور پر ناممکن ہے۔
جب ٹیمیں مائیکرو سروسز میں منتقل ہو کر اپنے سسٹمز کو جدید بنانے کا فیصلہ کرتی ہیں، تو انہیں ایک اعلیٰ سوال کا سامنا کرنا پڑتا ہے: ہم اپنے موجودہ کاروبار کو توڑے بغیر سسٹم کو دوبارہ کیسے لکھیں گے؟
ایک آپشن “بگ بینگ” کو دوبارہ لکھنا ہے — بند دروازوں کے پیچھے شروع سے نئے نظام کی تعمیر اور ایک ہی دن میں ہر چیز کو تبدیل کرنا۔ تاہم، یہ ناقابل یقین حد تک خطرناک ہے اور اکثر ناکامی کا باعث بنتا ہے۔
خوش قسمتی سے، ایک محفوظ، زیادہ قابل اعتماد متبادل ہے: Strangler Fig Pattern۔ اس گائیڈ میں، ہم دریافت کریں گے کہ Strangler Fig پیٹرن کیا ہے، یہ کیوں کام کرتا ہے، اور واضح خاکوں اور حقیقی دنیا کے کوڈ کا استعمال کرتے ہوئے اسے مرحلہ وار کیسے لاگو کیا جائے۔
حقیقی دنیا کی تشبیہ: اسٹرینگلر فِگ پلانٹ
اس پیٹرن کا نام strangler fig کے نام پر رکھا گیا ہے، یہ ایک پودا ہے جو اشنکٹبندیی بارشی جنگلات کا ہے۔
ایک اجنبی انجیر کا بیج موجودہ “میزبان” درخت کی اوپری شاخوں میں اگتا ہے۔ انجیر زمین سے اوپر اگنے کے بجائے نیچے کی طرف بڑھتا ہے:
- یہ میزبان درخت کے تنے کے نیچے جڑوں کو بھیجتا ہے جب تک کہ وہ جنگل کے فرش تک نہ پہنچ جائیں اور مٹی میں لنگر انداز ہو جائیں۔
- وقت گزرنے کے ساتھ، مزید جڑیں اگتی ہیں، میزبان کے گرد لپیٹتی ہیں، اور ایک ساتھ مل جاتی ہیں۔
- انجیر پتے اگاتا ہے جو روشنی کو میزبان درخت تک پہنچنے سے روکتا ہے۔
- آخرکار، میزبان کا درخت مر جاتا ہے اور سڑ جاتا ہے، جس سے ایک کھوکھلا اجنبی انجیر کا درخت اپنی جگہ مضبوطی سے کھڑا رہتا ہے۔
سافٹ ویئر کے فن تعمیر میں، لیگیسی یک سنگی میزبان درخت ہے، اور نئی مائیکرو سروسز ایک سٹریگلر انجیر ہیں۔ ہم یک سنگی کے کناروں کے ارد گرد نئی سروسز بناتے ہیں، دھیرے دھیرے ٹریفک کو میراثی نظام سے دور کر دیتے ہیں جب تک کہ یک سنگی مکمل طور پر بند نہ ہو جائے۔
کیوں “بگ بینگ” دوبارہ لکھنا ناکام ہوتا ہے۔
Strangler Fig پیٹرن کے میکانکس میں غوطہ لگانے سے پہلے، آئیے سمجھتے ہیں کہ متبادل — ایک مکمل دوبارہ لکھنا — اتنا خطرناک کیوں ہے:
- مہینوں (یا سالوں) کی کوئی قیمت نہیں: ڈویلپرز کوڈ لکھنے میں ایک طویل وقت صرف کرتے ہیں، لیکن اس میں سے کوئی بھی اس وقت تک زندہ نہیں ہوتا جب تک کہ پورا پروجیکٹ مکمل نہ ہوجائے۔
- اسکوپ کریپ: دو سالہ دوبارہ لکھنے کے دوران، کاروبار میں تبدیلی کی ضرورت ہے۔ ٹارگٹ حرکت کرتا ہے، اور نئے سسٹم کو ان خصوصیات کو سپورٹ کرنا ہوتا ہے جو دوبارہ لکھنا شروع ہونے پر موجود نہیں تھیں۔
- گمشدہ مضمر رویہ: مونولتھس میں سالوں کی غیر دستاویزی بگ فکسس اور ایج کیس ہینڈلنگ شامل ہیں۔ کلین سلیٹ دوبارہ لکھنا اکثر ان تفصیلات کو بھول جاتا ہے۔ تعیناتی کا زیادہ خطرہ: بڑے پیمانے پر میراثی نظام کو بند کرنے اور ایک ہی وقت میں ایک نیا آن کرنے سے اگر کچھ غلط ہو جاتا ہے تو بڑے پیمانے پر دھماکے کا رداس پیدا ہوتا ہے۔
Strangler Fig پیٹرن کیسے کام کرتا ہے۔
Strangler Fig پیٹرن کا بنیادی خیال بڑھتی ہوئی منتقلی ہے۔ پورے نظام کو منتقل کرنے کے بجائے، آپ ایک وقت میں ایک چھوٹی خصوصیت یا “سلائس” کو منتقل کرتے ہیں۔
نقل مکانی کے عمل کو پانچ اہم مراحل میں انجام دیا جاتا ہے:
1. ایک پابند سیاق و سباق کی شناخت کریں۔
اپنے یک سنگی کو دیکھیں اور ایک واحد، خود ساختہ کاروباری صلاحیت کی نشاندہی کریں جسے نکالنا آسان ہے۔ اچھے امیدواروں میں شامل ہیں:
- وہ خصوصیات جو کثرت سے تبدیل ہوتی ہیں (لہذا ٹیم آزاد تعیناتیوں سے جلد فائدہ اٹھاتی ہے)۔
- نقل مکانی کی پائپ لائن کو جانچنے کے لیے آسان، کم خطرے والی خصوصیات (جیسے جامد اکثر پوچھے گئے سوالات یا صارف کی ترجیحات کا سیکشن)۔
- صاف، اچھی طرح سے طے شدہ ڈیٹا بیس کی حدود کے ساتھ خصوصیات۔
2. نئی مائیکرو سروس کو لاگو کریں۔
ایک بالکل نئی، جدید مائیکرو سروس کے طور پر شناخت شدہ صلاحیت کو تیار کریں۔ اس سروس کا اپنا ڈیٹا بیس ہے، اس کی اپنی تعیناتی پائپ لائن ہے، اور اسے جدید ٹیک اسٹیکوں کا استعمال کرتے ہوئے بنایا گیا ہے۔ اہم بات یہ ہے کہ یک سنگی میں پرانی خصوصیت ابھی تک فعال اور غیر تبدیل شدہ ہے۔
3. انٹرسیپشن لیئر متعارف کروائیں۔
اپنے صارفین کے لیے منتقلی کو شفاف بنانے کے لیے، آپ ایپلیکیشن کے سامنے ایک انٹرسیپشن لیئر (جیسے API گیٹ وے یا ریورس پراکسی) متعارف کراتے ہیں۔ کلائنٹ کی تمام ٹریفک اب پہلے اس گیٹ وے پر جاتی ہے۔
ابتدائی طور پر، گیٹ وے تمام درخواستوں کا 100% میراثی یک سنگی تک پہنچاتا ہے۔
4. ٹرانزیشن ٹریفک میں اضافہ
ایک بار جب نئی مائیکرو سروس مکمل طور پر ٹیسٹ اور تیار ہو جاتی ہے، تو آپ انٹرسیپشن لیئر میں روٹنگ کے قواعد کو اپ ڈیٹ کرتے ہیں۔ منتقلی کی خصوصیت (مثلاً /api/users) کی درخواستوں کو یک سنگی پر روٹ کرنے کے بجائے، گیٹ وے انہیں نئی مائیکرو سروس پر بھیج دیتا ہے۔
باقی تمام درخواستیں یکجہتی پر جاتی رہیں۔ اگر نئی سروس ناکام ہو جاتی ہے یا کیڑے ظاہر کرتی ہے، تو آپ گیٹ وے کو فوری طور پر اپ ڈیٹ کر سکتے ہیں تاکہ ٹریفک کو یک سنگی کی طرف لے جایا جا سکے، کم سے کم خلل کو یقینی بنا کر۔
5. منسوخی اور دہرائیں۔
نئی مائیکرو سروس کے کچھ عرصے تک مستقل طور پر چلنے کے بعد، آپ محفوظ طریقے سے متعلقہ کوڈ کو میراثی یک سنگی کے اندر حذف کر سکتے ہیں۔
پھر آپ اگلی خصوصیت کو منتخب کریں اور عمل کو دہرائیں۔ وقت گزرنے کے ساتھ، یک سنگی سکڑ جاتا ہے جب تک کہ اس میں کوئی ٹریفک باقی نہ رہے، اور آپ میراثی سرور کو مکمل طور پر ختم کر سکتے ہیں۔
انٹرسیپشن لیئر: ایکسپریس روٹنگ کی مثال
Strangler Fig پیٹرن کا دل انٹرسیپشن لیئر ہے۔ یہ آپ کو کلائنٹ ایپلی کیشنز (ویب ایپس، موبائل ایپس) میں ترمیم کیے بغیر درخواستوں کو ری ڈائریکٹ کرنے کی اجازت دیتا ہے۔
یہاں ایکسپریس پر مبنی گیٹ وے پراکسی کا استعمال کرتے ہوئے ایک عملی 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}`);
});
ڈیٹا بیس کو ہینڈل کرنا: سب سے مشکل حصہ
اگرچہ API ٹریفک کو روٹ کرنا نسبتاً آسان ہے، ڈیٹا کا انتظام یک سنگی منتقلی کا سب سے مشکل پہلو ہے۔ ایک مونولیتھ میں عام طور پر ایک واحد، بڑے پیمانے پر ڈیٹا بیس ہوتا ہے جہاں میزیں بہت زیادہ جڑی ہوتی ہیں۔
جب آپ کوئی سروس نکالتے ہیں، تو آپ کو اس کا ڈیٹا بھی نکالنا چاہیے۔ اس سے نمٹنے کے لیے دو عام طریقے ہیں:
- دوہری تحریریں: انٹرسیپشن لیئر یا ایپلی کیشن منتقلی کے مرحلے کے دوران بیک وقت لیگیسی ڈیٹا بیس اور نئے سروس ڈیٹا بیس دونوں کو ڈیٹا لکھتی ہے۔ یہ دونوں ڈیٹا بیس کو مطابقت پذیر رکھتا ہے۔
- **ڈیٹا کیپچر کو تبدیل کریں (CDC): Debezium جیسا ٹول لیگیسی ڈیٹا بیس ٹرانزیکشن لاگ کی نگرانی کرتا ہے اور خود بخود تبدیلیوں کو نئے مائیکرو سرویس ڈیٹا بیس میں تقریباً حقیقی وقت میں اسٹریم کرتا ہے۔
ایک بار جب آپ کو یقین ہو جائے کہ ڈیٹا بیس مکمل طور پر مطابقت پذیر ہیں اور نیا ڈیٹا بیس درست ہے، تو آپ پڑھنے والی ٹریفک کو نئی سروس میں تبدیل کر دیتے ہیں اور لیگیسی ٹیبلز کو بند کر دیتے ہیں۔
موازنہ: بگ بینگ ری رائٹ بمقابلہ اسٹرینگلر تصویر
| فیچر / میٹرک | بگ بینگ دوبارہ لکھنا | گلا گھونٹنے والا انجیر کا نمونہ |
|---|---|---|
| خطرے کی سطح | انتہائی اعلیٰ | کم اور منظم |
| فیڈ بیک لوپ | بہت سست (صرف آخر میں) | تیز (مسلسل پیداوار کی جانچ) |
| رول بیک حکمت عملی | مشکل (بیک اپ بحال کرنے کی ضرورت ہے) | آسان (گیٹ وے میں راستے کے قوانین کو تبدیل کریں) |
| کاروباری اثرات | خلل ڈالنے والا | زیرو ڈاؤن ٹائم |
| نظام کی پیچیدگی | اعلی (تعمیر کے مرحلے کے دوران) | ہائی (ہجرت کے مرحلے کے دوران) |
| تعیناتی وقت | بڑے پیمانے پر سنگل ریلیز | چھوٹے، بار بار اپ ڈیٹس |
نتیجہ
Strangler Fig پیٹرن مائیکرو سروسز میں یک سنگی کو منتقل کرنے کے لیے صنعت کا معیار ہے۔ میراثی کوڈ کو ایک ساتھ تبدیل کرنے کی بجائے بتدریج تبدیل کر کے، آپ “بگ بینگ” کی ناکامی کے خطرے کو ختم کر دیتے ہیں۔
یہ تعیناتیوں کو چھوٹا رکھتا ہے، حقیقی پیداواری ٹریفک سے فوری تاثرات فراہم کرتا ہے، اور آپ کی ٹیم کو مائیگریشن لائف سائیکل کے دوران کاروباری قدر کی فراہمی جاری رکھنے کی اجازت دیتا ہے۔
ڈیٹابیس کی منتقلی کا انتظام کرنے اور دو متوازی نظام چلانے سے آپریشنل پیچیدگی میں اضافہ ہوتا ہے، لیکن یہ جو حفاظت، پیشن گوئی اور استحکام پیش کرتا ہے اسے جدید کلاؤڈ ہجرت کے لیے ترجیحی انتخاب بناتا ہے۔
غزنکس بلاگ پر مزید سافٹ ویئر ڈویلپمنٹ اور بیک اینڈ انجینئرنگ کی بصیرتیں دریافت کریں →