آموزش انتقال به معماری میکروسرویس ها یکی دیگر از آموزش های گروه آموزشی پرووید می باشد که در این قسمت آن را به شما معرفی می کنیم. این بسته ی آموزشی نیز یکی از دوره های آموزشی دیگر که در حوزه ی فارسی سازی آموزش های انگلیسی تنظیم شده است می باشد. عنوان این بسته ی آموزشی انتقال به معماری مایکروسرویسی است که با نام اصلی Your Microservices Transition از شرکت Pluralsight منتشر شده است.

معماری میکروسرویس ها

میکروسرویس ها اساساً سرویس های کوچکی هستند که به طور مستقل به عنوان بخشی از یک سیستم پیچیده تر کار می کنند. آنها به راحتی قابل مدیریت و قابل حمل و ایجاد هستند تا اهداف تجاری برنامه را به انجام برسانند. معماری میکروسرویسی را می توان با استفاده از زبان های برنامه نویسی مختلف مانند: جاوا، پایتون و PHP و Node.js توسعه داد.

میکروسرویس اجازه می دهد تا به طور مستقل بر روی سرویس های مختلف کار کنید بدون اینکه بر روی سایر کامپوننت ها تأثیر بگذارد. میکروسرویس ها اساساً همه چالش های معماری monolith را حل می کنند.

مزایای انتقال به میکروسرویس ها

مقیاس پذیری (Scalability): از آنجایی که معماری میکروسرویس ها مبتنی بر کامپوننت های کوچک است، مقیاس بندی آن بسیار ساده تر از معماری monolith است. این بدان معنی است که وقتی تغییرات بزرگ در یک کامپوننت خاص اتفاق می افتد، بقیه دست نخورده باقی می مانند و به درستی اجرا می شوند. این یک روش عالی برای شرکت هایی است که روی تعداد زیادی دستگاه و برنامه کار می کنند.

انعطاف پذیری : روش استفاده از روش مایکروسرویسی برنامه نویسان را از نظر ابزار ها و تکنولوژی ها محدود نمی کند. هر سرویس می تواند با فریم ورک و زبان متفاوتی ایجاد شود. این روش مناسب ترین تکنولوژی را برای نیازهای خاص سرویس شما ساده می کند. این موضوع که کامپوننت ها متفاوت هستند به هیچ وجه بر کار سایر میکروسرویس ها یا ارتباط بین آنها تأثیر نمی گذارد. میکروسرویس ها در استفاده از تکنولوژی ها شما را محدود نمی کنند، بر خلاف معماری Monolith که در کل فرآیند با یک تکنولوژی کار می کنید.

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

ارتباط آسان تر در تیم های توزیع شده: اگر تیم‌های راه دور با معماری میکروسرویس کار کنند، بسیار راحت‌تر عمل می‌کنند. میکروسرویس‌ها به برنامه نویسان این آزادی را می‌دهند تا بدون نیاز به منتظر ماندن برای تصمیم‌گیری کل تیم، مستقل کار کنند.

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

چه زمانی باید به میکروسرویس ها منتقل شوید؟

اگرچه میکروسرویس ها برای محصولات بزرگی که برنامه نویسان زیادی روی آنها کار می کنند مزایای زیادی به همراه دارد اما پروژه های کوچکتر معمولاً با monolith ساخته می شوند. توسعه و راه‌اندازی monolith ‌ها ارزان‌تر است زیرا از یک کد پایه تشکیل شده‌اند. به همین دلیل است که انتقال به میکروسرویس ها باید برنامه ریزی شده و تصمیمی بر اساس نیازها و قدرت شرکت باشد.

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

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

سرفصل مطالب آموزش ویدیویی انتقال به معماری مایکروسرویسی ها

فصل اول: مقدمه این دوره آموزشی

• مقدمه

فصل دوم: استراتژی انتقال به معماری مایکروسرویسی

• مقدمه
• بررسی معماری Monolith
• آموزش عملی: بررسی پروژه معماری Monolith
• نیاز به یک روش سیستماتیک
• بررسی Strangler Application Pattern
• رهگیری نقاط تعامل
• بررسی Interaction Point ها در معماری Monolith
• بررسی کلی دوره
• جمع بندی و راهنما

فصل سوم: انتقال اولین Capability به یک مایکروسرویس

• مقدمه
• شناسایی قابلیت های انتقال به مایکروسرویس ها
• شناسایی اولین قابلیت انتقال به مایکروسرویس ها
• ایجاد یک مایکروسرویس برای اولین قابلیت
• بررسی روش Shared Database از طریق Abstraction
• بررسی وابستگی های غیر موجود
• جمع بندی

فصل چهارم: رفع مشکل وابستگی های غیر موجود

• مقدمه
• وابستگی از مایکروسرویس به Monolith
• بررسی مساله Temporal Coupling
• وابستگی از Monolith به مایکروسرویس
• بررسی الگوی Feature Toggle Pattern
• حذف Temporal Coupling با استفاده از یک Cache
• جمع بندی

فصل پنجم: تکمیل کردن روال انتقال

• مقدمه
• انتقال دادن ترافیک به مایکروسرویس
• نسخه قدیمی قابلیت را حذف کنید
• تجزیه پایگاه داده
• چالش های تجزیه پایگاه داده
• جداسازی UI برای Decouple کردن Capability ها
• افزودن ویژگی های جدید در طول انتقال
• تکرار کردن روال برای کامل کردن انتقال به معماری مایکروسرویس ها
• بررسی کلی
• جمع بندی