Modul 07Penggal 3 · Kebolehpercayaan dan skala8 item poster

Corak Ketahanan

Log masuk untuk menyimpan kemajuan anda merentas peranti. Sehingga itu, ia disimpan dalam pelayar ini.

Mengapa ini penting

Setiap panggilan luaran (pangkalan data, gerbang pembayaran, penyedia LLM, SMS) pada satu masa nanti akan menjadi perlahan, gagal, atau gagal separuh jalan. Kod yang dijana AI hampir selalu menganggap laluan bahagia sahaja. Satu dependency yang perlahan tanpa timeout boleh menjatuhkan seluruh aplikasi anda dengan menghabiskan thread, sambungan atau concurrency serverless.

Hasil pembelajaran

  1. Letakkan timeout pada setiap panggilan keluar dan tetapkannya berdasarkan bajet latency.
  2. Retry dengan selamat: hanya operasi idempotent, dengan exponential backoff dan jitter, dengan had.
  3. Gunakan circuit breaker dan fallback untuk degradasi yang anggun.
  4. Gunakan backpressure dan dead letter queue supaya beban berlebihan dan mesej beracun tidak merebak.
  5. Dedahkan health check yang bermakna.

Pelajaran

7.1 Timeout (11)

  • Timeout lalai dalam banyak client HTTP ialah tanpa had atau berminit-minit. Tetapkan secara eksplisit: connect timeout + request timeout.
  • Terbitkan daripada bajet: jika halaman mesti memberi respons dalam 2 s dan memanggil tiga servis secara berjujukan, setiap satu mendapat jauh di bawah 2 s.
  • Sebarkan deadline: jika pemanggil hanya ada baki 300 ms, jangan mulakan panggilan 2 s.
  • Panggilan LLM: gunakan streaming dengan timeout token pertama dan timeout keseluruhan.

7.2 Retry dan exponential backoff (12, 13)

  • Retry hanya ralat sementara (timeout, 429, 502, 503, 504, connection reset). Jangan sekali-kali retry 400/401/403/422.
  • Retry hanya operasi idempotent, atau yang membawa idempotency key (04 · API dan Kontrak).
  • Backoff: delay = min(cap, base * 2^attempt) ditambah jitter rawak supaya beribu-ribu client tidak retry serentak (thundering herd).
  • Hadkan cubaan (selalunya 3) dan jumlah masa. Patuhi Retry-After.
  • Retry di satu lapisan sahaja. Retry di setiap lapisan akan berganda: 3 x 3 x 3 = 27 panggilan bagi satu tindakan pengguna.

7.3 Circuit breaker (10)

Keadaan: closed (normal) → open selepas ambang kegagalan (gagal cepat, tiada panggilan) → half-open selepas tempoh bertenang (benarkan beberapa panggilan lalu untuk menguji) → closed jika sihat. Pasangkan dengan fallback: data cache, ciri yang dikurangkan, mesej beratur "kami akan maklumkan anda," atau penyedia sekunder (cth. vendor LLM kedua).

7.4 Bulkhead dan backpressure (44)

  • Bulkhead: pool/had berasingan bagi setiap dependency supaya LLM yang perlahan tidak menghabiskan kapasiti yang diperlukan endpoint log masuk anda.
  • Backpressure: apabila consumer tidak dapat mengejar, tolak balik (queue terhad, 429/503 dengan Retry-After, load shedding kerja keutamaan rendah) dan bukannya menimbal sehingga memori habis.

7.5 Dead letter queue (20)

Selepas N cubaan pemprosesan gagal, pindahkan mesej ke DLQ dan bukannya retry selama-lamanya ("mesej beracun" boleh menyekat queue). Beri amaran tentang kedalaman DLQ. Bina alat untuk memeriksa, membaiki dan replay.

7.6 Health check (56, 57)

  • Liveness: "adakah proses masih hidup?" Murah; jangan sekali-kali semak dependency (jika tidak, satu gangguan kecil DB akan restart setiap pod).
  • Readiness: "bolehkah saya melayan trafik sekarang?" Semak dependency kritikal; keluarkan instance daripada load balancer apabila false.
  • Startup: untuk servis yang lambat boot.
  • Halaman status awam yang disuap oleh synthetic check terhadap perjalanan pengguna sebenar.

7.7 Degradasi yang anggun

Tentukan bagi setiap ciri: apa yang pengguna lihat apabila dependency ini down? Tuliskannya. Contoh: cadangan disembunyikan, pembayaran dimasukkan ke queue dengan mesej yang jelas, pembantu AI menunjukkan "tidak tersedia buat sementara waktu" dan bukannya spinner yang berpusing selama-lamanya.

Makmal 7: Chaos di laptop anda

Gunakan Toxiproxy (atau middleware fault-injection) antara aplikasi anda dan dependency-nya.

  1. Tambah latency 5 s kepada penyedia LLM. Perhatikan. Tambah timeout, retry dengan jitter, circuit breaker, fallback. Perhatikan semula.
  2. Jadikan penyedia pembayaran memulangkan 503 untuk 50% panggilan. Buktikan tiada caj berganda.
  3. Suntik mesej beracun ke dalam queue anda; buktikan ia mendarat dalam DLQ dan mencetuskan amaran.
  4. Matikan pangkalan data selama 30 s. Readiness gagal, liveness kekal hidup, servis pulih tanpa restart.

Definition of Done

Pek prompt AI

  • "Cari setiap panggilan rangkaian keluar dalam repo ini. Laporkan mana yang tiada timeout, mana yang retry operasi bukan idempotent, dan mana yang tiada fallback."
  • "Cipta client HTTP dikongsi dengan timeout, retry hanya pada ralat sementara dengan exponential backoff dan full jitter, serta circuit breaker bagi setiap host."