全部产品
Search

搜索本产品

    Alibaba Cloud Service Mesh：Konfigurasikan kolom connectionPool untuk menerapkan pemutusan sirkuit

    文档中心

    Alibaba Cloud Service Mesh：Konfigurasikan kolom connectionPool untuk menerapkan pemutusan sirkuit

    更新时间：Jul 02, 2025

    Pemutusan sirkuit adalah mekanisme manajemen lalu lintas yang melindungi sistem dari kerusakan lebih lanjut akibat kegagalan atau beban berlebih. Dalam layanan Java tradisional, framework seperti Resilience4j dapat digunakan untuk mengimplementasikan pemutusan sirkuit. Istio memungkinkan implementasi pemutusan sirkuit di tingkat jaringan tanpa perlu integrasi kode aplikasi pada setiap layanan. Anda dapat mengonfigurasi kolom connectionPool untuk menerapkan pemutusan sirkuit, meningkatkan stabilitas dan keandalan sistem serta melindungi layanan dari permintaan abnormal.

    Prasyarat

    Kluster Container Service for Kubernetes (ACK) telah ditambahkan ke instance Service Mesh (ASM). Untuk informasi lebih lanjut, lihat Tambahkan kluster ke instance ASM.

    Pengaturan connectionPool

    Sebelum mengaktifkan fitur pemutusan sirkuit, buat aturan tujuan untuk mengonfigurasi pemutusan sirkuit pada layanan tujuan yang diinginkan. Untuk detail tentang kolom dalam aturan tujuan, lihat Destination Rule.

    Kolom connectionPool mendefinisikan parameter terkait pemutusan sirkuit. Tabel berikut menjelaskan parameter dari kolom connectionPool.

    Parameter

    Tipe

    Diperlukan

    Deskripsi

    Nilai default

    tcp.maxConnections

    int32

    Tidak

    Jumlah maksimum koneksi HTTP1 atau TCP ke host tujuan. Batasan jumlah koneksi berlaku pada proxy sidecar di kedua sisi klien dan server. Pod klien tunggal tidak dapat memulai lebih dari jumlah koneksi yang dikonfigurasi ke server. Server tunggal tidak dapat menerima lebih dari jumlah koneksi yang dikonfigurasi. Jumlah koneksi yang dapat diterima oleh layanan aplikasi di server dihitung menggunakan rumus berikut: min(Jumlah pod klien, jumlah pod server) × maxConnections.

    2³²-1

    http.http1MaxPendingRequests

    int32

    Tidak

    Jumlah maksimum permintaan yang akan diantrekan saat menunggu koneksi kolam koneksi siap.

    1024

    http.http2MaxRequests

    int32

    Tidak

    Jumlah maksimum permintaan aktif ke layanan backend.

    1024

    Parameter ini bekerja dengan jelas dalam skenario sederhana dengan satu klien dan satu instance layanan tujuan. Dalam lingkungan Kubernetes, satu instance setara dengan pod. Namun, dalam lingkungan produksi, skenario berikut lebih umum:

    • Satu instance klien dan beberapa instance layanan tujuan

    • Beberapa instance klien dan satu instance layanan tujuan

    • Beberapa instance klien dan beberapa instance layanan tujuan

    Dalam skenario yang berbeda, sesuaikan nilai-nilai parameter ini berdasarkan kebutuhan bisnis untuk memastikan kolam koneksi dapat beradaptasi dengan lingkungan beban tinggi dan kompleks serta memberikan performa dan keandalan yang baik. Bagian berikut menyediakan contoh konfigurasi kolam koneksi dalam skenario sebelumnya untuk membantu Anda memahami batasan konfigurasi pada klien dan server. Kemudian, Anda dapat mengonfigurasi kebijakan pemutusan sirkuit yang sesuai untuk lingkungan produksi.

    Contoh konfigurasi

    Dalam topik ini, dua skrip Python dibuat: satu untuk layanan tujuan (server) dan lainnya untuk layanan pemanggil (klien).

    • Skrip server membuat aplikasi Flask dengan satu titik akhir pada rute root. Saat mengakses rute root, server tidur selama 5 detik lalu mengembalikan string "Hello World!" dalam format JSON.

      Tampilkan skrip server

      #!  /usr/bin/env python3
from flask import Flask
import time

app = Flask(__name__)

@app.route('/hello')
def get():
    time.sleep(5)
    return 'hello world!'

if __name__ == '__main__':
    app.run(debug=True, host='0.0.0.0', port='9080', threaded = True)

    • Skrip klien memanggil titik akhir server dengan mengirimkan 10 permintaan secara paralel sekaligus, lalu tidur sejenak sebelum mengirimkan batch berikutnya dari 10 permintaan. Skrip melakukan ini dalam loop tak terbatas. Untuk memastikan semua pod klien mengirimkan batch 10 permintaan pada waktu yang sama ketika beberapa pod klien berjalan, batch 10 permintaan dikirimkan pada detik ke-0, ke-20, dan ke-40 setiap menit (menurut waktu sistem).

      Tampilkan skrip klien

      #!  /usr/bin/env python3
import requests
import time
import sys
from datetime import datetime
import _thread

def timedisplay(t):
  return t.strftime("%H:%M:%S")

def get(url):
  try:
    stime = datetime.now()
    start = time.time()
    response = requests.get(url)
    etime = datetime.now()
    end = time.time()
    elapsed = end-start
    sys.stderr.write("Status: " + str(response.status_code) + ", Start: " + timedisplay(stime) + ", End: " + timedisplay(etime) + ", Waktu Berlalu: " + str(elapsed)+"\n")
    sys.stdout.flush()
  except Exception as myexception:
    sys.stderr.write("Pengecualian: " + str(myexception)+"\n")
    sys.stdout.flush()

time.sleep(30)

while True:
  sc = int(datetime.now().strftime('%S'))
  time_range = [0, 20, 40]

  if sc not in time_range:
    time.sleep(1)
    continue

  sys.stderr.write("\n----------Info----------\n")
  sys.stdout.flush()

  # Kirim 10 permintaan secara paralel
  for i in range(10):
    _thread.start_new_thread(get, ("http://circuit-breaker-sample-server:9080/hello", ))

  time.sleep(2)

    Menyebarkan aplikasi sampel

    1. Buat file YAML dengan konten berikut lalu jalankan perintah kubectl apply -f ${nama file YAML}.yaml untuk menyebarkan aplikasi sampel.

      Tampilkan kode YAML

      ##################################################################################################
#  layanan circuit-breaker-sample-server
##################################################################################################
apiVersion: v1
kind: Service
metadata:
  name: circuit-breaker-sample-server
  labels:
    app: circuit-breaker-sample-server
    service: circuit-breaker-sample-server
spec:
  ports:
  - port: 9080
    name: http
  selector:
    app: circuit-breaker-sample-server
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: circuit-breaker-sample-server
  labels:
    app: circuit-breaker-sample-server
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: circuit-breaker-sample-server
      version: v1
  template:
    metadata:
      labels:
        app: circuit-breaker-sample-server
        version: v1
    spec:
      containers:
      - name: circuit-breaker-sample-server
        image: registry.cn-hangzhou.aliyuncs.com/acs/istio-samples:circuit-breaker-sample-server.v1
        imagePullPolicy: Always
        ports:
        - containerPort: 9080
---
##################################################################################################
#  layanan circuit-breaker-sample-client
##################################################################################################
apiVersion: apps/v1
kind: Deployment
metadata:
  name: circuit-breaker-sample-client
  labels:
    app: circuit-breaker-sample-client
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: circuit-breaker-sample-client
      version: v1
  template:
    metadata:
      labels:
        app: circuit-breaker-sample-client
        version: v1
    spec:
      containers:
      - name: circuit-breaker-sample-client
        image: registry.cn-hangzhou.aliyuncs.com/acs/istio-samples:circuit-breaker-sample-client.v1
        imagePullPolicy: Always

    2. Jalankan perintah berikut untuk melihat pod klien dan server:

      kubectl get po |grep circuit

      Output yang diharapkan:

      circuit-breaker-sample-client-d4f64d66d-fwrh4   2/2     Running   0             1m22s
circuit-breaker-sample-server-6d6ddb4b-gcthv    2/2     Running   0             1m22s

    Jika tidak ada batasan yang didefinisikan dalam aturan tujuan, server dapat menangani 10 permintaan bersamaan dari klien. Oleh karena itu, kode respons yang dikembalikan oleh server selalu 200. Blok kode berikut menunjukkan log klien:

    ----------Info----------
Status: 200, Start: 02:39:20, End: 02:39:25, Waktu Berlalu: 5.016539812088013
Status: 200, Start: 02:39:20, End: 02:39:25, Waktu Berlalu: 5.012614488601685
Status: 200, Start: 02:39:20, End: 02:39:25, Waktu Berlalu: 5.015984535217285
Status: 200, Start: 02:39:20, End: 02:39:25, Waktu Berlalu: 5.015599012374878
Status: 200, Start: 02:39:20, End: 02:39:25, Waktu Berlalu: 5.012874364852905
Status: 200, Start: 02:39:20, End: 02:39:25, Waktu Berlalu: 5.018714904785156
Status: 200, Start: 02:39:20, End: 02:39:25, Waktu Berlalu: 5.010422468185425
Status: 200, Start: 02:39:20, End: 02:39:25, Waktu Berlalu: 5.012431621551514
Status: 200, Start: 02:39:20, End: 02:39:25, Waktu Berlalu: 5.011001348495483
Status: 200, Start: 02:39:20, End: 02:39:25, Waktu Berlalu: 5.01432466506958

    Konfigurasikan kolom connectionPool

    Untuk mengaktifkan pemutusan sirkuit untuk layanan tujuan menggunakan teknologi mesh layanan, cukup definisikan aturan tujuan yang sesuai untuk layanan tersebut.

    Gunakan konten berikut untuk membuat aturan tujuan untuk layanan tujuan sampel. Untuk informasi lebih lanjut, lihat Kelola aturan tujuan. Aturan tujuan ini membatasi jumlah koneksi TCP ke layanan tujuan menjadi 5.

    apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: circuit-breaker-sample-server
spec:
  host: circuit-breaker-sample-server
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 5

    Skenario 1: Satu pod klien dan satu pod untuk layanan tujuan

    1. Mulai pod klien dan pantau log.

      Disarankan untuk memulai ulang klien guna mendapatkan hasil statistik yang lebih intuitif. Log berikut dapat diamati:

      ----------Info----------
Status: 200, Start: 02:49:40, End: 02:49:45, Waktu Berlalu: 5.0167787075042725
Status: 200, Start: 02:49:40, End: 02:49:45, Waktu Berlalu: 5.011920690536499
Status: 200, Start: 02:49:40, End: 02:49:45, Waktu Berlalu: 5.017078161239624
Status: 200, Start: 02:49:40, End: 02:49:45, Waktu Berlalu: 5.018405437469482
Status: 200, Start: 02:49:40, End: 02:49:45, Waktu Berlalu: 5.018689393997192
Status: 200, Start: 02:49:40, End: 02:49:50, Waktu Berlalu: 10.018936395645142
Status: 200, Start: 02:49:40, End: 02:49:50, Waktu Berlalu: 10.016417503356934
Status: 200, Start: 02:49:40, End: 02:49:50, Waktu Berlalu: 10.019930601119995
Status: 200, Start: 02:49:40, End: 02:49:50, Waktu Berlalu: 10.022735834121704
Status: 200, Start: 02:49:40, End: 02:49:55, Waktu Berlalu: 15.02303147315979

      Log menunjukkan bahwa semua permintaan berhasil. Namun, hanya lima permintaan dalam setiap batch yang direspons dalam waktu sekitar 5 detik. Permintaan lainnya direspons dalam 10 detik atau lebih. Ini menunjukkan bahwa penggunaan hanya tcp.maxConnections menghasilkan permintaan berlebih yang diantrekan, menunggu koneksi dibebaskan. Secara default, jumlah permintaan yang dapat diantrekan adalah 2³² - 1.

    2. Gunakan konten berikut untuk memperbarui aturan tujuan agar hanya memungkinkan satu permintaan tertunda. Untuk informasi lebih lanjut, lihat Kelola aturan tujuan.

      Untuk mewujudkan pemutusan sirkuit (fail-fast), atur http.http1MaxPendingRequests untuk membatasi jumlah permintaan yang dapat diantrekan. Nilai default parameter http1MaxPendingRequests adalah 1024. Jika nilainya diatur menjadi 0, maka akan kembali ke nilai default. Oleh karena itu, atur nilainya setidaknya menjadi 1.

      apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: circuit-breaker-sample-server
spec:
  host: circuit-breaker-sample-server
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 5
      http:
        http1MaxPendingRequests: 1

    3. Mulai ulang pod klien untuk mendapatkan statistik yang benar dan pantau log.

      Log sampel:

      ----------Info----------
Status: 503, Start: 02:56:40, End: 02:56:40, Waktu Berlalu: 0.005339622497558594
Status: 503, Start: 02:56:40, End: 02:56:40, Waktu Berlalu: 0.007254838943481445
Status: 503, Start: 02:56:40, End: 02:56:40, Waktu Berlalu: 0.0044133663177490234
Status: 503, Start: 02:56:40, End: 02:56:40, Waktu Berlalu: 0.008964776992797852
Status: 200, Start: 02:56:40, End: 02:56:45, Waktu Berlalu: 5.018309116363525
Status: 200, Start: 02:56:40, End: 02:56:45, Waktu Berlalu: 5.017424821853638
Status: 200, Start: 02:56:40, End: 02:56:45, Waktu Berlalu: 5.019804954528809
Status: 200, Start: 02:56:40, End: 02:56:45, Waktu Berlalu: 5.01643180847168
Status: 200, Start: 02:56:40, End: 02:56:45, Waktu Berlalu: 5.025975227355957
Status: 200, Start: 02:56:40, End: 02:56:50, Waktu Berlalu: 10.01716136932373

      Log menunjukkan bahwa empat permintaan segera dibatasi, lima permintaan dikirim ke layanan tujuan, dan satu permintaan diantrekan.

    4. Jalankan perintah berikut untuk melihat jumlah koneksi aktif yang didirikan oleh proxy Istio klien dengan pod layanan tujuan:

      kubectl exec $(kubectl get pod --selector app=circuit-breaker-sample-client --output jsonpath='{.items[0].metadata.name}') -c istio-proxy -- curl -X POST http://localhost:15000/clusters | grep circuit-breaker-sample-server | grep cx_active

      Output yang diharapkan:

      outbound|9080||circuit-breaker-sample-server.default.svc.cluster.local::172.20.192.124:9080::cx_active::5

      Output menunjukkan bahwa lima koneksi aktif didirikan antara proxy Istio klien dan pod layanan tujuan.

    Skenario 2: Satu pod klien dan beberapa pod untuk layanan tujuan

    Bagian ini memverifikasi apakah batas koneksi diterapkan pada tingkat pod atau tingkat layanan. Anggaplah ada satu pod klien dan tiga pod untuk layanan tujuan.

    • Jika batas koneksi diterapkan pada tingkat pod, setiap pod layanan tujuan memiliki maksimal lima koneksi.

      Dalam hal ini, tidak ada pembatasan atau pengantrean yang diamati karena jumlah koneksi maksimum yang diizinkan adalah 15 (3 pod dikalikan dengan 5 koneksi per pod). Karena hanya 10 permintaan yang dikirim sekaligus, semua permintaan harus berhasil dan direspons dalam waktu sekitar 5 detik.

    • Jika batas koneksi diterapkan pada tingkat layanan, tidak peduli berapa banyak pod yang berjalan untuk layanan tujuan, total maksimum lima koneksi yang diizinkan.

      Dalam hal ini, empat permintaan segera dibatasi, lima permintaan dikirim ke layanan tujuan, dan satu permintaan diantrekan.

    1. Jalankan perintah berikut untuk menskalakan penyebaran layanan tujuan menjadi tiga replika:

      kubectl scale deployment/circuit-breaker-sample-server  --replicas=3

    2. Mulai ulang pod klien dan pantau log.

      Log sampel:

      ----------Info----------
Status: 503, Start: 03:06:20, End: 03:06:20, Waktu Berlalu: 0.011791706085205078
Status: 503, Start: 03:06:20, End: 03:06:20, Waktu Berlalu: 0.0032286643981933594
Status: 503, Start: 03:06:20, End: 03:06:20, Waktu Berlalu: 0.012153387069702148
Status: 503, Start: 03:06:20, End: 03:06:20, Waktu Berlalu: 0.011871814727783203
Status: 200, Start: 03:06:20, End: 03:06:25, Waktu Berlalu: 5.012892484664917
Status: 200, Start: 03:06:20, End: 03:06:25, Waktu Berlalu: 5.013102769851685
Status: 200, Start: 03:06:20, End: 03:06:25, Waktu Berlalu: 5.016939163208008
Status: 200, Start: 03:06:20, End: 03:06:25, Waktu Berlalu: 5.014261484146118
Status: 200, Start: 03:06:20, End: 03:06:25, Waktu Berlalu: 5.01246190071106
Status: 200, Start: 03:06:20, End: 03:06:30, Waktu Berlalu: 10.021712064743042

      Log menunjukkan pembatasan dan pengantrean serupa seperti yang ditunjukkan dalam blok kode sebelumnya, yang berarti meningkatkan jumlah instance layanan tujuan tidak meningkatkan batas koneksi untuk klien. Ini menunjukkan bahwa batas koneksi diterapkan pada tingkat layanan.

    3. Jalankan perintah berikut untuk melihat jumlah koneksi aktif yang didirikan oleh proxy Istio klien dengan pod layanan tujuan:

      kubectl exec $(kubectl get pod --selector app=circuit-breaker-sample-client --output jsonpath='{.items[0].metadata.name}') -c istio-proxy -- curl -X POST http://localhost:15000/clusters | grep circuit-breaker-sample-server | grep cx_active

      Output yang diharapkan:

      outbound|9080||circuit-breaker-sample-server.default.svc.cluster.local::172.20.192.124:9080::cx_active::2
outbound|9080||circuit-breaker-sample-server.default.svc.cluster.local::172.20.192.158:9080::cx_active::2
outbound|9080||circuit-breaker-sample-server.default.svc.cluster.local::172.20.192.26:9080::cx_active::2

      Output menunjukkan bahwa proxy Istio klien mendirikan dua koneksi aktif dengan setiap pod layanan tujuan. Total enam, bukan lima, koneksi didirikan. Seperti disebutkan dalam dokumentasi Envoy dan Istio, proxy memungkinkan beberapa toleransi dalam hal jumlah koneksi.

    Skenario 3: Beberapa pod klien dan satu pod untuk layanan tujuan

    1. Jalankan perintah berikut untuk menyesuaikan jumlah replika untuk layanan tujuan dan klien:

      kubectl scale deployment/circuit-breaker-sample-server --replicas=1 
kubectl scale deployment/circuit-breaker-sample-client --replicas=3

    2. Mulai ulang pod klien dan pantau log.

      Tampilkan log klien

      Klien 1

----------Info----------
Status: 503, Start: 03:10:40, End: 03:10:40, Waktu Berlalu: 0.008828878402709961
Status: 503, Start: 03:10:40, End: 03:10:40, Waktu Berlalu: 0.010806798934936523
Status: 503, Start: 03:10:40, End: 03:10:40, Waktu Berlalu: 0.012855291366577148
Status: 503, Start: 03:10:40, End: 03:10:40, Waktu Berlalu: 0.004465818405151367
Status: 503, Start: 03:10:40, End: 03:10:40, Waktu Berlalu: 0.007823944091796875
Status: 503, Start: 03:10:40, End: 03:10:40, Waktu Berlalu: 0.06221342086791992
Status: 503, Start: 03:10:40, End: 03:10:40, Waktu Berlalu: 0.06922149658203125
Status: 503, Start: 03:10:40, End: 03:10:40, Waktu Berlalu: 0.06859922409057617
Status: 200, Start: 03:10:40, End: 03:10:45, Waktu Berlalu: 5.015282392501831
Status: 200, Start: 03:10:40, End: 03:10:50, Waktu Berlalu: 9.378434181213379

Klien 2

----------Info----------
Status: 503, Start: 03:11:00, End: 03:11:00, Waktu Berlalu: 0.007795810699462891
Status: 503, Start: 03:11:00, End: 03:11:00, Waktu Berlalu: 0.00595545768737793
Status: 503, Start: 03:11:00, End: 03:11:00, Waktu Berlalu: 0.013380765914916992
Status: 503, Start: 03:11:00, End: 03:11:00, Waktu Berlalu: 0.004278898239135742
Status: 503, Start: 03:11:00, End: 03:11:00, Waktu Berlalu: 0.010999202728271484
Status: 200, Start: 03:11:00, End: 03:11:05, Waktu Berlalu: 5.015426874160767
Status: 200, Start: 03:11:00, End: 03:11:05, Waktu Berlalu: 5.0184690952301025
Status: 200, Start: 03:11:00, End: 03:11:05, Waktu Berlalu: 5.019806146621704
Status: 200, Start: 03:11:00, End: 03:11:05, Waktu Berlalu: 5.0175628662109375
Status: 200, Start: 03:11:00, End: 03:11:05, Waktu Berlalu: 5.031521558761597

Klien 3

----------Info----------
Status: 503, Start: 03:13:20, End: 03:13:20, Waktu Berlalu: 0.012019157409667969
Status: 503, Start: 03:13:20, End: 03:13:20, Waktu Berlalu: 0.012546539306640625
Status: 503, Start: 03:13:20, End: 03:13:20, Waktu Berlalu: 0.013760805130004883
Status: 503, Start: 03:13:20, End: 03:13:20, Waktu Berlalu: 0.014089822769165039
Status: 503, Start: 03:13:20, End: 03:13:20, Waktu Berlalu: 0.014792442321777344
Status: 503, Start: 03:13:20, End: 03:13:20, Waktu Berlalu: 0.015463829040527344
Status: 503, Start: 03:13:20, End: 03:13:20, Waktu Berlalu: 0.01661539077758789
Status: 200, Start: 03:13:20, End: 03:13:20, Waktu Berlalu: 0.02904224395751953
Status: 200, Start: 03:13:20, End: 03:13:20, Waktu Berlalu: 0.03912043571472168
Status: 200, Start: 03:13:20, End: 03:13:20, Waktu Berlalu: 0.06436014175415039

      Log menunjukkan bahwa jumlah kesalahan 503 pada setiap klien meningkat. Sistem hanya mengizinkan lima permintaan bersamaan dari ketiga pod klien.

    3. Lihat log proxy klien.

      Tampilkan log proxy klien

      {"authority":"circuit-breaker-sample-server:9080","bytes_received":"0","bytes_sent":"81","downstream_local_address":"192.168.142.207:9080","downstream_remote_address":"172.20.192.31:44610","duration":"0","istio_policy_status":"-","method":"GET","path":"/hello","protocol":"HTTP/1.1","request_id":"d9d87600-cd01-421f-8a6f-dc0ee0ac8ccd","requested_server_name":"-","response_code":"503","response_flags":"UO","route_name":"default","start_time":"2023-02-28T03:14:00.095Z","trace_id":"-","upstream_cluster":"outbound|9080||circuit-breaker-sample-server.default.svc.cluster.local","upstream_host":"-","upstream_local_address":"-","upstream_service_time":"-","upstream_transport_failure_reason":"-","user_agent":"python-requests/2.21.0","x_forwarded_for":"-"}

{"authority":"circuit-breaker-sample-server:9080","bytes_received":"0","bytes_sent":"81","downstream_local_address":"192.168.142.207:9080","downstream_remote_address":"172.20.192.31:43294","duration":"58","istio_policy_status":"-","method":"GET","path":"/hello","protocol":"HTTP/1.1","request_id":"931d080a-3413-4e35-91f4-0c906e7ee565","requested_server_name":"-","response_code":"503","response_flags":"URX","route_name":"default","start_time":"2023-02-28T03:12:20.995Z","trace_id":"-","upstream_cluster":"outbound|9080||circuit-breaker-sample-server.default.svc.cluster.local","upstream_host":"172.20.192.84:9080","upstream_local_address":"172.20.192.31:58742","upstream_service_time":"57","upstream_transport_failure_reason":"-","user_agent":"python-requests/2.21.0","x_forwarded_for":"-"}

      Anda dapat melihat dua jenis log berbeda untuk permintaan yang dibatasi. Kode kesalahan 503 dikembalikan untuk permintaan tersebut. Log menunjukkan bahwa bidang RESPONSE_FLAGS memiliki dua nilai: UO dan URX.

      • UO: menunjukkan limpahan upstream (pemutusan sirkuit).

      • URX: menunjukkan bahwa permintaan ditolak karena kondisi pengulangan untuk permintaan HTTP upstream tidak terpenuhi atau jumlah maksimum percobaan koneksi TCP telah tercapai.

      Berdasarkan nilai bidang lainnya dalam log, seperti DURATION, UPSTREAM_HOST, dan UPSTREAM_CLUSTER, kita dapat menyimpulkan lebih lanjut sebagai berikut:

      Permintaan dengan flag UO dibatasi secara lokal oleh proxy klien, dan permintaan dengan flag URX ditolak oleh proxy layanan tujuan.

    4. Verifikasi kebenaran kesimpulan pada langkah sebelumnya dan periksa log proxy layanan tujuan.

      Tampilkan log proxy layanan tujuan

      {"authority":"circuit-breaker-sample-server:9080","bytes_received":"0","bytes_sent":"81","downstream_local_address":"172.20.192.84:9080","downstream_remote_address":"172.20.192.31:59510","duration":"0","istio_policy_status":"-","method":"GET","path":"/hello","protocol":"HTTP/1.1","request_id":"7684cbb0-8f1c-44bf-b591-40c3deff6b0b","requested_server_name":"outbound_.9080_._.circuit-breaker-sample-server.default.svc.cluster.local","response_code":"503","response_flags":"UO","route_name":"default","start_time":"2023-02-28T03:14:00.095Z","trace_id":"-","upstream_cluster":"inbound|9080||","upstream_host":"-","upstream_local_address":"-","upstream_service_time":"-","upstream_transport_failure_reason":"-","user_agent":"python-requests/2.21.0","x_forwarded_for":"-"}
{"authority":"circuit-breaker-sample-server:9080","bytes_received":"0","bytes_sent":"81","downstream_local_address":"172.20.192.84:9080","downstream_remote_address":"172.20.192.31:58218","duration":"0","istio_policy_status":"-","method":"GET","path":"/hello","protocol":"HTTP/1.1","request_id":"2aa351fa-349d-4283-a5ea-dc74ecbdff8c","requested_server_name":"outbound_.9080_._.circuit-breaker-sample-server.default.svc.cluster.local","response_code":"503","response_flags":"UO","route_name":"default","start_time":"2023-02-28T03:12:20.996Z","trace_id":"-","upstream_cluster":"inbound|9080||","upstream_host":"-","upstream_local_address":"-","upstream_service_time":"-","upstream_transport_failure_reason":"-","user_agent":"python-requests/2.21.0","x_forwarded_for":"-"}

      Seperti yang diharapkan, kode respons 503 muncul dalam log proxy layanan tujuan. Itulah alasan mengapa log proxy klien berisi "response_code":"503" dan "response_flags":"URX".

    Secara keseluruhan, proxy klien mengirimkan permintaan sesuai dengan batas bahwa hingga lima koneksi diizinkan untuk setiap pod, dan membatasi atau mengantrekan permintaan berlebih menggunakan flag respons UO. Ketiga proxy klien dapat mengirimkan hingga 15 permintaan paralel di awal batch. Namun, hanya lima permintaan yang dapat berhasil dikirim karena proxy layanan tujuan juga membatasi jumlah koneksi menjadi lima. Proxy layanan tujuan hanya menerima lima permintaan dan membatasi sisanya. Permintaan yang dibatasi ditandai oleh flag URX dalam log proxy klien.

    Gambar berikut menunjukkan bagaimana permintaan dikirim dari beberapa pod klien ke satu pod layanan tujuan dalam skenario sebelumnya.

    Skenario 4: Beberapa pod untuk klien dan layanan tujuan

    Saat meningkatkan jumlah replika layanan tujuan, tingkat keberhasilan keseluruhan permintaan naik karena setiap proxy layanan tujuan mengizinkan lima permintaan paralel. Dengan cara ini, pembatasan pada proxy klien dan proxy layanan tujuan dapat diamati.

    1. Jalankan perintah berikut untuk meningkatkan jumlah replika layanan tujuan menjadi 2 dan jumlah replika klien menjadi 3:

      kubectl scale deployment/circuit-breaker-sample-server --replicas=2
kubectl scale deployment/circuit-breaker-sample-client --replicas=3

      Anda dapat melihat bahwa 10 permintaan berhasil dari total 30 permintaan yang dihasilkan oleh semua 3 proxy klien dalam satu batch.

    2. Jalankan perintah berikut untuk meningkatkan jumlah replika layanan tujuan menjadi 3:

      kubectl scale deployment/circuit-breaker-sample-server --replicas=3

      Anda dapat melihat bahwa 15 permintaan berhasil.

    3. Jalankan perintah berikut untuk meningkatkan jumlah replika layanan tujuan menjadi 4:

      kubectl scale deployment/circuit-breaker-sample-server --replicas=3

      Setelah jumlah replika layanan tujuan ditingkatkan dari 3 menjadi 4, Anda masih melihat hanya 15 permintaan yang berhasil. Batas pada proxy klien berlaku untuk seluruh layanan tujuan tanpa memperhatikan jumlah replika yang dimiliki layanan tujuan. Oleh karena itu, terlepas dari jumlah replika yang dimiliki layanan tujuan, setiap proxy klien dapat mengirimkan maksimal lima permintaan bersamaan ke layanan tujuan.

    Operasi terkait

    Lihat metrik terkait pemutusan sirkuit kolam koneksi

    Pemutusan sirkuit kolam koneksi diimplementasikan dengan membatasi jumlah maksimum koneksi TCP ke host tujuan. Saat pemutusan sirkuit terjadi, serangkaian metrik terkait dihasilkan. Metrik ini membantu Anda menentukan apakah pemutusan sirkuit terjadi. Tabel berikut menjelaskan beberapa metrik.

    Metrik

    Tipe

    Deskripsi

    envoy_cluster_circuit_breakers_default_cx_open

    Gauge

    Menunjukkan apakah pemutusan sirkuit dipicu untuk kolam koneksi. Nilai 1 menunjukkan bahwa pemutusan sirkuit dipicu. Nilai 0 menunjukkan bahwa pemutusan sirkuit tidak dipicu.

    envoy_cluster_circuit_breakers_default_rq_pending_open

    Gauge

    Menunjukkan apakah jumlah permintaan yang akan diantrekan saat menunggu koneksi kolam koneksi siap telah melebihi nilai yang diberikan. Nilainya adalah 1 jika jumlah permintaan telah melebihi nilai yang diberikan. Nilainya adalah 0 jika jumlah permintaan belum melebihi nilai yang diberikan.

    Anda dapat mengonfigurasi proxyStatsMatcher untuk proxy sidecar untuk mengaktifkan proxy sidecar melaporkan metrik terkait pemutusan sirkuit. Kemudian, Anda dapat menggunakan Prometheus untuk mengumpulkan dan melihat metrik tersebut.

    1. Konfigurasikan proxyStatsMatcher untuk mengaktifkan proxy sidecar melaporkan metrik terkait pemutusan sirkuit. Setelah memilih proxyStatsMatcher, pilih Regular Expression Match dan atur nilainya menjadi .*circuit_breaker.*. Untuk informasi lebih lanjut, lihat Konfigurasikan proxyStatsMatcher.

    2. Redeploy Deployment untuk circuit-breaker-sample-server dan circuit-breaker-sample-client. Untuk informasi lebih lanjut, lihat Redeploy workloads.

    3. Lengkapi konfigurasi pemutusan sirkuit kolam koneksi dan lakukan pengujian permintaan dengan mengikuti langkah-langkah sebelumnya.

    4. Jalankan perintah berikut untuk melihat metrik terkait pemutusan sirkuit kolam koneksi untuk layanan circuit-breaker-sample-client:

      kubectl exec -it deploy/circuit-breaker-sample-client -c istio-proxy -- curl localhost:15090/stats/prometheus | grep circuit_breaker | grep circuit-breaker-sample-server

      Output yang diharapkan:

      kubectl exec -it deploy/circuit-breaker-sample-client -c istio-proxy -- curl localhost:15090/stats/prometheus | grep circuit_breaker | grep circuit-breaker-sample-server
envoy_cluster_circuit_breakers_default_cx_open{cluster_name="outbound|9080||circuit-breaker-sample-server.default.svc.cluster.local"} 1
envoy_cluster_circuit_breakers_default_cx_pool_open{cluster_name="outbound|9080||circuit-breaker-sample-server.default.svc.cluster.local"} 0
envoy_cluster_circuit_breakers_default_remaining_cx{cluster_name="outbound|9080||circuit-breaker-sample-server.default.svc.cluster.local"} 0
envoy_cluster_circuit_breakers_default_remaining_cx_pools{cluster_name="outbound|9080||circuit-breaker-sample-server.default.svc.cluster.local"} 18446744073709551613
envoy_cluster_circuit_breakers_default_remaining_pending{cluster_name="outbound|9080||circuit-breaker-sample-server.default.svc.cluster.local"} 1
envoy_cluster_circuit_breakers_default_remaining_retries{cluster_name="outbound|9080||circuit-breaker-sample-server.default.svc.cluster.local"} 4294967295
envoy_cluster_circuit_breakers_default_remaining_rq{cluster_name="outbound|9080||circuit-breaker-sample-server.default.svc.cluster.local"} 4294967295
envoy_cluster_circuit_breakers_default_rq_open{cluster_name="outbound|9080||circuit-breaker-sample-server.default.svc.cluster.local"} 0
envoy_cluster_circuit_breakers_default_rq_pending_open{cluster_name="outbound|9080||circuit-breaker-sample-server.default.svc.cluster.local"} 0
envoy_cluster_circuit_breakers_default_rq_retry_open{cluster_name="outbound|9080||circuit-breaker-sample-server.default.svc.cluster.local"} 0
envoy_cluster_circuit_breakers_high_cx_open{cluster_name="outbound|9080||circuit-breaker-sample-server.default.svc.cluster.local"} 0
envoy_cluster_circuit_breakers_high_cx_pool_open{cluster_name="outbound|9080||circuit-breaker-sample-server.default.svc.cluster.local"} 0
envoy_cluster_circuit_breakers_high_rq_open{cluster_name="outbound|9080||circuit-breaker-sample-server.default.svc.cluster.local"} 0
envoy_cluster_circuit_breakers_high_rq_pending_open{cluster_name="outbound|9080||circuit-breaker-sample-server.default.svc.cluster.local"} 0
envoy_cluster_circuit_breakers_high_rq_retry_open{cluster_name="outbound|9080||circuit-breaker-sample-server.default.svc.cluster.local"} 0

    Konfigurasikan pengumpulan metrik dan peringatan untuk pemutusan sirkuit kolam koneksi

    Setelah mengonfigurasi metrik terkait pemutusan sirkuit kolam koneksi, Anda dapat mengonfigurasi pengfigurasi untuk mengumpulkan metrik ke Prometheus dan menetapkan aturan peringatan berdasarkan metrik utama. Dengan cara ini, peringatan dapat dihasilkan saat pemutusan sirkuit terjadi. Bagian berikut mendemonstrasikan cara mengonfigurasi pengumpulan metrik dan peringatan untuk pemutusan sirkuit kolam koneksi. Dalam contoh ini, Managed Service for Prometheus digunakan.

    1. Dalam Managed Service for Prometheus, Anda dapat menghubungkan kluster pada data plane ke komponen Alibaba Cloud ASM atau meningkatkan komponen ke versi terbaru. Ini memastikan bahwa metrik terkait pemutusan sirkuit yang diekspos dapat dikumpulkan oleh Managed Service for Prometheus. Untuk informasi lebih lanjut tentang cara mengintegrasikan komponen ke ARMS, lihat Kelola komponen. (Jika Anda telah mengonfigurasi instance Prometheus yang dikelola sendiri untuk mengumpulkan metrik instance ASM dengan merujuk ke Pantau instance ASM menggunakan instance Prometheus yang dikelola sendiri, Anda tidak perlu melakukan langkah ini.)

    2. Buat aturan peringatan untuk pemutusan sirkuit kolam koneksi. Untuk informasi lebih lanjut, lihat Gunakan pernyataan PromQL kustom untuk membuat aturan peringatan. Contoh berikut mendemonstrasikan cara menentukan parameter utama untuk mengonfigurasi aturan peringatan. Untuk informasi lebih lanjut tentang cara mengonfigurasi parameter lainnya, lihat dokumentasi sebelumnya.

    Parameter

    Contoh

    Deskripsi

    Pernyataan PromQL Kustom

    (sum by(cluster_name, pod_name,namespace) (envoy_cluster_circuit_breakers_default_cx_open)) != 0

    Dalam contoh, metrik envoy_cluster_circuit_breakers_default_cx_open diquery untuk menentukan apakah pemutusan sirkuit sedang terjadi di kolam koneksi kluster saat ini. Berdasarkan nama host layanan upstream dan nama pod yang melaporkan metrik, Anda dapat menentukan lokasi di mana pemutusan sirkuit terjadi.

    Pesan Peringatan

    Pemutusan sirkuit terjadi untuk kolam koneksi. Jumlah koneksi TCP yang didirikan oleh proxy sidecar telah mencapai batas atas. Namespace: {{$labels.namespace}}, Pod tempat pemutusan sirkuit untuk kolam koneksi terjadi:{{$labels.pod_name}}, Informasi tentang layanan upstream: {{ $labels.cluster_name }}

    Informasi peringatan dalam contoh menunjukkan pod tempat pemutusan sirkuit untuk kolam koneksi terjadi, layanan upstream ke mana pod tersebut terhubung, dan namespace ke mana pod tersebut milik.

    Batasan pada konfigurasi kolam koneksi

    Tabel berikut menjelaskan batasan pada konfigurasi kolom connectionPool pada klien dan layanan tujuan.

    Peran

    Deskripsi

    Klien

    Setiap proxy klien menerapkan batas secara independen. Jika batas jumlah permintaan adalah 100, setiap proxy klien dapat memiliki 100 permintaan yang tertunda sebelum pembatasan lokal diterapkan. Jika N klien memanggil layanan tujuan, jumlah maksimum permintaan tertunda yang didukung adalah hasil kali 100 dan N.

    Batas pada proxy klien berlaku untuk seluruh layanan tujuan, bukan untuk satu replika layanan tujuan. Bahkan jika layanan tujuan berjalan dalam 200 pod aktif, maksimal 100 permintaan diizinkan.

    Layanan tujuan

    Batas berlaku untuk setiap proxy layanan tujuan. Jika layanan berjalan dalam 50 pod aktif, setiap pod dapat memiliki hingga 100 permintaan tertunda yang dikirim dari proxy klien sebelum pembatasan dipicu dan kode respons 503 dikembalikan.