وبینار رایگان میکروسرویس

در این وبینار به معرفی الگوها و رویکردهای طراحی توسعه نرم افزار می پردازیم. همچنین تمرکز اصلی وبینار را، بررسی چالشهای پیاده سازی الگوی معماری Microservices و رویکرد طراحی Domain Driven Design(DDD) در تیم های نرم افزاریی قرار دادیم و سعی میکنیم راهکارها و الگوهایی که برا حل این چالشها وجود دارند رو معرفی نماییم، تا بتوانیم نقشه راه خوبی رو ازچگونگی پیاده سازی این معماری برای شرکت کنندگان ترسیم کنیم.

معماری نرم‌افزار شناخت کامپوننتهای سیستم و تشخیص ارتباط بین آن‌هاست. میکروسرویس یک Architecture Style یا همان معماری نرم‌افزار است.

سیستم را به لایه‌های متعدد که هرکدام دارای وظیفهٔ مشخصی است تقسیم می‌نماییم که هر لایه دارای وظیفهٔ تعیین شده است. لایه کاربر، لایه‌ای برای ارائه قوانین کسب‌و‌کار، لایه مکانیزم دسترسی به دیتابیس از جمله لایه‌های تشکیل‌دهنده N-Layer هستند. معماری N-Layer گاهی به‌عنوان ‌ N-Tier نیز شناخته می‌شود.

الگوی معماری میکرو کرنل از دو جزء ماژول‌های سیستم و ماژول‌های پلاگین تشکیل شده است. معماری میکرو کرنل به شما این امکان را می‌دهد که ویژگی‌های برنامه را به‌عنوان افزونه به برنامه اصلی اضافه نمایید و توسعه‌پذیری و همچنین امکان جداسازی و تفکیک ویژگی‌ها را فراهم می‌کند.

معماری pipe & filter یکی از رایج‌ترین سبک‌های معماری است که در طراحی سیستم‌های نرم‌افزاری مورداستفاده قرار می‌گیرد. این معماری شامل یک‌سری مراحل مجزا است که در یک توالی قابل‌پیش‌بینی انجام می‌شود. درواقع یک سبک معماری مبتنی بر مؤلفه است که امکان تجزیه فرایندهای یکپارچه را به اجزای مستقل و کوچک فراهم می‌کند. داده‌ها از پایپ به فیلترهای منتقل می‌شوند و داده‌های نهایی در data sink به هم می‌رسند.

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

معماری سرویس‌گرا (SOA) روشی برای توسعه نرم‌افزار است که از اجزای نرم‌افزاری به نام سرویس‌ها برای ایجاد برنامه‌های کاربردی تجاری استفاده می‌کند. هر سرویس یک قابلیت تجاری را ارائه می‌دهد و سرویس‌ها همچنین می‌توانند در پلتفرم‌ها و زبان‌ها با یکدیگر ارتباط برقرار کنند.

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

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

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

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

فناوری مونولیت به اندازه فناوری میکروسرویس پیچیده نیست. در مجموع، ماهیت مستقل یک برنامه مونولیت؛ استقرار، مدیریت و نگهداری آن را نسبت به یک معماری میکروسرویس آسان‌تر می‌کند.

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

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

در معماری توزیع‌شده، اجزا بر روی پلتفرم‌های مختلفی ارائه می‌شوند و چندین مؤلفه می‌توانند از طریق یک شبکه ارتباطی با یکدیگر همکاری کنند تا به یک هدف خاص دست یابند. در این معماری، پردازش اطلاعات به یک ماشین محدود نمی شود، بلکه بر روی چندین کامپیوتر مستقل توزیع می شود. یک سیستم توزیع شده را می توان با معماری مشتری-سرور نشان داد که پایه معماری های چند لایه را تشکیل می دهد. چندین چارچوب فناوری برای پشتیبانی از معماری های توزیع شده وجود دارد، از جمله : J2EE، CORBA، دات نت، AXIS Java، و سرویس های Globus Grid.

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

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

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

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

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

درسیستمهای توزیع شده تئوری به نام CAP وجود دارد. این تئوری اشاره به این مطلب دارد که در این سیستمها نمیتوان سه ویژگی (Cnsistency, Availability, partition tolerance) را همزمان پیاده سازی کرد.

Cnsistency : یا همان سازگاری به این معناست که تمامی گره های (node) سرور بتوانند داده یکسانی را دریافت نمایند. برای رخ دادن این قانون داده هایی که روی یک گره قرار دارند باید به سرعت روی سایر گره ها فرستاده شوند.

Availability : دسترس پذیری؛ به این معناست که در صورتیکه بخشی از سیستم آسیب ببیند همچنان پاسخ معتبری برای هر درخواست وجود داشته باشد.

partition tolerance: اتصال قطع شده در سیستم را پارتیشن می نامیم. این مسئله به تحمل پذیری خطا در سیستم اشاره دارد و بیان می کند در صورت ایجاد خرابی؛ سیستم همچنان به کار خود ادامه دهد.

در ادامه به بررسی روند تبدیل اپلیکیشن مونولیت به اپلیکیشن میکروسرویس میپردازیم. برای انجام این فرآیند؛ چهار گام زیر را پیش میگیریم.

گام اول : جداسازی کد (Split the code)

گام دوم : جداسازی پایگاه داده (Split the database)

گام سوم : تعریف Standalone Delivery Service

گام چهارم : استفاده از Standalone Delivery Service

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

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

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

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

(Command Query Responsibility Segregation)CQRS یک الگوی معماری است که یک شکاف دقیق را در یک برنامه تجویز می‌کند؛ تقسیمی بین بخشی که به عملیات پردازش (Command) می‌پردازد و بخشی که به Query ها پاسخ می‌دهد. در واقع می‌توان گفت Command درخواست‌های نوشتن و Query درخواست خواندن است.

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

Service Discovery شامل کشف و مکان‌یابی خودکار سرویس‌ها و دستگاه‌ها در شبکه است. استاندارد شبکه مورداستفاده SDP (service discovery protocol) است که می‌تواند به client جهت شناسایی منابع در شبکه کمک کند. Service Discovery با کمک به کاربران برای یافتن منابع سازگار مانند دستگاه‌های دارای بلوتوث در نزدیکی خود، به تسهیل تلاش‌های پیکربندی کمک کرد. اخیراً، این مفهوم گسترش‌یافته است تا منابع مبتنی بر کانتینر توزیع شده را به‌عنوان خدماتی که می‌توان به‌صورت پویا کشف و به آنها دسترسی داشت، در نظر گرفت.

Circuit Breakerبه میکروسرویسها اجازه میدهد تا با هم ارتباط برقرار کرده و تعداد خرابی های رخ داده در بازه زمانی تعریف شده را نظارت نمایند. اگر تعداد خرابی‌ها از مقدار آستانه تعیین شده بیشتر شود، Circuit Breaker به حالت open میرود.

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