کتاب میکروسرویس

۱. دنیا قبل از میکروسرویس به چه صورت بود؟
۲. پیش به سوی جهنم!
۳. بهشت گمشده میکروسرویس
۴. مزایای میکروسرویس‌ها
۵. معایب میکروسرویس‌ها

در توسعه به روش میکروسرویس، هر سرویس مجموع‌های از وظایف مرتبط با هم را به طور کامل و بدون وابستگی به بخش دیگری به انجام می‌رساند. برای مثال در سیستم تولید محتوا و مدیریت خبر می‌توان به مواردی چون مدیریت نظرات، مدیریت ثبت خبر و محتوا، مدیریت فایل، مدیریت انتشار در بستر وب و … اشاره کرد. در این روش هر مینی‌اپلیکیشن از یک معماری تمیز مثل Hexagonal یا Onion به طور داخلی استفاده می‌کند. هر مینی‌اپلیکیشن این توانایی را خواهد داشت که در صورت نیاز بخشی از خدمات و داده‌های خودش را برای سایر قسمت‌ها به صورت API در اختیار قرار بدهد. برای نصب و راه‌اندازی هم هر کدام از این مینی اپلیکیشن‌ها توانایی این را خواهند داشت که در یک VM جداگانه به کار خودشان ادامه بدهند یا به عنوان Docker Image در اختیار تیم زیرساخت برای نصب و راه‌اندازی قرار بگیرند.

۱. تعامل مستقیم Client‌ها با میکروسرویس‌ها
۲. حل مشکلات با استفاده از API Gateway

مثل هر کار دیگری استفاده از API Gateway هم مزایا و معایب خاص خود را دارد که ابتدا به مزایای آن می‌پردازیم. بزرگ‌ترین مزیت آن از بین بردن معایب روش دسترسی مستقیم است. عدم وابستگی به معماری داخلی سیستم ما باعث می‌شود کار Refactoring ساده‌تر قابل اجرا باشد. و دیگر برای ترکیب یا تجزیه سرویس‌های مختلف دغدغه‌های قبل را نداشته باشیم ( پیدا کردن جایی تا زمانی که آب‌ها از آسیاب بیوفتد.) ارائه API تخصصی برای هر Client باعث افزایش بهره‌وری و بهبود خروجی‌ها و در یک کلام UX بهتر می‌شود. کاهش تعداد درخواست‌های ارسالی از Client هم مورد بعدی است که بهره‌وری کار را بالاتر می‌برد. در کنار این مزایا اما چند ایراد نیز می‌توان به استفاده از این روش گرفت. بزرگ‌ترین ایراد این روش اضافه شدن یک ماژول بزرگ به سیستم است که باید همیشه سرحال و آنلاین باشد و در صورتی که عملکرد درستی ارائه نکند کل سیستم با مشکل مواجه خواهد شد. با توجه به اینکه تعامل با هرکدام از میکروسرویس‌ها باید در API Gateway پیاده‌سازی شود و به ازای هر Client هم نیاز داریم که پیاده‌سازی اختصاصی داشته ‌باشیم این احتمال وجود دارد که همین API Gateway به سدی برای تیم توسعه تبدیل شود. زمانی که یک سرویس به روز می‌شود Client‌ها باید منتظر بمانند تا این به روزرسانی در Gateway ارائه شود. به همین دلیل باید توسعه API Gateway ما طوری باشد که به سادگی قابل تغییر و به روزرسانی باشد.

۱. انواع روش‌های تعامل
۲. تعریف API‌ها
۳. تکامل API‌ها
۴. مدیریت بحران هنگامی که بخشی از سیستم دچار مشکل می‌شود

در برنامه‌ها Monolithic با توجه به اینکه کل برنامه ما در یک نرم‌افزار با یک زبان برنامه نویسی پیاده سازی شده ‌است ارتباط بین بخش‌های مختلف به سادگی صدا زدن یک تابع انجام می‌شود. اما در میکروسرویس‌ها با توجه به اینکه بخش‌های مختلف برنامه ما روی چندین سیستم مختلف به صورت توزیع شده اجرا می‌شوند. امکان استفاده از روش قبل وجود ندارد. هر بخش از نرم‌افزار ما به صورت یک پروسه کاملا جداگانه و ایزوله اجرا می‌شود. در میکروسرویس‌ها ارتباط بین بخش‌های مختلف اصطلاحا از روشی به نام Inter Process Communication که از این به بعد به اختصار IPC می‌گوییم انجام می‌شود.

۱. ارسال پیام به صورت Async
۲. ارتباط Sync و Request/Response
۳. سرویس‌های REST
۴. مزایای HTTP
۵. معایب HTTP
۶. ساختار پیام‌ها

وقتی در مورد ارتباط صحبت می‌کنیم دو گروه از عناصر اصلی قابل شناسایی هستند. شرکت کنندگان در یک رابطه و پیام‌های ارتباطی دو عنصر اصلی هر ارتباطی هستند که در این فصل قصد داریم در مورد این دو مورد صحبت کنیم. در یک ارتباط IPC تکنولوژی‌های مختلفی قابل انتخاب است. برای مثال برای یک ارتباط از نوع Request/Response و به روش Sync می‌توان Rest API‌هایی براساس پروتکل HTTP توسعه داد یا برای توسعه سرویس‌های خود از Thrift استفاده کنید. در مقابل اگر نیاز به برقراری ارتباط Async داشته‌ باشیم می‌توانیم به سراغ AMQP یا STOMP برویم.

برای فرمت پیام‌های ارسالی و دریافتی نیز گزینه‌های زیادی وجود دارد. یکی از معمول‌ترین انتخاب‌ها قالب‌های محبوب JSON و XML است که قابلیت خوانایی بالایی نیز دارد. اگر خوانایی برای انسان اهمیت نداشته‌ باشد یا نیاز به بهره‌وری بالایی داشته باشیم Avro یا Protocol Buffer انتخاب‌های مناسبی به نظر می‌رسند.

۱. آشنایی با Service Registry
۲. آشنایی با الگوی Client-Side Discovery
۳. آشنایی با الگوی Server-Side Discovery
۴. بررسی دقیق Service Registry
۵. انواع روش‌های مدیریت سرویس‌ها

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

۱. مشکلات داده‌های توزیع شده در میکروسرویس‌ها
۲. توسعه بر مبانی Event‌ها
۳. ویژگی Automicity هنگام استفاده از Event‌ها

در بسیاری از برنامه‌ها راهکار مشکل استفاده از Event‌ها است. در این روش هر زمانی که یکی از داده‌های مهم سرویس تغییر می‌کند یک Event در سیستم ایجاد و ارسال می‌شود و سایر سرویس‌های موجود در سیستم می‌توانند در صورت نیاز این Event را مدیریت کنند و داده‌های داخلی خود را با توجه به این Event به روز کنند. این تغییر داده‌ها خود می‌تواند موجب ایجاد چندین Event دیگر در سیستم شود.

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

۱. تاریخچه، نحوه امن کردن نرم افزارهای یکپارچه
۲. مبانی کلیدی امنیت
۳. امنیت مرزهای نرم افزار
۴. امن کردن ارتباط سرویس به سرویس

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

۱. نصب چند سرویس مختلف به ازای هر میزبان
۲. نصب یک سرویس به ازای هر میزبان
۳. نصب هر سرویس روی یک ماشین مجازی
۴. نصب و راه اندازی به کمک کانتینرها

اگر از معماری Monolithic برای توسعه سرویس‌های خود استفاده کنیم، در انتها نیاز داریم برنامه‌ای را روی یک سرور نصب کنیم. یا اگر برنامه ما قرار باشد بار زیادی را تحمل کند، چندین سرور تهیه می‌کنیم و نرم‌افزار خود را روی چند سرور نصب می‌کنیم و به کمک یک Load Balancer بار را روی نمونه‌های مختلف توزیع می‌کنیم. هرچند همیشه کار به همین سادگی نیست اما در پیچیده‌ترین حالات هم معمولا توزیع نرم‌افزارهای Monolithic ساده‌تر از میکروسرویس‌ها است.

در مقابل هنگامی که از معماری میکروسرویس استفاده می‌کنیم، برای یک برنامه ممکن است ده‌ها یا صدها سرویس داشته باشیم. هر کدام از این سرویس‌ها ممکن است با زبان و فریمورکی خاص توسعه داده شده‌ باشند. هر کدام از این مینی‌اپلیکیش نهایی که تولید می‌‌کنیم، اندازه‌های متفاوت، بارهای متفاوت، درخواست‌های متفاوت و زیرساخت‌های نگهداری و مانیتورینگ متفاوتی هم ممکن است داشته‌ باشند

۱. کار را متوقف کنید
۲. جداسازی Front-end و Back-end
۳. استخراج سرویس

مهاجرت از Monolith به Microservice یکی از روش‌های مدرن‌سازی فرایند کاری است که هم در دنیای نرم‌افزار و هم در زندگی روزمره انجام می‌شود. حتما همه ما تجربیاتی روی مهاجرت از فری مورکی قدیمی به جدید داشته‌ایم، یا در زندگی روزمره برای خود ما یا یکی از بستگان فرایند به روز رسانی محیط زندگی اتفاق افتاده، که این به رو زرسانی می‌تواند بازسازی منزل، خرید اسباب جدید یا خرید خانه جدید باشد. به هر حال با توجه به اینکه این یک فرایند تکراری است، احتمالا تجربیات مشترکی نیز در این زمینه وجود دارد که می‌توانیم از این تجربه‌ها استفاده کنیم.

۱. سیستم‌ها و تیم‌ها
۲. خروجی کار  Front-end
۳. ادغام Integration
۴. موضوعات مشترک

برای بهبود شرایط معمولا نرم‌افزار به چندین قسمت شکسته می‌شود. یکی از راهکارهای معمول برای انجام این کار شکستن افقی پروژه و ساختار تیم بر اساس تکنولوژی است. معمولا تیم‌های دیتابیس، Back-end و Front-end تشکیل می‌شوند و هر تیم مسئولیت بخشی از نرم‌افزار را برعهده گرفته و کار را پیش می‌برد. به جای استفاده از این روش، Micro Front-end استفاده از شکستن عمودی پروژه را پیشنهاد می‌دهد. هر کدام از این بخش‌ها از پایین‌ترین لایه تا خروجی کاربر توسط یک تیم جداگانه توسعه داده می‌شود. تفاوت این روش با میکروسرویس در لایه UI است. در این روش توسعه، به جزء سرویس لایه UI نیز برای هریک از بخش‌های نرم‌افزار توسط تیم تولید می‌شود و نیاز به تولید یک UI مرکزی را از بین می‌برد. که این روش توسعه مزایای زیادی دارد.

۱. سرعت بالا در افزودن ویژگی‌های جدید
۲. حذف گلوگاه Front-end
۳. توانایی تغییر
۴. مزایایی عدم وابستگی
۵. معایب Micro Front-end

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