Modul 09Penggal 3 · Kebolehpercayaan dan skala16 item poster

Prestasi dan Penskalaan

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

Mengapa ini penting

Dua kesilapan yang bertentangan membunuh produk: melancarkan sesuatu yang tumbang pada 100 pengguna, dan membina berlebihan untuk sejuta pengguna yang anda belum ada. Modul ini mengajar anda untuk mengukur dahulu, kemudian gunakan pembaikan yang paling murah, mengikut tertib yang diketahui.

Hasil pembelajaran

  1. Cari bottleneck dengan load test dan profiling, bukan dengan meneka.
  2. Gunakan tangga penskalaan mengikut tertib yang betul.
  3. Cache dengan betul, termasuk invalidation.
  4. Fahami load balancer, reverse proxy dan API gateway.
  5. Ketahui had serverless dan cold start.
  6. Kawal kos cloud dan AI sebagai metrik utama.

Tangga penskalaan (naik hanya selepas diukur)

  1. Baiki kod: indeks, N+1, pagination, saiz payload (03 · Asas Data).
  2. Cache: CDN untuk kandungan statik, edge cache untuk kandungan dinamik awam, app cache untuk pengiraan yang mahal.
  3. Pindahkan kerja ke async (08 · Async, Event dan Masa Nyata).
  4. Penskalaan menegak (47): pangkalan data/server yang lebih besar. Murah dari segi masa kejuruteraan; pergi lebih jauh daripada yang orang sangka.
  5. Penskalaan mendatar lapisan aplikasi stateless (46) di belakang load balancer, dengan autoscaling (45).
  6. Read replica (29) untuk beban yang banyak membaca (terima replication lag).
  7. Partition (31) jadual besar (cth. mengikut bulan untuk event/log).
  8. Shard (30) hanya apabila satu pangkalan data primary benar-benar tidak mampu menampung. Kebanyakan syarikat tidak pernah memerlukannya.

Pelajaran

9.1 Caching (2, 48, 49, 50)

  • Lapisan: pelayar (Cache-Control), CDN untuk aset statik (48), edge caching untuk respons dinamik (49), cache aplikasi (Redis), cache query DB.
  • Corak: cache-aside (baca melalui aplikasi), write-through, stale-while-revalidate.
  • Invalidation (50): TTL (ringkas, akhirnya segar), purge eksplisit semasa tulis (purge berasaskan tag), kunci berversi (user:42:v7).
  • Jangan sekali-kali cache data peribadi per pengguna dalam cache dikongsi di bawah kunci yang dikongsi (kebocoran data). Sertakan pengguna/tenant dalam kunci atau tandakan Cache-Control: private.
  • Elakkan stampede: request coalescing, TTL dengan jitter, refresh awal.
  • Khusus LLM: gunakan prompt caching penyedia untuk prefix statik yang panjang; cache hasil yang deterministik (embedding, klasifikasi).

9.2 Komponen pintu depan (3, 4, 5)

  • Reverse proxy (4): menamatkan TLS, memampatkan, menimbal client yang perlahan, menghala trafik (Nginx, Caddy, Cloudflare, edge platform).
  • Load balancer (3): menyebarkan trafik merentas instance menggunakan health check; L4 (TCP) atau L7 (HTTP). Sticky session ialah tanda amaran; pastikan server aplikasi stateless.
  • API gateway (5): auth, kuota, rate limit, penghalaan, kunci API untuk banyak servis. Berguna apabila anda sudah ada beberapa servis atau menjual akses API.

9.3 Realiti serverless (89, 90)

  • Had: masa pelaksanaan maksimum, memori, saiz payload, pelaksanaan serentak, dan tekanan sambungan DB. Ketahui angka platform anda.
  • Cold start: request pertama selepas melahu adalah perlahan. Kurangkan dengan bundle lebih kecil, runtime lebih ringan (edge), instance provisioned/minimum untuk laluan yang kritikal dari segi latency.
  • Kerja ejen yang berjalan lama tidak sepatutnya berada dalam function yang terikat kepada request; gunakan job tahan lasak.

9.4 Pengoptimuman kos (88)

  • Layan kos per pengguna aktif dan kos per tugas AI sebagai metrik produk pada dashboard.
  • Kemenangan terbesar: instance bersaiz tepat, matikan sumber yang melahu, cache hasil LLM, halakan tugas mudah ke model yang lebih kecil/murah, batching, peraturan kitar hayat storage, kesedaran tentang kos egress.
  • Had perbelanjaan keras dan amaran anomali pada setiap penyedia. Tag sumber mengikut produk/venture untuk atribusi.

9.5 Kaedah load testing

Tentukan senario (perjalanan pengguna yang realistik, think time, volum data) → tingkatkan beban (smoke, load, stress, soak) → perhatikan p95/p99, kadar ralat, saturation (CPU, memori, sambungan DB, kedalaman queue) → cari perkara pertama yang pecah → baiki → ulang.

Makmal 9: Cari tebing

  1. Tulis senario k6 untuk perjalanan utama anda; tingkatkan beban sehingga kadar ralat melebihi 1% atau p95 melanggar bajet. Rekodkan "tebing" itu.
  2. Profil dan baiki bottleneck teratas. Ulang dua kali. Carta peningkatan kapasiti bagi setiap pembaikan.
  3. Tambah CDN + edge caching untuk satu halaman dinamik awam dengan invalidation yang betul semasa kemas kini.
  4. Bina dashboard kos: kos infra + AI bulanan per pengguna aktif.

Definition of Done

Pek prompt AI

  • "Berdasarkan output k6 ini dan statistik DB ini, susun bottleneck yang mungkin mengikut kedudukan dan cadangkan pembaikan paling murah untuk setiap satu."
  • "Tambah caching pada endpoint ini. Sertakan reka bentuk kunci cache (dengan tenant), TTL, invalidation semasa tulis, dan perlindungan stampede."