Pemutusan sirkuit statis mengharuskan Anda memperkirakan dan menetapkan secara manual ambang batas konkurensi tetap untuk setiap layanan. Jika perkiraan terlalu rendah, lalu lintas sah akan diblokir; jika terlalu tinggi, layanan akan kelebihan beban sebelum pemutus sirkuit aktif. CustomResourceDefinition (CRD) ASMAdaptiveConcurrency menghilangkan ketidakpastian ini dengan menyesuaikan batas konkurensi secara dinamis berdasarkan pengukuran latensi waktu nyata, sehingga menjaga batas tersebut mendekati kapasitas aktual layanan tanpa perlu penyetelan manual.
Ketika permintaan konkuren melebihi batas yang dihitung, proxy sidecar mengembalikan kode status HTTP 503 dengan pesan error reached concurrency limit.
Cara kerja
Pengontrol konkurensi adaptif menggunakan algoritma berbasis gradien yang secara berkala mengukur latensi dasar layanan (MinRTT) dan membandingkannya dengan latensi permintaan yang diambil sampelnya (SampleRTT) untuk menyesuaikan batas konkurensi.
Perhitungan gradien
Pengontrol menghitung nilai gradien dari latensi yang diambil sampelnya:
gradient = (minRTT + buffer) / sampleRTTBuffer menyerap variasi latensi normal, sehingga gradien hanya menurun ketika latensi sampel melebihi garis dasar dalam jumlah yang signifikan:
buffer = minRTT * buffer_pctGradien kemudian memperbarui batas konkurensi:
new_limit = gradient * current_limit + headroomKetika layanan dalam kondisi sehat, sampleRTT tetap mendekati minRTT, gradien tetap mendekati 1,0, dan batas tetap stabil atau meningkat. Saat layanan mulai kelebihan beban, sampleRTT meningkat, gradien turun di bawah 1,0, dan batas berkurang—menolak permintaan berlebih sebelum layanan mengalami degradasi lebih lanjut.
Perhitungan ulang MinRTT
Pengontrol secara berkala menghitung ulang MinRTT dengan sementara mengurangi batas konkurensi ke nilai min_concurrency. Selama jendela ini, hanya sejumlah kecil permintaan yang diteruskan agar layanan dapat merespons pada latensi minimum sebenarnya.
Batas konkurensi turun secara signifikan selama perhitungan ulang MinRTT, yang dapat menyebabkan lonjakan respons 503. Untuk mengurangi dampak ini, buat aturan tujuan (destination rule) yang mengaktifkan retry untuk layanan target. Hal ini memungkinkan proxy sidecar melakukan retry terhadap permintaan yang ditolak pada host lain yang tidak sedang dalam jendela perhitungan ulang MinRTT.
Prasyarat
Sebelum memulai, pastikan Anda telah memiliki:
Instans Service Mesh (ASM) versi 1.12.4.19 atau lebih baru. Untuk informasi selengkapnya, lihat Buat instans ASM.
Kluster yang ditambahkan ke instans ASM. Untuk informasi selengkapnya, lihat Tambahkan kluster ke instans ASM.
Klien kubectl yang terhubung ke kluster. Untuk informasi selengkapnya, lihat Dapatkan file kubeconfig kluster dan gunakan kubectl untuk terhubung ke kluster.
Langkah 1: Deploy aplikasi contoh
Tutorial ini menggunakan dua aplikasi untuk mendemonstrasikan kontrol konkurensi adaptif:
| Application | Role | Configuration |
|---|---|---|
| testserver | Target service | Menangani hingga 500 permintaan konkuren, masing-masing memerlukan waktu pemrosesan 1.000 ms. Permintaan yang melebihi batas konkurensi akan masuk antrian. |
| gotest | Load generator | Setiap replika mengirim 200 permintaan konkuren ke testserver. |
Deploy testserver
Buat file bernama
testserver.yamldengan konten berikut:Flag
-mmengatur jumlah maksimum permintaan bersamaan (500). Flag-tmengatur waktu pemrosesan per permintaan dalam milidetik (1.000).Terapkan Deployment:
kubectl apply -f testserver.yaml
Buat Service testserver
Buat file bernama
testservice.yamldengan konten berikut:Terapkan Service:
kubectl apply -f testservice.yaml
Deploy gotest
Buat file bernama
gotest.yamldengan konten berikut:Jumlah replika awal adalah 0. Tingkatkan jumlahnya di Langkah 4 untuk menghasilkan beban.
Terapkan Deployment:
kubectl apply -f gotest.yaml
Langkah 2: Buat CRD ASMAdaptiveConcurrency
Hubungkan kubectl ke instans ASM Anda. Untuk informasi selengkapnya, lihat Gunakan kubectl pada lapisan kontrol untuk mengakses resource Istio.
Buat file bernama
adaptiveconcurrency.yamldengan konten berikut:apiVersion: istio.alibabacloud.com/v1beta1 kind: ASMAdaptiveConcurrency metadata: name: sample-adaptive-concurrency namespace: default spec: workload_selector: labels: app: testserver sample_aggregate_percentile: value: 60 concurrency_limit_params: max_concurrency_limit: 500 concurrency_update_interval: 15s min_rtt_calc_params: interval: 60s request_count: 100 jitter: value: 15 min_concurrency: 50 buffer: value: 25Konfigurasi ini dapat dijelaskan sebagai berikut:
Targetkan workload
testserverdan tetapkan batas atas menjadi 500 permintaan konkuren.Perbarui batas konkurensi setiap 15 detik menggunakan persentil ke-60 dari latensi yang diambil sampelnya sebagai SampleRTT.
Hitung ulang MinRTT setiap 60 detik (dengan jitter acak hingga 15%) menggunakan 100 permintaan sampel. Selama perhitungan ulang MinRTT, batasi konkurensi menjadi 50 permintaan.
Perlakukan fluktuasi latensi dalam rentang 25% dari MinRTT sebagai hal yang normal.
Terapkan CRD:
kubectl apply -f adaptiveconcurrency.yaml
Referensi parameter
| Parameter | Type | Required | Default | Description |
|---|---|---|---|---|
workload_selector | WorkloadSelector | Yes | -- | Memilih pod target berdasarkan label. |
labels | map | Yes | -- | Label untuk mencocokkan pod target. |
sample_aggregate_percentile | Percent | Yes | -- | Persentil yang digunakan untuk mengagregasi latensi sampel menjadi SampleRTT. Nilai valid: 0 hingga 100. |
concurrency_limit_params | Object | Yes | -- | Pengaturan batas konkurensi. |
max_concurrency_limit | int | No | 1000 | Batas atas untuk permintaan konkuren. |
concurrency_update_interval | duration | Yes | -- | Frekuensi pembaruan batas konkurensi oleh pengontrol. Contoh: 60s. |
min_rtt_calc_params | Object | Yes | -- | Pengaturan perhitungan MinRTT. |
interval | duration | No | -- | Frekuensi perhitungan ulang MinRTT. Contoh: 120s. |
request_count | int | No | 50 | Jumlah permintaan yang diambil sampelnya untuk menghitung MinRTT. |
jitter | Percent | No | 15 | Jitter acak yang ditambahkan ke interval perhitungan ulang MinRTT. Misalnya, jika interval adalah 120s dan jitter adalah 50, interval aktualnya adalah random(120, 120 + 120 * 50%) detik. |
min_concurrency | int | No | 3 | Batas konkurensi selama perhitungan ulang MinRTT. Juga berfungsi sebagai batas awal saat pengontrol dimulai. Tetapkan nilai ini jauh di bawah kapasitas aktual layanan untuk mendapatkan pengukuran garis dasar yang akurat. |
buffer | Percent | No | 25 | Fluktuasi latensi yang dapat diterima sebagai persentase dari MinRTT. Misalnya, jika MinRTT adalah 100 ms dan buffer adalah 10, latensi hingga 110 ms dianggap normal. |
Langkah 3: Siapkan pemantauan dengan Prometheus
Ekspor metrik konkurensi adaptif ke Managed Service for Prometheus untuk mengamati perilaku pengontrol dan menyetel parameter.
Aktifkan Managed Service for Prometheus untuk kluster Anda. Untuk informasi selengkapnya, lihat Gunakan Managed Service for Prometheus.
Buat ServiceMonitor untuk mengambil metrik dari proxy sidecar testserver.
Buat file bernama
servicemonitor.yamldengan konten berikut:apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: testserver-envoy-metrics namespace: default spec: endpoints: - interval: 5s path: /stats/prometheus port: metrics namespaceSelector: any: true selector: matchLabels: app: testserverHubungkan kubectl ke kluster ACK dan terapkan ServiceMonitor:
kubectl apply -f servicemonitor.yaml
Impor Dasbor Grafana untuk memvisualisasikan metrik pengontrol. Unduh JSON dasbor dan impor melalui konsol Managed Service for Grafana. Untuk petunjuk impor, lihat dokumentasi ARMS.
Langkah 4: Verifikasi pengontrol konkurensi
Hasilkan beban terhadap testserver untuk memastikan bahwa CRD ASMAdaptiveConcurrency membatasi konkurensi sesuai harapan.
Skalakan Deployment gotest menjadi 5 replika. Dengan 200 permintaan konkuren per replika, ini menghasilkan 1.000 permintaan simultan—dua kali lipat kapasitas testserver sebesar 500 permintaan.
Masuk ke Konsol ACK. Di panel navigasi kiri, klik Clusters.
Di halaman Clusters, temukan kluster Anda dan klik nama kluster tersebut atau klik Details di kolom Actions.
Di panel navigasi kiri, pilih Workloads > Deployments.
Di halaman Deployments, atur Namespace ke default. Di kolom Actions untuk aplikasi gotest, pilih More > View in YAML.
Di kotak dialog Edit YAML, atur
replicasmenjadi5dan klik Update.
Buka Dasbor Grafana yang Anda impor di Langkah 3. Atur Service ke
testserverdan Pod keALL.Periksa panel ConcurrencyLimit. Batas konkurensi harus stabil di bawah 500, yang mengonfirmasi bahwa pengontrol melindungi testserver dari kelebihan beban. Panel RqBlocked menampilkan jumlah kumulatif permintaan yang ditolak.
Referensi metrik
Pengontrol konkurensi adaptif mengekspos metrik Prometheus berikut melalui proxy sidecar. Gunakan metrik ini untuk memantau perilaku pengontrol dan menyetel parameter CRD.
| Metric | Type | Description |
|---|---|---|
rq_blocked | Counter | Total permintaan yang ditolak oleh pengontrol konkurensi. |
burst_queue_size | Gauge | Nilai headroom saat ini yang digunakan dalam perhitungan batas konkurensi. |
concurrency_limit | Gauge | Batas konkurensi saat ini yang diberlakukan oleh pengontrol. |
gradient | Gauge | Nilai gradien saat ini. |
min_rtt_msecs | Gauge | Pengukuran MinRTT saat ini dalam milidetik. |
sample_rtt_msecs | Gauge | Agregat SampleRTT saat ini dalam milidetik. |
min_rtt_calculation_active | Gauge | Bernilai 1 saat pengontrol sedang menghitung ulang MinRTT. |
Semua metrik menggunakan awalan namespace envoy_http_inbound_0_0_0_0_8080_adaptive_concurrency_gradient_controller_.
Terapkan pada layanan produksi
Aktifkan retry: Buat destination rule dengan kebijakan retry untuk layanan target guna menangani respons 503 selama jendela perhitungan ulang MinRTT.
Setel parameter: Sesuaikan
concurrency_update_interval,min_concurrency, danbufferberdasarkan pengamatan di Dasbor Grafana. Nilaibufferyang lebih kecil membuat pengontrol lebih sensitif terhadap perubahan latensi; nilai yang lebih besar memungkinkan fluktuasi lebih besar.Targetkan workload Anda sendiri: Ganti label
workload_selectoruntuk menargetkan workload produksi Anda. Mulailah dengan pengaturan konservatif (min_concurrencyjauh di bawah kapasitas yang diharapkan) dan lakukan iterasi berdasarkan metrik.