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

تنظیم: از شیمی پایه تا مکانیک کوانتومی

راه‌اندازی یک پایگاه داده و برنامه کاربردی با فرآیند پس‌زمینه، فرآیندی نسبتاً ساده بود. من readme را در Github منتشر می کنم - و اغلب بعد از یک ساعت، حداکثر چند ساعت، همه چیز کار می کند، و من یک پروژه جدید را شروع می کنم. افزودن و اجرای کد، حداقل برای محیط اولیه، در روز اول انجام می شود. اما اگر به سمت میکروسرویس ها بپردازیم، زمان پرتاب اولیه سر به فلک می کشد. بله، اکنون Docker را با ارکستراسیون و مجموعه ای از ماشین های K8 داریم، اما برای یک برنامه نویس تازه کار همه اینها بسیار پیچیده تر است. برای بسیاری از نوجوانان، این باری است که واقعاً یک عارضه غیر ضروری است.

سیستم به راحتی قابل درک نیست

بیایید یک لحظه روی جوان خود تمرکز کنیم. با برنامه‌های یکپارچه، اگر خطایی رخ می‌داد، ردیابی آن آسان بود و بلافاصله به سراغ اشکال‌زدایی رفت. اکنون سرویسی داریم که با سرویس دیگری صحبت می کند که در یک گذرگاه پیام که در حال پردازش سرویس دیگری است، چیزی را در صف قرار می دهد - و سپس خطایی رخ می دهد. ما باید همه این قطعات را کنار هم بگذاریم تا در نهایت متوجه شویم که سرویس A نسخه 11 را اجرا می کند، و سرویس E در حال حاضر منتظر نسخه 12 است. این با گزارش تلفیقی استاندارد من بسیار متفاوت است: نیاز به استفاده از یک ترمینال/اشکال زدای تعاملی برای راه رفتن از طریق فرآیند مرحله به مرحله اشکال زدایی و درک ذاتاً دشوارتر شده است.

اگر نتوان آن را اشکال زدایی کرد، شاید آنها را آزمایش کنیم

ادغام مستمر و توسعه مستمر اکنون به امری عادی تبدیل شده است. اکثر برنامه‌های جدیدی که می‌بینم به‌طور خودکار با هر نسخه جدید آزمایش‌هایی را ایجاد و اجرا می‌کنند و قبل از ثبت‌نام نیاز به آزمایش و بررسی دارند. اینها فرآیندهای بزرگی هستند که نباید رها شوند و تغییر بزرگی برای بسیاری از شرکت ها بوده است. اما اکنون، برای اینکه واقعاً این سرویس را آزمایش کنم، باید یک نسخه کامل از برنامه خود را اجرا کنم. آن مهندس جدید با 8 سرویس K150 را به خاطر دارید؟ خوب، اکنون به سیستم CI خود آموزش می دهیم که چگونه همه این سیستم ها را برای تأیید اینکه همه چیز واقعاً کار می کند بالا بیاورد. این احتمالاً تلاش زیادی است، بنابراین ما فقط هر بخش را به صورت مجزا آزمایش می‌کنیم: من مطمئن هستم که مشخصات ما به اندازه کافی خوب است، APIها تمیز هستند، و خرابی سرویس جدا است و بر دیگران تأثیری نخواهد گذاشت.

همه مصالحه ها دلیل خوبی دارند. درست؟

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

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

منبع: www.habr.com