برای مقابله با شکست های جزئی، از یکی از استراتژی هایی که در اینجا توضیح داده شده است استفاده کنید.
از ارتباطات ناهمزمان (به عنوان مثال، ارتباطات مبتنی بر پیام) در میکروسرویس های داخلی استفاده کنید. بسیار توصیه میشود که زنجیرههای طولانی تماسهای HTTP همزمان در میکروسرویسهای داخلی ایجاد نکنید، زیرا این طراحی نادرست در نهایت به دلیل اصلی قطعیهای بد میشود. برعکس، بهجز ارتباطات فرانتاند بین برنامههای سرویس گیرنده و سطح اول میکروسرویسها یا دروازههای API ریز، توصیه میشود پس از گذشتن از چرخه درخواست/پاسخ اولیه، فقط از ارتباطات ناهمزمان (مبتنی بر پیام) استفاده کنید. میکروسرویس های داخلی سازگاری نهایی و معماری های رویداد محور به به حداقل رساندن اثرات امواج کمک می کند. این رویکردها سطح بالاتری از استقلال میکروسرویس را اعمال میکنند و بنابراین از مشکلی که در اینجا ذکر شد جلوگیری میکنند.
از تلاش های مجدد با عقب نشینی نمایی استفاده کنید. این تکنیک به جلوگیری از خرابی های کوتاه و متناوب با انجام چندین بار تماس مجدد کمک می کند، در صورتی که سرویس فقط برای مدت کوتاهی در دسترس نبود. این ممکن است به دلیل مشکلات شبکه متناوب یا زمانی که یک میکروسرویس/کانتینر به گره دیگری در یک خوشه منتقل میشود رخ دهد. با این حال، اگر این تلاشهای مجدد بهدرستی با کلیدهای مدار طراحی نشده باشند، میتواند اثرات امواج را تشدید کند و در نهایت حتی باعث انکار سرویس (DoS) شود.
روی زمانبندی شبکه کار کنید. به طور کلی، کلاینتها باید طوری طراحی شوند که بهطور نامحدود مسدود نشوند و همیشه در زمان انتظار برای پاسخ از زمانبندی استفاده کنند. استفاده از تایم اوت تضمین می کند که منابع هرگز به طور نامحدود بسته نمی شوند.
از الگوی Circuit Breaker استفاده کنید. در این رویکرد، فرآیند مشتری تعداد درخواست های ناموفق را ردیابی می کند. اگر میزان خطا از حد تنظیم شده بیشتر شود، یک "مدار شکن" فعال می شود تا تلاش های بعدی بلافاصله با شکست مواجه شوند. (اگر تعداد زیادی از درخواستها با شکست مواجه شوند، نشان میدهد که سرویس در دسترس نیست و ارسال درخواستها بیمعنی است.) پس از یک بازه زمانی، مشتری باید دوباره تلاش کند و در صورت موفقیتآمیز بودن درخواستهای جدید، قطع کننده مدار را ببندد.
موارد جایگزین ارائه کنید. در این رویکرد، فرآیند کلاینت منطق بازگشتی را زمانی که یک درخواست با شکست مواجه میشود، انجام میدهد، مانند برگرداندن دادههای کش یا یک مقدار پیشفرض. این یک رویکرد مناسب برای پرس و جو است و برای به روز رسانی یا دستورات پیچیده تر است.
تعداد درخواست های در صف را محدود کنید. مشتریان همچنین باید برای تعداد درخواستهای معوقی که یک میکروسرویس مشتری میتواند به یک سرویس خاص ارسال کند، یک حد بالایی اعمال کنند. اگر به حد مجاز رسیده باشد، احتمالاً درخواست های اضافی بیهوده است و این تلاش ها باید فوراً با شکست مواجه شوند. از نظر پیاده سازی، سیاست جداسازی دیواره Polly را می توان برای برآورده کردن این نیاز مورد استفاده قرار داد. این رویکرد اساساً یک دریچه گاز موازی سازی با SemaphoreSlim به عنوان پیاده سازی است. همچنین اجازه یک "صف" در خارج از دیوار را می دهد. حتی قبل از اجرا نیز میتوانید بار اضافی را به طور فعال دفع کنید (به عنوان مثال، زیرا ظرفیت کامل در نظر گرفته میشود). این باعث می شود که پاسخ آن به سناریوهای خرابی خاص سریعتر از یک قطع کننده مدار باشد، زیرا مدار شکن منتظر خرابی ها است. شیء BulkheadPolicy در Polly نشان میدهد که قسمت و صف چقدر پر است، و رویدادهایی را در سرریز ارائه میدهد، بنابراین میتوان از آن برای ایجاد مقیاس افقی خودکار استفاده کرد.
- ۰۱/۱۱/۲۹