مقابله با خرابی های غیرمنتظره یکی از سخت ترین مشکلات برای حل است، به ویژه در یک سیستم توزیع شده. بسیاری از کدهایی که توسعه دهندگان می نویسند شامل مدیریت استثناها می شود، و همچنین در اینجا بیشترین زمان صرف تست می شود. مشکل بیشتر از نوشتن کد برای رسیدگی به خرابی ها است. وقتی دستگاهی که میکروسرویس در آن کار می کند از کار بیفتد چه اتفاقی می افتد؟ نه تنها باید این خرابی میکروسرویس را تشخیص دهید (مشکلی سخت به خودی خود)، بلکه به چیزی برای راه اندازی مجدد میکروسرویس خود نیز نیاز دارید.
یک میکروسرویس باید در برابر خرابی مقاوم باشد و بتواند اغلب در ماشین دیگری برای در دسترس بودن راه اندازی مجدد شود. این انعطاف‌پذیری همچنین به وضعیت ذخیره شده از طرف میکروسرویس مربوط می‌شود، جایی که میکروسرویس می‌تواند این حالت را از آن بازیابی کند، و اینکه آیا میکروسرویس می‌تواند با موفقیت دوباره راه‌اندازی شود. به عبارت دیگر، نیاز به انعطاف پذیری در قابلیت محاسباتی وجود دارد (فرایند می تواند در هر زمانی دوباره راه اندازی شود) و همچنین انعطاف پذیری در حالت یا داده ها (بدون از دست دادن داده ها، و داده ها ثابت می مانند).
مشکلات انعطاف‌پذیری در سناریوهای دیگر، مانند زمانی که خرابی در حین ارتقاء برنامه رخ می‌دهد، ترکیب می‌شود. میکروسرویس که با سیستم استقرار کار می‌کند، باید تعیین کند که آیا می‌تواند به سمت نسخه جدیدتر حرکت کند یا در عوض به نسخه قبلی برگردد تا وضعیت ثابتی داشته باشد. سؤالاتی مانند اینکه آیا ماشین های کافی برای ادامه حرکت رو به جلو در دسترس هستند یا خیر و نحوه بازیابی نسخه های قبلی میکروسرویس باید در نظر گرفته شوند. این رویکرد به میکروسرویس نیاز دارد که اطلاعات بهداشتی را منتشر کند تا برنامه کلی و ارکستراتور بتوانند این تصمیمات را بگیرند.
علاوه بر این، انعطاف پذیری با نحوه رفتار سیستم های مبتنی بر ابر مرتبط است. همانطور که گفته شد، یک سیستم مبتنی بر ابر باید شکست ها را بپذیرد و سعی کند به طور خودکار آنها را بازیابی کند. به عنوان مثال، در صورت خرابی شبکه یا کانتینر، برنامه های سرویس گیرنده یا سرویس های سرویس گیرنده باید استراتژی برای ارسال مجدد پیام ها یا تلاش مجدد درخواست ها داشته باشند، زیرا در بسیاری از موارد خرابی ها در ابر جزئی هستند. بخش پیاده‌سازی برنامه‌های انعطاف‌پذیر در این راهنما به نحوه رسیدگی به شکست جزئی می‌پردازد. با استفاده از کتابخانه‌هایی مانند Polly که طیف وسیعی از سیاست‌ها را برای رسیدگی به این موضوع ارائه می‌دهد، تکنیک‌هایی مانند تلاش‌های مجدد با عقب‌نشینی نمایی یا الگوی Circuit Breaker در دات‌نت را توصیف می‌کند.
ممکن است بدیهی به نظر برسد، و اغلب نادیده گرفته می شود، اما یک میکروسرویس باید سلامت و تشخیص آن را گزارش کند. در غیر این صورت، بینش کمی از دیدگاه عملیات وجود دارد. مرتبط کردن رویدادهای تشخیصی در میان مجموعه‌ای از سرویس‌های مستقل و برخورد با انحرافات ساعت ماشین برای درک ترتیب رویداد، چالش برانگیز است. همانطور که با یک میکروسرویس از طریق پروتکل‌های توافق شده و قالب‌های داده تعامل می‌کنید، نیاز به استانداردسازی در نحوه ثبت رویدادهای سلامت و تشخیصی وجود دارد که در نهایت به فروشگاه رویداد برای جستجو و مشاهده ختم می‌شوند. در رویکرد میکروسرویس‌ها، مهم است که تیم‌های مختلف بر روی یک قالب گزارش واحد به توافق برسند. برای مشاهده رویدادهای تشخیصی در برنامه باید یک رویکرد ثابت وجود داشته باشد.
سلامتی با تشخیص متفاوت است. سلامتی در مورد میکروسرویس است که وضعیت فعلی خود را برای انجام اقدامات مناسب گزارش می دهد. یک مثال خوب کار با مکانیسم های ارتقا و استقرار برای حفظ در دسترس بودن است. اگرچه ممکن است یک سرویس در حال حاضر به دلیل خرابی فرآیند یا راه اندازی مجدد ماشین ناسالم باشد، اما ممکن است این سرویس همچنان عملیاتی باشد. آخرین چیزی که شما نیاز دارید این است که با انجام یک ارتقا، این وضعیت را بدتر کنید. بهترین روش این است که ابتدا یک بررسی انجام دهید یا زمانی را برای بهبودی میکروسرویس در نظر بگیرید. رویدادهای بهداشتی از یک میکروسرویس به ما کمک می کند تا تصمیمات آگاهانه بگیریم و در واقع به ایجاد خدمات خود درمانی کمک کنیم.
شما همچنین می توانید از یک کتابخانه منبع باز عالی به نام AspNetCore.Diagnostics.HealthChecks استفاده کنید که در GitHub و به عنوان بسته NuGet موجود است. این کتابخانه همچنین چک های سلامتی را انجام می دهد، با یک چرخش، دو نوع بررسی را انجام می دهد:
گزارش‌ها اطلاعاتی را درباره نحوه اجرای یک برنامه یا سرویس ارائه می‌دهند، از جمله استثناها، هشدارها و پیام‌های اطلاعاتی ساده. معمولاً، هر گزارش در قالب متنی با یک خط در هر رویداد است، اگرچه استثنائات نیز اغلب رد پشته را در چندین خط نشان می‌دهند.
در برنامه های کاربردی مبتنی بر سرور یکپارچه، می توانید گزارش ها را روی یک فایل روی دیسک بنویسید (یک فایل لاگ) و سپس آن را با هر ابزاری تجزیه و تحلیل کنید. از آنجایی که اجرای برنامه محدود به یک سرور ثابت یا VM است، معمولاً تحلیل جریان رویدادها چندان پیچیده نیست. با این حال، در یک برنامه توزیع شده که در آن چندین سرویس در بسیاری از گره‌ها در یک خوشه ارکستراتور اجرا می‌شوند، توانایی مرتبط کردن رویدادهای توزیع شده یک چالش است.
یک برنامه کاربردی مبتنی بر میکروسرویس نباید سعی کند جریان خروجی رویدادها یا فایل های گزارش را به تنهایی ذخیره کند و حتی سعی در مدیریت مسیریابی رویدادها به یک مکان مرکزی نداشته باشد. باید شفاف باشد، به این معنی که هر فرآیند فقط باید جریان رویداد خود را در یک خروجی استاندارد بنویسد که زیر آن توسط زیرساخت محیط اجرا که در آن اجرا می‌شود جمع‌آوری می‌شود. نمونه ای از این روترهای جریان رویداد Microsoft.Diagnostic.EventFlow است که جریان های رویداد را از چندین منبع جمع آوری می کند و آن را در سیستم های خروجی منتشر می کند. اینها می توانند شامل خروجی استاندارد ساده برای یک محیط توسعه یا سیستم های ابری مانند Azure Monitor و Azure Diagnostics باشند. همچنین پلتفرم‌ها و ابزارهای تجزیه و تحلیل لاگ شخص ثالث خوبی وجود دارد که می‌تواند گزارش‌ها را جستجو، هشدار، گزارش و نظارت کند، حتی در زمان واقعی، مانند Splunk.
هنگامی که یک برنامه کاربردی مبتنی بر میکروسرویس ایجاد می کنید، باید با پیچیدگی مقابله کنید. البته برخورد با یک میکروسرویس ساده است، اما ده ها یا صدها نوع و هزاران نمونه میکروسرویس مشکل پیچیده ای است. این فقط در مورد ساختن معماری میکروسرویس شما نیست - اگر می‌خواهید یک سیستم پایدار و منسجم داشته باشید، به دسترسی بالا، آدرس‌پذیری، انعطاف‌پذیری، سلامت و تشخیص نیاز دارید.
تیم های توسعه باید بر حل مشکلات تجاری و ایجاد برنامه های کاربردی سفارشی با رویکردهای مبتنی بر میکروسرویس تمرکز کنند. آنها نباید بر حل مشکلات زیرساختی پیچیده تمرکز کنند. اگر این کار را انجام دهند، هزینه هر برنامه کاربردی مبتنی بر میکروسرویس بسیار زیاد خواهد بود. بنابراین، پلتفرم‌های میکروسرویس‌گرا وجود دارند که به آنها ارکستراتور یا خوشه‌های میکروسرویس گفته می‌شود، که سعی در حل مشکلات سخت ساخت و اجرای یک سرویس و استفاده بهینه از منابع زیرساختی دارند. این رویکرد پیچیدگی های ساخت برنامه هایی را که از رویکرد میکروسرویس استفاده می کنند، کاهش می دهد.
ممکن است ارکسترهای مختلف شبیه هم به نظر برسند، اما بررسی‌های تشخیصی و سلامتی ارائه شده توسط هر یک از آنها در ویژگی‌ها و وضعیت بلوغ متفاوت است، که گاهی به پلتفرم سیستم‌عامل بستگی دارد.
