آموزش پیاده سازی معماری مایکروسرویسی در ASP.NET Core

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

معماری مایکروسرویسی چیست؟

واژه معماری مایکروسرویس نمایانگر یک محصول نرم افزاری که با استفاده از معماری مایکروسرویس ایجاد شده است. معماری معماری مایکروسرویسی سبکی را در تولید نرم افزار ایجاد می کند که با استفاده از آن بتوانیم به نیازهای فعلی این صنعت؛ یعنی سرعت بالا، کارآمدی بالا و امکان مدیریت و توسعه دادن راحت تر نرم افزار جامه عمل بپوشانیم.

معماری مایکروسرویسی کمک می کند تا بتوانیم اصول و الگوهای مختلف معماری را در یک اپلیکیشن ایجاد کنیم. در این معماری یک برنامه به قسمت های کوچکتری به نام مایکروسرویس شکسته می شود. هر مایکروسرویس به صورت مستقل به کار خود ادامه می دهد. البته مایکروسرویس ها می توانند برای تکمیل کردن رسالت نهایی سیستم، با یکدیگر ارتباط برقرار کنند.تمامی مایکروسرویس های موجود در یک solution با سرعت و استقلال خاص خود deploy می شوند. استقلال مایکروسرویس ها از یکدیگر کمک می کند تا بتوانیم نرم افزار های ایجاد شده با این سبک معماری را در scale بالا به سادگی مدیریت کنیم.

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

ارتباط هم زمان و غیرهم زمان در معماری Microservices

در معماری Microservices، سرویس ها برای انجام عملیات مشترک یا تبادل اطلاعات باید با یکدیگر ارتباط برقرار کنند. در ارتباط هم زمان یا `Synchronous`، سرویس درخواست کننده معمولاً منتظر دریافت پاسخ می ماند تا بتواند پردازش خود را ادامه دهد. برای مثال، یک سرویس سفارش ممکن است برای دریافت اطلاعات یک محصول، درخواست مستقیمی به سرویس محصولات ارسال کند. این روش ساده و قابل فهم است، اما زمان پاسخ و در دسترس بودن سرویس مقصد می تواند بر عملکرد درخواست اولیه تأثیر بگذارد.

در ارتباط غیرهم زمان یا `Asynchronous`، ارسال پیام لزوماً به معنای انتظار برای پاسخ نهایی سرویس مقصد نیست. سرویس ها می توانند پیام ها را از طریق یک واسط پیام رسان یا سازوکارهای دیگر مبادله کنند و عملیات خود را مستقل تر پیش ببرند. برای مثال، پس از ثبت سفارش، یک پیام می تواند برای آغاز فرایند ارسال اعلان یا پردازش پرداخت منتشر شود. انتخاب میان این دو روش به نیازمندی های سیستم، میزان وابستگی سرویس ها و انتظارات مربوط به زمان پاسخ بستگی دارد.

طراحی مرز سرویس ها و مسئولیت هر Microservice

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

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

مدیریت خطا و تاب آوری در Microservices

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

مفاهیمی مانند Timeout، Retry و Circuit Breaker در طراحی سیستم های مقاوم اهمیت دارند، اما استفاده از آن ها باید با توجه به نوع عملیات انجام شود. تکرار یک درخواست خواندنی معمولاً با تکرار یک عملیات پرداخت یا ثبت سفارش یکسان نیست و ممکن است به اجرای ناخواسته عملیات منجر شود. به همین دلیل، باید اثر هر خطا و امکان تکرار ایمن عملیات بررسی شود. شناخت این ملاحظات به شما کمک می کند سرویس هایی طراحی کنید که در برابر اختلال های موقت رفتار کنترل شده تری داشته باشند.

چالش های داده و سازگاری در معماری Microservices

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

در چنین شرایطی، ممکن است سیستم به جای یک تراکنش واحد در پایگاه داده، از مجموعه ای از عملیات محلی و پیام های بین سرویس ها استفاده کند. این رویکرد می تواند به سازگاری نهایی یا `Eventual Consistency` منجر شود؛ یعنی داده ها ممکن است برای مدتی یکسان نباشند، اما در صورت موفقیت عملیات لازم به وضعیت سازگار برسند. انتخاب این مدل باید بر اساس نیازمندی های کسب وکار انجام شود. درک تفاوت سازگاری فوری و سازگاری نهایی برای طراحی فرایندهای چندمرحله ای در Microservices ضروری است.