Share via

Strategi untuk menangani kegagalan parsial

  • Artikel

Tip

Konten ini adalah kutipan dari eBook, .NET Microservices Architecture for Containerized .NET Applications, tersedia di .NET Docs atau sebagai PDF yang dapat diunduh gratis dan dapat dibaca secara offline.

Unduh PDF

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

Untuk menangani kegagalan parsial, gunakan salah satu strategi yang dijelaskan di sini.

Gunakan komunikasi asinkron (misalnya, komunikasi berbasis pesan) di seluruh layanan mikro internal. Sangat disarankan untuk tidak membuat rantai panjang panggilan HTTP sinkron di seluruh layanan mikro internal karena desain yang salah pada akhirnya akan menjadi penyebab utama gangguan yang buruk. Sebaliknya, kecuali untuk komunikasi ujung depan antara aplikasi klien dan tingkat layanan mikro pertama atau API Gateway terperinci, sebaiknya gunakan komunikasi asinkron (berbasis pesan) saja setelah melewati siklus permintaan/respons awal, di seluruh layanan mikro internal. Konsistensi akhir dan arsitektur berbasis peristiwa akan membantu mengecilkan efek riak. Pendekatan ini memberlakukan tingkat otonomi layanan mikro yang lebih tinggi dan oleh karena itu mencegah terjadinya masalah yang dicatat di sini.

Menggunakan coba kembali dengan backoff eksponensial. Teknik ini membantu menghindari kegagalan yang singkat dan terputus-putus dengan melakukan panggilan coba kembali beberapa kali, jika layanan tidak tersedia hanya untuk waktu yang singkat. Hal ini mungkin terjadi karena masalah jaringan yang terputus-putus atau ketika layanan mikro/kontainer dipindahkan ke node yang berbeda dalam kluster. Namun, jika percobaan kembali ini tidak dirancang dengan benar dengan pemutus sirkuit, hal ini dapat memperburuk efek riak, yang pada akhirnya bahkan menyebabkan Penolakan Serangan Layanan (DoS).

Mengatasi batas waktu jaringan. Secara umum, klien harus dirancang agar tidak memblokir tanpa waktu dan agar selalu menggunakan batas waktu saat menunggu respons. Menggunakan batas waktu memastikan bahwa sumber daya tidak pernah terikat tanpa batas waktu.

Menggunakan pola Pemutus Sirkuit. Dalam pendekatan ini, proses klien melacak jumlah permintaan yang gagal. Jika tingkat kesalahan melebihi batas yang dikonfigurasi, "pemutus sirkuit" bertindak cepat sehingga upaya lebih lanjut segera digagalkan. (Jika sejumlah besar permintaan mengalami kegagalan, hal tersebut menunjukkan bahwa layanan tidak tersedia dan bahwa mengirim permintaan tidak ada gunanya) Setelah periode batas waktu, klien harus mencoba lagi dan, jika permintaan baru berhasil, tutup pemutus sirkuit.

Sediakan fallback. Dalam pendekatan ini, proses klien melakukan logika fallback ketika permintaan gagal, seperti mengembalikan data yang dicache atau nilai default. Pendekatan ini cocok untuk kueri, dan lebih kompleks untuk pembaruan atau perintah.

Batasi jumlah permintaan yang diantrekan. Klien juga harus memberlakukan batas atas pada jumlah permintaan luar biasa yang dapat dikirim oleh layanan mikro klien ke layanan tertentu. Jika batas telah tercapai, mungkin tidak ada gunanya membuat permintaan tambahan, dan upaya tersebut harus segera digagalkan. Dalam hal implementasi, kebijakan Isolasi Polly Bulkhead dapat digunakan untuk memenuhi persyaratan ini. Pendekatan ini pada dasarnya adalah pembatasan paralelisasi dengan SemaphoreSlim sebagai implementasi. Hal ini juga mengizinkan "antrean" di luar sekat. Anda dapat secara proaktif mengurangi kelebihan muatan bahkan sebelum eksekusi (misalnya, karena kapasitas dianggap penuh). Hal ini membuat respons terhadap skenario kegagalan tertentu lebih cepat daripada pemutus sirkuit, karena pemutus sirkuit menunggu kegagalan. Objek BulkheadPolicy di Polly memaparkan seberapa penuh sekat dan antrean, dan menawarkan peristiwa pada luapan sehingga juga dapat digunakan untuk mendorong penskalaan horizontal otomatis.

Sumber daya tambahan

SebelumnyaBerikutnya