Gesaan dan skop
Titik akhir bootstrap mengatur tiga panggilan hiliran (downstream). Profil dan kebenaran diperlukan untuk cangkerang (shell) yang betul; suapan mungkin lapuk (stale) atau tiada. Titik akhir mesti mengembalikan respons bertaip yang membolehkan klien memaparkan bahagian yang selamat secara bebas. Bajet p95 sebanyak 300 ms merangkumi overhed orkestrasi, dan reka bentuk harus menyatakan data yang boleh dicache dan tempohnya.
Perkara yang diuji oleh penemu duga
- Menerbitkan keselarasan (parallelism), bajet tamat masa (timeout budgets), dan semantik kegagalan daripada keperluan yang kelihatan kepada pengguna.
- Membezakan antara data yang hilang, hasil kosong, dan ralat kebergantungan.
- Menggubah percubaan semula, pemutus litar (circuit breakers), sekat kedap (bulkheads), dan dasar cache tanpa menggandakan beban.
- Mereka bentuk kontrak respons yang boleh berkembang dan isyarat operasi yang berguna.
Soalan penjelasan untuk ditanya
Tanya sama ada kebenaran boleh menjadi lapuk, sama ada data suapan mempunyai had kesegaran, sama ada klien boleh memaparkan secara progresif, dan sama ada panggilan berkongsi konteks penyewa atau kebenaran. Jika kebenaran tidak pernah dibenarkan lapuk, data tersebut kekal pada laluan kritikal; jika suapan mempunyai sasaran kesegaran lima minit, cache stale-while-revalidate boleh melindungi kependaman.
Jawapan 30 saat
Saya akan menetapkan get laluan (gateway) untuk mengesahkan sekali, mengagihkan keluar (fan out) panggilan profil, kebenaran, dan suapan secara selari, serta memperuntukkan had masa (deadline) untuk pemasangan respons. Bahagian yang diperlukan gagal tutup (fail closed); bahagian pilihan mengembalikan status tidak tersedia yang eksplisit dengan kod sebab dan cap masa kesegaran. Percubaan semula dihadkan kepada panggilan fana (transient) yang idempoten dan menggunakan bajet kongsi. Tamat masa bagi setiap kebergantungan, bulkhead, pemutus litar, cache lapuk, dan sampul problem-details bertaip menghalang satu gangguan daripada mengosongkan cangkerang. Metrik menjejaki kejayaan peringkat bahagian, kehabisan had masa, hidangan lapuk, dan ketepuan kebergantungan.
Perbincangan terperinci langkah demi langkah
1. Tetapkan bajet masa dan keserentakan
Pada 2,000 permintaan sesaat, tiga panggilan berurutan membazirkan bajet 300 ms. Lakukan fan-out secara serentak, berikan setiap kebergantungan had masa di bawah had masa keseluruhan, dan kekalkan pemasangan serta penyirikan di dalam baki masa tersebut. Gunakan kolam sambungan terikat dan isyarat pembatalan bagi setiap permintaan supaya kebergantungan yang tamat masa berhenti menggunakan kerja pemprosesan.
2. Tentukan semantik respons separa
Kembalikan sampul stabil dengan status untuk setiap bahagian: ready, stale, atau unavailable. Sertakan sebab yang boleh dibaca mesin dan cap masa data, tetapi jangan membocorkan nama hos dalaman. Ralat profil atau kebenaran harus gagal tutup atau mengembalikan status log masuk/tindakan; tamat masa suapan boleh membiarkan cangkerang kekal boleh digunakan. Objek ralat yang mematuhi RFC 9457 boleh menerangkan kegagalan keseluruhan permintaan tanpa berpura-pura bahawa setiap bahagian telah gagal.
3. Lindungi kebergantungan daripada percubaan semula dan gangguan
Cuba semula ralat fana sahaja, hanya untuk bacaan idempoten, dan hanya sekali dalam had masa kongsi. Tambahkan jitter dan hentikan percubaan semula apabila litar terbuka. Bulkhead mengehadkan panggilan serentak bagi setiap kebergantungan; cache lapuk atau nilai lalai terikat mengendalikan data suapan pilihan. Pemutus litar berguna apabila kegagalan hiliran yang berulang boleh menggunakan semua kapasiti get laluan, tetapi ia tidak menggantikan tamat masa atau prob pemulihan.
4. Kembangkan dan perhatikan kontrak
Versikan medan secara aditif, biarkan klien mengabaikan bahagian yang tidak diketahui, dan sertakan pengecam korelasi permintaan. Catatkan kependaman kebergantungan, punca tamat masa, keadaan litar, usia cache, status bahagian, dan saiz muatan (payload). Surih pepohon fan-out, ambil sampel permintaan yang perlahan, dan tetapkan amaran pada kadar kegagalan bahagian yang diperlukan, usia lapuk, dan volum percubaan semula. Ujian kontrak mesti merangkumi hasil bercampur seperti kebenaran sedia, profil lapuk, dan suapan tidak tersedia.
Contoh jawapan yang kukuh
Saya akan menjelaskan kesegaran data dan sama ada paparan progresif dibenarkan. Get laluan mengesahkan sekali, mengagihkan keluar tiga bacaan, dan menetapkan had masa bagi setiap panggilan dalam bajet keseluruhan 300 ms. Ia mengembalikan status peringkat bahagian ready, stale, atau unavailable. Identiti dan kebenaran yang diperlukan gagal tutup; data suapan boleh diperoleh daripada cache lapuk terikat. Satu percubaan semula dengan jitter dibenarkan hanya untuk bacaan idempoten fana, dilindungi oleh bulkhead kebergantungan dan pemutus litar. Metrik dan surihan mendedahkan kegagalan bahagian serta tekanan had masa, manakala pemversian aditif memastikan klien lama terus berfungsi.
Kesilapan lazim
- Memanggil kebergantungan secara berurutan → kependaman terkumpul melebihi bajet → lakukan fan-out dengan kolam terikat dan had masa.
- Mengembalikan HTTP 200 dengan nilai null yang kabur → klien tidak dapat membezakan data kosong daripada kegagalan → gunakan status bahagian dan kod sebab yang eksplisit.
- Mencuba semula setiap ralat dalam setiap lapisan → satu gangguan menjadi ribut percubaan semula (retry storm) → kelaskan ralat dan laksanakan satu bajet percubaan semula kongsi.
- Mencache kebenaran tanpa dasar → akses boleh bertahan lebih lama daripada kebenarannya → tentukan had kesegaran atau laksanakan gagal tutup.
- Menggunakan satu litar global → gangguan suapan menyekat data identiti → asingkan pemutus litar dan bulkhead mengikut kebergantungan.
- Hanya mencatat jumlah kependaman → kegagalan pilihan dan yang diperlukan tidak dapat dibezakan → pancarkan metrik dan surihan peringkat bahagian.
Soalan susulan dan jawapan
Suapan perlahan tetapi pengguna memerlukan cangkerang dengan segera. Apakah yang berubah?
Pendekkan had masa suapan, hidangkan hasil lapuk yang terikat apabila usianya boleh diterima, dan kembalikan unavailable jika sebaliknya. Pastikan respons cangkerang kekal bebas supaya klien boleh memuatkan suapan kemudian.
Data kebenaran lapuk di satu rantau. Bolehkah anda menghidangkannya?
Hanya jika dasar kebenaran membenarkan kelapukan tersebut secara eksplisit dan respons menyampaikan usianya. Untuk tindakan sensitif, semak semula terhadap sumber berwibawa dan pilih gagal tutup jika terdapat ketidaktentuan.
Bagaimanakah anda menghalang percubaan semula daripada menjangkau melebihi 300 ms?
Sampaikan satu had masa mutlak melalui konteks fan-out. Sebelum setiap percubaan semula, peruntukkan masa untuk percubaan dan pemasangan; jika tiada masa berbaki, kembalikan status tamat masa bahagian dan bukannya memulakan kerja yang tidak dapat diselesaikan.
Satu kebergantungan pulih selepas litar terbuka. Bagaimanakah trafik dipulihkan?
Selepas tempoh bertenang, hantar sejumlah kecil prob separa terbuka (half-open). Tutup litar hanya selepas prob yang berjaya memenuhi kriteria tamat masa dan ralat yang sama; jika tidak, pastikan ia kekal terbuka dengan masa prob seterusnya yang boleh diperhatikan.