Suite penjadwalan lalu lintas dari Service Mesh (ASM) mendukung kebijakan penjadwalan permintaan berdasarkan prioritas. Saat sistem mengalami beban berlebih, permintaan dengan prioritas tinggi diproses terlebih dahulu. Topik ini menjelaskan cara menggunakan AverageLatencySchedulingPolicy yang disediakan oleh suite penjadwalan lalu lintas untuk mengimplementasikan penjadwalan permintaan berdasarkan prioritas.
Informasi latar belakang
Kebijakan penjadwalan permintaan berdasarkan prioritas membandingkan latensi waktu nyata dengan latensi rata-rata historis untuk menentukan apakah terjadi overload lalu lintas. Jika terjadi overload, mekanisme penjadwalan berdasarkan bucket token dan prioritas digunakan untuk menjadwalkan permintaan. Kebijakan ini bekerja sebagai berikut:
Pendeteksian Overload: Kebijakan ini membandingkan latensi rata-rata pada periode sebelumnya dengan latensi saat ini untuk menentukan apakah sistem mengalami beban berlebih.
Penyesuaian Laju Penerbitan Token: Jika terjadi overload, data pemantauan yang diperoleh pada langkah sebelumnya dikirim ke pengontrol khusus, yang akan mengatur laju pengisian bucket token.
Penjadwalan Permintaan: Permintaan memiliki prioritas yang berbeda. Saat terjadi overload, permintaan dengan prioritas lebih tinggi memiliki peluang lebih besar untuk mendapatkan token.
Kebijakan ini dapat digunakan untuk mengantri permintaan ketika layanan macet akibat konkurensi permintaan tinggi dan latensi respons terus meningkat. Berbeda dengan kebijakan throttling umum, kebijakan ini tidak langsung menolak permintaan tetapi meletakkannya dalam antrian prioritas. Laju permintaan dibatasi menggunakan mekanisme bucket token, dan urutan pemrosesan permintaan disesuaikan sesuai dengan prioritas.
Prasyarat
Sebuah kluster Container Service for Kubernetes (ACK) yang dikelola telah ditambahkan ke instance ASM Anda, dan versi instance ASM Anda adalah V1.21.6.44 atau lebih baru. Untuk informasi lebih lanjut, lihat Tambahkan Kluster ke Instance ASM.
Injeksi proxy sidecar otomatis diaktifkan untuk namespace default di kluster ACK. Untuk informasi lebih lanjut, lihat Kelola Namespace Global.
Anda telah terhubung ke kluster ACK menggunakan kubectl. Untuk informasi lebih lanjut, lihat Dapatkan File kubeconfig Kluster dan Gunakan kubectl untuk Terhubung ke Kluster.
Suite penjadwalan lalu lintas ASM diaktifkan. Untuk informasi lebih lanjut, lihat Aktifkan Suite Penjadwalan Lalu Lintas ASM.
Aplikasi HTTPBin telah diterapkan dan dapat diakses menggunakan gateway ASM. Untuk informasi lebih lanjut, lihat Terapkan Aplikasi HTTPBin.
(Opsional) Fitur pembuatan dan pengumpulan log akses gateway ASM diaktifkan. Untuk informasi lebih lanjut, lihat Konfigurasikan Fitur Pembuatan dan Pengumpulan Log Akses Gateway ASM.
Langkah 1: Buat AverageLatencySchedulingPolicy
Gunakan kubectl untuk terhubung ke instance ASM. Untuk informasi lebih lanjut, lihat Gunakan kubectl pada Control Plane untuk Mengakses Sumber Daya Istio.
Buat file AverageLatencySchedulingPolicy.yaml dengan konten berikut:
apiVersion: istio.alibabacloud.com/v1 kind: AverageLatencySchedulingPolicy metadata: name: workload-prioritization namespace: istio-system spec: load_scheduling_core: aimd_load_scheduler: load_scheduler: workload_latency_based_tokens: true selectors: - service: httpbin.default.svc.cluster.local scheduler: workloads: - label_matcher: match_labels: http.request.header.user_type: "guest" parameters: priority: 50.0 name: "guest" - label_matcher: match_labels: http.request.header.user_type: "subscriber" parameters: priority: 200.0 name: "subscriber"Tabel berikut menjelaskan beberapa bidang tersebut.
Bidang
Deskripsi
workload_latency_based_tokens
Menunjukkan apakah akan menyesuaikan jumlah token secara dinamis berdasarkan latensi rata-rata beban kerja. Jendela waktu untuk memperkirakan latensi rata-rata adalah 30 menit terakhir.
service
Layanan tempat kebijakan penjadwalan berlaku.
workloads
Dua jenis permintaan didefinisikan berdasarkan user_type di header permintaan: guest dan subscriber. Prioritas permintaan tipe guest adalah 50, dan prioritas permintaan tipe subscriber adalah 200.
Untuk informasi lebih lanjut tentang bidang yang didukung oleh AverageLatencySchedulingPolicy, lihat Deskripsi Bidang AverageLatencySchedulingPolicy.
Langkah 2: Lakukan pengujian
Dalam contoh ini, alat pengujian beban fortio digunakan. Untuk informasi lebih lanjut, lihat Instal Fortio.
Pertama, simulasi beberapa permintaan layanan normal untuk menghasilkan latensi rata-rata permintaan:
fortio load -c 20 -qps 100000 -t 60m http://${Alamat IP gateway ASM}/status/200Tiga menit setelah perintah sebelumnya dijalankan, buka dua terminal lagi dan kirim permintaan uji. Selama pengujian, pastikan proses fortio selalu berjalan dan jangan tutup terminal yang sesuai.
Di dua terminal tersebut, jalankan dua perintah pengujian beban berikut secara terpisah. Mulailah menjalankan kedua tes tersebut bersamaan sebanyak mungkin.
fortio load -c 40 -qps 100000 -H "user_type:guest" -t 3m http://${Alamat IP gateway ASM}/status/201fortio load -c 40 -qps 100000 -H "user_type:subscriber" -t 3m http://${Alamat IP gateway ASM}/status/202Dalam dua perintah tersebut, jalur permintaan yang berbeda digunakan untuk memudahkan pengamatan hasil pengujian berdasarkan log akses.
Langkah 3: Analisis hasil pengujian
Blok kode berikut menunjukkan beberapa baris terakhir dari keluaran dua perintah dalam lingkungan pengujian saat ini:
Kode 201 : 26852 (97,8 %)
Kode 503 : 601 (2,2 %)
Ukuran Header Respons : hitungan 27453 rata-rata 242,91564 +/- 36,35 min 0 maks 249 total 6668763
Ukuran Body/Totals Respons : hitungan 27453 rata-rata 246,17754 +/- 14,56 min 149 maks 249 total 6758312
Semua selesai 27453 panggilan (plus 40 pemanasan) 262,318 ms rata-rata, 152,4 qpsKode 202 : 52765 (100,0 %)
Ukuran Header Respons : hitungan 52765 rata-rata 248,86358 +/- 0,5951 min 248 maks 250 total 13131287
Ukuran Body/Totals Respons : hitungan 52765 rata-rata 248,86358 +/- 0,5951 min 248 maks 250 total 13131287
Semua selesai 52765 panggilan (plus 40 pemanasan) 136,472 ms rata-rata, 292,9 qpsBlok kode tersebut menunjukkan bahwa:
Semua permintaan dari pengguna subscriber berhasil, dan tidak ada kode status HTTP 503 yang dikembalikan. Kode status HTTP 503 dikembalikan untuk 2,2% permintaan dari pengguna guest.
Latensi rata-rata permintaan dari pengguna subscriber sekitar 136 ms. Latensi rata-rata permintaan dari pengguna guest sekitar 262 ms. Selain itu, queries per second (QPS) dari kedua pengguna berbeda secara signifikan.
Dapat disimpulkan bahwa AverageLatencySchedulingPolicy memprioritaskan pemrosesan permintaan pengguna subscriber saat latensi permintaan meningkat.
Hasil pengujian dalam topik ini hanya nilai teoretis. Data aktual bergantung pada lingkungan operasi Anda. Hasil pengujian beban bervariasi di lingkungan pengujian yang berbeda. Hanya hubungan relatif data yang dianalisis dalam contoh ini.
(Opsional) Langkah 4: Analisis hasil pengujian berdasarkan log akses gateway ASM
Masuk ke Konsol ASM. Di panel navigasi di sebelah kiri, pilih .
Di halaman Mesh Management, klik nama instance ASM. Di panel navigasi di sebelah kiri, pilih .
Klik nama gateway ASM untuk masuk ke halaman Gateway overview. Kemudian, klik Gateway Logs untuk melihat log akses gateway ASM.
Jalur akses pengguna guest dan subscriber berbeda. Anda dapat menggunakan jalur akses untuk mengambil hasil akses masing-masing pengguna:


Referensi
Anda dapat memverifikasi apakah AverageLatencySchedulingPolicy berlaku di Grafana. Pastikan bahwa instance Prometheus untuk Grafana telah dikonfigurasi dengan suite penjadwalan lalu lintas ASM.
Anda dapat mengimpor konten berikut ke Grafana untuk membuat dasbor untuk AverageLatencySchedulingPolicy.
Dasbor adalah sebagai berikut.
