تدهور رشيق

1) جوهر النهج

التدهور الرشيق هو الانتقال المُدار للنظام إلى وضع أبسط ولكنه مفيد عندما تكون الموارد نادرة أو تفشل التبعيات أو تصل إلى ذروتها. الهدف هو الحفاظ على جوهر قيمة المستخدم ومرونة النظام الأساسي من خلال التضحية بالقدرات الثانوية والجودة.

• إمكانية التنبؤ: سيناريوهات محددة مسبقًا و «سلالم» التدهور.
• نصف قطر الضربة المقيدة: عزل الميزات والقيود.
• إمكانية الرصد: المقاييس والسجلات والآثار «ما هو مستوى التحلل النشط ولماذا».
• الانعكاسية: العودة السريعة إلى طبيعتها.

2) المبادئ والحدود

1. احفظ الشيء الرئيسي: SLA/SLO الرئيسي (على سبيل المثال «شراء»، «دخول»، «بحث») - الأولوية أعلى من الثانوية (الصور الرمزية والتوصيات والرسوم المتحركة).

• الضمان والمدفوعات والحقوق - مغلقة (رفض أفضل من الانتهاك).
• محتوى مخبأ، تلميحات، صور رمزية - فشل في الفتح مع فولباك.
• 3. الميزانيات الزمنية: المهلات من أعلى إلى أسفل (العميل <البوابة <الخدمة). بعد انتهاء الصلاحية - التدهور بدلاً من التراجع إلى أجل غير مسمى.
• 4. التحكم في التكاليف: ينبغي أن يقلل التدهور من استهلاك وحدة المعالجة المركزية/المكتب الدولي/الشبكة، وليس فقط أخطاء «إخفاء».

3) مستويات التحلل

3. 1 عميل/UX

الهياكل العظمية/العناصر الفرعية والتحميل «الكسول» للأدوات الثانوية.
واجهة المستخدم الجزئية: يتم تحميل الكتل الحرجة، ويتم إخفاء/تبسيط الكتل الثانوية.
ذاكرة التخزين المؤقت لجانب العميل: آخر سلعة معروفة (LKG) تحمل علامة «ربما أصبحت البيانات قديمة».
الوضع غير المتصل: طابور الأمر مع التكرار لاحقًا (الخصوصية!).

3. 2 بوابة Edge/CDN/WAF/API

إعادة المصادقة التي لا معنى لها: نعطي المخبأ، ونحدّث الخلفية.
تحديد الأسعار وتسريح الأحمال: عند التحميل الزائد، إعادة ضبط الخلفية/حركة المرور المجهولة.
التوجيه الجغرافي/التوجيه المرجح: يتم تحويل حركة المرور إلى أقرب منطقة صحية.

3. 3 طبقة خدمة

الرد الجزئي: إعادة جزء من بيانات + «التحذيرات».
وضع القراءة فقط: حظر الطفرات مؤقتًا (الأعلام).
Brownout: التعطيل المؤقت للخصائص كثيفة الاستخدام للموارد (التوصيات والإثراء).
التزامن التكيفي: تقليل التزامن ديناميكيًا.

3. 4 بيانات/تدفق

ذاكرة التخزين المؤقت كمصدر للحقيقة مع TTL (مؤقتًا): «أفضل من لا شيء تقريبًا».
تقليل دقة النماذج/الخوارزميات (المسار السريع مقابل المسار الدقيق).
تأجيل/قائمة الانتظار - نقل المهام الثقيلة إلى الخلفية (صندوق الخروج/قائمة انتظار الوظائف).
قوائم الانتظار ذات الأولوية: الأحداث الحرجة - في فصل منفصل.

4) التحلل «السلالم» (كتب اللعب)

• L0 (عادي) → L1: إخفاء التخصيص واللافتات → L2: تعطيل المرادفات/البحث الغامض → L3: الحد من حجم الاستجابة والوقت المستقطع إلى 300 ms → L4: إعطاء نتائج من ذاكرة التخزين المؤقت 5 دقائق → L5: «قراءة فقط ومخبأة فقط» + طابور طلبات إعادة الحساب.

• المشغلات: الحمل الزائد لوحدة المعالجة المركزية> 85٪ p95> الهدف، الأخطاء> العتبة، علم العتبة كافكا>، علم التبعية.
• الإجراءات: قم بتشغيل العلم 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 براونوت (تبسيط مؤقت)

الفكرة: تقليل «سطوع» (تكلفة) الميزة عند نفاد الموارد.

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. 3 رد جزئي وتحذيرات

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

6. 4 إعادة المصادقة على الحافة (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 + flag)

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 واجهة المستخدم: احتياطي رشيق

أخفي الأدوات «الثقيلة»، وأظهر ذاكرة التخزين المؤقت/الهيكل العظمي ووصف البيانات القديمة بوضوح.

7) أمثلة التكوين

7. 1 تجمعات خارجية + أولوية

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 {الطريق، العقل} '- كم يتم إعادة ضبط ولماذا.
«الردود القديمة _ الكلية» - مقدار المخبأ الذي تم إصداره.
«اقرأ _ فقط _ mode _ seconds _ total».
«brownout _ activations _ total {feature}».
الميزانية الخاطئة: معدل الحرق، نسبة انتهاكات SLO.

8. 2 التعقب

سمات الامتدادات: «تحلل = صحيح»، «مستوى = 2»، «سبب = المنبع _ مهلة».
الروابط بين إعادة التصوير/الاستفسارات التحوطية لمعرفة المساهمة في الذيول.

8. 3 سجلات/تنبيهات

تبديل مستوى التدهور الأحداث مع أسباب التغيير والمالك.
تنبيهات مستوى «الالتصاق» (التدهور يستمر لفترة طويلة جدًا).

9) إدارة المخاطر والأمن

لا تحط من سلامة التوثيق/الإذن/البيانات: فشل أفضل.
يتم الحفاظ على إخفاء PII في أي وضع.
التمويل/المدفوعات: المعاملات الخفية فقط، والمهل الزمنية الصارمة والتراجع ؛ في شك - اقرأ فقط/انتظر.

10) الأنماط المضادة

تدهور هادئ دون دفع المستخدم وبدون قياس عن بعد.
إعادة العواصف بدلاً من التخلص من الأحمال والإجازات القصيرة.
«مفاتيح» عالمية بدون تجزئة - نصف قطر انفجار ضخم.
امزج مسارات الحث وخفيفة الوزن في نفس المخبأ/قائمة الانتظار.
التدهور الأبدي: البني كمعايير خروج «طبيعية جديدة» منسية.
الكتابة القديمة: محاولات الكتابة بناءً على البيانات القديمة.

11) قائمة التنفيذ المرجعية

• تحديد القيمة الأساسية وسيناريوهات المستعملين الحرجة.
• يتم تجميع سلالم التحلل حسب الخدمة/المجال مع المحفزات والنواتج.
• يتم إدخال المهلات/القيود وتسريح الأحمال بجانب الخادم.
• تم تشكيل حدود الأسعار وفئات المرور ذات الأولوية.
• تنفيذ رد جزئي، قراءة فقط، إعادة التحقق.
• أعلام الميزات المتكاملة/مفاتيح القتل مع التدقيق.
• المقاييس/التعقب/التنبيهات لمستويات التدهور وأسبابه.
• تمارين يوم اللعبة العادية مع محاكاة الحمل الزائد/الفشل.
• سياسة تدهور → الموثقة والمتعلقة بالأخطاء في الميزانية.

12) الأسئلة الشائعة

س: متى تختار البني ومتى تتساقط ؟

ج: إذا كان الهدف هو تقليل تكلفة الطلبات دون فشل - البني. إذا كان الهدف هو حماية النظام عندما لا يساعد حتى التبسيط، فإن التخلص من تسجيل الدخول.

س: هل أبلغ المستخدم عن التدهور ؟

ج: للسيناريوهات الحرجة - نعم (شارة «الوضع المحدود»). الشفافية تقلل من الدعم والاستياء.

س: هل يمكن جعل المخبأ مصدرًا للحقيقة ؟

ج: مؤقتًا - نعم، مع اتفاقيات SLAs الصريحة وملصقات الشيخوخة. للطفرات - محظورة.

س: كيف لا تجعل retrai «مكسورًا» ؟

ج: فترات زمنية قصيرة، وتراجع أسي مع النبض، والغباء، والحد من المحاولة ؛ استعادة العمليات الآمنة فقط.

13) المجاميع

التدهور الرشيق هو عقد معماري ومجموعة من أنماط التشغيل الخاضعة للرقابة، يتم تشغيلها بواسطة إشارات المقاييس والميزانية الخاطئة. سلالم مصممة بشكل صحيح، وإجازات صارمة وسفك، واسترداد النقود والبني، بالإضافة إلى إمكانية المراقبة القوية - وتظل منصتك مفيدة واقتصادية حتى في حالة حدوث عاصفة.