آموزش پیاده سازی Versioning در میکروسرویس ها

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

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

مایکروسرویس ها که تحت عنوان معماری مایکروسرویسی نیز شناخته می شوند یک سبک معماری استکه در آن یک سیستم نرم افزاری در قالب مجموعه ای از سرویس های کوچک تشکیل می شود. سرویس هایی که در معماری مایکروسرویسی پیاده سازی می شوند باید دارای قابلیت های مختلفی از قبیل قابلیت نگهداری و تست پذیری بالا، قابلیت loosely coupled بودن، قابلیت به طور مستقل قابل deploy بودن و نهایتاً قابلیت سازماندهی شدن توسط تیم کوچک توسعه نرم افزار را داشته باشند. با استفاده از معماری مایکروسرویسی میتوان به سادگی نرم افزارهای پیچیده و بزرگ را به روشی کاملاً قابل اعتماد و با سرعت بسیار بالاتری تحویل مشتری داد.

علاوه بر این، امکان تکامل یک technology stack نیز با استفاده از معماری مایکروسرویسی امکان پذیر خواهد بود. البته نباید به این قضیه فکر کرد که معماری مایکروسرویسی حلال تمامی مشکلات است. در کنار مزیت های بسیار زیادی که در معماری مایکروسرویسی وجود دارد این معماری دارای چالش های متعددی نیز است. در کنار سبک معماری مایکروسرویسی اغلب از سبک معماری Monolithic و یا Monolithic Architecture یاد می شود که یک سبک معماری سنتی است. البته هنوز هم توسط بسیاری از نرم افزارها استفاده می گردد. این سبک معماری نیز دارای محدودیت های مختلفی است که استفاده کردن از آن را برای برخی از نرم افزارها نامناسب می کند.

ورژن بندی کردن (Versioning) میکروسرویس ها

همانطور که احتمالا می دانید یک API در معماری مایکروسرویسی یک قرارداد و یا contract بین سرویس و کلاینت های آن سرویس به حساب می آید. بنابراین شما می توانید معماری مایکروسرویسی خود را به طور مستقل از کلاینت ها تکامل و یا تغییر بدهید. البته در انجام چنین کاری باید توجه کرد که API contract مربوط به معماری مایکروسرویسی اصطلاحاً break نشود و یا نشکند. از آنجایی که این contract پل ارتباطی سرویس و کلاینت می باشد نگهداری آن بدون هیچگونه تغییر بسیار مهم است. اگر contract مربوطه دچار تغییر بشود تأثیر این موضوع بر روی کلاینت ها و همچنین API Gateway غیرقابل اجتناب خواهد بود. ساختار یک API بستگی به پروتکل استفاده شده دارد. برای مثال اگر شما از messaging از قبیل AMQP استفاده کنید API شما شامل انواع مختلفی از message ها و یا اصطلاحاً message type ها خواهد بود. این در حالی است که اگر از HTTP و یا Restful service ها استفاده کنید API شامل URL ها و request و response های در قالب JSON خواهند بود.

در معماری مایکروسرویسی امکان اینکه نیاز داشته باشید service API را پس از مدتی تحقیق بدهید بسیار محتمل است. وقتی که این اتفاق رخ می دهد و البته public API شما توسط چندین client application مورد استفاده قرار می گیرند نمی توانید همه کلاینت ها را مجبور کنید در یک زمان یکسان از API contract بروزرسانی شده استفاده کنند. به عبارت دیگر نیاز است که نسخه جدید سرویس مورد نظرتان را برای مدتی در کنار نسخه قدیمی قرار دهید تا کلاینت ها بتوانند هر دوی این نسخه ها را در کنار یکدیگر مورد استفاده قرار بدهند و پس از مدتی service contract قدیمی تر اصطلاحاً بازنشسته می شود و جای خود را به service contract جدیدتر می دهد. به همین جهت در بروزرسانی کردن API مربوط به معماری مایکروسرویسی در نظر داشتن یک استراتژی بسیار مهم برای به روزرسانی اهمیت زیادی دارد. به این استراتژی و تکنیک های مختلفی که در کنار آن استفاده می شود اصطلاحاً نسخه بندی و یا versioning می گویند.

حفظ Backward Compatibility هنگام تغییر API های میکروسرویس

API ها در طول عمر یک سیستم ثابت نمی‌مانند؛ ممکن است نیازمندی‌های جدید باعث اضافه شدن فیلدها، تغییر قراردادها یا بازطراحی برخی عملیات شوند. آموزش Versioning and Evolving Microservices in ASP.NET Core به بررسی دلیل تکامل API ها و تفاوت میان تغییرات سازگار و Breaking Change ها می‌پردازد. تغییر شکننده می‌تواند مصرف‌کننده‌ای را که هنوز از قرارداد قبلی استفاده می‌کند دچار مشکل کند. به همین دلیل، بررسی Backward Compatibility یکی از مراحل مهم طراحی تغییرات است؛ به‌ویژه زمانی که چند برنامه یا سرویس مستقل به یک API وابسته هستند و هم‌زمان به‌روزرسانی نمی‌شوند.

در آموزش از نمونه GloboTicket برای بررسی تغییرات و Database Migration ها استفاده می‌شود و موضوع الزامات جدید نیز در مسیر تکامل سیستم قرار دارد. این مثال‌ها کمک می‌کنند تغییر API را جدا از سایر اجزای نرم‌افزار نبینید؛ زیرا تغییر قرارداد ممکن است با تغییر مدل داده و منطق برنامه نیز همراه باشد. آموزش همچنین به Refactoring می‌پردازد تا بتوانید کد را در حین تکامل قابلیت‌ها بازسازمان‌دهی کنید. شناخت این ملاحظات به توسعه‌دهنده کمک می‌کند پیش از انتشار تغییرات، اثر آن‌ها بر مصرف‌کنندگان موجود را ارزیابی کند و راهبردی مناسب برای حفظ سازگاری انتخاب کند.

پیاده‌سازی API Versioning و مدیریت نسخه‌های Message

پس از شناخت دلایل تغییر API، آموزش به روش‌های پیاده‌سازی Versioning در ASP.NET Core می‌پردازد. یکی از موضوعات عملی، Routing مبتنی بر URL است که نسخه موردنظر را در مسیر درخواست مشخص می‌کند. این شیوه به مصرف‌کننده اجازه می‌دهد هنگام فراخوانی API، نسخه قرارداد را به‌صورت آشکار تعیین کند. آموزش همچنین فعال‌سازی Versioning و بررسی Swagger Documentation را پوشش می‌دهد تا مستندات API با نسخه‌بندی آن ارتباط پیدا کنند. این مباحث برای پروژه‌هایی کاربرد دارند که لازم است نسخه‌های متفاوتی از یک API را در کنار هم مدیریت کنند.

نسخه‌بندی در معماری میکروسرویس‌ها فقط به درخواست‌های HTTP محدود نیست؛ Command ها و Event Message ها نیز قراردادهایی دارند که با تغییر آن‌ها ممکن است مصرف‌کنندگان تحت تأثیر قرار گیرند. به همین دلیل، آموزش ورژن‌بندی Message ها و پیاده‌سازی یک نسخه جدید از Message را بررسی می‌کند. وقتی سرویس‌ها از طریق پیام با یکدیگر ارتباط دارند، باید مشخص باشد مصرف‌کننده چگونه با قالب قدیمی یا جدید کنار می‌آید. این آموزش با کنار هم قرار دادن API Versioning و Message Versioning، دیدی جامع‌تر نسبت به تکامل قراردادهای ارتباطی ارائه می‌کند و به تصمیم‌گیری درباره انتشار تغییرات در سیستم‌های توزیع‌شده کمک می‌کند.