Pola Desain Pemutus Sirkuit

Pola Circuit Breaker membantu menangani kesalahan yang mungkin membutuhkan waktu yang bervariasi untuk pulih dari saat aplikasi terhubung ke layanan atau sumber daya jarak jauh. Pemutus sirkuit untuk sementara memblokir akses ke layanan yang rusak setelah mendeteksi kegagalan. Tindakan ini mencegah upaya yang gagal berulang sehingga sistem dapat pulih secara efektif. Pola ini dapat meningkatkan stabilitas dan ketahanan aplikasi.

Konteks dan masalah

Di lingkungan terdistribusi, panggilan ke sumber daya dan layanan jarak jauh dapat gagal karena kesalahan sementara. Kesalahan sementara termasuk sumber daya yang terlalu dialokasikan atau sementara tidak tersedia, koneksi jaringan lambat, atau batas waktu habis. Kesalahan ini biasanya memperbaiki sendiri setelah waktu yang singkat. Untuk membantu mengelola kesalahan ini, Anda harus merancang aplikasi cloud untuk menggunakan strategi, seperti pola Coba Lagi.

Peristiwa yang tidak tertandingi dapat membuat kesalahan yang membutuhkan waktu lebih lama untuk diperbaiki. Kesalahan ini dapat berkisar dalam tingkat keparahan dari hilangnya sebagian konektivitas hingga kegagalan layanan lengkap. Dalam situasi ini, aplikasi seharusnya tidak terus mencoba kembali operasi yang tidak mungkin berhasil. Sebaliknya, aplikasi harus dengan cepat mengenali operasi yang gagal dan menangani kegagalan yang sesuai.

Jika layanan sibuk, kegagalan di salah satu bagian sistem dapat menyebabkan kegagalan berkala. Misalnya, Anda dapat mengonfigurasi operasi yang memanggil layanan untuk menerapkan waktu habis. Jika layanan gagal merespons dalam periode ini, operasi membalas dengan pesan kegagalan.

Namun, strategi ini dapat memblokir permintaan bersamaan ke operasi yang sama sampai periode waktu habis berakhir. Permintaan yang diblokir ini mungkin menyimpan sumber daya sistem penting, seperti memori, utas, dan koneksi database. Masalah ini dapat menghabiskan sumber daya, yang mungkin menggagalkan bagian lain yang tidak terkait dari sistem yang perlu menggunakan sumber daya yang sama.

Dalam situasi ini, operasi harus langsung gagal dan hanya mencoba memanggil layanan jika kemungkinan berhasil. Untuk mengatasi masalah ini, atur waktu habis yang lebih singkat. Namun, pastikan bahwa waktu habis cukup lama bagi operasi untuk berhasil pada sebagian besar waktu.

Solusi

Pola Circuit Breaker membantu mencegah aplikasi berulang kali mencoba menjalankan operasi yang kemungkinan gagal. Pola ini memungkinkan aplikasi untuk terus berjalan tanpa menunggu kesalahan diperbaiki atau membuang-buang siklus CPU untuk menentukan bahwa kesalahan tersebut persisten. Pola Circuit Breaker juga memungkinkan aplikasi mendeteksi kapan kesalahan diselesaikan. Jika kesalahan diselesaikan, aplikasi dapat mencoba memanggil operasi lagi.

Nota

Pola Circuit Breaker melayani tujuan yang berbeda dari pola Coba Lagi. Pola Coba Lagi memungkinkan aplikasi untuk mencoba kembali operasi dengan harapan bahwa itu akhirnya berhasil. Pola Circuit Breaker mencegah aplikasi melakukan operasi yang kemungkinan gagal. Sebuah aplikasi dapat menggabungkan kedua pola ini dengan menggunakan pola Retry untuk memanggil operasi melalui pemutus sirkuit. Namun, logika pengulangan harus sensitif terhadap pengecualian apa pun yang dikembalikan oleh pemutus sirkuit dan harus menghentikan upaya pengulangan jika pemutus sirkuit menunjukkan bahwa kesalahan tersebut tidak bersifat sementara.

Pemutus sirkuit bertindak sebagai perantara untuk operasi yang mungkin gagal. Proksi harus memantau jumlah kegagalan terbaru dan menggunakan informasi ini untuk memutuskan apakah akan memungkinkan operasi dilanjutkan atau segera mengembalikan pengecualian.

Anda dapat menerapkan proksi sebagai mesin status, yang menyertakan status-status berikut. Status-status ini meniru fungsionalitas pemutus sirkuit listrik:

• Ditutup: Permintaan dari aplikasi diarahkan ke operasi. Proksi menghitung jumlah kegagalan yang baru-baru terjadi. Jika panggilan ke operasi tidak berhasil, proksi akan menambah jumlah ini. Jika jumlah kegagalan terakhir melebihi ambang yang ditentukan dalam periode waktu tertentu, proksi ditempatkan ke dalam status Buka dan memulai pengatur waktu habis. Ketika timer kedaluwarsa, proksi ditempatkan ke dalam status Half-Open.

  Nota

  Selama waktu habis, sistem mencoba memperbaiki masalah yang menyebabkan kegagalan sebelum memungkinkan aplikasi untuk mencoba operasi lagi.

• Buka: Permintaan dari aplikasi segera gagal dan sebuah pengecualian dikembalikan ke aplikasi.

• Half-Open: Sejumlah permintaan terbatas dari aplikasi diizinkan untuk mengakses dan memanggil operasi. Jika permintaan ini berhasil, pemutus sirkuit mengasumsikan bahwa kesalahan yang menyebabkan kegagalan diperbaiki, dan pemutus sirkuit beralih ke status Tertutup. Penghitung kegagalan diatur ulang. Jika ada permintaan yang gagal, pemutus sirkuit mengasumsikan bahwa kesalahan masih ada, sehingga kembali ke status Terbuka. Ini memulai ulang timer time-out sehingga sistem dapat pulih dari kegagalan.

  Nota

  Status Setengah Terbuka membantu mencegah layanan yang sedang dalam pemulihan secara tiba-tiba dibanjiri permintaan. Saat layanan pulih, layanan mungkin dapat mendukung volume permintaan terbatas hingga pemulihan selesai. Tetapi saat pemulihan sedang berlangsung, banjir pekerjaan dapat menyebabkan layanan kehabisan waktu atau gagal lagi.

Diagram berikut menunjukkan operasi penghitung untuk setiap keadaan.

Diagram menunjukkan tiga bagian yang diberi label tertutup, setengah terbuka, dan terbuka. Status tertutup mencakup tindakan untuk mengatur ulang penghitung kegagalan. Jika operasi berhasil, operasi mengembalikan hasil, jika tidak, penghitung kegagalan kenaikan mengembalikan kegagalan. Status setengah terbuka mencakup tindakan untuk mengatur ulang penghitung keberhasilan. Jika operasi berhasil, penghitung keberhasilan kenaikan mengembalikan hasil, jika tidak, operasi akan mengembalikan kegagalan. Keadaan terbuka mencakup tindakan untuk memulai timer time-out lalu mengembalikan status kegagalan. Panah dari status tertutup ke terbuka menunjukkan bahwa ambang batas kegagalan telah tercapai. Panah dari status terbuka ke setengah terbuka menunjukkan bahwa timer telah habis waktu. Panah dari keadaan setengah terbuka ke tertutup menunjukkan bahwa ambang batas jumlah keberhasilan telah tercapai. Sebuah panah dari keadaan setengah terbuka ke terbuka menunjukkan bahwa operasi gagal.

Penghitung kegagalan untuk status Tertutup berbasis waktu. Ini secara otomatis direset pada interval berkala. Desain ini membantu mencegah pemutus sirkuit memasuki keadaan Terbuka jika mengalami kegagalan sesekali. Ambang kegagalan memicu status Buka hanya ketika jumlah kegagalan tertentu terjadi selama interval yang ditentukan.

Penghitung keberhasilan untuk status Half-Open mencatat jumlah upaya yang berhasil untuk memanggil operasi. Pemutus arus kembali ke status Tertutup setelah jumlah tertentu pemanggilan operasi berturut-turut yang berhasil. Jika ada pemanggilan yang gagal, pemutus arus segera memasuki status Open, dan penghitung keberhasilan mengatur ulang saat memasuki status Setengah Terbuka berikutnya.

Nota

Pemulihan sistem didasarkan pada operasi eksternal, seperti memulihkan atau memulai ulang komponen yang gagal atau memperbaiki koneksi jaringan.

Pola Pemutus Sirkuit memberikan stabilitas saat sistem pulih dari kegagalan dan meminimalkan dampak pada performa. Ini dapat membantu mempertahankan waktu respons sistem. Pola ini dengan cepat menolak permintaan untuk operasi yang kemungkinan besar akan gagal, daripada menunggu waktu operasi habis atau tidak pernah kembali. Jika pemutus sirkuit menghasilkan peristiwa setiap kali berubah keadaan, informasi ini dapat membantu memantau kesehatan komponen sistem yang dilindungi atau memperingatkan administrator saat pemutus sirkuit beralih ke keadaan Terbuka .

Anda dapat menyesuaikan dan adaptasikan pola ini dengan berbagai jenis kegagalan. Misalnya, Anda dapat menerapkan timer waktu habis yang meningkat ke pemutus sirkuit. Anda dapat menempatkan pemutus sirkuit dalam status Terbuka untuk beberapa detik pada awalnya. Jika kegagalan tidak diselesaikan, tambah batas waktu menjadi beberapa menit dan sesuaikan seperlunya. Dalam beberapa kasus, daripada mengembalikan kegagalan dan meningkatkan pengecualian, status Open dapat mengembalikan nilai default yang bermakna bagi aplikasi.

Nota

Secara tradisional, pemutus arus mengandalkan ambang batas yang telah dikonfigurasi sebelumnya, seperti jumlah kegagalan dan durasi waktu habis. Pendekatan ini menghasilkan perilaku deterministik tetapi kadang-kadang suboptimal.

Teknik adaptif yang menggunakan AI dan pembelajaran mesin dapat secara dinamis menyesuaikan ambang batas berdasarkan pola lalu lintas real time, anomali, dan tingkat kegagalan historis. Pendekatan ini meningkatkan ketahanan dan efisiensi.

Masalah dan pertimbangan

Pertimbangkan faktor-faktor berikut saat Anda menerapkan pola ini:

• penanganan pengecualian : Aplikasi yang memanggil operasi melalui pemutus sirkuit harus dapat menangani pengecualian jika operasi tidak tersedia. Manajemen pengecualian didasarkan pada aplikasi. Misalnya, aplikasi mungkin menurunkan fungsionalitasnya untuk sementara waktu, memanggil operasi alternatif untuk mencoba melakukan tugas yang sama atau mendapatkan data yang sama, atau melaporkan pengecualian kepada pengguna dan meminta mereka untuk mencoba lagi nanti.

• Jenis pengecualian: Alasan kegagalan permintaan dapat bervariasi dalam tingkat keparahan. Misalnya, permintaan mungkin gagal karena layanan jarak jauh mengalami crash dan memerlukan beberapa menit untuk pulih, atau karena layanan yang kelebihan beban menyebabkan waktu habis. Pemutus arus mungkin dapat memeriksa jenis pengecualian yang terjadi dan menyesuaikan strateginya berdasarkan sifat pengecualian ini. Misalnya, mungkin memerlukan sejumlah besar pengecualian waktu habis untuk memicu pemutus sirkuit ke status Terbuka dibandingkan dengan jumlah kegagalan yang disebabkan oleh layanan yang tidak tersedia.

• Pemantauan: Pemutus sirkuit harus memberikan pengamatan yang jelas terhadap permintaan yang gagal dan berhasil sehingga tim operasi dapat menilai kesehatan sistem. Gunakan pelacakan terdistribusi untuk visibilitas end-to-end di seluruh layanan.

• Recoverability: Anda harus mengonfigurasi pemutus sirkuit agar sesuai dengan pola pemulihan operasi yang mungkin dilindunginya. Misalnya, jika pemutus sirkuit tetap berada dalam status Buka untuk jangka waktu yang lama, pemutus sirkuit dapat memunculkan pengecualian bahkan jika alasan kegagalan diselesaikan. Demikian pula, pemutus sirkuit dapat berfluktuasi dan mengurangi waktu respons aplikasi jika beralih dari status Buka ke status Setengah Terbuka terlalu cepat.

• Pengujian operasi gagal: Dalam status Buka, daripada menggunakan timer untuk menentukan kapan harus beralih ke status Setengah Terbuka, pemutus sirkuit dapat secara berkala melakukan ping pada layanan jarak jauh atau sumber daya untuk menentukan apakah tersedia. Ping ini dapat mencoba memanggil operasi yang sebelumnya gagal atau menggunakan operasi pemeriksaan kesehatan khusus yang disediakan layanan jarak jauh. Untuk informasi selengkapnya, lihat pola Pemantauan Titik Akhir Kesehatan.

• Penimpaan manual: Jika waktu pemulihan untuk operasi yang gagal sangat bervariasi, Anda harus menyediakan opsi reset manual yang memungkinkan administrator menutup pemutus sirkuit dan mengatur ulang penghitung kegagalan. Demikian pula, administrator dapat memaksa pemutus sirkuit menjadi status Terbuka dan memulai ulang penghitung waktu habis jika operasi yang diproteksi sementara tidak tersedia.

• Konkurensi: Sejumlah besar instans aplikasi yang bersamaan dapat mengakses pemutus sirkuit yang sama. Implementasi tidak boleh memblokir permintaan yang bersamaan atau menambahkan overhead yang berlebihan untuk setiap panggilan ke operasi.

• Diferensiasi sumber daya: Berhati-hatilah saat Anda menggunakan pemutus arus tunggal untuk satu jenis sumber daya jika mungkin ada beberapa penyedia independen yang mendasar. Misalnya, di penyimpanan data yang berisi beberapa pecahan, satu pecahan mungkin dapat diakses sepenuhnya sementara yang lain mengalami masalah sementara. Jika respons kesalahan dalam skenario ini digabungkan, aplikasi mungkin mencoba mengakses beberapa pecahan bahkan ketika kegagalan kemungkinan besar. Dan akses ke pecahan lain mungkin diblokir meskipun kemungkinannya tinggi untuk berhasil.

• Pemutusan sirkuit yang dipercepat: Terkadang respons kegagalan dapat berisi informasi yang cukup bagi pemutus sirkuit untuk segera mati dan tetap terputus untuk durasi waktu minimum. Misalnya, respons kesalahan dari sumber daya bersama yang kelebihan beban dapat menunjukkan bahwa aplikasi harus mencoba lagi dalam beberapa menit, alih-alih segera mencoba kembali.

• Penyebaran multiregion: Anda dapat merancang pemutus sirkuit untuk penyebaran wilayah tunggal atau multiregion. Untuk merancang penyebaran multiregion, gunakan penyeimbang beban global atau strategi pemecahan masalah sirkuit sadar wilayah kustom yang membantu memastikan failover terkontrol, pengoptimalan latensi, dan kepatuhan terhadap peraturan.

• Pemutus arus pada mesh layanan: Anda dapat menerapkan pemutus sirkuit di lapisan aplikasi atau sebagai fitur lintas fungsional dan abstraksi. Misalnya, jala layanan sering mendukung pemutusan sirkuit sebagai sidecar atau sebagai kemampuan mandiri tanpa memodifikasi kode aplikasi.

  Nota

  Layanan dapat mengembalikan HTTP 429 (terlalu banyak permintaan) jika membatasi klien atau HTTP 503 (layanan tidak tersedia) jika layanan tidak tersedia. Respons dapat mencakup informasi lain, seperti durasi penundaan yang diantisipasi.

• Pemutaran ulang permintaan gagal: Dalam status Terbuka, daripada hanya gagal dengan cepat, pemutus sirkuit juga dapat merekam detail setiap permintaan ke jurnal dan mengatur agar permintaan ini diputar ulang ketika sumber daya atau layanan jarak jauh tersedia.

• Waktu habis yang tidak tepat pada layanan eksternal: Pemutus sirkuit mungkin tidak sepenuhnya melindungi aplikasi dari kegagalan dalam layanan eksternal yang memiliki periode waktu habis yang lama. Jika tenggang waktu terlalu lama, utas yang menjalankan pemutus sirkuit mungkin diblokir untuk waktu lama sebelum pemutus sirkuit menunjukkan kegagalan operasi. Selama waktu ini, banyak instans aplikasi lain mungkin juga mencoba memanggil layanan melalui pemutus sirkuit dan mengikat banyak utas sebelum semuanya gagal.

• Adaptabilitas terhadap diversifikasi komputasi: pemutus sirkuit harus memperhitungkan lingkungan komputasi yang berbeda, dari beban kerja tanpa server hingga kontainer, di mana faktor-faktor seperti mulai dingin dan skalabilitas memengaruhi penanganan kegagalan. Pendekatan adaptif dapat secara dinamis menyesuaikan strategi berdasarkan jenis komputasi, yang membantu memastikan ketahanan di seluruh arsitektur heterogen.

Kapan menggunakan pola ini

Gunakan pola ini ketika:

• Anda ingin mencegah kegagalan berkala dengan menghentikan panggilan layanan jarak jauh yang berlebihan atau permintaan akses ke sumber daya bersama jika operasi ini kemungkinan gagal.

• Anda ingin merutekan lalu lintas dengan cerdas berdasarkan sinyal kegagalan real-time untuk meningkatkan ketahanan antarwilayah.

• Anda ingin melindungi terhadap dependensi yang lambat agar Anda dapat mempertahankan sasaran tingkat layanan dan menghindari penurunan performa akibat layanan dengan latensi tinggi.

• Anda ingin mengelola masalah konektivitas terputus-terputus dan mengurangi kegagalan permintaan di lingkungan terdistribusi.

Pola ini mungkin tidak cocok ketika:

• Anda perlu mengelola akses ke sumber daya privat lokal dalam aplikasi, seperti struktur data dalam memori. Di lingkungan ini, pemutus sirkuit menambahkan overhead ke sistem Anda.

• Anda perlu menggunakannya sebagai pengganti untuk menangani pengecualian dalam logika bisnis aplikasi Anda.

• Algoritma coba ulang yang terkenal sudah memadai dan ketergantungan Anda dirancang untuk menangani mekanisme coba ulang. Dalam skenario ini, pemutus sirkuit di aplikasi Anda mungkin menambahkan kompleksitas yang tidak perlu ke sistem Anda.

• Menunggu pemutus sirkuit diatur ulang mungkin menimbulkan penundaan yang tidak dapat diterima.

• Anda memiliki arsitektur berbasis pesan atau berbasis peristiwa, karena sering merutekan pesan yang gagal ke antrean surat mati untuk pemrosesan manual atau ditangguhkan. Isolasi kegagalan bawaan dan mekanisme pengulangan sering kali cukup.

• Pemulihan kegagalan dikelola di tingkat infrastruktur atau platform, seperti dengan pemeriksaan kesehatan sistem di penyeimbang beban global atau jala layanan.

Desain beban kerja

Evaluasi cara menggunakan pola Pemutus Sirkuit dalam merancang beban kerja untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar Framework Azure Well-Architected. Tabel berikut memberikan panduan tentang bagaimana pola ini mendukung tujuan setiap pilar.

Pilar	Bagaimana pola ini mendukung tujuan pilar
Keputusan desain Keandalan membantu beban kerja Anda menjadi tangguh tidak berfungsi dan memastikan bahwa memulihkan ke keadaan yang berfungsi penuh setelah kegagalan terjadi.	Pola ini membantu mencegah dependensi yang salah dari kelebihan beban. Gunakan pola ini untuk memicu degradasi anggun dalam beban kerja. Gabungkan pemutus sirkuit dengan pemulihan otomatis untuk memberikan perlindungan diri dan penyembuhan diri. - RE:03 Analisis mode kegagalan Kesalahan sementara - - RE:07 Perlindungan Diri
Efisiensi Performa membantu beban kerja Anda memenuhi permintaan secara efisien melalui pengoptimalan dalam penskalaan, data, dan kode.	Pola ini menghindari pendekatan coba lagi kesalahan, yang dapat menyebabkan penggunaan sumber daya yang berlebihan selama pemulihan dependensi dan dapat membebani performa pada dependensi yang mencoba pemulihan. - Pe:07 Kode dan infrastruktur - Respons masalah langsung PE:11

Jika pola ini memperkenalkan kompromi di dalam pilar, bandingkan dengan tujuan pilar lain.

Contoh

Contoh ini mengimplementasikan pola Circuit Breaker untuk membantu mencegah kuota diserbu dengan menggunakan tingkat gratis masa pakai Azure Cosmos DB. Tingkat ini terutama untuk data noncritical dan beroperasi di bawah rencana kapasitas yang mengalokasikan kuota unit sumber daya tertentu per detik. Selama peristiwa musiman, permintaan mungkin melebihi kapasitas yang disediakan, yang dapat menghasilkan respons 429.

Ketika lonjakan permintaan terjadi, peringatan Azure Monitor dengan ambang batas dinamis mendeteksi dan secara proaktif menginformasikan tim operasi dan manajemen bahwa database memerlukan lebih banyak kapasitas. Secara bersamaan, pemutus sirkuit yang disesuaikan dengan menggunakan pola kesalahan historis memutus aliran untuk mencegah kegagalan bertingkat. Dalam keadaan ini, aplikasi menangani penurunan kinerja dengan baik dengan mengembalikan respons default atau cache. Aplikasi ini menginformasikan kepada pengguna tentang tidak tersedianya sementara data tertentu sambil mempertahankan stabilitas sistem secara keseluruhan.

Strategi ini meningkatkan ketahanan yang selaras dengan pembenaran bisnis. Ini mengontrol lonjakan kapasitas sehingga tim beban kerja dapat mengelola peningkatan biaya dengan sengaja dan menjaga kualitas layanan tanpa secara tak terduga meningkatkan biaya operasi. Setelah permintaan mereda atau peningkatan kapasitas dikonfirmasi, pemutus arus mengatur ulang, dan aplikasi kembali ke fungsionalitas penuh yang selaras dengan tujuan teknis dan anggaran.

Diagram

Diagram memiliki tiga bagian utama. Bagian pertama berisi dua ikon browser web. Ikon pertama menampilkan antarmuka pengguna yang berfungsi penuh, dan ikon kedua menunjukkan pengalaman pengguna yang terdegradasi yang memiliki peringatan di layar untuk menunjukkan masalah kepada pengguna. Bagian kedua terletak dalam persegi panjang bergaris putus-putus, yang dibagi menjadi dua kelompok. Grup teratas mencakup sumber daya beban kerja, App Service, dan Azure Cosmos DB. Panah dari kedua ikon browser web menunjuk ke instans App Service yang mewakili permintaan masuk dari klien. Selain itu, panah dari instans App Service menunjuk ke Azure Cosmos DB, yang menunjukkan interaksi data antara layanan aplikasi dan database. Panah lain berputar dari instans App Service kembali ke dirinya sendiri, melambangkan mekanisme batas waktu pemutus rangkaian. Perulangan ini menandakan bahwa ketika respons 429 Terlalu Banyak Permintaan terdeteksi, sistem kembali melayani respons cache, menurunkan pengalaman pengguna hingga situasi teratasi. Grup bawah bagian ini berfokus pada pengamatan dan pemberitahuan. Azure Monitor mengumpulkan data dari sumber daya Azure di grup teratas. Azure Monitor juga tersambung ke ikon aturan pemberitahuan. Bagian ketiga menunjukkan alur kerja skalabilitas yang dipicu saat pemberitahuan dinaikkan. Panah menyambungkan ikon pemberitahuan ke pemberi persetujuan, yang menunjukkan bahwa pemberitahuan dikirimkan kepada mereka untuk ditinjau. Panah lain mengarah dari pemberi persetujuan ke konsol pengembangan, yang menandakan proses persetujuan untuk menskalakan database. Terakhir, panah selanjutnya diperpanjang dari konsol pengembangan ke Azure Cosmos DB, yang menggambarkan tindakan penskalaan database untuk merespons kondisi kelebihan beban.

Unduh file Visio arsitektur ini.

Alur A: Status tertutup

• Sistem beroperasi secara normal, dan semua permintaan mencapai database tanpa mengembalikan respons HTTP 429 apa pun.

• Pemutus sirkuit tetap ditutup, dan tidak ada respons bawaan atau cache yang diperlukan.

Alur B: Status terbuka

1. Ketika pemutus sirkuit menerima respons 429 pertama, pemutus sirkuit berpindah ke status Terbuka.

2. Permintaan berikutnya segera dihentikan sementara, yang memberikan respons default atau cache dan menginformasikan kepada pengguna tentang penurunan kualitas sementara. Aplikasi dilindungi dari kelebihan beban lebih lanjut.

3. Azure Monitor menerima log dan data telemetri dan mengevaluasinya terhadap ambang batas dinamis. Sebuah peringatan akan dipicu jika memenuhi kondisi dari aturan peringatan.

4. Grup tindakan secara proaktif memberi tahu tim operasi tentang kondisi kelebihan beban.

5. Setelah persetujuan tim yang menangani beban kerja, tim operasi dapat meningkatkan throughput yang disediakan untuk mengurangi kelebihan beban atau dapat menunda penskalaan jika beban mereda secara alami.

Alur C: keadaan Half-Open

1. Setelah batas waktu yang telah ditentukan sebelumnya, pemutus sirkuit memasuki status Setengah Terbuka yang mengizinkan sejumlah permintaan uji coba terbatas.

2. Jika permintaan uji coba ini berhasil tanpa mengembalikan respons 429, pengalih diatur ulang ke status Tertutup, dan operasi normal dipulihkan kembali ke Aliran A. Jika kegagalan berlanjut, pengalih kembali ke status Buka, atau Aliran B.

Komponen

• Azure App Service menghosting aplikasi web yang berfungsi sebagai titik masuk utama untuk permintaan klien. Kode aplikasi menerapkan logika yang memberlakukan kebijakan pemutus sirkuit dan memberikan respons default atau cache saat sirkuit terbuka. Arsitektur ini membantu mencegah kelebihan beban pada sistem hilir dan mempertahankan pengalaman pengguna selama permintaan atau kegagalan puncak.

• Azure Cosmos DB adalah salah satu penyimpanan data aplikasi. Ini menyediakan data tidak krusial melalui tingkatan gratis, yang ideal untuk beban kerja produksi kecil. Mekanisme pemutus sirkuit membantu membatasi lalu lintas ke database selama periode permintaan tinggi.

• Azure Monitor berfungsi sebagai solusi pemantauan terpusat. Ini menggabungkan semua log aktivitas untuk membantu memastikan pengamatan yang komprehensif dari awal hingga akhir. Azure Monitor menerima log dan data telemetri dari App Service dan metrik utama dari Azure Cosmos DB (seperti jumlah respons 429) untuk agregasi dan analisis.

• Peringatan Azure Monitor mengevaluasi aturan peringatan terhadap ambang batas dinamis untuk mengidentifikasi potensi pemadaman berdasarkan data historis. Pemberitahuan yang telah ditentukan sebelumnya memberi tahu tim operasi ketika ambang batas dilanggar.

  Terkadang, tim beban kerja mungkin menyetujui peningkatan throughput yang disediakan, tetapi tim operasi mengantisipasi bahwa sistem dapat pulih sendiri karena bebannya tidak terlalu tinggi. Dalam kasus ini, penghentian sementara pemutus sirkuit berlalu secara alami. Selama waktu ini, jika respons 429 berhenti, perhitungan ambang batas mendeteksi pemadaman yang berkepanjangan dan mengecualikannya dari algoritma pembelajaran. Akibatnya, saat terjadi kelebihan beban berikutnya, ambang batas menunggu tingkat kesalahan yang lebih tinggi di Azure Cosmos DB, yang menunda pemberitahuan. Penyesuaian ini memungkinkan pemutus sirkuit untuk menangani masalah tanpa pemberitahuan langsung, yang meningkatkan efisiensi biaya dan operasional.

Sumber daya terkait

• Pola Reliable Web App menerapkan pola Circuit Breaker ke aplikasi web yang berkumpul pada cloud.

• Pola Coba Lagi menjelaskan bagaimana aplikasi dapat menangani kegagalan sementara yang diantisipasi ketika mencoba menyambungkan ke layanan atau sumber daya jaringan dengan mencoba kembali operasi yang sebelumnya gagal secara transparan.

• Pola Pemantauan Titik Akhir Kesehatan menjelaskan bagaimana pemutus arus dapat menguji kesehatan layanan dengan mengirim permintaan ke titik akhir yang diekspos layanan. Layanan harus mengembalikan informasi yang menunjukkan statusnya.