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

معماری میکروسرویس ها (Microservices Architecture) چیست؟

معماری مایکروسرویس ها که به آن Microservices Architecture یک سبک معماری است که در آن یک سیستم نرم افزاری از مجموعه ای از سرویس های کوچک و مستقل ایجاد می‌شود. هر سرویس اصطلاحاً Self-Contained و یا خودشمون می باشد و می بایست یک قابلیت تجاری تک را پیاده سازی کنند. به عبارت دیگر اصل Single Responsibility که در آموزش اصول سالید SOLID در برنامه نویسی شی گرا به آن پرداخته ایم یکی از ویژگی‌های مهم معماری مایکروسرویس ها می باشد. برخی از ویژگی های مهم مایکروسرویس ها در این سبک از معماری را در قسمت زیر با یکدیگر بررسی خواهیم کرد.

1. مایکروسرویس ها باید کوچک، مستقل و کاملا Loosely-coupled باشند.
2. یک تیم توسعه نرم‌افزار کوچک می تواند یک سرویس را نوشته و نگهداری کند.
3. هر مایکروسرویس  باید Code Base منحصر به فرد خود را داشته باشد که توسط یک تیم توسعه نرم افزار کوچک مدیریت می شود.
4. سرویس ها باید بتوانند مستقل از یکدیگر قابل Deploy کردن باشند.
5. یک تیم توسعه نرم‌افزار باید بتواند یک سرویس از قبل موجود را بدون نیاز به Rebuild کردن و یا Redeploy کردن تمامی اپلیکیشن بروزرسانی کند.
6. سرویس‌ها مسئول ذخیره‌سازی داده‌ها و External State خاص خود هستند. این موضوع نسبت به مدل‌های سنتی که در آنها یک Data Layer جداگانه مسئولیت Persistence سازی داده ها را به عهده دارند متفاوت است.
7. سرویس ها می توانند با یکدیگر با استفاده از API های خود ارتباط برقرار کنند.
8. جزئیات پیاده سازی درونی و یا Internal Implementation Detail هر کدام از سرویس ها از دیگر سرویس‌های مخفی خواهد بود.
9. در هر کدام از سرویس ها می توان از Technology Stack متفاوت و Library ها و کتابخانه های منحصر به فرد استفاده کرد.

در ادامه برخی از مزیت های مربوط به معماری مایکروسرویس ها را بررسی خواهیم کرد.

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

1. چابکی و یا Agility: از آنجایی که مایکروسرویس  ها به صورت مستقل از یکدیگر Deploy میشوند مدیریت کردن آنها و انجام Bug Fixing ها و Feature Release ها ساده تر خواهد بود.
2. امکان Redeploy کردن یک مایکروسرویس و به روزرسانی کردن آن بدون نیاز به Redeploy کردن کل یک اپلیکیشن وجود دارد.
3. در صورت نیاز می توان یک بروزرسانی را به سادگی Rollback کرد. در بسیاری از نرم افزارهای سنتی در زمان به وجود آمدن یک Bug در بخشی از برنامه می بایست که کل Release Process متوقف گردد و البته در چنین شرایطی Feature جدید نیازمند منتظر ماندن برای اشکال زدایی، یکپارچه‌سازی، تست کردن و سپس Publish نمودن نرم افزار خواهند بود.
4. تیم های توسعه نرم افزار کوچک و متمرکز: در معماری مایکروسرویس ها هر سرویس بسیار کوچک است و می‌تواند توسط یک تیم توسعه نرم افزار ساخته، تست کردن و Deploy بگردد. هر تیم می تواند با استفاده از Agility و یا چابکی بالایی، روند پیشرفت یک مایکروسرویس را رقم بزند. در تیم های توسعه نرم‌افزار پرجمعیت اغلب سطح تولید نرم افزار کاهش پیدا می‌کند، ارتباطات کند اتفاق می‌افتند و سربار مدیریتی نیز بسیار زیاد است. این موضوع در معماری میکروسرویس ها وجود ندارد.
5. اندازه کوچکتر Code Base: در اپلیکیشن‌های Monolithic امکان به وجود آمدن Dependency های مختلف و تودرتو وجود دارند. در چنین برنامه ها اضافه کردن یک Feature جدید نیازمند ایجاد تغییرات در قسمت‌های زیادی از خود می باشند. این موضوع در معماری مایکروسرویس ها به حداقل می رسد.
6. مایکروسرویس ها کد و  یا مخزن ذخیره داده های خود را با دیگر مایکروسرویس ها را به اشتراک نمی‌گذارند و به همین ترتیب Dependency ها در این نوع از معماری ها به حداقل می‌رسد و بنابراین اضافه کردن Feature های جدید به سادگی انجام پذیر است.
7. ترکیب تکنولوژی‌های مختلف: تیم های توسعه نرم افزار در معماری مایکروسرویس ها می تواند بر اساس نیازمندیهای هر کدام از سرویس ها از تکنولوژی‌های مختلف و متعدد استفاده کنند. به عبارت دیگر هر مایکروسرویس بر اساس نیاز متدی هایی که تعریف می‌کند می‌تواند از زبان های برنامه نویسی، فریم ورک ها، کتابخانه ها و بانک های اطلاعاتی متعدد و متنوعی استفاده نمایند.
8. ایزوله کردن و یا تفکیک کردن خطاها (Fault Isolation): با استفاده از معماری میکروسرویس ها زمانی که یک مایکروسرویس دچار مشکل می‌شود به دلیل عدم وجود Dependency و یا وابستگی بین آنها کل یک اپلیکیشن دچار اختلال نخواهد گردید. مایکروسرویس های دیگر می‌توانند با Handle کردن صحیح خطاهای رخ داده و پیاده سازی مکانیزم هایی از قبیل Circuit Breaking کار خود را ادامه بدهند.
9. مقیاس پذیری و یا Scalability: در معماری مایکروسرویس  ها امکان مقیاس پذیری و پیاده‌سازی کردن آن به طور مستقل در مایکروسرویس های مختلف به سادگی امکان پذیر است، از آنجایی که مایکروسرویس ها به یکدیگر حداقل وابستگی را دارند به سادگی می توان هر کدام از آنها را در صورت نیاز مقیاس کرد. علاوه بر این با استفاده از ابزراهای Orchestration هایی از قبیل Kubernetes و Service Fabric شما می توانید یک تراکم بالاتر از سرویس ها را به درون یک Host و یا یک میزبان تک قرار بدهید، که این موضوع باعث می‌شود سطح Utilization و یا استفاده کردن از منابع افزایش پیدا کند.
10. ایزوله کردن و یا تفکیک کردن داده ها (Data Isolation): از آنجایی که هر مایکروسرویس بانک اطلاعاتی و فضای ذخیره سازی و خاص خود را دارد، تغییر دادن Schema مربوط به هرکدام بسیار ساده تر انجام می شود این موضوع در اپلیکیشن‌های Monolithic به این سادگی نیست. در واقع در این نوع از اپلیکیشن‌ها بروزرسانی کردن Schema بانک اطلاعاتی بسیار چالش برانگیز می شود. دلیل این موضوع نیز در این قضیه نهفته است که قسمت‌های مختلف برنامه بر روی Schema بانک اطلاعاتی وابستگی دارند و تغییر در آن Schema باعث ایجاد تغییر در قسمتهای برنامه خواهد شد.

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

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

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

• مقدمه

فصل دوم: بررسی مزیتهای میکروسرویس ها

• تعریف کردن Monolith ها و مایکروسرویس ها
• مزیتهای استفاده از مایکروسرویس ها برای برنامه نویسها
• مزیتهای نگهداری و یا Maintenance مربوط به مایکروسرویس ها
• مزیتهای پایداری و یا Resilience مربوط به مایکروسرویس ها
• بررسی یک معماری مایکروسرویس نمونه
• جمع بندی

فصل سوم: چالشهای پیاده سازی میکروسرویس ها نسبت به

Monolith

ها

• پیاده سازی مایکروسرویس ها دشوار می باشد
• بررسی Performance مربوط به ارتباطات شبکه
• بررسی Resilience مربوط به ارتباطات شبکه
• اجرا کردن مایکروسرویس ها در Production
• چالشهای مربوط به مدیریت مستقل
• مرور چالشهای مربوط به مایکروسرویس ها

فصل چهارم: معماری های ارتباطات

Synchronous

• معرفی RPC
• بررسی Service Discovery
• بررسی Stateless RPC و Stateful RPC
• بررسی Performance مربوط به ارتباطات Synchronous
• جمع بندی

فصل پنجم: معماری های ارتباطات

Asynchronous

• معرفی کردن ارتباطات Asynchronous
• بررسی مباحث اولیه در Message Bus
• طراحی کردن جریانهای ارتباطات Asynchronous
• بررسی Distributed Transaction ها
• بررسی الگوی Saga و الگوی Routing Slip
• جمع بندی

فصل ششم: توسعه قابلیتهای مختلف در معماری میکروسرویس‌ ها

• کنترل کردن کیفیت یک مایکروسرویس‌
• بررسی تکنیکهای Continuous Delivery
• بررسی فرهنگ تیمی مایکروسرویس‌ ها

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

• تعریف کردن بهبودهای طراحی در مایکروسرویس ها
• اولویت بندی کردن بهبودهای معماری
• تاثیرات مربوط به معماری
• جمع بندی

فصل هشتم: ساختن معماری های میکروسرویس مقاوم (

Resilient

)

• اهمیت Resilient و کیفیت
• درک کردن System Capacity
• بررسی کردن مایکروسرویس های Observable
• پیاده سازی تکنیکهای Resilience

فصل نهم: ارزیابی آمادگی میکروسرویس ها

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