Ketika layanan downstream merespons secara lambat atau mengembalikan error dengan tingkat tinggi, kegagalan tersebut dapat berantai dan menurunkan kinerja seluruh aplikasi Anda. Pemutusan sirkuit di Microservices Engine (MSE) memantau dependensi downstream ini dan secara otomatis menghentikan pengiriman permintaan ketika ambang batas yang dikonfigurasi terlampaui. Setelah periode pendinginan berakhir, MSE melakukan probing pemulihan dengan secara bertahap mengizinkan permintaan kembali.
Pemutusan sirkuit ditujukan untuk dependensi lemah—layanan downstream yang dapat ditoleransi oleh aplikasi Anda saat tidak tersedia sementara. Untuk dependensi kritis yang kegagalannya harus segera dipropagasikan, gunakan strategi retry atau fallback sebagai gantinya.
Cara kerja
Pemutus sirkuit beralih di antara tiga status:
Closed (operasi normal)—Semua permintaan dilewatkan. MSE melacak metrik (rasio panggilan lambat atau rasio error) dalam jendela waktu yang dikonfigurasi.
Open (sirkuit terpicu)—Ketika metrik yang dilacak melebihi ambang batas yang dikonfigurasi dan jumlah minimum permintaan terpenuhi, MSE memblokir semua permintaan selama durasi yang dikonfigurasi. Permintaan yang diblokir gagal alih-alih menunggu timeout.
Half-open (probing pemulihan)—Setelah durasi pemutusan sirkuit berakhir, MSE mengizinkan permintaan berikutnya sebagai uji coba:
Jika permintaan uji berhasil, pemutus sirkuit kembali ke status Closed.
Jika permintaan uji gagal, pemutus sirkuit kembali ke status Open selama durasi penuh berikutnya.
MSE juga mendukung progressive recovery, yang secara bertahap meningkatkan persentase permintaan yang diizinkan melalui beberapa tahap alih-alih mengandalkan satu permintaan uji saja.
Prasyarat
Sebelum memulai, pastikan Anda telah:
Mengaktifkan MSE Edisi Perusahaan.
Mengaktifkan Microservices Governance untuk aplikasi Anda. Untuk petunjuk penyiapan, lihat:
Buat aturan pemutusan sirkuit
-
Masuk ke Konsol MSE, lalu pilih Wilayah di bilah navigasi atas.
-
Di panel navigasi kiri, pilih Microservices Governance > Application Governance.
Pada halaman Application list, klik aplikasi target. Lalu buka kotak dialog Add Circuit Breaking Rule melalui salah satu jalur berikut:
Jalur A: Di panel navigasi kiri, klik API Details. Pada tab WEB service, klik tab Client. Pilih antarmuka, klik tab Circuit Breaking, lalu klik Added fusing rule.
Jalur B: Di panel navigasi kiri, klik Traffic management. Klik tab Flow protection, lalu klik tab Fuse rule, dan kemudian klik Added fusing rule.
Pada kotak dialog Add Circuit Breaking Rule, konfigurasikan parameter berikut lalu klik New.
Parameter aturan
| Parameter | Deskripsi | Nilai valid |
|---|---|---|
| Interface name | Antarmuka yang akan dilindungi oleh aturan ini. | -- |
| Statistical window duration | Durasi jendela waktu yang digunakan untuk menghitung metrik. | 1 detik hingga 120 menit |
| Minimum number of requests | Jumlah minimum permintaan yang diperlukan dalam jendela waktu sebelum pemutusan sirkuit dapat dipicu. Jika jumlah permintaan aktual berada di bawah nilai ini, pemutus sirkuit tetap tertutup terlepas dari rasio metrik. | Bilangan bulat positif |
| Threshold Type | Metrik yang digunakan untuk mengevaluasi apakah sirkuit harus diputus. | Slow call ratio (%), Abnormal proportion (%) |
| Slow call RT | Ambang batas waktu respons (dalam milidetik) yang mendefinisikan panggilan lambat. Permintaan yang memakan waktu lebih lama dari nilai ini dihitung sebagai panggilan lambat. Hanya berlaku ketika Threshold Type diatur ke Slow call ratio (%). | Bilangan bulat positif (ms) |
| Circuit Breaking Ratio Threshold | Ambang batas persentase yang memicu pemutusan sirkuit. Untuk rasio panggilan lambat, ini adalah persentase panggilan lambat. Untuk proporsi abnormal, ini adalah persentase permintaan abnormal. | 0–100 (%) |
| Circuit Breaking Duration (s) | Lama waktu pemutus sirkuit tetap terbuka. Selama periode ini, semua permintaan ke antarmuka yang dilindungi gagal. | Bilangan bulat positif (detik) |
| Circuit Breaking Policy | Strategi pemulihan setelah durasi pemutusan sirkuit berakhir. | Single detection recovery, Progressive recovery |
Catatan: Parameter Statistical window duration dan Minimum number of requests bekerja bersama. Misalnya, mengatur jendela 1 detik dengan minimum 10 permintaan berarti antarmuka bertrafik rendah (kurang dari 10 permintaan per detik) tidak akan pernah memicu pemutus sirkuit. Untuk antarmuka bertrafik rendah, gunakan jendela yang lebih panjang dengan jumlah minimum permintaan yang lebih rendah.
Kebijakan pemulihan
Single detection recovery
Setelah durasi pemutusan sirkuit berakhir, MSE mengizinkan permintaan berikutnya sebagai probe uji:
Jika permintaan berhasil (waktu respons di bawah ambang batas Slow call RT atau tidak terjadi error), pemutus sirkuit menutup dan trafik normal dilanjutkan.
Jika permintaan gagal, pemutus sirkuit membuka kembali selama durasi penuh berikutnya.
Progressive recovery
Alih-alih menggunakan satu permintaan uji, MSE secara bertahap meningkatkan rasio trafik melalui beberapa tahap pemulihan. Hal ini mengurangi risiko sirkuit terpicu ulang segera setelah pemulihan.
Konfigurasikan dua parameter tambahan:
| Parameter | Deskripsi |
|---|---|
| Number of recovery phases | Jumlah tahap yang digunakan untuk meningkatkan trafik kembali ke 100%. |
| Minimum number of passes per step | Jumlah minimum permintaan dalam setiap tahap sebelum MSE mengevaluasi apakah akan melanjutkan ke tahap berikutnya. |
Persentase trafik yang diizinkan pada setiap tahap dihitung sebagai:
Traffic ratio = 100% / Number of recovery phases
Contohnya, dengan 3 tahap pemulihan dan minimum 5 permintaan per tahap:
| Tahap | Trafik yang diizinkan | Perilaku |
|---|---|---|
| 1 | 33% | MSE mengizinkan 33% permintaan dilewatkan. Setelah minimal 5 permintaan lolos, MSE memeriksa metrik. Jika di bawah ambang batas, lanjut ke Tahap 2. Jika di atas, pemutus sirkuit dibuka kembali. |
| 2 | 67% | MSE mengizinkan 67% permintaan dilewatkan. Evaluasi sama seperti Tahap 1. |
| 3 | 100% | Semua permintaan dilewatkan. Pemutus sirkuit sepenuhnya menutup. |
Jika jumlah permintaan dalam suatu tahap kurang dari jumlah minimum lolos per langkah, sistem masuk ke tahap pemulihan berikutnya hingga semua permintaan diizinkan dilewatkan.
Contoh
Pemutusan sirkuit berdasarkan panggilan lambat
Skenario: Aplikasi Anda memanggil layanan pihak ketiga yang kadang-kadang merespons secara lambat, menyebabkan timeout yang menurunkan kinerja aplikasi Anda.
Konfigurasi:
| Parameter | Nilai | Alasan |
|---|---|---|
| Interface name | test | Antarmuka yang memanggil layanan downstream lambat. |
| Statistical window duration | 1 detik | Mendeteksi degradasi dengan cepat. |
| Minimum number of requests | 10 | Menghindari pemicuan pada antarmuka bertrafik rendah. |
| Threshold Type | Slow call ratio (%) | Memantau waktu respons, bukan error. |
| Slow call RT | 1000 ms | Permintaan yang melebihi 1 detik dianggap sebagai panggilan lambat. |
| Circuit Breaking Ratio Threshold | 80% | Putuskan saat 80% permintaan mengalami kelambatan. |
| Circuit Breaking Duration (s) | 10 detik | Memblokir semua permintaan selama 10 detik. |
| Circuit Breaking Policy | Single detection recovery | Menguji satu permintaan setelah setiap periode pemutusan sirkuit. |
Perilaku: Jika lebih dari 10 permintaan tiba dalam 1 detik dan lebih dari 80% memakan waktu lebih dari 1.000 ms, pemutus sirkuit membuka. Semua permintaan ke antarmuka test gagal selama 10 detik berikutnya. Setelah 10 detik, MSE mengizinkan satu permintaan dilewatkan. Jika permintaan tersebut selesai dalam waktu kurang dari 1.000 ms, pemutus sirkuit menutup. Jika tidak, pemutus sirkuit membuka kembali selama 10 detik berikutnya.
Pemutusan sirkuit berdasarkan permintaan abnormal
Skenario: Aplikasi Anda menampilkan konten dari layanan pihak ketiga. Saat lonjakan permintaan abnormal terjadi, konten yang terdegradasi merusak pengalaman pengguna.
Konfigurasi:
| Parameter | Value | Rationale |
|---|---|---|
| Interface name | test | Antarmuka yang memanggil layanan downstream yang abnormal. |
| Statistical window duration | 1 second | Mendeteksi lonjakan permintaan abnormal secara cepat. |
| Minimum number of requests | 10 | Menghindari pemicuan pada antarmuka dengan traffic rendah. |
| Threshold Type | Abnormal proportion (%) | Memantau rasio permintaan abnormal. |
| Circuit Breaking Ratio Threshold | 80% | Memutus sirkuit ketika 80% permintaan bersifat abnormal. |
| Circuit Breaking Duration (s) | 10 seconds | Memblokir semua permintaan selama 10 detik. |
| Circuit Breaking Policy | Single detection recovery | Menguji satu permintaan setelah setiap periode pemutusan sirkuit. |
Perilaku: Jika lebih dari 10 permintaan tiba dalam 1 detik dan lebih dari 80% bersifat abnormal, pemutus sirkuit membuka. Semua permintaan ke antarmuka test gagal selama 10 detik berikutnya. Setelah 10 detik, MSE mengizinkan satu permintaan dilewatkan. Jika permintaan tersebut berhasil, pemutus sirkuit menutup. Jika tidak, pemutus sirkuit membuka kembali selama 10 detik berikutnya.
Praktik terbaik
Pilih jenis ambang batas yang tepat
Gunakan Slow call ratio ketika degradasi waktu respons menjadi perhatian utama, seperti panggilan API sinkron yang latensinya secara langsung memengaruhi pengalaman pengguna.
Gunakan Abnormal proportion ketika error downstream merupakan risiko utama, seperti panggilan ke layanan pihak ketiga yang tidak andal.
Tetapkan nilai jendela dan ambang batas yang sesuai
Statistical window: Jendela yang lebih pendek (1–10 detik) mendeteksi masalah lebih cepat tetapi lebih sensitif terhadap lonjakan trafik. Jendela yang lebih panjang (1–5 menit) memberikan sinyal yang lebih stabil untuk antarmuka bertrafik rendah.
Minimum number of requests: Tetapkan nilai ini cukup tinggi untuk menghindari false positive. Untuk antarmuka bertrafik rendah, minimum 5–10 permintaan dengan jendela yang lebih panjang biasanya lebih andal daripada 10 permintaan per detik.
Pilih kebijakan pemulihan
Single detection recovery cocok untuk layanan yang pulih secara bersih—mereka berfungsi atau tidak sama sekali.
Progressive recovery lebih aman untuk layanan yang mungkin hanya pulih sebagian. Ini mencegah banjir trafik mendadak yang dapat membebani layanan yang baru saja kembali online.
Verifikasi bahwa aturan aktif
Setelah Anda menyimpan aturan pemutusan sirkuit, pastikan aturan tersebut berfungsi sebagaimana mestinya:
Di panel navigasi kiri, klik Traffic management. Pada tab Flow protection, klik tab Fuse rule untuk melihat semua aturan yang dikonfigurasi beserta statusnya.
Hasilkan trafik uji ke antarmuka yang dilindungi dan pantau metrik pemutus sirkuit untuk memastikan aturan tersebut terpicu dengan benar.
Topik terkait
Konfigurasikan aturan pembatasan kecepatan untuk mengontrol laju permintaan selain pemutusan sirkuit.