مدار شکن ایستیو: غیرفعال کردن ظروف معیوب

تعطیلات به پایان رسید و ما با دومین پست خود در سری سرویس مش ایستیو برگشتیم.

موضوع امروز Circuit Breaker است که به مهندسی برق روسی ترجمه شده است به معنی "شکن مدار" و در اصطلاح رایج - "شکن مدار". فقط در ایستیو این دستگاه مدار کوتاه یا اضافه بار را قطع نمی کند، بلکه ظروف معیوب را قطع می کند.

چگونه این باید به طور ایده آل کار کند

وقتی میکروسرویس‌ها توسط Kubernetes مدیریت می‌شوند، برای مثال در پلتفرم OpenShift، بسته به بار، به‌طور خودکار بالا و پایین می‌شوند. از آنجایی که میکروسرویس ها در پادها اجرا می شوند، ممکن است چندین نمونه از یک میکروسرویس کانتینری در یک نقطه پایانی وجود داشته باشد و Kubernetes درخواست ها و تعادل بار را بین آنها مسیریابی می کند. و - در حالت ایده آل - همه اینها باید کاملاً کار کنند.

ما به یاد داریم که میکروسرویس ها کوچک و زودگذر هستند. زودگذری که در اینجا به معنای سهولت ظاهر شدن و ناپدید شدن است، اغلب دست کم گرفته می شود. تولد و مرگ یک نمونه دیگر از یک میکروسرویس در یک پاد چیزهای کاملاً قابل انتظاری است، OpenShift و Kubernetes به خوبی از عهده این کار بر می آیند، و همه چیز عالی کار می کند - اما دوباره در تئوری.

در واقع چگونه کار می کند

حال تصور کنید که یک نمونه خاص از یک میکروسرویس، یعنی یک ظرف، غیرقابل استفاده شده است: یا پاسخ نمی دهد (خطای 503)، یا، ناخوشایندتر، پاسخ می دهد، اما خیلی کند. به عبارت دیگر، مشکل می شود یا به درخواست ها پاسخ نمی دهد، اما به طور خودکار از استخر حذف نمی شود. در این صورت چه باید کرد؟ برای تلاش مجدد؟ آیا باید آن را از طرح مسیریابی حذف کنم؟ و "خیلی کند" به چه معنی است - تعداد آن چند است و چه کسی آنها را تعیین می کند؟ شاید فقط به آن استراحت بدهید و بعداً دوباره امتحان کنید؟ اگر بله، چقدر بعد؟

Pool Ejection در ایستیو چیست؟

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

Istio با استفاده از یک استراتژی تشخیص پرت، غلاف‌های منحنی را که خارج از خط هستند شناسایی می‌کند و آنها را برای مدت زمان مشخصی که پنجره خواب نامیده می‌شود، از مجموعه منابع حذف می‌کند.

برای نشان دادن این که چگونه این کار در Kubernetes در پلتفرم OpenShift کار می‌کند، اجازه دهید با یک اسکرین شات از میکروسرویس‌های معمولی از نمونه موجود در مخزن شروع کنیم. نسخه ی نمایشی برنامه نویس Red Hat. در اینجا دو پاد داریم، v1 و v2، که هر کدام یک کانتینر را اجرا می کنند. وقتی از قوانین مسیریابی Istio استفاده نمی شود، Kubernetes به طور پیش فرض مسیریابی چرخشی متوازن را تعیین می کند:

آماده شدن برای یک تصادف

قبل از انجام Pool Ejection، باید یک قانون مسیریابی Istio ایجاد کنید. فرض کنید می خواهیم درخواست ها را بین پادها به نسبت 50/50 توزیع کنیم. علاوه بر این، تعداد کانتینرهای v2 را از یک به دو افزایش خواهیم داد، مانند این:

oc scale deployment recommendation-v2 --replicas=2 -n tutorial

اکنون یک قانون مسیریابی تنظیم می کنیم تا ترافیک بین پادها به نسبت 50/50 توزیع شود.

در اینجا نتیجه این قانون به نظر می رسد:

می توانید ایراد بگیرید که این صفحه نمایش 50/50 نیست، بلکه 14:9 است، اما با گذشت زمان وضعیت بهتر می شود.

ایجاد یک نقص

حالا بیایید یکی از دو کانتینر v2 را غیرفعال کنیم تا یک کانتینر v1 سالم، یک کانتینر v2 سالم و یک کانتینر v2 معیوب داشته باشیم:

رفع اشکال

بنابراین، ما یک ظرف معیوب داریم، و زمان تخلیه استخر است. با استفاده از یک پیکربندی بسیار ساده، این کانتینر ناموفق را به مدت 15 ثانیه از هر طرح مسیریابی حذف می کنیم به این امید که به حالت سالم بازگردد (یا راه اندازی مجدد یا بازیابی عملکرد). این پیکربندی و نتایج کار آن به این صورت است:

همانطور که می بینید، کانتینر v2 شکست خورده دیگر برای درخواست های مسیریابی استفاده نمی شود زیرا از استخر حذف شده است. اما پس از 15 ثانیه به طور خودکار به استخر باز می گردد. در واقع، ما فقط نحوه عملکرد Pool Ejection را نشان دادیم.

بیایید معماری را شروع کنیم

Pool Ejection، همراه با قابلیت های نظارت ایستیو، به شما امکان می دهد تا شروع به ساخت چارچوبی برای جایگزینی خودکار ظروف معیوب کنید تا زمان خرابی و خرابی ها را کاهش دهید، اگر نه حذف کنید.
 
ناسا یک شعار بلند دارد - شکست یک گزینه نیست که نویسنده آن مدیر پرواز در نظر گرفته می شود. جین کرانز. می توان آن را به روسی به عنوان "شکست یک گزینه نیست" ترجمه کرد، و معنای اینجا این است که اگر اراده کافی داشته باشید، می توان همه چیز را به کار انداخت. با این حال، در زندگی واقعی، شکست‌ها فقط اتفاق نمی‌افتند، بلکه در همه جا و در همه چیز اجتناب‌ناپذیر هستند. و در مورد میکروسرویس ها چگونه باید با آنها برخورد کرد؟ به نظر ما، بهتر است نه بر اراده، بلکه به قابلیت های کانتینرها تکیه کنیم. کوبرنیتس, سرخپوش OpenShiftو ایستیو.

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

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

مدار شکن در تئوری

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

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

مدار شکن در عمل

به عنوان مثال، ما دو نسخه از میکروسرویس پیشنهادی خود را در OpenShift اجرا خواهیم کرد. نسخه 1 به خوبی کار می کند، اما در نسخه 2 ما با تاخیر ایجاد می کنیم تا کاهش سرعت در سرور را شبیه سازی کنیم. برای مشاهده نتایج، از ابزار استفاده کنید محاصره:

siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io

به نظر می رسد همه چیز کار می کند، اما به چه قیمتی؟ در نگاه اول، ما 100٪ در دسترس بودن داریم، اما نگاهی دقیق‌تر بیندازید - حداکثر مدت تراکنش 12 ثانیه است. این به وضوح یک گلوگاه است و باید گسترش یابد.

برای این کار از ایستیو برای حذف تماس با کانتینرهای کند استفاده می کنیم. این چیزی است که پیکربندی مربوطه با استفاده از Circuit Breaker به نظر می رسد:

آخرین خط با پارامتر httpMaxRequestsPerConnection نشان می دهد که هنگام تلاش برای ایجاد یک اتصال دیگر - دوم - علاوه بر اتصال موجود، باید اتصال با آن قطع شود. از آنجایی که کانتینر ما یک سرویس آهسته را شبیه سازی می کند، چنین موقعیت هایی به صورت دوره ای ایجاد می شود و سپس ایستیو یک خطای 503 را برمی گرداند، اما این چیزی است که siege نشان می دهد:

خوب، ما Circuit Breaker داریم، بعد چی؟

بنابراین، ما خاموش شدن خودکار را بدون دست زدن به کد منبع خود سرویس ها اجرا کردیم. با استفاده از Circuit Breaker و Pool Ejection که در بالا توضیح داده شد، می‌توانیم محفظه‌های ترمز را تا زمانی که به حالت عادی برمی‌گردند را از مخزن منبع خارج کنیم و وضعیت آنها را در یک فرکانس مشخص بررسی کنیم - در مثال ما، این دو دقیقه است (پارامتر SleepWindow).

توجه داشته باشید که توانایی برنامه برای پاسخ به خطای 503 هنوز در سطح کد منبع تنظیم شده است. استراتژی های زیادی برای استفاده از Circuit Breaker بسته به شرایط وجود دارد.

در پست بعدی: ما در مورد ردیابی و نظارتی که قبلاً تعبیه شده یا به راحتی به ایستیو اضافه شده است و همچنین نحوه وارد کردن عمدی خطاها به سیستم صحبت خواهیم کرد.

منبع: www.habr.com