Pola olahpesan asinkron dan ketersediaan tinggi

Pesan asinkron dapat diimplementasikan dengan berbagai cara yang berbeda. Dengan antrean, topik, dan langganan, Azure Service Bus mendukung asinkronisme melalui mekanisme penyimpanan dan maju. Dalam operasi normal (sinkron), Anda mengirim pesan ke antrean dan topik, dan menerima pesan dari antrean dan langganan. Aplikasi yang Anda tulis bergantung pada entitas ini selalu tersedia. Ketika kesehatan entitas berubah, karena berbagai keadaan, Anda memerlukan cara untuk menyediakan entitas kemampuan yang berkurang yang dapat memenuhi sebagian besar kebutuhan.

Aplikasi biasanya menggunakan pola olahpesan asinkron untuk mengaktifkan sejumlah skenario komunikasi. Anda dapat membangun aplikasi di mana klien dapat mengirim pesan ke layanan, bahkan ketika layanan tidak berjalan. Untuk aplikasi yang mengalami ledakan komunikasi, antrean dapat membantu meningkatkan beban dengan menyediakan tempat untuk menyangga komunikasi. Akhirnya, Anda bisa mendapatkan load balancer yang sederhana namun efektif untuk mendistribusikan pesan di beberapa komputer.

Untuk menjaga ketersediaan salah satu entitas ini, pertimbangkan sejumlah cara berbeda di mana entitas ini dapat terlihat tidak tersedia untuk sistem olahpesan yang tahan lama. Secara umum, kita melihat entitas menjadi tidak tersedia untuk aplikasi yang kita tulis dengan cara yang berbeda berikut:

• Tidak bisa mengirim pesan.
• Tidak bisa menerima pesan.
• Tidak dapat mengelola entitas (membuat, mengambil, memperbarui, atau menghapus entitas).
• Tidak bisa menghubungi layanan ini.

Untuk setiap kegagalan ini, ada mode kegagalan yang berbeda yang memungkinkan aplikasi untuk terus melakukan pekerjaan pada beberapa tingkat kemampuan yang berkurang. Misalnya, sistem yang dapat mengirim pesan tetapi tidak menerimanya masih dapat menerima pesanan dari pelanggan tetapi tidak dapat memproses pesanan tersebut. Topik ini membahas masalah potensial yang dapat terjadi, dan bagaimana isu-isu tersebut dimitigasi. Bus Layanan telah memperkenalkan sejumlah mitigasi yang harus Anda pilih, dan topik ini juga membahas aturan yang mengatur penggunaan mitigasi keikutsertaan tersebut.

Keandalan dalam Bus Layanan

Ada beberapa cara untuk menangani masalah pesan dan entitas, dan ada pedoman yang mengatur penggunaan mitigasi tersebut dengan tepat. Untuk memahami pedoman, Anda harus terlebih dahulu memahami apa yang dapat gagal dalam Bus Layanan. Karena desain sistem Azure, semua masalah ini cenderung berumur pendek. Pada tingkat tinggi, berbagai penyebab tidak tersedia muncul sebagai berikut:

• Pembatasan dari sistem eksternal tempat Bus Layanan tergantung. Pembatasan terjadi dari interaksi dengan penyimpanan dan sumber daya komputasi.
• Masalah untuk sistem tempat Bus Layanan bergantung. Misalnya, bagian penyimpanan yang diberikan dapat mengalami masalah.
• Kegagalan Bus Layanan pada subsistem tunggal. Dalam situasi ini, node komputasi dapat masuk ke status yang tidak konsisten dan harus menghidupkan ulang sendiri, menyebabkan semua entitas melayani load balance ke node lainnya. Ini nantinya dapat menyebabkan periode singkat untuk pemrosesan pesan yang lambat.
• Kegagalan Bus Layanan dalam pusat data Azure. Ini adalah "kegagalan bencana" di mana sistem tidak dapat dijangkau selama beberapa menit atau beberapa jam.

Catatan

Istilah penyimpanan bisa berarti Azure Storage dan SQL Azure.

Bus Layanan berisi sejumlah mitigasi untuk masalah ini. Bagian berikut membahas setiap masalah dan mitigasi masing-masing.

Pembatasan

Dengan Bus Layanan, pembatasan memungkinkan manajemen tarif pesan kooperatif. Setiap node Bus Layanan individu memiliki banyak entitas. Setiap entitas tersebut membuat tuntutan pada sistem dalam hal CPU, memori, penyimpanan, dan aspek lainnya. Ketika salah satu aspek ini mendeteksi penggunaan yang melebihi ambang batas yang ditentukan, Bus Layanan dapat menolak permintaan yang diberikan. Penelepon menerima pengecualian sibuk server dan mencoba kembali setelah 10 detik.

Sebagai mitigasi, kode harus membaca kesalahan dan menghentikan upaya ulang pesan setidaknya selama 10 detik. Karena kesalahan dapat terjadi di seluruh bagian aplikasi pelanggan, diharapkan setiap bagian secara independen menjalankan logika coba lagi. Kode dapat mengurangi probabilitas pembatasan dengan mengaktifkan partisi pada namespace, antrean, atau topik.

Untuk informasi selengkapnya tentang bagaimana kode aplikasi harus menangani masalah pembatasan, lihat dokumentasi tentang Pola Pembatasan.

Masalah untuk dependensi Azure

Komponen lain dalam Azure terkadang dapat mengalami masalah layanan. Misalnya, ketika sistem yang digunakan Bus Layanan sedang ditingkatkan, sistem tersebut dapat mengalami pengurangan kemampuan untuk sementara waktu. Untuk mengatasi jenis masalah ini, Bus Layanan secara teratur menyelidiki dan mengimplementasikan mitigasi. Efek samping dari mitigasi ini memang muncul. Misalnya, untuk menangani masalah sementara dengan penyimpanan, Bus Layanan menerapkan sistem yang memungkinkan operasi pengiriman pesan bekerja secara konsisten. Karena sifat mitigasi, pesan terkirim dapat memakan waktu hingga 15 menit untuk muncul dalam antrean atau langganan yang terpengaruh dan bersiaplah untuk operasi penerima. Secara umum, sebagian besar entitas tidak akan mengalami masalah ini. Namun, mengingat jumlah entitas dalam Bus Layanan dalam Azure, mitigasi ini terkadang diperlukan untuk sebagian kecil pelanggan Bus Layanan.

Kegagalan Bus Layanan pada satu subsistem

Dengan aplikasi apa pun, keadaan dapat menyebabkan komponen internal Bus Layanan menjadi tidak konsisten. Ketika Bus Layanan mendeteksi hal ini, ia mengumpulkan data dari aplikasi untuk membantu mendiagnosis apa yang terjadi. Setelah data dikumpulkan, aplikasi dihidupkan ulang dalam upaya untuk mengembalikannya ke status yang konsisten. Proses ini terjadi cukup cepat, dan mengakibatkan entitas tampaknya tidak tersedia hingga beberapa menit, meskipun waktu tidak berfungsi yang biasanya jauh lebih singkat.

Dalam kasus ini, aplikasi klien menghasilkan pengecualian waktu habis atau pengecualian pesan. Bus Layanan berisi mitigasi untuk masalah ini dalam bentuk logika coba lagi klien otomatis. Setelah periode coba lagi habis dan pesan tidak terkirim, Anda dapat menjelajahi menggunakan yang lainnya yang disebutkan dalam artikel tentangpenanganan gangguan dan bencana.

Langkah berikutnya

Sekarang setelah Anda belajar dasar-dasar pesan asinkron di Bus Layanan, baca detail selengkapnya tentang menangani gangguan dan bencana.