Kemana perginya pemutus sirkuit?

Aug 18 2020

Saya sedang mengembangkan REST API baru dan saya telah melihat beberapa proyek menempatkan pemutus sirkuit di Controller. Saya biasa menempatkannya di DAO.

Perbedaan pertama yang dapat saya katakan adalah bahwa menempatkannya di DAOadalah bahwa setiap layanan yang menggunakan pihak ketiga ini akan terbuka dalam skenario kesalahan. Dan menempatkannya di Controller, SETIAPNYA akan membuka setiap rute yang memakan pihak ketiga ini; jadi tidak akan segera. Namun pilihan kedua (dalam Controller) tampaknya lebih mudah untuk dipertahankan.

Adakah rekomendasi tentang kemana harus pergi?

Jawaban

3 Christophe Aug 19 2020 at 17:02

Ada dua bagian dalam jawaban ini. Bagian pertama sudah dialamatkan oleh Robert Harvey dalam komentarnya:

  • Menurut katalog pola layanan mikro Chris Richardson, pemutus sirkuit harus berada dalam proxy untuk layanan jarak jauh. API Gateway adalah tempat yang tepat untuk itu.
  • Alternatif lain adalah penemuan sisi server, terutama jika strategi pemulihan menyiratkan menemukan contoh lain yang berjalan dari layanan yang sama.

Tapi ada bagian kedua. Tujuan dari pemutus sirkuit adalah untuk cepat gagal jika layanan terdeteksi tidak tersedia, alih-alih mengumpulkan langkah-langkah yang nantinya akan gagal menciptakan banyak frustrasi. Jadi pemutus sirkuit mengerti sepenuhnya hanya jika layanan konsumsi siap bereaksi terhadap pemutusan:

  • Mungkin layanan jarak jauh itu penting, dan layanan yang mengonsumsi dapat memutuskan untuk menunda sendiri (misalnya, pemutus sirkuit internal).
  • Mungkin layanan jarak jauh tidak penting, dan layanan yang mengonsumsi dapat memutuskan untuk terus melayani, tetapi dalam mode terdegradasi.
  • (Pemutus berbasis penemuan layanan mungkin tidak akan gagal tetapi menemukan layanan lain yang berfungsi dan konsumen tidak akan menyadarinya).

Dari sudut pandang umum, jenis pilihan dalam perilaku ini adalah tanggung jawab pengontrol: pengontrol berkoordinasi antara elemen layanan, dan mampu menyesuaikan pemrosesan berdasarkan informasi "gagal".

Namun, jika dalam kasus Anda, ini hanya tentang mendapatkan data dari tempat lain dan jika strategi pemrosesan kesalahan Anda selalu sama (tidak ada perbedaan antara esensial dan non-esensial; misalnya mencoba menggunakan nilai cache jika tersedia dan gagal jika tidak) Anda bisa dengan baik memutuskan untuk memasukkannya ke dalam dao imho.