تخریب برازنده

1) ماهیت رویکرد

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

• قابل پیش بینی: سناریوهای از پیش تعریف شده و تخریب «نردبان».
• محدود کردن شعاع ضربه: ویژگی ها و محدودیت ها را جدا کنید.
• قابلیت مشاهده: معیارها، سیاهههای مربوط و ردیابی «چه سطح تخریب فعال است و چرا».
• برگشت پذیری: بازگشت سریع به حالت عادی.

2) اصول و مرزها

1. نکته اصلی را ذخیره کنید: SLA/SLO اصلی شما (به عنوان مثال «خرید»، «ورود»، «جستجو») - اولویت بالاتر از ثانویه است (آواتار، توصیه، انیمیشن).

• امنیت، پرداخت، حقوق - شکست بسته (امتناع بهتر از نقض).
• محتوای کش, نکات, آواتار - شکست باز با folback.
• 3. بودجه های زمانی: تایم اوت های بالا به پایین (client
• 4. کنترل هزینه: تخریب باید مصرف CPU/IO/شبکه را کاهش دهد، نه فقط «پنهان کردن» خطاها.

3) سطح تخریب

3. 1 مشتری/UX

اسکلت/متغیرهایی و بارگذاری «تنبل» ویدجت ثانویه.
UI جزئی: بلوک های بحرانی بارگذاری می شوند، بلوک های ثانویه پنهان/ساده می شوند.
حافظه نهان سمت مشتری: آخرین شناخته شده (LKG) با علامت «داده ها ممکن است منسوخ شده باشند».
حالت آفلاین: صف فرمان با تکرار بعد (idempointence!).

3. 2 لبه/CDN/WAF/API دروازه

stale-while-revalidate: کش را می دهیم، پس زمینه را به روز می کنیم.
محدود کردن نرخ و بارگذاری بار: هنگام بارگیری، ترافیک پس زمینه/ناشناس را بازنشانی کنید.
مسیریابی Geofence/Weighted: ترافیک به نزدیکترین منطقه سالم هدایت می شود.

3. 3 لایه خدمات

پاسخ جزئی: بازگشت بخشی از + «هشدار» داده است.
حالت فقط خواندنی: به طور موقت ممنوع جهش (پرچم).
Brownout: موقت غیر فعال کردن ویژگی های منابع فشرده (توصیه, غنی سازی).
همزمانی تطبیقی: به صورت پویا همزمانی را کاهش میدهد.

3. 4 داده/جریان

کش به عنوان یک منبع حقیقت با TTL (به طور موقت): «تقریبا بهتر از هیچ چیز».
کاهش دقت مدل ها/الگوریتم ها (مسیر سریع در مقابل مسیر دقیق).
تعویق/صف - انتقال وظایف سنگین به پس زمینه (صندوق خروجی/صف کار).
صف های اولویت: رویدادهای بحرانی - در یک کلاس جداگانه.

4) تخریب «نردبان» (کتاب های بازی)

• L0 (عادی) → L1: مخفی کردن شخصی سازی و آگهی ها → L2: جستجوی مترادف/فازی را غیرفعال کنید → L3: محدود کردن اندازه پاسخ و اتمام وقت تا 300 ms → L4: نتایج را از حافظه پنهان 5 دقیقه → L5: «فقط خواندنی و فقط ذخیره شده» + صف درخواست برای محاسبه مجدد.

• Triggers: CPU overload> 85% p95> target, errors> threshold, Kafka> threshold flag, dependency flag.
• اقدامات: پرچم X را روشن کنید، همزمانی را به N کاهش دهید، منبع Y را به حافظه پنهان تغییر دهید.
• معیارهای خروج: 10 دقیقه معیارهای سبز، سر منابع.

5) سیاست های تصمیم گیری

5. 1 بودجه اشتباه و SLO

از نرخ سوزاندن بودجه خطا به عنوان یک محرک قهوه ای/ریختن استفاده کنید.
خط مشی: «اگر میزان سوختگی> 4 × در عرض 15 دقیقه - تخریب L2 را روشن کنید».

5. 2 کنترل پذیرش

ما RPS ورودی را در مسیرهای بحرانی محدود می کنیم تا p99 را تضمین کنیم و از فروپاشی صف جلوگیری کنیم.

5. 3 اولویت بندی

کلاس ها: تعاملی> سیستم> پس زمینه.
اولویت های هر مستاجر (طلا/نقره/برنز) و عدالت (سهم عادلانه).

6) الگوها و پیاده سازی ها

6. 1 ریختن بار

درخواستها را قبل از اینکه تمام منابع را بگیرند، حذف کنید.
بازگشت «429 »/« 503» با «دوباره سعی کنید پس از» و توضیح سیاست (برای مشتریان).

نماینده (همزمانی تطبیقی + شکستن مدار)

yaml typed_extension_protocol_options:
envoy. filters. http. adaptive_concurrency:
"@type": type. googleapis. com/envoy. extensions. filters. http. adaptive_concurrency. v3. AdaptiveConcurrency gradient_controller_config:
sample_aggregate_percentile: 90 circuit_breakers:
thresholds:
- max_requests: 2000 max_pending_requests: 500 max_connections: 1000

6. 2 Brownout (ساده سازی موقت)

ایده: برای کاهش «روشنایی» (هزینه) ویژگی زمانی که منابع در حال اجرا هستند.

kotlin class Brownout(val level: Int) { // 0..3 fun recommendationsEnabled() = level < 2 fun imagesQuality() = if (level >= 2) "low" else "high"
fun timeoutMs() = if (level >= 1) 150 else 300
}

6. ۳ پاسخ و هشدارهای جزئی

json
{
"items": [...],
"degradation": {
"level": 2,
"applied": ["cache_only", "no_personalization"],
"expiresAt": "2025-10-31T14:20:00Z"
}
}

6. 4 Stale-while-revalidate در لبه (Nginx)

nginx proxy_cache_valid 200 10m;
proxy_cache_use_stale error timeout http_500 http_502 http_504 updating;
proxy_cache_background_update on;

6. 5 سوئیچ فقط خواندنی (Kubernetes + پرچم)

yaml apiVersion: v1 kind: ConfigMap data:
MODE: "read_only"

The code should check MODE and block mutations with a friendly message.

6. 6 کافکا: کلاس های فشار پشتی و صف

مصرف کنندگان سنگین را به «max» کوچکتر تغییر دهید. نظرسنجی. سوابق، محدود کردن دسته تولید و.
رویدادهای «انتقادی» و «فله» را بر اساس موضوع/سهمیه جدا کنید.

6. 7 UI: عقب نشینی برازنده

پنهان کردن ویدجت های «سنگین»، نشان دادن کش/اسکلت و به وضوح برچسب داده های قدیمی.

7) نمونه های پیکربندی

7. 1 Istio outlier + استخرهای اولویت

yaml outlierDetection:
consecutive5xx: 5 interval: 10s baseEjectionTime: 30s maxEjectionPercent: 50

7. 2 Nginx: ترافیک پس زمینه زیر چاقو اول

nginx map $http_x_priority $bucket { default low; high high; }

limit_req_zone $binary_remote_addr zone=perip:10m rate=20r/s;
limit_req_status 429;

server {
location /api/critical/ { limit_req zone=perip burst=40 nodelay; }
location /api/background/ {
limit_req zone = perip burst = 5 nodelay; # stricter
}
}

7. 3 ویژگی های پرچم/کشتن سوئیچ

ذخیره در پیکربندی پویا (ConfigMap/Consul)، به روز رسانی بدون انتشار.
جداگانه هر ویژگی و پرچم های جهانی، فعال ورود به سیستم.

8) قابلیت مشاهده

8. 1 معیارها

«degradation _ level {service}» سطح فعلی است.
'shed _ requests _ total {route, reason}' - مقدار بازنشانی و چرایی آن چقدر است.
'stale _ responses _ total' - چه مقدار کش صادر شده است.
'read _ only _ mode _ seconds _ total'.
'brownout _ activations _ total {feature}'.
بودجه اشتباه: نرخ سوختن، نسبت نقض SLO.

8. 2 ردیابی

ویژگی های دهانه: 'degraded = true', 'level = 2', 'reason = upstream _ timeout'.
پیوندهای بین درخواستهای retrays/hedged برای دیدن سهم در دم.

8. 3 سیاههها/هشدارها

سطح تخریب حوادث سوئیچ با علل تغییر و مالک.
هشدار برای سطح «چسبیده» (تخریب طول می کشد بیش از حد طولانی).

9) مدیریت ریسک و امنیت

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

10) ضد الگوهای

تخریب آرام بدون ایجاد کاربر و بدون تله متری.
طوفان های Retray به جای ریختن بار و زمان کوتاه.
جهانی «سوئیچ» بدون تقسیم بندی - شعاع انفجار بزرگ.
prod و مسیرهای سبک وزن را در همان کش/صف مخلوط کنید.
تخریب ابدی: brownout به عنوان «عادی جدید»، معیارهای خروج فراموش شده.
Stale-write: تلاش برای نوشتن بر اساس دادههای stale.

11) چک لیست پیاده سازی

• ارزش اصلی و سناریوهای مهم کاربر تعریف شده است.
• نردبان تخریب توسط سرویس/domaine با باعث و خروجی وارد شده است.
• زمان بندی/محدودیت ها و بارگذاری سمت سرور وارد می شوند.
• محدودیت های نرخ و کلاس های ترافیک اولویت پیکربندی شده اند.
• پاسخ جزئی اجرا شده، فقط خواندنی، stale-while-revalidate.
• پرچم ویژگی های یکپارچه/کشتن سوئیچ با حسابرسی.
• متریک/ردیابی/هشدار برای سطوح تخریب و علل.
• به طور منظم تمرینات روز بازی با اضافه بار شبیه سازی/شکست.
• SLO مستند و خطا بودجه → سیاست تخریب.

12) سوالات متداول

س: هنگامی که برای انتخاب قهوه ای و زمانی که به ریختن ؟

A: اگر هدف این است که کاهش هزینه درخواست بدون شکست - brownout. اگر هدف این است که برای محافظت از سیستم زمانی که حتی ساده سازی کمک نمی کند، ریختن ورود به سیستم.

س: آیا من گزارش تخریب به کاربر ؟

A: برای سناریوهای بحرانی - بله (نشان «حالت محدود»). شفافیت حمایت و نارضایتی را کاهش می دهد.

س: آیا می توان یک حافظه پنهان را منبع حقیقت دانست ؟

A: به طور موقت - بله، با SLA های صریح و برچسب های پیری. برای جهش - ممنوع است.

س: چگونه می توان «شکسته» نشد ؟

A: مدت زمان کوتاه، عقب نشینی نمایشی با jitter، idempotency و حد تلاش ؛ فقط عملیات ایمن را انجام دهید.

13) مجموع

تخریب برازنده یک قرارداد معماری و مجموعه ای از حالت های کنترل شده عملکرد است که توسط سیگنال های معیارها و بودجه اشتباه روشن می شود. پله ها به درستی طراحی شده، زمان بندی دقیق و ریختن، cashback و brownout، به علاوه قابلیت مشاهده قدرتمند - و پلت فرم خود را مفید و مقرون به صرفه حتی در طوفان باقی می ماند.