الگوی Strangler برای جایگزینی مقطعی و تدریجی سیستم قدیمی که Legacy System نامیده میشود، با سیستم مدرن و جدید ارائه شده است. این الگو سالها پیش توسط مارتین فاولر ارائه شد و در سال 2019 در مقاله جدیدی مارتین فاولر نام آن را به Strangler Fig تغییر داد. به تدریج که ویژگی های سیستم جدید جایگزین سیستم قدیمی می شود، نهایتا سیستم جدید تمام عملیات سیستم قبلی را پوشش داده و جایگزین آن می شود.

Strangler Pattern

صورت مساله

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

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

راه حل

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

Strangler Facade

این الگو کمک میکند که ریسک انتقال کاهش یابد و کنترل بیشتری روی زمان جایگزینی سیستم قدیمی با جدید وجود دارد. به تدریج و بر اساس اولویت میتوان برای بخش های مختلف سیستم، کدهای قدیمی را با تکه کدهای جدید جایگزین کرد و میتوان در صورت درخواست جدید حتی ویژگی ها و عملیات جدید به سیستم اضافه نمود. به مرور زمان که سیستم جدید جایگزین سیستم قدیمی میشود نهایتا سیستم قدیمی اصطلاحا خفه شده (Strangled) و سیستم جدید جایگزین آن می شود.

نکات و ملاحظات الگوی Strangler

  • ممکن است نیاز باشد هر دو سیستم قدیمی و جدید بتوانند به سرویسها و یا جداولی از پایگاه داده به طور همزمان دسترسی داشته باشند. این دسترسی باید بدون ایجاد مشکل برقرار شود.
  • هر سیستمی بالاخره در آینده Legacy خواهد شد. بنابراین سیستم های جدید باید طوری طراحی شوند که به راحتی بتوان برای آنها لایه Strangler Facade ایجاد و با سیستمهای جدید جایگزین کرد.
  • زمانی که عملیات جایگزینی کامل شد، ممکن است لایه Facade کلا از بین برود و یا برای کلاینت های قدیمی به Adapter تبدیل شود.
  • از آنجا که تمام درخواستها به لایه Facade میرسد، باید خاطر جمع شویم که لایه Facade با خطا مواجه نشود. یا به عبارتی Single Point Of Failure رخ ندهد.

چه زمانی از الگوی Strangler استفاده کنیم؟

از این الگو زمانی استفاده می کنیم که قصد داریم معماری backend یک سیستم قدیمی را تغییر دهیم. برای مثال زمانی که بخواهیم یک سیستم یکپارچه را با معماری میکروسرویس ها بازنویسی کنیم.

این الگو برای موارد زیر مناسب نیست:

  • زمانی که درخواست های ارسالی به Backend را نتوان قطع کرد و interceptor نوشت و یا به عبارتی زمانی که نتوانیم لایه Facade را ایجاد نماییم.
  • برای سیستم های کوچک که جایگزینی آنها چالش سیستم های بزرگ را ندارد و به یکباره می توان این جایگزینی را انجام داد.

مقالات مرتبط