الگوی انجیر خفه کننده: راهی مطمئن برای مهاجرت برنامه های یکپارچه

در مهندسی نرم افزار مدرن، برنامه های کاربردی یکپارچه قدیمی یک چالش رایج هستند. با گذشت زمان، یک پایگاه کد موفق به قدری بزرگ و به هم مرتبط می شود که ایجاد تغییرات ساده خطرناک می شود، استقرار ساعت ها طول می کشد و مقیاس بندی ویژگی های فردی عملاً غیرممکن است.

وقتی تیم‌ها تصمیم می‌گیرند سیستم‌های خود را با مهاجرت به میکروسرویس‌ها مدرن‌سازی کنند، با یک سوال پرمخاطب مواجه می‌شوند: چگونه سیستم را بدون شکستن کسب‌وکار فعلی‌مان بازنویسی کنیم؟

یکی از گزینه‌ها بازنویسی «بیگ بنگ» است – ساختن سیستم جدید از ابتدا پشت درهای بسته و تغییر همه چیز در یک روز. با این حال، این فوق العاده خطرناک است و اغلب منجر به شکست می شود.

خوشبختانه، یک جایگزین مطمئن تر و مطمئن تر وجود دارد: ** الگوی خفه کننده انجیر **. در این راهنما، ما به بررسی الگوی Strangler Fig چیست، چرا کار می‌کند و چگونه می‌توان آن را گام به گام با استفاده از نمودارهای واضح و کدهای واقعی اعمال کرد.

قیاس دنیای واقعی: گیاه انجیر خفه کننده

این الگو برگرفته از انجیر خفه کننده، گیاهی بومی جنگل های بارانی استوایی است.

یک بذر انجیر خفه کننده در شاخه های بالایی یک درخت “میزبان” موجود جوانه می زند. انجیر به جای رشد از زمین به سمت پایین رشد می کند:

1. ریشه ها را به پایین تنه درخت میزبان می فرستد تا به کف جنگل برسند و در خاک لنگر بیاندازند.
2. با گذشت زمان، ریشه های بیشتری رشد می کنند، به دور میزبان می پیچند و به هم می پیوندند.
3. انجیر برگ هایی می روید که مانع از رسیدن نور به درخت میزبان می شود.
4. سرانجام درخت میزبان می میرد و می پوسد و درخت انجیر خفه کننده توخالی به شدت در جای خود ایستاده است.

در معماری نرم‌افزار، مونولیت میراث درخت میزبان است و ریزسرویس‌های جدید شکل خفه‌کننده هستند. ما سرویس‌های جدید را در اطراف لبه‌های یکپارچه می‌سازیم، به تدریج ترافیک را از سیستم قدیمی دور می‌کنیم تا زمانی که یکپارچه به طور کامل خاموش شود.

چرا “بیگ بنگ” بازنویسی می کند شکست می خورد

قبل از فرو رفتن در مکانیک الگوی Strangler Fig، بیایید درک کنیم که چرا جایگزین - بازنویسی کامل - بسیار خطرناک است:

• بدون ارزش برای ماه ها (یا سال ها): توسعه دهندگان زمان زیادی را صرف نوشتن کد می کنند، اما هیچ کدام از آن ها تا زمانی که کل پروژه کامل نشود، فعال نمی شود.
• Scope Creep: در طول یک بازنویسی دو ساله، نیازهای کسب و کار تغییر می کند. هدف حرکت می کند و سیستم جدید باید از ویژگی هایی پشتیبانی کند که در زمان شروع بازنویسی وجود نداشتند.
• رفتار ضمنی از دست رفته: یکپارچه ها حاوی سال ها رفع اشکال غیرمستند و رسیدگی به موارد لبه هستند. یک بازنویسی ساده اغلب این جزئیات را فراموش می کند.
• خطر استقرار بالا: خاموش کردن یک سیستم قدیمی قدیمی و روشن کردن یک سیستم جدید به یکباره، شعاع انفجار عظیمی را در صورت بروز مشکل ایجاد می کند.

الگوی انجیر خفه کننده چگونه کار می کند

ایده اصلی الگوی Strangler Fig ** مهاجرت تدریجی ** است. به جای انتقال کل سیستم، یک ویژگی کوچک یا “برش” را در یک زمان منتقل می کنید.

فرآیند مهاجرت در پنج مرحله کلیدی اجرا می شود:

1. یک زمینه محدود را شناسایی کنید

به یکپارچگی خود نگاه کنید و یک قابلیت تجاری واحد و مستقل را شناسایی کنید که استخراج آن آسان است. نامزدهای خوب عبارتند از:

• ویژگی هایی که اغلب تغییر می کنند (بنابراین تیم به سرعت از استقرار مستقل بهره مند می شود).
• ویژگی‌های ساده و کم خطر (مانند سؤالات متداول ثابت یا بخش ترجیحات کاربر) برای آزمایش خط لوله مهاجرت.
• ویژگی هایی با مرزهای پایگاه داده تمیز و به خوبی تعریف شده.

2. Microservice جدید را پیاده سازی کنید

قابلیت شناسایی شده را به عنوان یک میکروسرویس کاملاً جدید و مدرن ایجاد کنید. این سرویس دارای پایگاه داده خاص خود، خط لوله استقرار خود است و با استفاده از پشته های فناوری مدرن ساخته شده است. مهمتر از همه، ویژگی قدیمی در یکپارچه در حال حاضر فعال و بدون تغییر باقی مانده است.

3. لایه Interception را معرفی کنید

برای شفاف سازی انتقال برای کاربران خود، یک لایه رهگیری (مانند یک دروازه API یا پروکسی معکوس) را در جلوی برنامه معرفی می کنید. اکنون تمام ترافیک مشتری ابتدا به این دروازه می رود.

در ابتدا، دروازه 100٪ از تمام درخواست ها را به یکپارچه قدیمی هدایت می کند.

4. انتقال ترافیک به صورت افزایشی

هنگامی که میکروسرویس جدید به طور کامل آزمایش و آماده شد، قوانین مسیریابی را در لایه Interception به روز می کنید. به جای مسیریابی درخواست‌ها برای ویژگی منتقل شده (به عنوان مثال، /api/users) به یکپارچه، دروازه آنها را به میکروسرویس جدید هدایت می‌کند.

تمام درخواست های دیگر همچنان به یکپارچه می روند. اگر سرویس جدید از کار افتاد یا باگ‌هایی را نشان داد، می‌توانید به سرعت دروازه را به‌روزرسانی کنید تا ترافیک را به یکپارچه بازگرداند و از حداقل اختلال اطمینان حاصل کنید.

5. از کار افتادن و تکرار

پس از اینکه میکروسرویس جدید برای مدتی به طور پایدار اجرا شد، می‌توانید با خیال راحت کد مربوطه را در یکپارچه قدیمی حذف کنید.

سپس ویژگی بعدی را انتخاب کرده و روند را تکرار کنید. با گذشت زمان، یکپارچه کوچک می شود تا زمانی که ترافیکی باقی نماند، و می توانید سرور قدیمی را به طور کامل از کار بیندازید.

لایه رهگیری: مثال مسیریابی سریع

قلب الگوی Strangler Fig لایه رهگیری است. این به شما امکان می دهد بدون تغییر برنامه های مشتری (برنامه های وب، برنامه های تلفن همراه) درخواست ها را تغییر مسیر دهید.

در اینجا یک مثال کاربردی Node.js با استفاده از پروکسی دروازه مبتنی بر Express آورده شده است. درخواست‌ها را به صورت پویا مسیریابی می‌کند: درخواست‌های دریافتی اگر با مسیرهای انتقال‌یافته مطابقت داشته باشند، به سرویس‌های جدید می‌روند. در غیر این صورت، آنها به یکپارچگی میراث باز می گردند.

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 نسبتا آسان است، مدیریت داده ها چالش برانگیزترین جنبه مهاجرت یکپارچه است. یک مونولیت معمولاً دارای یک پایگاه داده واحد و عظیم است که جداول در آن به شدت به هم متصل شده اند.

هنگامی که یک سرویس را استخراج می کنید، باید داده های آن را نیز استخراج کنید. دو رویکرد رایج برای رسیدگی به این موضوع وجود دارد:

1. Dual Writes: لایه رهگیری یا برنامه کاربردی داده ها را در پایگاه داده قدیمی و پایگاه داده سرویس جدید به طور همزمان در مرحله انتقال می نویسد. این هر دو پایگاه داده را همگام نگه می دارد.
2. Change Data Capture (CDC): ابزاری مانند Debezium گزارش تراکنش های پایگاه داده قدیمی را نظارت می کند و به طور خودکار تغییرات را در پایگاه داده میکروسرویس جدید در زمان واقعی پخش می کند.

هنگامی که مطمئن شدید پایگاه‌های داده کاملاً همگام هستند و پایگاه داده جدید درست است، ترافیک خوانده شده را به سرویس جدید تغییر می‌دهید و جداول قدیمی را می‌بندید.

مقایسه: بیگ بنگ بازنویسی در مقابل خفه کننده شکل

نتیجه گیری

الگوی Strangler Fig استاندارد صنعتی برای مهاجرت مونولیت ها به میکروسرویس ها است. با تعویض تدریجی کدهای قدیمی و نه یکباره، خطر شکست “بیگ بنگ” را از بین می برید.

استقرارها را کوچک نگه می‌دارد، بازخورد فوری از ترافیک تولید واقعی ارائه می‌کند و به تیم شما اجازه می‌دهد تا به ارائه ارزش تجاری در طول چرخه عمر مهاجرت ادامه دهد.

در حالی که مدیریت مهاجرت پایگاه داده و اجرای دو سیستم موازی به پیچیدگی عملیاتی می‌افزاید، اما ایمنی، پیش‌بینی‌پذیری و ثباتی که ارائه می‌دهد، آن را به انتخاب مطلوب برای مهاجرت‌های ابری مدرن تبدیل می‌کند.

درباره توسعه نرم‌افزار بیشتر و بینش‌های مهندسی باطن در Ghaznix Blog →