عينات حيوية/جاهزية

2) مبادئ التصميم

1. دلالات منفصلة.

الاستعداد: القدرة الخارجية على تقديم الطلبات (مع مراعاة حالات التبعية الحرجة).
الحساسية: إمكانية الكشف عن الحالة «غير القابلة للشفاء» للعملية.
2. فشل سريع، لكن ليس بسرعة كاذبة. اضبط المهلة/العتبة «الفشل» بحيث لا تؤدي الرشقات القصيرة إلى إعادة تشغيل غير ضرورية.
3. لا توجد عمليات ثقيلة في العينات. يجب أن يكون الفحص سريعًا (≤100 -200 مللي ثانية) وبدون آثار جانبية.
4. تدهور رشيق. في حالة عدم توفر التبعيات جزئيًا - الاستعداد = حسنًا، إذا كان هناك فولباك آمن (مخبأ/خشن).
5. الحتمية I/O. تعتمد الحالات فقط على الحالة الحالية، وليس على الاختبارات الخارجية «العشوائية».

3) دلالات نقاط النهاية الصحية

3. 1 نهج HTTP (موصى به)

«احصل على/صحة/حيوية» → 200 إذا كانت العملية «حية» (حلقة الحدث تدور، GC ليست عالقة، «القلب» المراقب ينبض).
«احصل على/صحة/استعداد» → 200 إذا كانت الحالة جاهزة لحركة مرور الفئة الحرجة. الشيكات: تجمع اتصال، مخابئ محلية، توافر نواة منطق العمل.
'GET/healthz/startup' → 200 بعد البدء (الهجرات/نماذج الإحماء/التحميل).

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

3. 2 gRPC الفحص الصحي

استخدم معيار «grpc». الصحة. v1. Health/Check 'with service-scoped states (' SERVICE ',' NOT _ SELVING '). لـ Kubernetes - مجسات grpc (أو http proxy).

3. 3 محفزات داخلية

توقف Watchdog "الناعم": مع مجموعة SIGTERM الاستعداد = فشل → انتظر نهاية → "إنهاء GracePeriodSeconds'، وتمرين قوائم الانتظار.

4) التوقيت والعتبات (الضبط)

• "IntialDelaySeconds' و" TimeSeconds' و "TimeoutSeconds' و" SuccessThreshold' و "failureThreshold'.

• الاستعداد: 'الفترة = 5s، المهلة = 0. 2–0. 5s، فشل = 2 '
• الحساسية: 'الفترة = 10 ثوانٍ، المهلة = 0. 2–0. 5s، فشل = 3 '

• بدء التشغيل: 'الفترة = 5 ث، الفشل = 60' (حتى 5 دقائق ~)
• تنشيط الاستعداد/الحساسية بعد نجاح الشركة الناشئة

• الاستعداد يعكس الاستعداد للمعالجة (الاتصال بالسمسار، سواء كان هناك تدهور في DLQ)،
• الحيوية - حلقة نبضات القلب الداخلية.

التراجع عن الإخفاقات: في التطبيق، استخدم التراجع الأسي لإعادة الاتصال بالتبعيات، وإلا فإن الاستعداد «سيرى».

5) التشكيلات (الشظايا)

5. 1 تحقيقات Kubernetes و HTTP

yaml livenessProbe:
httpGet: { path: /healthz/liveness, port: 8080 }
periodSeconds: 10 timeoutSeconds: 1 failureThreshold: 3

readinessProbe:
httpGet: { path: /healthz/readiness, port: 8080 }
periodSeconds: 5 timeoutSeconds: 1 failureThreshold: 2

startupProbe:
httpGet: { path: /healthz/startup, port: 8080 }
periodSeconds: 5 failureThreshold: 60

5. 2 كوبرنيت، عينة gRPC

yaml readinessProbe:
grpc:
port: 9090 service: my. app. Service periodSeconds: 5 timeoutSeconds: 1

5. 3 إغلاق رشيق

yaml terminationGracePeriodSeconds: 30 lifecycle:
preStop:
exec:
command: ["/bin/sh","-c","curl -s localhost:8080/healthz/drain && sleep 5"]

«/healthz/drain »داخل الخدمة يترجم الاستعداد = FAIL (التوقف عن القبول)، يمنح الوقت لإكمال الطلبات النشطة.

6) التبعيات والتدهور

الحرج (لا يمكن خدمته بدونهم): قاعدة بيانات الإذن لـ «/دخول »، وبوابة الدفع لـ «/دفع». يمكن فحص الاستعداد مع المهلة ≤80٪ من عينات "timeoutSeconds'.
غير حرج: التحليلات، البريد الإلكتروني، طبقة التخزين المؤقت إذا كان هناك حمل. عدم إشراكهم في الاستعداد ؛ استخدم البصيلات.
أعلام الميزة: إذا تدهورت جزئيًا، فقم بتعطيل الميزات المعتمدة مع الحفاظ على الاستعداد = حسنًا.

7) قوائم الانتظار ومعالجي الخلفية

• الاستعداد = حسنًا إذا تم تثبيت اشتراك/اتصال بالوسيط وكان هناك مورد للمعالجة.
• عند فائض DLQ/التأخر → قد يظل الاستعداد جيدًا (إذا قبلنا وأضفنا)، لكن SLI «نضارة/تأخر» تضيء - تنبيه وفقًا للبيانات.
• الحيوية: التحكم في دورة الاستطلاع/نبضات القلب، كاشف الموت.

الخصوصية: تسريع التعافي من إعادة تشغيل الحيوية.

8) سيدكار/شبكة/دخول

• تمكين «بوابة الاستعداد» (K8s) لحساب حالة السيارة الجانبية،
• التأكد من أن العينات لا تقع ضمن حواجز mTLS (أو إضافة استثناءات).
• الدخول/المبعوث/Nginx: Prox '/healthz/' محليًا، لا «تبرز» الأجزاء الداخلية.

9) الأمن والخصوصية

يجب ألا تكشف نقاط النهاية الصحية عن التكوينات وإصدارات المكتبة وسلاسل الخطأ - فقط «OK/FAIL» + رمز السبب الأدنى.
تقييد الوصول الخارجي (NetworkPolicy/ACL). للجمهور - دعنا فقط نتحرك دون تفاصيل.
سجلات الفحوصات الصحية - على مستوى DEBUG، مع الاختناق.

10) إمكانية الرصد و SLO

مقاييس التصدير: 'health _ readiness {status}', 'health _ liality {status}', sample processing time.
أعلام الاستعداد المرتبطة مع SLOs المتاحة (انخفض من نقاط النهاية → 5xx/إعادة تعيين الاتصال).

• «إعادة التشغيل المتكررة بالحيوية> N/hour» - أحد أعراض الجمود/التسريبات.
• «Flap Readiness> X/15 min» - أحد أعراض الإدمان/مشاكل الشبكة.
• الارتباط مع النشر ('الخدمة. (.

11) الاختبار

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

12) الأخطاء المتكررة وكيفية تجنبها

يتحقق من قواعد البيانات/واجهات برمجة التطبيقات الخارجية. والنتيجة هي إعادة تشغيل لا نهاية لها للحوادث. الحل: قصر الحياة على «معالجة الحياة».
فحوصات ثقيلة في العينات. يؤدي إلى إخفاقات كاذبة. الحل: الفحوصات الخفيفة + شاشات صحة الخلفية الفردية.
لا مسبار بدء التشغيل. البدايات البطيئة «تقتل» بالحيوية. الحل: أضف شركة ناشئة مع نافذة واسعة.
لا إغلاق رشيق. نادر 5xx في debena. الحل: PreStop + عدم التوازن.
عواصف رفرف. عتبات عدوانية للغاية. الحل: رفع «عتبة الفشل»، زيادة «المهلة»، إضافة التراجع.
نفس نقاط النهاية لكل شيء. خلط الدلالات. الحل: «الحياة/الاستعداد/بدء التشغيل» الفردي.

13) أنماط التنفيذ المصغرة

python
@app. get("/healthz/liveness")
def liveness():
return 200

@app. get("/healthz/readiness")
def readiness():
ok_core = core_is_ready () # local pools/caches/initialization ok_db = db. ping (timeout = 50 _ ms) # only if the DB is critical return 200 if (ok_core and ok_db) else 503

@app. get("/healthz/startup")
def startup():
return 200 if INIT_DONE else 503

@app. post("/healthz/drain")
def drain():
set_readiness(False); return 200

go
// use google. golang. org/grpc/health/grpc_health_v1 healthServer. SetServingStatus("my. app. Service", SERVING) // or NOT_SERVING

yaml spec:
readinessGates:
- conditionType: "proxy. istio. io/ready"

14) القوائم المرجعية

قبل البيع

• يتم فصل نقاط النهاية للحيوية/الاستعداد/بدء التشغيل، ويتم وصف دلالاتها.
• لا تمس الحيوية التبعيات الخارجية ؛ تختبر الجاهزية فقط مع المهلة والبصيلات.
• تم تكوين «التأخير الأولي/الفترة/المهلة/الفشل عتبة» لملف تعريف الخدمة.
• تمكين الإغلاق الرشيق: «توقف مسبقًا» + عدم التوازن.
• يتم توصيل المقاييس/الجذوع الصحية ؛ تنبيهات لإعادة التشغيل/رفرف.
• فشل التبعية واختبارات البداية البطيئة مرت.

عملية

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

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

س: هل من الممكن إغلاق كل شيء بانهيار واحد ؟

ج: غير مرغوب فيه. منفصل «بدء التشغيل» و «الاستعداد» و «الحيوية» - وهذا يقلل من الإيجابيات الخاطئة ويسرع RCA.

س: هل أتحقق من المخبأ استعدادًا ؟

ج: إذا كان هناك وضع صحيح (وإن كان أبطأ) بدون ذاكرة تخزين مؤقت، فلا تقلل من الاستعداد، فقط قم بتشغيل التدهور.

س: ماذا تفعل مع عمليات إعادة التشغيل المتكررة للحيوية ؟

ج: استبعاد الكاهن/التسريب أولاً ؛ ثم تخفيف العتبات وإضافة رقيب في التطبيق.

س: كيف نحسب الإيجارات المتعددة ؟

ج: يجب أن يعكس الاستعداد القدرة على خدمة أي حركة تأجير. بالنسبة للمشاكل الخاصة لمستأجر معين - لا تغير الاستعداد، ولكن قم بالإشارة باستخدام SLI/تنبيهات منفصلة.

• «إمكانية الرصد: السجلات والمقاييس والآثار»
• «آثار موزعة»
• "SLO/SLA and Metrics'
• «ضمانات تسليم الويب»
• «In Transit Encryption»
• «الإدارة السرية»