Gaya arsitektur Web-Queue-Worker

Arsitektur ini memiliki dua komponen inti. Front end web menangani permintaan klien, dan pekerja melakukan tugas intensif sumber daya, alur kerja yang berjalan lama, atau pekerjaan batch. Front end web berkomunikasi dengan pekerja melalui antrean pesan.

Diagram logika yang memperlihatkan arsitektur Web-Queue-Worker.

Arsitektur ini biasanya menggunakan komponen berikut:

  • Satu atau beberapa database

  • Cache untuk menyimpan nilai dari database untuk pembacaan cepat

  • Jaringan pengiriman konten untuk menyajikan konten statis

  • Layanan jarak jauh, seperti email atau Layanan Pesan Singkat (SMS), yang biasanya disediakan oleh penyedia layanan non-Microsoft

  • Penyedia identitas untuk autentikasi

Ujung depan web dan pekerja keduanya tanpa status. Anda dapat menyimpan status sesi dalam cache terdistribusi. Pekerja menangani pekerjaan jangka panjang secara asinkron. Anda dapat memicu pekerja dengan menggunakan pesan antrean atau menjalankannya sesuai jadwal pemrosesan batch. Pekerja bersifat opsional jika aplikasi tidak memiliki operasi yang berjalan lama.

Front end mungkin menyertakan API web. Aplikasi satu halaman dapat menggunakan API web dengan membuat permintaan HTTP asinkron, atau aplikasi klien asli dapat mengonsumsinya secara langsung.

Kapan menggunakan arsitektur ini

Untuk menerapkan arsitektur web-Queue-Worker, Anda biasanya menggunakan layanan komputasi terkelola seperti Azure App Service, Azure Kubernetes Service (AKS), atau Azure Container Apps.

Pertimbangkan arsitektur ini untuk kasus penggunaan berikut:

  • Aplikasi yang memiliki domain yang relatif sederhana

  • Aplikasi yang memiliki alur kerja atau operasi batch yang berjalan lama

  • Skenario di mana Anda lebih memilih layanan terkelola daripada infrastruktur sebagai layanan (IaaS)

Keuntungan

  • Arsitektur langsung yang mudah dipahami

  • Penyebaran dan manajemen sederhana

  • Pemisahan tanggung jawab yang jelas antara frontend dan pekerja

  • Pesan asinkron yang memisahkan ujung depan dari pekerja

  • Kemampuan untuk menskalakan front end dan pekerja secara mandiri

Tantangan

  • Tanpa desain yang cermat, front end dan worker dapat tumbuh menjadi komponen monolitik besar yang menjadi sulit untuk dipertahankan dan diperbarui.

  • Skema data bersama atau modul kode antara ujung depan dan pekerja dapat membuat dependensi tersembunyi.

  • Antarmuka depan web dapat gagal setelah menulis ke database tetapi sebelum mengirim pesan ke antrean. Kegagalan ini menyebabkan masalah konsistensi karena pekerja tidak pernah memproses bagiannya dari logika. Untuk mengatasi masalah ini, gunakan teknik seperti pola Transactional Outbox, yang merutekan pesan keluar melalui antrean terpisah terlebih dahulu. Pustaka Sesi Transaksi NServiceBus mendukung pendekatan ini.

Praktik terbaik

Web-Queue-Worker di App Service

Bagian ini menjelaskan arsitektur Web-Queue-Worker yang direkomendasikan dan menggunakan App Service.

Diagram yang memperlihatkan arsitektur web-Queue-Worker.

Unduh file Visio dari arsitektur ini.

Alur kerja

  • Aplikasi web App Service berfungsi sebagai ujung depan, dan aplikasi Azure Functions berfungsi sebagai pekerja. Kedua komponen berjalan pada paket App Service.

  • Antrean pesan menggunakan Azure Service Bus atau Azure Storage queues. Diagram sebelumnya memperlihatkan antrean Penyimpanan.

  • Azure Managed Redis menyimpan status sesi dan data lain yang memerlukan akses latensi rendah.

  • Azure Content Delivery Network menyimpan konten statis seperti gambar, CSS, dan HTML.

  • Untuk penyimpanan, pilih teknologi yang paling sesuai dengan kebutuhan aplikasi Anda. Pendekatan ini, yang dikenal sebagai persistensi poliglot, menggabungkan beberapa teknologi penyimpanan dalam satu sistem untuk memenuhi persyaratan yang berbeda. Diagram sebelumnya menunjukkan pendekatan ini dengan menggunakan Azure SQL Database dan Azure Cosmos DB.

Untuk informasi selengkapnya, lihat Baseline aplikasi web redundansi zona dengan ketersediaan tinggi dan Membangun aplikasi bisnis berbasis pesan dengan menggunakan NServiceBus dan Service Bus.

Pertimbangan lain

  • Tidak setiap transaksi harus melalui antrean dan pekerja ke penyimpanan. Front end web dapat menangani operasi baca dan tulis sederhana secara langsung. Menyediakan pekerja untuk tugas yang memerlukan banyak sumber daya atau proses kerja yang memakan waktu lama. Jika aplikasi Anda tidak memiliki tugas seperti itu, Anda mungkin tidak memerlukan pekerja.

  • Gunakan fitur penskalaan otomatis bawaan platform komputasi Anda untuk meningkatkan skala instans. Jika beban mengikuti pola yang dapat diprediksi, gunakan autoscaling berbasis jadwal. Jika beban tidak dapat diprediksi, gunakan penskalaan otomatis berbasis metrik.

  • Pertimbangkan untuk menempatkan aplikasi web dan aplikasi Functions dalam paket App Service terpisah sehingga dapat diskalakan secara independen.

  • Gunakan paket App Service terpisah untuk lingkungan produksi dan pengujian.

  • Gunakan slot penyebaran untuk mengelola penyebaran untuk paket App Service. Sebarkan versi terbaru ke slot staging, lalu ganti ke versi terbaru. Jika masalah terjadi, tukar kembali ke versi sebelumnya.

  • Last updated on