Gesaan dan konteks yang sesuai
Ini ialah soalan reka bentuk sistem. Terasnya bukan memilih pemversian URL atau pengepala; ia adalah mereka bentuk satah kawalan (control plane) kitaran hayat API. Perubahan kontrak harus disalurkan ke dalam analisis impak, penemuan pengguna sebenar, semakan tingkah laku lama/baharu, migrasi berperingkat dan penutupan berasaskan bukti. Microsoft mengesyorkan untuk mengekalkan keserasian ke belakang jika boleh, dan Google Cloud juga menasihatkan untuk mencuba evolusi serasi terlebih dahulu. Temu duga ini meminta anda menukar prinsip tersebut kepada sistem yang berfungsi merentas pasukan.
Perkara yang dinilai oleh penemu duga
- Sama ada anda membezakan keserasian format, perubahan semantik entiti dan perubahan pemecah (breaking changes) yang sebenar.
- Sama ada anda menghubungkan kontrak API, inventori pengguna, trafik masa jalanan (runtime) dan kerja migrasi.
- Sama ada anda mereka bentuk ujian keserasian, pelancaran berperingkat, amaran, notis dan pembalikan (rollback) dan bukannya sekadar label versi.
- Sama ada anda boleh menerangkan kos operasi bagi pelbagai versi, risiko penukaran data dan sempadan organisasi.
Penjelasan untuk ditanya terlebih dahulu
Sahkan sama ada API tersebut adalah dalaman, untuk rakan kongsi atau awam; sama ada pengguna boleh dikenal pasti sepenuhnya; serta sasaran trafik, kependaman dan ketersediaan. Jelaskan sama ada medan tersebut adalah pilihan, sama ada maknanya berubah, dan sama ada operasi baca, tulis atau data yang disimpan terlibat. Tanya tentang OpenAPI atau sumber kontrak lain, SDK klien, saluran notis, tempoh sokongan, keperluan pematuhan dan tempoh pembalikan. Jika skala tidak dinyatakan, nyatakan andaian anda.
Rangka jawapan 30 saat
Saya akan mereka bentuk lima peringkat: registri kontrak, penemuan impak, pengesahan keserasian, penyelarasan migrasi dan bukti penutupan. Setiap kontrak API dimasukkan ke dalam registri; enjin peraturan mengklasifikasikan perubahan, kemudian menggabungkan kebergantungan statik dan panggilan masa jalanan untuk mengenal pasti pengguna. Versi lama dan baharu berjalan secara selari sementara pengguna menerima notis berserta tarikh akhir dan panduan migrasi. Semasa pelancaran berperingkat, rekod kejayaan, ralat dan sisa trafik mengikut versi. Lakukan penutupan hanya selepas pengguna kritikal selesai bermigrasi, bukti migrasi lengkap, pembalikan telah dilatih dan pemilik meluluskan perubahan tersebut.
Jawapan mendalam langkah demi langkah
1. Bina registri kontrak dan peraturan perubahan
Registri menyimpan setiap API, versi, pemilik, semantik medan, skop pengesahan, status sokongan, tarikh susut guna dan dokumentasi migrasi. Permintaan perubahan merangkumi perbezaan kontrak (diff), dan enjin peraturan menandakan medan yang dialih keluar, enum yang dipersempit, perubahan status mandatori, semantik ralat yang diubah dan perubahan hubungan entiti. Menambah medan yang boleh diabaikan selalunya serasi, tetapi klien tidak boleh dianggap mengabaikan medan yang tidak diketahui dengan betul; pasukan memerlukan laluan pengecualian yang disokong bukti.
2. Temui pengguna dan bina graf impak
Gabungkan kebergantungan repositori, log get laluan, telemetri jaring perkhidmatan (service-mesh), pendaftaran SDK dan pengisytiharan ke dalam graf API-versi-pengguna. Penemuan statik boleh terlepas permintaan yang dibina secara dinamik, manakala penemuan masa jalanan boleh terlepas tugas berkala yang jarang berlaku, jadi tandakan sumber bukti, masa kali terakhir dilihat dan keyakinan. Bagi klien luaran, simpan hanya pengecam penyewa dan aplikasi yang diperlukan dan bukannya menganggap log sebagai data peribadi tanpa had.
3. Sahkan keserasian dengan pintu keselamatan
Bagi setiap perubahan, jalankan ujian kontrak, main semula pengguna dan perbandingan trafik sampel. Semak semantik respons pada operasi baca dan sahkan bahawa operasi tulis klien lama tidak kehilangan data atau menghasilkan kesan sampingan yang tidak diingini. Mulakan perubahan pemecah dalam trafik bayang (shadow traffic) atau kohort penyewa yang kecil; penghalaan versi dan bendera ciri (feature flags) mestilah boleh diterbalikkan. Kekalkan versi lama sekiranya berlaku kegagalan daripada menganggap set ujian yang lulus sebagai bukti untuk pengguna yang belum diuji.
4. Selaraskan notis, migrasi dan operasi pelbagai versi
Perkhidmatan notis menghantar panduan migrasi, tarikh akhir, contoh permintaan dan kenalan berdasarkan pengguna, keterukan dan kontrak sokongan; pelanggan luaran memerlukan halaman status atau konsol yang boleh ditanya. Kerja migrasi merekodkan pemilik, penghalang, bukti pengesahan dan panggilan terakhir yang berjaya. Pelbagai versi menambah kos ujian, penggunaan (deployment) dan pemantauan, jadi tetapkan had versi, peringkat susut guna dan laluan migrasi dan bukannya menyokong setiap versi selama-lamanya.
5. Putuskan penutupan, perhatikan dan pulihkan
Sebelum penutupan, sahkan bahawa pengguna kritikal telah menaik taraf, panggilan sisa berada di bawah ambang, tiada regresi ralat, penukaran data boleh diterbalikkan dan kesediaan sokongan dipenuhi. Gunakan kohort dan tetingkap masa: hentikan penerimaan baharu, kembalikan ralat susut guna yang jelas dan pautan migrasi kepada panggilan lama, kemudian nyahdayakan penghalaan. Jejaki kegagalan keserasian, trafik versi lama, penyelesaian migrasi, penghantaran notis, bilangan pembalikan dan ralat yang disegmenkan mengikut pengguna. Kubernetes menunjukkan cara tahap kestabilan, tempoh sokongan minimum, penukaran dan kekangan pembalikan boleh menjadi dasar yang jelas; konfigurasikan kekangan tersebut untuk organisasi dan bukannya menyalin tarikhnya secara bulat-bulat.
Contoh jawapan berkualiti tinggi
Saya akan menjelaskan jenis pengguna, sumber kontrak, semantik baca/tulis medan yang dialih keluar, kewajipan notis luaran dan tempoh pembalikan. Registri kontrak menyalurkan maklumat kepada enjin peraturan perubahan yang mengenal pasti perbezaan pemecah dan memautkannya kepada graf impak yang dibina daripada kebergantungan kod, log get laluan dan telemetri jaring perkhidmatan, bersama dengan kesegaran bukti. Ujian keserasian, main semula pengguna dan trafik berperingkat mengesahkan tingkah laku lama dan baharu; perkhidmatan notis menghantar panduan migrasi dan tarikh akhir kepada setiap pengguna. Versi beroperasi secara selari, dan kerja migrasi menyimpan bukti pengesahan. Hanya selepas pengguna kritikal bermigrasi, sisa trafik dan ralat memenuhi ambang, pembalikan dilatih dan pemilik meluluskannya, barulah kami menamatkan laluan lama. Log audit merangkumi perubahan, notis, pemerhatian dan pembalikan supaya klien yang tidak diketahui tidak diputuskan secara tiba-tiba.
Kesilapan lazim
- Membahaskan label URL, pengepala atau pemversian semantik tanpa penemuan pengguna dan bukti penutupan.
- Hanya bergantung pada carian kod statik atau satu log akses sambil terlepas panggilan dinamik dan jarang berlaku.
- Menganggap bahawa mengalih keluar medan pilihan adalah selamat secara automatik tanpa menguji penghuraian klien sebenar.
- Melancarkan versi baharu dan menutup versi lama serta-merta tanpa pelancaran berperingkat atau keupayaan pembalikan.
- Menyokong setiap versi selama-lamanya tanpa mengambil kira kos ujian, pemantauan dan penukaran.
- Menghantar satu e-mel tanpa tarikh akhir, pemilik, laluan eskalasi atau metrik yang disegmenkan.
Soalan susulan dan jawapan
Bagaimanakah anda memutuskan untuk menutup apabila klien luaran tidak dapat ditemui?
Anggap penggunaan yang tidak diketahui sebagai keadaan berisiko, lanjutkan tempoh pemerhatian, tingkatkan telemetri dan hubungi pemilik kontrak atau tawarkan diagnostik migrasi. Log sifar tidak membuktikan penggunaan sifar; gunakan dasar penolakan yang boleh dipulihkan dan sandaran kecemasan sebelum penutupan.
Adakah menambah medan respons sentiasa serasi?
Tidak. Peraturan mungkin mengklasifikasikannya sebagai biasanya serasi, tetapi main semula pengguna sebenar, matriks SDK dan sampel ralat masih perlu mengesahkannya. Pengesah skema yang ketat mungkin memerlukan migrasi berasingan atau sempadan versi baharu.
Bagaimanakah anda memigrasikan data yang ditulis oleh klien lama dengan selamat?
Tentukan pemetaan semantik dan syarat tanpa kehilangan data terlebih dahulu, kemudian gunakan bacaan dwi, penulisan dwi atau penukaran luar talian dengan rekod versi. Penukaran mestilah boleh disahkan dan boleh diterbalikkan; jangan ubah makna perniagaan secara senyap semasa masa bacaan.
Bagaimana jika pelanggan tidak dapat menaik taraf sebelum tarikh akhir?
Tawarkan tempoh keserasian terhad, penyesuai (adapter) atau migrasi berbantu mengikut kontrak dan risiko, dengan merekodkan kos, pemilik dan tarikh keluar yang baharu. Pengecualian harus bertujuan mengurangkan trafik yang tidak diketahui dan bukannya menjadikan versi lama kekal.
Bagaimanakah anda mengelakkan satah kawalan daripada menjadi titik kegagalan tunggal (SPOF)?
Penghalaan satah data (data-plane) tidak sepatutnya memerlukan penulisan langsung ke satah kawalan secara masa nyata. Simpan dasar versi yang diluluskan dalam cache dan kekalkan konfigurasi selamat yang terakhir semasa kegagalan satah kawalan berlaku. Perkhidmatan registri, notis dan metrik boleh pulih secara tidak segerak (asynchronous), manakala penutupan memerlukan kelulusan dwi dan pembalikan yang jelas.