Microservices Engine：FAQ tentang mulai dan shutdown yang mulus

Kemana fitur lanjutan pergi, apa dampaknya pada aplikasi terintegrasi, dan bagaimana saya masih bisa mengaktifkan atau menonaktifkannya?

Pengaturan lanjutan untuk solusi mulai dan shutdown yang mulus tersedia dalam versi lama Tata Kelola Mikro Layanan di Konsol MSE. Namun, pengaturan tersebut melibatkan banyak konsep mikro layanan dan disembunyikan dalam versi baru demi kemudahan penggunaan. Dalam versi lama, pengaturan lanjutan mencakup fitur-fitur berikut:

• Penyelesaian pendaftaran layanan sebelum probe kesiapan

  Fitur ini masih tersedia dan diaktifkan secara default di versi baru. Jika fitur ini sebelumnya tidak diaktifkan untuk aplikasi Anda, fitur ini akan diaktifkan otomatis setelah Anda mengaktifkan kembali fitur mulai yang mulus di halaman Mulai dan Shutdown yang Mulus di Konsol. Jika fitur ini sudah aktif, kami sarankan agar Anda tidak menonaktifkannya. Ketika diaktifkan secara default, fitur ini tidak memiliki dampak negatif pada aplikasi dan dapat mencegah risiko trafik turun menjadi nol dalam skenario tertentu selama rilis. Untuk informasi lebih lanjut, lihat Mengapa mengonfigurasi 55199/readiness.

• Penyelesaian pra-pemuatan layanan sebelum probe kesiapan

  Fitur ini tidak lagi tersedia di versi baru. Fitur ini awalnya dirancang untuk memastikan bahwa efek pra-ambil sesuai harapan dan mencegah peningkatan mendadak pada kurva permintaan per detik (QPS) untuk layanan yang telah dipra-ambil. Prinsip implementasinya adalah menunda waktu untuk melewati pemeriksaan yang dilakukan oleh Pemeriksaan Kesiapan Kubernetes. Ini memperpanjang durasi rilis keseluruhan namun memastikan bahwa sistem memberikan waktu cukup bagi node baru untuk pra-ambil dan memungkinkan node lama memproses jumlah trafik tertentu selama pra-ambil layanan. Hal ini memastikan nilai QPS layanan yang dipra-ambil meningkat secara bertahap seiring waktu. Dalam proses rilis, jika semua node lama dinonaktifkan selama pra-ambil node baru, node baru harus memproses semua trafik online. Akibatnya, pra-ambil layanan dengan trafik rendah tidak dapat dilakukan. Aplikasi yang memiliki fitur ini diaktifkan tidak terpengaruh. Namun, Anda tidak dapat lagi mengaktifkan fitur ini untuk aplikasi baru saat mengonfigurasi aturan. Jika Anda sebelumnya telah mengaktifkan fitur ini, kami tidak merekomendasikan agar Anda menonaktifkannya. Fitur ini tidak memiliki dampak negatif ketika diaktifkan. Untuk informasi tentang cara mencapai efek yang diinginkan untuk pra-ambil trafik rendah di versi baru, lihat Praktik Terbaik untuk Pra-Ambil Trafik Rendah.

Bagaimana cara kerja fitur pra-pemuatan layanan dengan trafik rendah?

Saat konsumen memanggil layanan, konsumen memilih penyedia layanan. Jika pra-pemuatan layanan dengan trafik rendah diaktifkan untuk penyedia, Tata Kelola Mikroservis mengoptimalkan proses pemilihan penyedia. Saat konsumen memilih penyedia, bobot setiap penyedia dihitung sebagai nilai persentase (0% hingga 100%). Konsumen memprioritaskan memilih dan memanggil penyedia yang memiliki bobot tinggi. Jika pra-pemuatan layanan dengan trafik rendah diaktifkan untuk penyedia, saat penyedia mulai, bobot penyedia yang dihitung oleh konsumen rendah, dan konsumen memanggil node pra-pemuatan dengan probabilitas rendah. Bobot yang dihitung meningkat secara bertahap seiring waktu dan akhirnya mencapai 100%. Saat bobot yang dihitung mencapai 100%, pra-pemuatan selesai, dan node pra-pemuatan dapat menerima trafik seperti node normal. Penyedia menyertakan waktu mulainya dalam metadata informasi pendaftaran layanan. Konsumen menghitung bobot penyedia berdasarkan waktu mulai. Proses ini memerlukan Tata Kelola Mikroservis diaktifkan untuk konsumen dan penyedia.

Mengapa tren data pra-pemuatan dalam kurva grafik garis tidak sesuai harapan? Bagaimana cara menyelesaikan masalah ini?

Grafik garis berikut menunjukkan contoh kurva QPS untuk pra-pemuatan layanan dengan trafik rendah dalam kasus normal.

Namun, dalam beberapa kasus, nilai QPS dalam kurva tidak meningkat secara bertahap seiring waktu untuk aplikasi yang menjalani pra-pemuatan layanan dengan trafik rendah. Berikut ini adalah dua situasi umum yang mungkin Anda temui.

• Nilai QPS melonjak pada titik waktu tertentu

  

  Dalam kebanyakan kasus, situasi ini terjadi selama rilis layanan. Jika node lama dihapus dari jaringan sebelum node baru sepenuhnya dipra-ambil, node baru sering dipanggil ketika konsumen memilih penyedia. Akibatnya, grafik garis QPS menunjukkan bahwa QPS dari node baru meningkat perlahan dan kemudian melonjak pada titik waktu tertentu setelah semua node lama dihapus dari jaringan. Anda dapat merujuk ke Praktik Terbaik untuk Pra-Ambil Trafik Rendah untuk menyelesaikan masalah ini.

• Nilai QPS tidak meningkat secara bertahap

  

  Jika situasi ini terjadi, kami sarankan Anda memeriksa apakah Tata Kelola Mikroservis diaktifkan untuk konsumen. Jika Tata Kelola Mikroservis tidak diaktifkan untuk konsumen, Anda dapat mengaktifkannya untuk menyelesaikan masalah ini. Jika trafik aplikasi yang perlu Anda pra-pemuat berasal dari layanan eksternal, seperti gateway Java, Tata Kelola Mikroservis tidak diaktifkan untuk konsumen, dan pra-pemuatan layanan dengan trafik rendah tidak didukung dalam skenario ini.

Apa praktik terbaik untuk pra-pemuatan layanan dengan trafik rendah?

Pra-pemuatan yang tidak lengkap sering terjadi selama penyebaran bergulir. Anda dapat merujuk pada praktik berikut untuk memastikan bahwa pra-pemuatan layanan sesuai harapan.

• Konfigurasikan waktu siap minimum (Direkomendasikan): Anda dapat mengonfigurasi .spec.minReadySeconds untuk beban kerja Anda untuk mengontrol interval waktu antara pod menjadi siap dan menjadi tersedia. Atur nilai parameter ini menjadi lebih besar dari durasi pra-ambil trafik rendah pod untuk memastikan bahwa K8s menunggu pod menyelesaikan pra-ambil sebelum melanjutkan penyebaran bergulir. Jika Anda menggunakan ACK, Anda dapat menemukan aplikasi Anda di Platform Kontainer dan mengonfigurasi pengaturan ini langsung di bawah Lainnya > Kebijakan Upgrade > Upgrade Bergulir > Waktu Siap Minimum (minReadySeconds). (Pengaturan ini memastikan bahwa penyebaran dilanjutkan hanya setelah pod yang baru dimulai siap dan telah mempertahankan status ini selama periode tertentu.)

• (Direkomendasikan) Gunakan metode penyebaran batch: Anda dapat menggunakan metode atau alat seperti OpenKruise untuk menerapkan beban kerja dalam batch. Interval penyebaran antar batch harus lebih lama dari durasi pra-pemuatan layanan dengan trafik rendah. Setelah node baru dalam batch sepenuhnya dipra-pemuat, Anda dapat melanjutkan untuk merilis batch node berikutnya.

Anda juga dapat meningkatkan nilai initialDelaySeconds untuk menyelesaikan masalah. Namun, kami sarankan agar Anda tidak menggunakan metode ini. Parameter initialDelaySeconds menentukan waktu tunggu sebelum pemeriksaan kesiapan pertama beban kerja. Anda harus memastikan bahwa nilai parameter ini lebih besar dari jumlah durasi pra-ambil layanan dengan trafik rendah, durasi pendaftaran tertunda, dan waktu startup aplikasi. Perhatikan bahwa Anda dapat memperoleh waktu startup aplikasi dari output log aktual. Waktu startup aplikasi bervariasi seiring dengan perkembangan bisnis. Jika Anda menunda waktu untuk melewati pemeriksaan kesiapan, endpoint node yang baru dimulai mungkin gagal ditambahkan ke endpoint layanan Kubernetes. Oleh karena itu, jika Anda ingin memastikan efek pra-ambil yang optimal, kami sarankan agar Anda tidak menggunakan metode ini.

Apa itu 55199/readiness? Jika saya tidak mengonfigurasi 55199/readiness, trafik mungkin turun menjadi nol. Mengapa?

55199/readiness adalah port probe kesiapan bawaan tipe HTTP yang disediakan oleh Tata Kelola Mikro Layanan MSE. Ketika probe kesiapan Kubernetes aplikasi dikonfigurasi ke 55199/readiness, probe kesiapan mengembalikan kode status 500 jika node baru belum menyelesaikan pendaftaran layanan selama startup, dan kode status 200 jika node telah menyelesaikan pendaftaran layanan.

Berdasarkan kebijakan penyebaran Kubernetes default, node lama tidak dihapus dari jaringan sampai node baru siap. Ketika probe kesiapan dikonfigurasi dengan 55199/readiness, node baru menjadi siap hanya setelah menyelesaikan pendaftaran layanan. Ini berarti node lama dihapus dari jaringan hanya setelah node baru telah menyelesaikan pendaftaran layanan. Ini memastikan bahwa layanan yang terdaftar dengan registri selalu memiliki node yang tersedia. Jika Anda tidak mengonfigurasi 55199/readiness, node lama mungkin dihapus dari jaringan selama rilis layanan sebelum node baru terdaftar. Akibatnya, layanan tersebut tidak memiliki node yang tersedia di registri. Hal ini menyebabkan semua konsumen layanan menerima kesalahan saat melakukan panggilan, dan trafik layanan turun menjadi nol. Oleh karena itu, kami sangat menyarankan agar Anda mengaktifkan mulai yang mulus dan mengonfigurasi 55199/readiness probe kesiapan untuk aplikasi Anda.

Jika versi probe aplikasi Anda lebih lama dari 4.1.10, Anda harus mengonfigurasi jalur pemeriksaan kesiapan sebagai /health bukan /readiness. Untuk melihat versi probe, navigasikan ke Konsol MSE > Pusat Administrasi > Tata Kelola Aplikasi, klik aplikasi yang sesuai, dan pilih Detail Node. Versi probe ditampilkan di sebelah kanan.

Mengapa acara pra-pemuatan aplikasi saya dilaporkan sebelum acara pendaftaran layanan? Apa yang harus saya lakukan jika masalah ini terjadi?

Dalam versi saat ini, ketika layanan menerima permintaan eksternal pertama, layanan memulai proses pra-ambil dan melaporkan acara mulai pra-ambil. Namun, dalam beberapa kasus, permintaan pertama yang diterima oleh aplikasi mungkin bukan permintaan panggilan mikro layanan. Permintaan seperti itu tidak mengikuti logika bisnis untuk memicu pra-ambil. Misalnya, Anda mengonfigurasi Pemeriksaan Kelangsungan Hidup Kubernetes untuk beban kerja aplikasi. Dalam kasus ini, ketika node baru dimulai, bahkan jika operasi pendaftaran layanan tidak dilakukan pada node, sistem menganggap bahwa pra-ambil telah dimulai ketika Kubernetes melakukan pemeriksaan menggunakan Pemeriksaan Kelangsungan Hidup.

Untuk mencegah masalah ini, Anda dapat mengonfigurasi parameter berikut dalam variabel lingkungan penyedia. Dengan cara ini, sistem tidak lagi memicu logika pra-pemuatan untuk permintaan ini.

# Abaikan permintaan untuk jalur /xxx atau /yyy/zz untuk mencegah mereka memicu proses pra-ambil.
profile_micro_service_record_warmup_ignored_path="/xxx,/yyy/zz"

Apa itu notifikasi proaktif? Kapan saya perlu mengaktifkan notifikasi proaktif?

Notifikasi proaktif adalah kemampuan lanjutan yang disediakan oleh modul shutdown yang mulus. Kemampuan ini memungkinkan penyedia Spring Cloud dalam keadaan offline untuk secara proaktif memulai permintaan jaringan guna memberi tahu konsumen tentang keadaan offline. Setelah konsumen menerima notifikasi, konsumen tidak lagi memanggil node penyedia. Dalam kasus normal, jika baik penyedia maupun konsumen menggunakan framework Spring Cloud, konsumen menyimpan daftar node penyedia di mesin lokal. Dalam skenario tertentu, meskipun konsumen menerima notifikasi dari registri, cache lokal mungkin tidak diperbarui pada kesempatan pertama. Akibatnya, konsumen masih memulai panggilan ke node offline. Fitur notifikasi proaktif diperkenalkan untuk menyelesaikan masalah ini.

Secara default, fitur notifikasi proaktif dinonaktifkan. Berdasarkan solusi shutdown yang mulus default, setelah Tata Kelola Mikro Layanan diaktifkan, jika penyedia yang akan offline menerima permintaan, penyedia menambahkan header khusus ke respons, dan mengembalikan respons ke konsumen. Setelah konsumen menerima respons, konsumen mengidentifikasi header dan tidak lagi memanggil node penyedia. Oleh karena itu, jika konsumen mengirimkan permintaan ke penyedia yang akan offline, konsumen dapat mendeteksi bahwa penyedia akan segera offline dan secara otomatis menghapus node penyedia dari daftar node penyedia. Namun, jika konsumen tidak mengirimkan permintaan ke penyedia dalam periode tenggang (sekitar 30 detik) sebelum penyedia menjadi offline, konsumen mungkin tidak mendeteksi bahwa node penyedia dalam keadaan offline dan mungkin mengirimkan permintaan ketika penyedia akan segera offline. Akibatnya, kesalahan permintaan dilaporkan. Dalam kasus ini, Anda dapat mengaktifkan fitur notifikasi proaktif. Kami sarankan Anda mengaktifkan fitur notifikasi proaktif untuk penyedia jika konsumen mengirimkan sedikit permintaan pada interval panjang ke penyedia.

Setelah acara matikan dengan lancar dilaporkan, trafik tidak langsung turun menjadi nol. Mengapa?

Dalam kebanyakan kasus, trafik langsung turun menjadi nol setelah acara matikan dengan lancar dilaporkan. Berikut ini adalah kemungkinan penyebab dan solusi untuk masalah ini.

• Aplikasi menerima permintaan dari objek non-mikro layanan seperti load balancer eksternal. Penyebab lain yang mungkin adalah bahwa aplikasi menerima permintaan yang diinisiasi menggunakan metode panggilan seperti skrip lokal dan tugas terjadwal.

  Solusi mulai dan matikan dengan lancar hanya mendukung permintaan dari aplikasi mikroservis untuk mana Tata Kelola Mikroservis diaktifkan. Solusi ini tidak didukung dalam skenario sebelumnya. Kami sarankan Anda mengonfigurasi solusi kustom berdasarkan fitur matikan dengan lancar yang disediakan oleh infrastruktur dan framework.

• Fitur notifikasi proaktif tidak diaktifkan untuk aplikasi. (Untuk informasi lebih lanjut, lihat Apa itu notifikasi proaktif?)

  Kami sarankan Anda memeriksa apakah kurva dalam grafik garis sesuai harapan setelah Anda mengaktifkan fitur notifikasi proaktif.

• Versi framework yang digunakan oleh aplikasi tidak didukung oleh solusi mulai dan shutdown yang mulus. Untuk informasi lebih lanjut tentang framework yang didukung oleh solusi mulai dan shutdown yang mulus dari Tata Kelola Mikro Layanan, lihat Framework Java yang didukung oleh Tata Kelola Mikro Layanan.

  Jika versi framework aplikasi Anda tidak didukung, Anda dapat meningkatkan versi framework aplikasi Anda.

Waktu rilis versi menjadi lebih lama setelah solusi mulai dan matikan dengan lancar diaktifkan untuk aplikasi. Apa yang harus saya lakukan?

Lakukan langkah-langkah berikut untuk memeriksa apakah pra-ambil layanan sebelum probe kesiapan diaktifkan:

1. Masuk ke Konsol Pusat Administrasi MSE, dan di bilah menu atas, pilih wilayah.

2. Di panel navigasi di sebelah kiri, pilih Administration Center > Application Administration.

3. Di halaman Application List, klik aplikasi target, dan pilih Traffic Governance > Graceful Online/Offline.

4. Di tab Online/Offline yang Mulus, tekan F12 untuk membuka alat pengembang. Di tab Network, cari permintaan GetLosslessRuleByApp. (Jika Anda tidak dapat menemukan permintaan, segarkan halaman.) Di Response, periksa apakah nilai bidang Related di Data adalah true. Jika nilainya true, itu menunjukkan bahwa fitur Selesaikan pra-ambil layanan sebelum melewati probe kesiapan diaktifkan untuk aplikasi tersebut sejak lama. (Fitur ini tidak lagi tersedia.) Ketika fitur ini diaktifkan, itu dapat meningkatkan waktu rilis. Kami sarankan Anda mengajukan tiket untuk menonaktifkan fitur ini.

   

Apa itu 55199/readiness yang disediakan oleh Tata Kelola Mikroservis MSE? Mengapa kegagalan probe kesiapan MSE persisten dalam beberapa skenario?

Kubernetes menyediakan jenis-jenis probe berikut:

• Probe startup: Mendeteksi apakah aplikasi berhasil dimulai selama proses startup pod. Jika probe gagal beberapa kali selama proses startup pod dan ambang batas kegagalan yang dikonfigurasikan tercapai, pod akan di-restart.

• Probe kelangsungan hidup: Mendeteksi apakah aplikasi hidup. Sistem memulai probe kelangsungan hidup setelah probe startup berhasil. Probe kelangsungan hidup dilakukan sepanjang siklus hidup pod. Jika probe gagal beberapa kali dan ambang batas kegagalan yang dikonfigurasikan tercapai, pod akan di-restart.

• Probe kesiapan: Mendeteksi apakah aplikasi siap. Sistem memulai probe kesiapan setelah probe startup berhasil. Probe kesiapan dilakukan sepanjang siklus hidup pod. Jika probe gagal beberapa kali dan ambang batas kegagalan yang dikonfigurasikan tercapai, Kubernetes menandai pod sebagai tidak siap, tetapi tidak me-restart pod. Ketika aplikasi dirilis, Anda dapat menggunakan probe kesiapan untuk mengontrol proses rilis. Berdasarkan kebijakan rilis default, jika pod baru tidak siap, Kubernetes akan menghentikan proses rilis sampai pod baru menjadi siap.

Setelah layanan Anda terintegrasi dengan Tata Kelola Layanan MSE, Anda dapat menggunakan endpoint 55199/readiness bawaan di Tata Kelola Layanan MSE untuk mengonfigurasi pemeriksaan kesiapan layanan. Setelah konfigurasi selesai, probe kesiapan K8s hanya akan berhasil setelah aplikasi menyelesaikan pendaftaran layanan. Ini memastikan bahwa selama proses penyebaran, pod yang baru dimulai telah menyelesaikan pendaftaran dengan registri layanan sebelum pod lama dihapus dari jaringan oleh K8s dan dicabut dari registri layanan. Proses ini memungkinkan pemanggil layanan selalu memiliki node yang tersedia untuk melakukan panggilan, yang mencegah kesalahan yang disebabkan oleh layanan yang tidak tersedia. Untuk informasi lebih lanjut tentang mengapa Anda perlu mengonfigurasi probe kesiapan MSE, lihat Pemeriksaan Status Pendaftaran Layanan.

Jika kegagalan probe kesiapan MSE terus berlanjut, masalah ini mungkin disebabkan oleh alasan berikut:

1. Mulai yang mulus tidak diaktifkan untuk aplikasi, dan 55199/readiness tidak berlaku. Akibatnya, probe kesiapan gagal.

2. Aplikasi saat ini tidak terhubung ke tata kelola layanan. Anda dapat memeriksa apakah log probe ada di direktori probe tata kelola layanan. Dalam lingkungan K8s, direktori probe adalah /home/admin/.opt/AliyunJavaAgent atau /home/admin/.opt/ArmsAgent secara default. Jika direktori tidak berisi direktori logs, itu menunjukkan bahwa aplikasi gagal terhubung ke tata kelola layanan. Silakan mengajukan tiket untuk menghubungi kami.

3. Aplikasi di-restart berulang kali karena kegagalan probe startup atau kelangsungan hidup mencapai ambang batas yang ditentukan. Dalam kasus ini, probe kesiapan MSE selalu gagal. Anda dapat memeriksa event Kubernetes pod di latar belakang dan memeriksa apakah ada event terkait kegagalan probe startup atau kelangsungan hidup.