Menangani kegagalan parsial

Petunjuk / Saran

Konten ini adalah kutipan dari eBook, Arsitektur Layanan Mikro .NET untuk Aplikasi .NET Kontainer, tersedia di .NET Docs atau sebagai PDF gratis yang dapat diunduh yang dapat dibaca secara offline.

Unduh PDF

Dalam sistem terdistribusi seperti aplikasi berbasis layanan mikro, ada risiko kegagalan parsial yang selalu ada. Misalnya, satu layanan mikro/kontainer dapat gagal atau mungkin tidak tersedia untuk merespons dalam waktu singkat, atau satu VM atau server dapat mengalami crash. Karena klien dan layanan adalah proses terpisah, layanan mungkin tidak dapat merespons dengan cara yang tepat waktu terhadap permintaan klien. Layanan ini mungkin kelebihan beban dan merespons permintaan dengan sangat lambat atau mungkin tidak dapat diakses untuk waktu yang singkat karena masalah jaringan.

Misalnya, pertimbangkan halaman Detail pesanan dari aplikasi sampel eShopOnContainers. Jika layanan mikro pemesanan tidak responsif ketika pengguna mencoba mengirimkan pesanan, implementasi yang buruk dari proses klien (aplikasi web MVC)—misalnya, jika kode klien menggunakan RPC sinkron tanpa batas waktu—akan memblokir utas tanpa batas waktu menunggu respons. Selain menciptakan pengalaman pengguna yang buruk, setiap penantian yang tidak responsif menghambat atau mengonsumsi utas, padahal utas sangat berharga dalam aplikasi yang sangat dapat diskalakan. Jika ada banyak utas yang diblokir, akhirnya runtime aplikasi dapat kehabisan utas. Dalam hal ini, aplikasi dapat menjadi tidak responsif secara global alih-alih hanya sebagian tidak responsif, seperti yang ditunjukkan pada Gambar 8-1.

Gambar 8-1. Kegagalan parsial karena dependensi yang memengaruhi ketersediaan utas layanan

Dalam aplikasi berbasis layanan mikro besar, kegagalan parsial apa pun dapat diperkuat, terutama jika sebagian besar interaksi layanan mikro internal didasarkan pada panggilan HTTP sinkron (yang dianggap anti-pola). Pikirkan tentang sistem yang menerima jutaan panggilan masuk per hari. Jika sistem Anda memiliki desain buruk yang didasarkan pada rantai panggilan HTTP sinkron yang panjang, panggilan masuk ini dapat mengakibatkan lebih banyak juta panggilan keluar (misalkan rasio 1:4) terhadap puluhan layanan mikro internal sebagai dependensi sinkron. Situasi ini ditunjukkan pada Gambar 8-2, terutama dependensi #3, yang memulai rantai, memanggil dependensi #4, yang kemudian memanggil #5.

Gambar 8-2. Dampak memiliki desain yang salah yang menampilkan rantai panjang permintaan HTTP

Kegagalan intermiten dijamin dalam sistem terdistribusi dan berbasis cloud, bahkan jika setiap dependensi tersebut memiliki ketersediaan yang sangat baik. Ini adalah fakta yang perlu Anda pertimbangkan.

Jika Anda tidak merancang dan menerapkan teknik untuk memastikan toleransi kesalahan, bahkan waktu henti kecil dapat diperkuat. Sebagai contoh, 50 dependensi masing-masing dengan 99,99% ketersediaan akan mengakibatkan beberapa jam waktu henti setiap bulan karena efek riak ini. Jika dependensi layanan mikro gagal saat menangani jumlah permintaan yang besar, kegagalan tersebut dapat dengan cepat membebani semua utas permintaan yang tersedia di setiap layanan dan menghentikan operasional seluruh aplikasi.

Gambar 8-3. Kegagalan parsial diperkuat oleh layanan mikro dengan rantai panjang panggilan HTTP sinkron

Untuk meminimalkan masalah ini, di bagian Integrasi layanan mikro asinkron memberlakukan otonomi layanan mikro, panduan ini mendorong Anda untuk menggunakan komunikasi asinkron di seluruh layanan mikro internal.

Selain itu, sangat penting bagi Anda untuk merancang layanan mikro dan aplikasi klien Anda untuk menangani kegagalan parsial—yaitu, untuk membangun layanan mikro dan aplikasi klien yang tangguh.

SebelumnyaBerikutnya