در دام "خدمات کوچک جالب هستند" نیفتید و بدانید چه زمانی باید به یکپارچه بچسبید

مونولیت ها و میکروسرویس ها دو رویکرد اساسی برای کاربردهای ساختمانی هستند. برخی آنها را به ترتیب میراثی و مدرن می دانند. اما این کاملا درست نیست. انتخاب بین آنها یک سوال بسیار پیچیده است که هر دو مزایا و معایب خود را دارند.

اکثر برنامه های جدید از همان ابتدا نیازی به میکروسرویس ندارند. سریع‌تر، آسان‌تر و ارزان‌تر است که به‌عنوان یکپارچه شروع به کار کنید و در صورت مفید بودن، بعداً به میکروسرویس‌ها بروید.

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

در این مقاله قصد نداریم مونولیت ها را با میکروسرویس ها مقایسه کنیم. در عوض، در مورد ملاحظات، الگوها و اصولی بحث خواهیم کرد که به شما کمک خواهند کرد:

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

یکپارچه مدولار

اولین کاری که باید انجام دهید این است که به ساختار پروژه خود نگاه کنید. اگر ماژول ندارید، اکیداً توصیه می کنم آنها را در نظر بگیرید. آنها شما را وادار نمی کنند که معماری خود را به میکروسرویس ها تغییر دهید (که خوب است زیرا ما می خواهیم از تمام تعمیرات مربوطه جلوگیری کنیم) اما مزایای زیادی از آنها می گیریم.

بسته به ابزار اتوماسیون ساخت پروژه خود (به عنوان مثال، maven، gradle یا موارد دیگر)، می توانید پروژه خود را به ماژول های جداگانه و مستقل تقسیم کنید. برخی از ماژول‌ها ممکن است برای دیگران مشترک باشند، در حالی که برخی دیگر ممکن است حوزه‌های دامنه خاصی را در بر گیرند یا ویژگی‌های خاصی داشته باشند و عملکرد مستقلی را به برنامه شما بیاورند.

مزایای زیر را به شما خواهد داد:

1. بخش های جدا شده از برنامه شما
2. ویژگی ها را می توان به طور مستقل توسعه داد و تضادها را به حداقل رساند.
3. سوار شدن به افراد جدید بسیار ساده تر است زیرا آنها نیازی به فرو رفتن عمیق در کل پروژه ندارند. در عوض، آنها می توانند از قسمت های جدا شده شروع کنند.
4. تست بهبود یافته، زیرا اکنون می توانید هر ماژول را جداگانه آزمایش کنید.
5. اگر در نهایت نیاز به مهاجرت به میکروسرویس دارید، پایه بسیار قوی برای آن دارید.

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

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

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

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

برای اجرای الگوی Strangler Fig، باید سه مرحله را دنبال کنید:

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

با انجام این سه مرحله، به تدریج یکپارچه را به میکروسرویس تبدیل خواهید کرد.

مزایای کلیدی استفاده از الگوی Strangler Fig عبارتند از:

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

مسائل و ملاحظات

هنگام اعمال الگوی Strangler Fig، باید استراتژی مهاجرت را به دقت برنامه ریزی کنید. این شامل شناسایی اجزایی است که باید ابتدا جایگزین شوند، اطمینان از یکپارچگی مناسب بین قطعات قدیمی و جدید، و حفظ مدل های داده سازگار. تیم‌ها همچنین باید کانال‌های ارتباطی و سیستم‌های نظارتی شفافی برای ردیابی پیشرفت و تأثیر هر جایگزین ایجاد کنند.

پیامدهای مهاجرت میکروسرویس ها

همانطور که قبلاً بحث کردیم، انتقال به میکروسرویس ها مزایایی به همراه دارد. با این حال، بسیاری از چیزهای دیگر را نیز سخت تر و گران تر می کند.

برای مثال، تیم‌های QA و Dev ممکن است با وضعیتی مواجه شوند که دیگر نتوانند روی ماشین‌های محلی آزمایش کنند، زیرا توانایی اجرای چندین میکروسرویس به صورت محلی محدود است. یا ممکن است گزارش‌های شما کمتر روشنگر شوند، زیرا به جای اینکه یک سرویس یک جریان واحد را پردازش کند، اکنون چندین سرویس آن را پردازش می‌کنند. در نتیجه، برای مشاهده توالی گزارش کامل، باید ابزار دقیق و ردیابی مناسب را پیاده سازی کنید.

بیایید چند جنبه مهم را که باید در نظر بگیرید و شاید قبل از شروع تحول میکروسرویس خود برنامه ریزی کنید، بحث کنیم.

استقرار و زیرساخت

مونولیت و میکروسرویس ها حداقل نیازهای زیرساختی متفاوتی دارند.

هنگام اجرای یک برنامه یکپارچه، معمولاً می توانید زیرساخت ساده تری را حفظ کنید. گزینه هایی مانند ماشین های مجازی یا راه حل های PaaS (مانند AWS EC2) کافی است. همچنین، می‌توانید بسیاری از مقیاس‌بندی، پیکربندی، ارتقاء و نظارت را به صورت دستی یا با ابزارهای ساده انجام دهید. در نتیجه، می‌توانید از راه‌اندازی‌های زیرساخت پیچیده اجتناب کنید و بدون نیاز به تخصص گسترده DevOps به توسعه‌دهندگان یا مهندسان پشتیبانی تکیه کنید.

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

لایه پلت فرم

حفظ یک برنامه یکپارچه نسبتا ساده است. اگر CVE ایجاد شود، وابستگی تحت تأثیر را در یک مکان به روز می کنید. آیا نیاز به استانداردسازی ارتباطات خدمات خارجی دارید؟ یک wrapper واحد را پیاده سازی کنید و از آن در کل پایگاه کد استفاده مجدد کنید.

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

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

نتیجه گیری

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

در این مقاله، مراحلی را که می توانید برای آماده شدن برای آن بردارید و به آرامی این فرآیند را طی کنید، مورد بحث قرار داده ایم. چسبیدن به الگوی Strangler Fig روند افزایشی را برای شما فراهم می کند و ثبات سیستم را در طول تحول تضمین می کند. همچنین، یکپارچه مدولار نه تنها می‌تواند یک مرحله آماده‌سازی مفید باشد، بلکه می‌تواند مزایایی را نیز به همراه داشته باشد که ممکن است شما را به تجدیدنظر در تصمیم تغییر میکروسرویس و اجتناب از پیچیدگی عملیاتی مربوطه ترغیب کند.