نمونه های زنده/آمادگی

2) اصول طراحی

1. معناشناسی جداگانه

آمادگی: توانایی خارجی برای ارائه خدمات به درخواست ها (با توجه به وابستگی های بحرانی).
Liveness: قابلیت تشخیص وضعیت «غیرقابل تحمل» این روند.
2. Fail-fast، اما نه false-fast. تنظیم timeouts/آستانه 'failureThreshold' به طوری که انفجار کوتاه به راه اندازی مجدد غیر ضروری منجر نمی شود.
3. بدون عملیات سنگین در نمونه. چک باید سریع (≤100 -200 میلی ثانیه) و بدون عوارض جانبی باشد.
4. تنزل مقام برازنده در صورت عدم دسترسی جزئی وابستگی ها - آمادگی = OK، اگر یک follback امن (cache/coarsening) وجود داشته باشد.
5. تعیین کننده I/O وضعیت فقط به وضعیت فعلی بستگی دارد، نه به آزمون های خارجی «تصادفی».

3) معناشناسی نقاط پایانی سلامت

3. 1 رویکرد HTTP (توصیه می شود)

GET/healz/liveness → 200 اگر روند «زنده» باشد (رویداد حلقه در حال چرخش است، GC گیر نکرده است، نگهبان «قلب» ضرب و شتم).
'GET/healz/readiness' → 200 اگر نمونه برای ترافیک بحرانی کلاس آماده باشد. چک: استخر اتصال، حافظه های پنهان محلی، در دسترس بودن هسته منطق کسب و کار.
'GET/healthz/startup' → 200 پس از راه اندازی (مدل های مهاجرت/کش گرم کردن/بارگیری).

• شما نمی توانید به پایگاه های داده/API های خارجی در زندگی بروید - این منجر به «خودکشی» در حوادث وابستگی خواهد شد.
• در آمادگی، شما می توانید وابستگی های بحرانی را بررسی کنید، اما با زمان بندی و تخریب: اگر یک follback معتبر وجود دارد، آن را پایین نیاورید.

3. 2 gRPC بررسی سلامت

از استاندارد «grpc» استفاده کنید. سلامتی. V1 بهداشت و درمان/بررسی "با کشورهای خدماتی (" خدمت "،" NOT _ SERVING "). برای Kubernetes - پروب grpc (یا پروکسی http).

3. 3 عوامل داخلی

Watchdog «soft» stop: with sIGTERM set Readiness = FAIL → منتظر «terminationGracePeriodSeconds» → end, working out queues.

4) زمان بندی و آستانه (تنظیم)

• 'initialDelaySeconds', 'periodSeconds', 'timeoutSeconds', 'successThreshold', 'failureThreshold'.

• آمادگی: 'period = 5s, timeout = 0. 2–0. 5 ثانیه، شکست = 2 '
• liveness: 'period = 10s, timeout = 0. 2–0. 5S، شکست = 3 '

• startup: 'period = 5s, failure = 60' (حداکثر ~ 5 دقیقه)
• آمادگی/زندگی پس از موفقیت راه اندازی فعال می شود

• آمادگی نشان دهنده آمادگی برای پردازش (اتصال به یک کارگزار، آیا تخریب DLQ وجود دارد)،
• liveness - حلقه ضربان قلب درونی.

Backoff on failures: در برنامه، از backoff نمایشی برای اتصال مجدد به وابستگی ها استفاده کنید، در غیر این صورت آمادگی «دیده می شود».

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 Kubernetes، نمونه 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' بررسی کرد.

غیر بحرانی: تجزیه و تحلیل، ایمیل، لایه کش اگر بار وجود دارد. آنها را در حالت آماده باش قرار ندهید. استفاده از یک follbeck

پرچم های ویژگی: اگر به طور جزئی تخریب شود، ویژگی های وابسته را غیرفعال کنید در حالی که حفظ آمادگی = OK.

7) صف ها و دستگیره های پس زمینه

• آمادگی = OK اگر اشتراک/اتصال به کارگزار نصب شده است و یک منبع برای پردازش وجود دارد.
• آمادگی ممکن است خوب باقی بماند (اگر ما قبول کنیم و اضافه کنیم)، اما SLI «طراوت/تاخیر» روشن می شود - هشدار با توجه به داده ها.
• زنده بودن: کنترل چرخه نظرسنجی/ضربان قلب، deathdetector.

Idempotence: تسریع بهبود از زندگی مجدد.

8) Sidecar/مش/ورود

• «readinessGate» (K8s) را برای حساب وضعیت جانبی فعال کنید،
• اطمینان حاصل کنید که نمونه ها در موانع mTLS قرار نمی گیرند (یا استثنائات را اضافه می کنند).
• ورود/فرستاده/Nginx: Prox '/healz/' به صورت محلی، قطعات داخلی را بیرون نکشید.

9) امنیت و حریم خصوصی

Endpoints Health نباید پیکربندی ها، نسخه های کتابخانه، رشته های خطا را افشا کند - فقط «OK/FAIL» + حداقل علت کد.
دسترسی خارجی را محدود کنید (NetworkPolicy/ACL). برای عمومی - اجازه دهید فقط زنده بودن پینگ بدون جزئیات.
سیاهههای مربوط به چک های بهداشتی - در سطح DEBUG، با کاهش.

10) قابلیت مشاهده و SLO

معیارهای صادرات: «health _ readiness {status}»، «health _ liveness {status}»، زمان پردازش نمونه.
پرچم های آمادگی وابسته با SLO در دسترس بودن (کاهش از نقاط پایانی → تنظیم مجدد 5xx/اتصال).

• «شروع مجدد مکرر توسط زندگی> N/ساعت» - نشانه ای از بن بست/نشت.
• «Flap Readiness> X/15 min» - نشانه اعتیاد/مشکلات شبکه است.
• ارتباط با استقرار ('سرویس. نسخه ').

11) تست کردن

واحد/قرارداد: نقاط پایانی/healz/' بازگشت وضعیت صحیح زمانی که هر وابستگی غیر فعال است.
هرج و مرج: غیر فعال کردن پایگاه داده/کش/کارگزار: آمادگی باید سقوط و یا فعال کردن follback به شدت با توجه به مدل. زنده بودن - اگر روند «زنده» باشد، باعث نمی شود.
Load/Soak: تحت بار، نقاط پایانی سلامت باید سریع باقی بمانند (محتوا را فشار ندهید).
Canary: قبل از افزایش ترافیک، ثبات آمادگی را بررسی کنید.

12) اشتباهات مکرر و چگونگی اجتناب از آنها

Liveness پایگاه داده ها/API های خارجی را بررسی می کند. نتیجه شروع مجدد بی پایان برای حوادث است. راه حل: محدود کردن زندگی به «روند زندگی».
چک های سنگین در نمونه ها منجر به شکست های کاذب می شود. راه حل: چک نور + فردی مانیتور سلامت پس زمینه.
بدون کاوشگر راه اندازی. شروع آهسته «کشته» می شود. راه حل: راه اندازی را با یک پنجره گسترده اضافه کنید.
بدون خاموش شدن برازنده. 5xx نادر در تخلیه. راه حل: عدم تعادل preStop +.
طوفان های فلپ آستانه هاي خيلي تهاجمي راه حل: بالا بردن 'failureThreshold'، افزایش 'timeoutSeconds'، اضافه کردن backoff.
همان نقطه پایان برای همه چیز. مخلوط کردن معانی. راه حل: زندگی/آمادگی/راه اندازی فردی.

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) چک لیست

قبل از فروش

• نقاط پایانی زندگی/آمادگی/راه اندازی جدا شده اند، معانی آنها شرح داده شده است.
• زنده بودن وابستگی های خارجی را لمس نمی کند ؛ آمادگی فقط با زمانبندی و follbeck تست می شود.
• Configured 'initialDelay/period/timeout/failureThreshold' برای نمایه سرویس.
• خاموش کردن برازنده را فعال کنید: «توقف» + عدم تعادل.
• معیارهای سلامت/سیاهههای مربوط متصل می شوند ؛ هشدارها برای راه اندازی مجدد/فلپ.
• شکست وابستگی و آزمون شروع آهسته گذشت.

عملیات

• گزارش هفتگی در راه اندازی مجدد و پرچم آمادگی.
• تنظیم آستانه پس از حوادث ؛ ارتباط با آزادی ها
• آزمون هرج و مرج به طور منظم از غیر فعال کردن وابستگی.
• ارتباط معانی زمانی که وابستگی بحرانی تغییر می کند.

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

س: آیا می توان همه چیز را با یک شکست بست ؟

A: ناخواسته جداگانه «راه اندازی»، «آمادگی»، «زنده بودن» - این مثبت کاذب را کاهش می دهد و سرعت RCA را افزایش می دهد.

س: آیا مخزن را در آمادگی بررسی می کنم ؟

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

س: با شروع مجدد مکرر برای زندگی چه باید کرد ؟

A: ابتدا یک dektor/leak را رد کنید ؛ سپس آستانه ها را شل کنید و یک نگهبان را در برنامه اضافه کنید.

س: چگونه برای چند اجاره حساب کنیم ؟

A: آمادگی باید توانایی خدمت به هر ترافیک اجاره را نشان دهد. برای مشکلات خصوصی یک مستاجر خاص - آمادگی را تغییر ندهید، اما با SLI/هشدار جداگانه سیگنال دهید.

• «قابلیت مشاهده: سیاهههای مربوط، معیارها، ردیابی»
• «آثار توزیع شده»
• «SLO/SLA و معیارها»
• «Webhook گارانتی تحویل»
• «در رمزگذاری حمل و نقل»
• «مدیریت مخفی»