Microservices Engine:FAQ Mulai dan Shutdown yang Mulus

Fitur lanjutan

Versi sebelumnya konsol untuk mulai dan shutdown yang mulus menyediakan fitur lanjutan. Karena fitur-fitur tersebut melibatkan konsep layanan mikro yang kompleks, mereka disembunyikan di antarmuka baru demi kesederhanaan. Fitur lanjutan dari versi sebelumnya mencakup dua sub-fitur:

• Registrasi layanan sebelum kesiapan

  Fitur ini masih tersedia dan diaktifkan secara default. Jika sebelumnya dinonaktifkan untuk aplikasi Anda, fitur ini akan diaktifkan secara otomatis saat Anda mengaktifkan mulai mulus pada halaman Graceful Online/Offline di konsol. Jika Anda telah mengaktifkan fitur ini sebelumnya, kami tidak menyarankan untuk menonaktifkannya. Saat diaktifkan secara default, fitur ini tidak memiliki dampak negatif dan membantu mencegah trafik turun menjadi nol selama rilis. Untuk informasi lebih lanjut, lihat Apa fungsi 55199/readiness, dan mengapa ada risiko trafik turun menjadi nol tanpa fitur tersebut?.

• Pra-ambil layanan sebelum kesiapan

  Fitur ini tidak lagi tersedia untuk konfigurasi baru. Tujuan awalnya adalah untuk memastikan bahwa pra-ambil layanan mencapai hasil yang diharapkan dan mencegah lonjakan mendadak pada kurva QPS. Fitur ini bekerja dengan menunda pemeriksaan kesiapan Kubernetes untuk memperpanjang durasi rilis secara keseluruhan. Hal ini memberi node baru waktu yang cukup untuk melakukan pra-ambil layanan dan memungkinkan node lama terus menangani trafik, sehingga memastikan peningkatan QPS yang bertahap. Jika node lama offline saat node baru masih dalam proses pra-ambil, node baru harus menangani seluruh trafik masuk, yang justru menggagalkan tujuan pra-ambil layanan bertrafik rendah. Aplikasi yang sebelumnya telah mengaktifkan fitur ini tidak terpengaruh, tetapi fitur ini tidak dapat diaktifkan untuk aplikasi baru. Jika Anda sebelumnya telah mengaktifkan fitur ini, kami tidak menyarankan untuk menonaktifkannya, karena tidak memiliki dampak negatif. Untuk hasil terbaik dengan pra-ambil layanan bertrafik rendah di versi baru, lihat Praktik terbaik untuk pra-ambil layanan bertrafik rendah.

Prinsip pra-ambil layanan bertrafik rendah

Saat sebuah konsumen memanggil layanan, konsumen tersebut memilih penyedia. Jika aplikasi penyedia telah mengaktifkan pra-ambil layanan bertrafik rendah, Microservices Governance meningkatkan proses pemilihan ini. Saat konsumen memilih penyedia, sistem menghitung bobot dari 0% hingga 100% untuk setiap penyedia. Semakin tinggi bobotnya, semakin besar kemungkinan penyedia tersebut dipilih. Saat penyedia dengan pra-ambil layanan bertrafik rendah diaktifkan, konsumen memberikan bobot rendah kepadanya. Artinya, node baru memiliki probabilitas lebih rendah untuk dipilih. Seiring waktu, bobot yang dihitung meningkat hingga akhirnya mencapai 100%. Pada titik ini, proses pra-ambil selesai, dan node mulai menerima trafik seperti node biasa. Penyedia menyertakan waktu startup-nya dalam metadata registrasi layanan, yang digunakan konsumen untuk menghitung bobot. Proses ini memerlukan baik penyedia maupun konsumen untuk mengaktifkan Microservices Governance.

Kurva QPS pra-ambil yang tidak sesuai harapan

Dalam kondisi normal, kurva QPS aplikasi selama pra-ambil layanan bertrafik rendah tampak sebagai berikut:

Namun, dalam beberapa kasus penggunaan yang tidak didukung atau akibat konfigurasi yang salah, kurva QPS aplikasi yang menjalani pra-ambil layanan bertrafik rendah mungkin tidak menunjukkan peningkatan bertahap. Berikut adalah dua pola tak terduga yang umum:

• Lonjakan mendadak pada kurva QPS

  

  Hal ini biasanya terjadi selama penerapan layanan. Jika node lama di-offline sebelum node baru menyelesaikan durasi pra-ambil, konsumen tidak lagi dapat menerapkan routing probabilitas rendah ke node baru. Akibatnya, kurva QPS node baru awalnya menunjukkan peningkatan bertahap, tetapi tiba-tiba melonjak setelah semua node lama di-offline. Untuk menyelesaikan masalah ini, lihat Praktik terbaik untuk pra-ambil layanan bertrafik rendah.

• Tidak adanya peningkatan QPS bertahap

  

  Masalah ini menunjukkan bahwa aplikasi konsumen yang melakukan permintaan tidak terhubung ke Microservices Governance. Untuk mengatasinya, hubungkan konsumen tersebut. Pra-ambil layanan bertrafik rendah tidak didukung untuk trafik dari sumber eksternal, seperti gerbang Java, karena mereka bukan konsumen yang terhubung.

Praktik terbaik untuk pra-ambil layanan bertrafik rendah

Dalam penyebaran bergulir, pra-ambil layanan sering kali tidak lengkap. Anda dapat mengikuti praktik berikut untuk memastikan pra-ambil layanan mencapai hasil yang diharapkan:

• Konfigurasikan minReadySeconds (Direkomendasikan): Anda dapat mengonfigurasi parameter .spec.minReadySeconds untuk workload Anda guna mengontrol interval waktu antara saat Pod menjadi ready dan saat dianggap tersedia. Atur parameter ini ke nilai lebih besar daripada durasi pra-ambil layanan bertrafik rendah Pod. Hal ini memastikan Kubernetes menunggu hingga Pod menyelesaikan pra-ambil sebelum melanjutkan penyebaran bergulir. Jika Anda menggunakan ACK, Anda dapat mengatur parameter ini dengan menemukan aplikasi Anda di platform kontainer dan menavigasi ke More > Upgrade Policy > Rolling Upgrade > Minimum Ready Time (minReadySeconds). Menyetel minReadySeconds memastikan Pod baru tetap dalam status ready selama durasi yang ditentukan sebelum Kubernetes melanjutkan penyebaran bergulir.

• Gunakan penyebaran batch (Direkomendasikan): Pertimbangkan penggunaan alat seperti OpenKruise untuk menerapkan penyebaran batch pada workload Anda. Atur interval waktu antar batch lebih lama daripada durasi pra-ambil layanan bertrafik rendah. Hal ini memastikan node baru dalam satu batch sepenuhnya selesai melakukan pra-ambil sebelum batch berikutnya diterapkan.

Tingkatkan delay awal untuk pemeriksaan kesiapan (Tidak direkomendasikan): Pendekatan lain adalah meningkatkan delay awal probe (initialDelaySeconds) untuk pemeriksaan kesiapan workload ke nilai yang lebih besar daripada jumlah durasi pra-ambil layanan bertrafik rendah, delay registrasi, dan waktu startup aplikasi. Perlu diperhatikan bahwa Anda harus menentukan waktu startup aplikasi dengan mengamati output log, dan nilainya dapat berubah seiring perkembangan bisnis Anda. Selain itu, menunda pemeriksaan kesiapan dapat mencegah node yang baru dimulai ditambahkan tepat waktu ke endpoint layanan Kubernetes. Oleh karena itu, kami tidak merekomendasikan metode ini untuk mencapai hasil pra-ambil optimal.

Titik akhir 55199/readiness

Titik akhir 55199/readiness adalah port HTTP readiness probe bawaan yang disediakan oleh MSE Microservices Governance. Saat pemeriksaan kesiapan Kubernetes aplikasi dikonfigurasi untuk menggunakan 55199/readiness, probe tersebut mengembalikan kode 500 jika node baru belum menyelesaikan registrasi layanan, dan 200 jika sudah.

Sesuai strategi penerapan Kubernetes default, node lama tidak dihentikan sampai node baru siap. Saat pemeriksaan kesiapan dikonfigurasi dengan 55199/readiness, node baru hanya dianggap siap setelah menyelesaikan registrasi layanan. Hal ini memastikan node lama hanya dihentikan setelah node baru terdaftar, sehingga selalu tersedia node untuk layanan di registrasi layanan. Jika Anda tidak mengonfigurasi 55199/readiness, node lama mungkin dihentikan sebelum node baru terdaftar selama penerapan layanan. Hal ini dapat menyebabkan tidak tersedianya node di registrasi layanan, sehingga semua panggilan konsumen gagal dan trafik layanan turun menjadi nol. Oleh karena itu, kami sangat menyarankan Anda mengaktifkan mulai mulus dan mengonfigurasi readiness probe 55199/readiness untuk aplikasi Anda.

Jika aplikasi Anda menggunakan versi probe sebelum 4.1.10, Anda perlu mengonfigurasi path readiness probe sebagai /health alih-alih /readiness. Untuk memeriksa versi probe, buka konsol MSE, navigasi ke Administration Center > Application Governance, klik aplikasi target, lalu klik Node Details. Versi probe ditampilkan di sebelah kanan.

Event pra-ambil sebelum registrasi layanan

Pada versi saat ini, proses pra-ambil dimulai dan event awal pra-ambil dilaporkan saat layanan menerima permintaan eksternal pertamanya. Namun, permintaan pertama yang diterima aplikasi mungkin bukan panggilan layanan mikro dan karenanya tidak memicu pra-ambil dalam logika bisnis. Misalnya, jika workload aplikasi dikonfigurasi dengan pemeriksaan kelangsungan hidup Kubernetes, proses pra-ambil dimulai segera setelah Kubernetes melakukan pemeriksaan kelangsungan hidup, meskipun registrasi layanan belum terjadi.

Untuk menghindari hal ini, Anda dapat mengonfigurasi parameter berikut dalam variabel lingkungan workload aplikasi penyedia agar logika pra-ambil mengabaikan permintaan tersebut:

# Kecualikan permintaan ke path /xxx dan /yyy/zz dari memicu proses pra-ambil
profile_micro_service_record_warmup_ignored_path="/xxx,/yyy/zz"

Notifikasi proaktif

Notifikasi proaktif adalah fitur lanjutan dari modul shutdown yang mulus. Fitur ini memungkinkan penyedia Spring Cloud mengirim permintaan jaringan ke konsumennya saat akan shutdown, memberi tahu bahwa node tersebut akan offline. Setelah menerima notifikasi, konsumen tidak akan lagi memanggil node tersebut. Biasanya, saat penyedia dan konsumen sama-sama menggunakan framework Spring Cloud, konsumen menyimpan cache daftar node penyedia secara lokal. Dalam beberapa skenario, meskipun telah menerima notifikasi dari registrasi layanan, konsumen mungkin tidak segera memperbarui cache lokalnya, sehingga tetap memanggil node yang sudah offline. Notifikasi proaktif secara efektif menyelesaikan masalah ini.

Notifikasi proaktif dinonaktifkan secara default. Dengan Microservices Governance diaktifkan, solusi shutdown yang mulus default melibatkan penyedia yang sedang shutdown menambahkan header khusus ke responsnya. Saat konsumen menerima respons, konsumen mengenali header tersebut dan berhenti memanggil node penyedia tersebut. Oleh karena itu, selama ada trafik dari konsumen ke penyedia yang sedang shutdown, konsumen akan mengetahui bahwa penyedia tersebut offline dan secara otomatis memasukkannya ke dalam blacklist. Namun, jika konsumen tidak mengirim permintaan apa pun ke penyedia yang sedang shutdown selama periode shutdown (biasanya sekitar 30 detik), konsumen mungkin tidak mengetahui bahwa penyedia tersebut offline. Permintaan bisa saja tiba tepat saat penyedia shutdown, menyebabkan error. Dalam skenario ini, Anda harus mengaktifkan notifikasi proaktif. Dengan kata lain, jika trafik konsumen Anda sangat jarang, kami menyarankan Anda mengaktifkan notifikasi proaktif untuk penyedia.

Penurunan trafik yang tertunda setelah shutdown

Umumnya, trafik turun menjadi nol segera setelah event shutdown yang mulus. Jika tidak demikian, berikut adalah kemungkinan penyebab dan solusinya:

• Panggilan non-layanan mikro

  Saat ini, mulai dan shutdown yang mulus hanya mengelola trafik dari panggilan layanan mikro internal. Skenario ini berada di luar cakupan fitur ini. Kami menyarankan Anda membuat solusi kustom berdasarkan fitur shutdown yang mulus yang disediakan oleh infrastruktur dan framework Anda.

• Notifikasi proaktif tidak diaktifkan

  Kami menyarankan Anda mengaktifkan notifikasi proaktif, lalu periksa apakah kurva shutdown sesuai harapan.

• Versi framework tidak didukung

  Jika Anda menemukan bahwa aplikasi Anda menggunakan versi framework yang tidak didukung, pertimbangkan untuk melakukan upgrade.

Durasi rilis yang lama

Ikuti langkah-langkah berikut untuk memeriksa apakah aplikasi memiliki fitur Lengkapi pra-ambil layanan sebelum lulus pemeriksaan kesiapan yang diaktifkan.

1. Login ke Konsol MSE dan pilih wilayah di bilah menu atas.

2. Di panel navigasi kiri, pilih Microservices Governance > Application Governance.

3. Pada halaman Applications, klik aplikasi target dan buka tab Traffic Governance > Graceful Start and Shutdown.

4. Pada tab Graceful Online/Offline, tekan F12 untuk membuka developer tools browser Anda. Di tab Network, cari permintaan GetLosslessRuleByApp. Jika tidak muncul, refresh halaman. Di badan respons, periksa apakah nilai bidang Related di bawah Data bernilai true. Jika ya, berarti aplikasi sebelumnya memiliki fitur Lengkapi pra-ambil layanan sebelum lulus pemeriksaan kesiapan yang diaktifkan. Fitur ini kini telah ditinggalkan dan dapat menyebabkan durasi rilis lebih lama. Kami menyarankan Anda membuat tiket untuk menonaktifkan fitur ini.

Titik akhir 55199/readiness dan kegagalan probe

Kubernetes menyediakan tiga jenis probe opsional: startup probe, liveness probe, dan readiness probe.

• startup probe: Memeriksa apakah aplikasi berhasil dimulai. Probe ini hanya berjalan selama fase startup Pod. Jika probe gagal berulang kali dan mencapai ambang batas kegagalan yang dikonfigurasi selama startup, probe ini memicu restart Pod.

• liveness probe: Memeriksa apakah aplikasi saat ini aktif. Probe ini mulai berjalan setelah startup probe berhasil dan berlanjut sepanjang siklus hidup Pod. Jika probe gagal berulang kali dan mencapai ambang batas kegagalan yang dikonfigurasi, probe ini memicu restart Pod.

• readiness probe: Memeriksa apakah aplikasi siap menerima trafik. Probe ini mulai berjalan setelah startup probe berhasil dan berlanjut sepanjang siklus hidup Pod. Jika probe gagal berulang kali dan mencapai ambang batas kegagalan yang dikonfigurasi, Kubernetes mengatur status Pod menjadi tidak siap, tetapi tidak merestart Pod. Selama penerapan, readiness probe juga dapat mengontrol kecepatan penerapan. Sesuai strategi penerapan default, jika Pod baru tidak menjadi siap, Kubernetes akan menjeda proses penerapan hingga Pod tersebut siap.

Setelah layanan Anda terhubung ke MSE Microservices Governance, Anda dapat menggunakan titik akhir bawaan 55199/readiness untuk konfigurasi readiness probe layanan Anda. Dengan konfigurasi ini, readiness probe Kubernetes hanya lolos setelah aplikasi menyelesaikan registrasi layanan. Hal ini memastikan bahwa selama penerapan, Pod baru terdaftar di registrasi layanan mikro sebelum Pod lama dihentikan dan dideregistrasi oleh Kubernetes. Ini menjamin pemanggil selalu memiliki node yang tersedia, sehingga menghindari exception "no available service". Untuk informasi lebih lanjut tentang mengapa Anda perlu mengonfigurasi readiness probe MSE, lihat Pemeriksaan status registrasi layanan.

Jika readiness probe MSE Anda terus-menerus gagal, ada tiga kemungkinan penyebab:

1. Mulai mulus tidak diaktifkan untuk layanan saat ini. Jika mulai mulus dinonaktifkan, API MSE 55199/readiness tidak diekspos, dan readiness probe tidak akan lolos.

2. Aplikasi saat ini tidak terhubung ke Microservices Governance. Anda dapat memeriksa apakah log probe ada di direktori probe governance layanan mikro. Di lingkungan Kubernetes, direktori probe default adalah /home/admin/.opt/AliyunJavaAgent atau /home/admin/.opt/ArmsAgent. Jika direktori log tidak ada di direktori tersebut, artinya aplikasi gagal terhubung ke Microservices Governance. Silakan buat tiket untuk menghubungi kami.

3. Aplikasi saat ini terus-menerus melakukan restart karena startup probe atau liveness probe telah mencapai ambang batas kegagalannya. Karena aplikasi gagal dimulai, readiness probe MSE tidak lolos. Periksa event Kubernetes Pod untuk menemukan event terkait kegagalan startup probe atau liveness probe.