Gesaan dan skop
Platform perkhidmatan mikro berbilang bahasa menggunakan API OpenTracing, shim vendor dan SDK OpenTelemetry. Sejak Mac 2026, spesifikasi OpenTelemetry tidak lagi memerlukan pelaksanaan baharu untuk menyediakan keserasian OpenTracing, manakala shim sedia ada masih diperlukan semasa peralihan. Reka bentuk migrasi yang mengekalkan surihan (traces), mengawal kos dan membolehkan perkhidmatan tunggal diundur balik (rollback).
Perkara yang diuji oleh penemu bual
Penemu bual sedang menguji sama ada anda memisahkan keserasian API, semantik data dan protokol bahagian belakang (backend); mengendalikan pemetaan atribut surihan dan span, penyebaran konteks (context propagation), ketekalan persampelan, kos dwi-tulis dan pergantungan vendor (vendor lock-in). Jawapan yang kukuh memberikan susunan migrasi, metrik penerimaan dan pengasingan kegagalan berbanding hanya menggantikan kebergantungan.
Soalan untuk dijelaskan terlebih dahulu
- Bahasa dan rangka kerja manakah yang menggunakan OpenTracing, dan adakah shim telah mengubah semantiknya?
- Adakah bahagian belakang menerima OTLP, dan adakah data sejarah serta dimensi pertanyaan mesti kekal stabil?
- Adakah keutamaan sifar kehilangan, overhed rendah, semantik bersatu atau kebolehtukaran vendor?
- Adakah dwi-tulis sementara dibenarkan, dan apakah had persampelan serta kos bagi setiap perkhidmatan?
Jawapan 30 saat
"Saya akan membahagikan migrasi kepada lapisan API, semantik, pengangkutan dan operasi. Mula-mula, bekukan kebergantungan OpenTracing baharu dan inventori shim, format penyebaran serta atribut utama. Dalam satu perkhidmatan, tambahkan OpenTelemetry natif sambil mengekalkan shim sebagai titik masuk keserasian, kemudian bandingkan kedua-duanya dengan satu konteks dan keputusan persampelan. Selepas kesinambungan surihan, kadar ralat, liputan atribut, kependaman dan kos memenuhi kriteria pelepasan (gates), kembangkan mengikut bahasa dan topologi kebergantungan. Sebarang kegagalan hanya mengundur balik laluan masuk atau eksport perkhidmatan tersebut, bukan keseluruhan platform Collector yang dikongsi."
Penyelesaian langkah demi langkah
1. Inventori panggilan dan semantik
Cipta inventori perkhidmatan, bahasa, pakej OpenTracing, versi shim, format penyebaran dan laluan eksport. Tandakan tag tersuai, log, baggage dan nama span, kemudian petakan setiap satu kepada atribut, peristiwa, pautan (links) dan baggage OpenTelemetry. Mulakan dengan perkhidmatan tanpa keadaan (stateless) yang mempunyai sempadan yang jelas, bukan tracer yang paling banyak diubah suai.
2. Tentukan sempadan keserasian
Pindahkan kod aplikasi ke arah tracer OpenTelemetry natif. Kekalkan shim untuk perpustakaan yang belum boleh diubah, tetapi bekukan ciri shim baharu. Penyebaran konteks mesti kekal konsisten pada sempadan kemasukan (ingress), baris gilir tak segerak (asynchronous queues), RPC dan kelompok (batch); nama API yang serupa tidak membuktikan persampelan atau hubungan induk (parent) yang setara.
3. Laksanakan dwi-tulis terkawal
Utamakan penghalaan terkawal pada sempadan eksport SDK atau Collector dan bukannya menjana dua set span dalam kod perniagaan. Jika dwi-tulis diperlukan, tetapkan had persampelan setiap perkhidmatan, had baris gilir, percubaan semula dan metrik gugur, membezakan antara "span perniagaan tidak dicipta" dengan "eksport gagal." Tetapkan syarat keluar yang jelas untuk tempoh dwi-tulis.
4. Pastikan bahagian belakang boleh disoal
Bekukan nama untuk perkhidmatan, operasi, status dan atribut perniagaan kritikal semasa migrasi. Hantar set permintaan yang sama melalui laluan lama dan baharu, kemudian bandingkan kiraan surihan, hubungan induk-anak, status ralat, persentil kependaman dan eksemplar (exemplars). Jika semantik pertanyaan bahagian belakang berubah, sediakan penyesuai (adapter) atau dua versi papan pemuka sebelum menukar paparan lalai.
5. Peluncuran kanari dengan kawalan kos
Lakukan migrasi secara kelompok mengikut bahasa, pasukan atau pohon kebergantungan. Jejak kesinambungan surihan hujung-ke-hujung, kehilangan span, baris gilir Collector, CPU dan memori, egress dan kos bagi setiap sejuta span. Apabila ambang gagal, hentikan kemasukan perkhidmatan baharu sambil mengekalkan perkhidmatan yang telah dimigrasikan dan bukti mentah.
6. Undur balik dengan kawalan kitaran hayat
Kekalkan suis pemula tracer, versi kebergantungan dan snapshot konfigurasi untuk setiap perkhidmatan. Lakukan undur balik dengan menukar laluan masuk atau eksport perkhidmatan tersebut, bukannya memadamkan sumber Collector yang dikongsi. Sebelum mengalih keluar shim, sahkan bahawa tiada perpustakaan hiliran yang masih memperoleh konteks melalui tracer global, dan kekalkan pemantauan keserasian untuk tempoh yang ditetapkan.
Jawapan model
Saya akan membekukan kerja keserasian OpenTracing baharu dan menginventori panggilan, semantik, penyebaran dan eksport. API OpenTelemetry natif dilaksanakan mengikut perkhidmatan; perpustakaan yang tidak boleh diubah diteruskan melalui shim, dengan Context, persampelan dan pemetaan atribut ditetapkan melalui ujian kontrak. Dwi-tulis dihadkan pada sempadan SDK atau eksport, dengan metrik untuk kesinambungan, liputan atribut, baris gilir Collector, kependaman dan kos. Peluncuran kanari dilakukan mengikut bahasa dan topologi kebergantungan. Sekiranya berlaku kegagalan, nyahdayakan laluan baharu satu perkhidmatan dan pulihkan eksport lamanya sambil mengekalkan konfigurasi, peristiwa dan data perbandingan; alih keluar shim hanya selepas semua perkhidmatan stabil.
Kesilapan biasa
- Hanya menggantikan import → semantik induk, baggage atau atribut berubah → uji penyebaran dan kontrak semantik.
- Melakukan dwi-tulis dalam setiap panggilan perniagaan → volum span dan kos melonjak → pusatkan dan hadkan penghalaan pada sempadan SDK atau eksport.
- Hanya memantau kejayaan Collector → aplikasi telah kehilangan span sebelum sampai ke sana → asingkan metrik penciptaan, baris gilir, eksport dan bahagian belakang.
- Memindahkan semua perkhidmatan sekali gus → radius impak kerosakan (blast radius) terlalu besar → lakukan kanari mengikut bahasa dan topologi kebergantungan.
- Memadamkan shim dengan serta-merta → perpustakaan yang tidak diubah suai gagal dimulakan → bekukan kebergantungan baharu dan sahkan rujukan telah tiada.
Soalan susulan dan respons
Mengapa tidak mewajibkan setiap pasukan bertukar serentak?
Perpustakaan yang dikongsi, jadual pelepasan dan SDK bahasa berbeza-beza, jadi peralihan serentak mewujudkan radius impak kerosakan yang besar. Keserasian berlapis memastikan perkhidmatan terus berjalan sementara API natif menjadi tumpuan kerja baharu.
Bagaimanakah anda membuktikan bahawa surihan tidak hilang?
Suntik pengecam stabil ke dalam permintaan yang boleh diulang, bandingkan kemasukan, penyebaran antara perkhidmatan, penerimaan Collector dan kiraan pertanyaan bahagian belakang, kemudian periksa sampel bagi pautan induk, status dan atribut utama.
Bolehkah dwi-tulis mengubah persampelan?
Ya. Melakukan persampelan secara bebas pada dua tracer boleh memutuskan surihan atau menggandakan kos. Buat keputusan persampelan dalam konteks yang dikongsi dan pastikan kedua-dua laluan mewarisi keputusan tersebut.
Bilakah lapisan keserasian boleh dialih keluar?
Selepas imbasan kebergantungan tidak menemui titik masuk OpenTracing, ujian kontrak merangkumi penyebaran dan semantik, metrik kanari memenuhi kriteria pelepasan dan tiada undur balik berlaku semasa tempoh pengekalan. Kemudian alih keluar shim dan simpan rekod audit.