Bagikan melalui

Pemrosesan peristiwa yang andal dengan Azure Functions dan Event Hubs

Pelajari cara membangun solusi tanpa server yang kuat dan andal menggunakan Azure Functions dengan pemicu Azure Event Hubs. Artikel ini membahas praktik terbaik untuk titik pemeriksaan, penanganan kesalahan, dan penerapan pola pemutus sirkuit untuk memastikan tidak ada peristiwa yang hilang dan aplikasi berbasis peristiwa Anda tetap stabil dan tangguh.

Tantangan aliran peristiwa dalam sistem terdistribusi

Pertimbangkan sistem yang mengirim peristiwa pada tingkat konstan 100 peristiwa per detik. Pada tingkat ini, dalam hitungan menit beberapa instans paralel dapat mengolah 100 peristiwa masuk setiap detik.

Namun, pertimbangkan tantangan ini untuk mengkonsumsi aliran peristiwa:

  • Penerbit peristiwa mengirimkan peristiwa yang rusak.
  • Kode fungsi Anda mengalami pengecualian yang tidak tertangani.
  • Sistem hilir tidak aktif dan memblokir pemrosesan peristiwa.

Tidak seperti pemicu penyimpanan Azure Queue, yang mengunci pesan selama pemrosesan, Azure Event Hubs membaca, per partisi, dari satu titik dalam aliran. Perilaku baca ini, yang mirip dengan pemutar video, memberikan manfaat yang diinginkan dari throughput tinggi, banyak kelompok konsumen, dan kemampuan pemutaran kembali. Peristiwa dibaca, maju atau mundur, dari titik pemeriksaan, tetapi Anda harus memindahkan penunjuk untuk memproses peristiwa baru. Untuk informasi selengkapnya, lihat Titik pemeriksaan di dokumentasi Azure Event Hubs.

Ketika kesalahan terjadi dalam aliran dan Anda memilih untuk tidak memajukan penunjuk, pemrosesan peristiwa lebih lanjut diblokir. Dengan kata lain, jika Anda menghentikan penunjuk untuk menangani masalah dalam memproses satu peristiwa, peristiwa yang belum diproses mulai menumpuk.

Fungsi menghindari kebuntuan dengan selalu memajukan penunjuk aliran, terlepas dari keberhasilan atau kegagalan. Karena pointer terus maju, fungsi Anda perlu menangani kegagalan dengan tepat.

Bagaimana pemicu Azure Event Hubs mengonsumsi peristiwa

Azure Functions memanfaatkan acara dari hub acara dengan menjalani langkah-langkah berikut:

  1. Penunjuk dibuat dan disimpan di Azure Storage untuk setiap partisi hub peristiwa.
  2. Peristiwa baru diterima dalam batch (secara default), dan host mencoba memicu fungsi yang menyediakan batch peristiwa untuk diproses.
  3. Ketika fungsi menyelesaikan eksekusi, dengan atau tanpa pengecualian, penunjuk dimajukan dan titik pemeriksaan disimpan ke akun penyimpanan host default.
  4. Jika kondisi mencegah eksekusi fungsi selesai, host tidak dapat memajukan penunjuk. Ketika pointer tidak dapat maju, eksekusi berikutnya memproses ulang peristiwa yang sama.

Perilaku ini mengungkapkan beberapa poin penting:

  • Pengecualian yang tidak tertangani dapat menyebabkan Anda kehilangan peristiwa:

    Fungsi yang menimbulkan pengecualian akan terus memajukan pointer. Mengatur kebijakan coba lagi atau logika coba lagi lainnya menunda pemajuan penunjuk hingga seluruh percobaan ulang selesai.

  • Functions menjamin pengiriman setidaknya sekali :

    Kode dan sistem dependen Anda mungkin perlu memperhitungkan fakta bahwa peristiwa yang sama dapat diproses dua kali. Untuk informasi selengkapnya, lihat Mendesain Azure Functions untuk input yang identik.

Menangani pengecualian

Meskipun semua kode fungsi harus menyertakan blok coba/tangkap pada tingkat kode tertinggi, memiliki catch blok bahkan lebih penting untuk fungsi yang menggunakan peristiwa Event Hubs. Dengan begitu, ketika terjadi pengecualian, blok tangkapan menangani kesalahan sebelum penunjuk melanjut.

Mencoba kembali mekanisme dan kebijakan

Karena banyak pengecualian di cloud bersifat sementara, langkah pertama dalam penanganan kesalahan adalah selalu mencoba kembali operasi. Anda dapat menerapkan kebijakan coba lagi bawaan atau menentukan logika coba lagi Anda sendiri.

Kebijakan Pengulangan

Functions menyediakan kebijakan coba lagi bawaan untuk Azure Event Hubs. Saat menggunakan kebijakan coba lagi, Anda hanya mengajukan pengecualian baru dan host mencoba memproses peristiwa lagi berdasarkan kebijakan yang ditentukan. Perilaku coba lagi ini memerlukan ekstensi Azure Event Hubs versi 5.x atau yang lebih baru. Untuk informasi selengkapnya, lihat Kebijakan coba lagi.

Logika ulangi khusus

Anda juga dapat menentukan logika coba lagi Anda sendiri dalam fungsi itu sendiri. Misalnya, Anda dapat menerapkan kebijakan yang mengikuti alur kerja yang diilustrasikan oleh aturan berikut:

  • Cobalah untuk memproses peristiwa tiga kali (berpotensi dengan penundaan antara percobaan ulang).
  • Jika hasil akhirnya dari semua percobaan ulang adalah kegagalan, tambahkan event ke dalam antrean sehingga pemrosesan dapat berlanjut di aliran.
  • Peristiwa yang rusak atau belum diolah akan ditangani kemudian.

Nota

Polly adalah contoh pustaka ketahanan dan penanganan kesalahan sementara untuk aplikasi C#.

Kesalahan bukan pengecualian

Beberapa masalah dapat terjadi tanpa pengecualian dimunculkan. Misalnya, pertimbangkan kasus di mana permintaan kehabisan waktu atau instans yang menjalankan fungsi mengalami crash. Ketika fungsi gagal diselesaikan tanpa pengecualian, penunjuk offset tidak pernah dimajukan. Jika pointer tidak maju, maka setiap instans yang berjalan setelah eksekusi yang gagal akan terus membaca peristiwa yang sama. Situasi ini memberikan jaminan setidaknya sekali .

Jaminan bahwa setiap peristiwa diproses setidaknya satu kali menyiratkan bahwa beberapa peristiwa dapat diproses lebih dari sekali. Aplikasi fungsi Anda perlu menyadari kemungkinan ini dan harus dibangun di sekitar prinsip idempotensi.

Menangani keadaan kegagalan

Aplikasi Anda mungkin dapat menangani beberapa kesalahan dalam pemrosesan peristiwa secara memadai. Namun, Anda juga harus siap untuk menangani status kegagalan persisten, yang mungkin terjadi sebagai akibat dari kegagalan dalam pemrosesan hilir. Dalam status kegagalan seperti itu, seperti penyimpanan data hilir sedang offline, fungsi Anda harus berhenti memicu peristiwa sampai sistem mencapai status sehat.

Pola pemutus sirkuit

Saat Anda menerapkan pola pemutus sirkuit , aplikasi Anda dapat secara efektif menjeda pemrosesan peristiwa lalu melanjutkannya di lain waktu setelah masalah diselesaikan.

Ada dua komponen yang diperlukan untuk menerapkan pemutus arus dalam proses aliran peristiwa:

  • Keadaan bersama di semua instance untuk melacak dan memantau kesehatan sirkuit.
  • Proses utama yang dapat mengelola status sirkuit, sebagai open atau closed.

Detail implementasi dapat bervariasi, tetapi untuk berbagi status di antara instans, Anda memerlukan mekanisme penyimpanan. Anda dapat menyimpan status di Azure Storage, cache Redis, atau layanan persisten lainnya yang dapat diakses oleh instans aplikasi fungsi Anda.

Durable Functions dan Azure Logic Apps menyediakan infrastruktur untuk mengelola alur kerja dan status sirkuit. Artikel ini menjelaskan penggunaan Logic Apps untuk menjeda dan memulai ulang eksekusi fungsi, memberi Anda kontrol yang diperlukan untuk menerapkan pola pemutus sirkuit.

Menentukan ambang kegagalan di seluruh instans

Status eksternal bersama yang dipertahankan diperlukan untuk memantau kesehatan sirkuit ketika beberapa instans memproses peristiwa secara bersamaan. Anda kemudian dapat memantau status bertahan ini berdasarkan aturan yang menunjukkan status kegagalan, seperti:

Ketika ada lebih dari 100 kegagalan peristiwa dalam periode 30 detik di semua instans, putuskan sirkuit untuk berhenti memicu peristiwa baru.

Detail implementasi untuk logika pemantauan ini bervariasi tergantung pada kebutuhan aplikasi spesifik Anda, tetapi secara umum Anda harus membuat sistem yang:

  1. Mencatat kegagalan ke penyimpanan persisten.
  2. Periksa jumlah bergulir saat kegagalan baru dicatat untuk menentukan apakah ambang kegagalan peristiwa terpenuhi.
  3. Ketika ambang ini terpenuhi, keluarkan peristiwa yang memberi tahu sistem untuk memutus sirkuit.

Mengelola status sirkuit dengan Azure Logic Apps

Azure Logic Apps dilengkapi dengan konektor bawaan ke berbagai layanan, fitur, dan orkestrasi stateful, serta merupakan pilihan alami untuk pengelolaan status sirkuit. Setelah mendeteksi kapan sirkuit harus rusak, Anda dapat membuat aplikasi logika untuk mengimplementasikan alur kerja ini:

  1. Memicu alur kerja Event Grid yang menghentikan pemrosesan fungsi.
  2. Kirim email pemberitahuan yang menyertakan opsi untuk memulai ulang alur kerja.

Untuk mempelajari cara menonaktifkan dan mengaktifkan kembali fungsi tertentu menggunakan pengaturan aplikasi, lihat Cara menonaktifkan fungsi di Azure Functions.

Penerima email dapat menyelidiki kesehatan sirkuit dan, jika sesuai, menghidupkan ulang sirkuit melalui tautan di email pemberitahuan. Saat alur kerja memulai ulang fungsi, peristiwa diproses dari titik pemeriksaan pusat aktivitas terakhir.

Ketika Anda menggunakan pendekatan ini, tidak ada peristiwa yang hilang, peristiwa diproses secara berurutan, dan Anda dapat merusak sirkuit selama yang diperlukan.

Strategi migrasi untuk pemicu Event Grid

Saat memigrasikan aplikasi fungsi yang ada antar wilayah atau di antara beberapa paket, Anda harus membuat ulang aplikasi selama proses migrasi. Dalam hal ini, selama proses migrasi, Anda mungkin memiliki dua aplikasi yang keduanya dapat menerima data dari aliran peristiwa yang sama dan menulis data ke tujuan output yang sama.

Anda harus mempertimbangkan untuk menggunakan grup konsumen untuk menghindari kehilangan atau duplikasi data peristiwa selama proses migrasi:

  1. Buat grup konsumen baru untuk aplikasi target baru.

  2. Konfigurasikan pemicu di aplikasi baru untuk menggunakan grup konsumen baru ini.

    Ini memungkinkan kedua aplikasi memproses peristiwa secara independen selama validasi.

  3. Validasi bahwa aplikasi baru memproses peristiwa dengan benar.

  4. Hentikan aplikasi asli atau hapus grup langganan/konsumennya.

  • Last updated on