Gaya arsitektur Web-Queue-Worker

Komponen inti dari arsitektur ini adalah ujung depan web yang menangani permintaan klien dan pekerja yang melakukan tugas intensif sumber daya, alur kerja yang berjalan lama, atau pekerjaan batch. Front end web berkomunikasi dengan pekerja melalui antrean pesan.

Komponen berikut biasanya dimasukkan ke dalam arsitektur ini:

• 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

Web dan pekerja bersifat tanpa status, dan status sesi dapat disimpan dalam cache terdistribusi. Pekerja menangani pekerjaan jangka panjang secara asinkron. Pesan pada antrean dapat memulai pekerja, atau jadwal dapat menjalankannya untuk 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 melakukan panggilan AJAX, atau aplikasi klien asli dapat menggunakannya secara langsung.

Kapan menggunakan arsitektur ini

Arsitektur Web-Queue-Worker biasanya diimplementasikan dengan menggunakan layanan komputasi terkelola seperti Azure App Service atau Azure Kubernetes Service.

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 yang mudah dan mudah diikuti

• Penyebaran dan manajemen dengan upaya minimal

• Pemisahan tanggung jawab yang jelas

• Memisahkan ujung depan dan pekerja melalui olahpesan asinkron

• Penskalaan independen dari ujung depan dan pekerja

Tantangan

• Tanpa desain yang cermat, frontend dan worker dapat menjadi komponen monolitik besar yang sulit dipelihara dan diperbarui.

• Jika front end dan pekerja berbagi skema data atau modul kode, mungkin ada dependensi tersembunyi.

• Front end web dapat gagal setelah menyimpan ke database namun sebelum mengirimkan pesan ke antrian, yang menyebabkan masalah konsistensi karena pekerja tidak melakukan bagian dari logika. Untuk mengurangi masalah ini, Anda dapat menggunakan teknik seperti pola Transactional Outbox, yang memerlukan merutekan pesan keluar agar memutar kembali melalui antrean terpisah. Pustaka Sesi Transaksi NServiceBus mendukung teknik ini.

Praktik terbaik

• Mengekspos API yang dirancang dengan baik ke klien. Untuk informasi selengkapnya, lihat Praktik terbaik desain API.

• Skalakan secara otomatis untuk menangani perubahan beban. Untuk informasi selengkapnya, lihat Praktik terbaik penskalaan otomatis.

• Cache data semistatik. Untuk informasi lebih lanjut, lihat Praktik terbaik cache.

• Gunakan jaringan pengiriman konten untuk menghosting konten statis. Untuk informasi selengkapnya, lihat Praktik terbaik jaringan pengiriman konten.

• Gunakan persistensi poliglot jika sesuai. Untuk informasi selengkapnya, lihat Memahami model data.

• Data partisi untuk meningkatkan skalabilitas, mengurangi ketidakcocokan, dan mengoptimalkan performa. Untuk informasi selengkapnya, lihat Praktik terbaik pemartisian data.

Web-Queue-Worker di App Service

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

Diagram arsitektur yang menunjukkan pengguna yang mengakses aplikasi web melalui Azure CDN untuk pengiriman konten statis. Arus lalu lintas ke aplikasi web App Service yang menangani permintaan pengguna dan mengirim pesan ke Azure Service Bus atau antrean Azure Storage. Pekerja Azure Functions memproses pesan dari antrian untuk menangani tugas yang memerlukan sumber daya besar. Sistem ini mencakup Azure Managed Redis untuk status sesi dan akses data latensi rendah, Azure Blob Storage untuk penyimpanan file dan dokumen, dan penyimpanan data poliglot dengan Azure SQL Database dan Azure Cosmos DB. Aplikasi web dan Functions keduanya berjalan pada paket App Service untuk infrastruktur komputasi.

Unduh file Visio dari arsitektur ini.

Alur kerja

• Front end diimplementasikan sebagai aplikasi web App Service , dan pekerja diimplementasikan sebagai aplikasi Azure Functions . Aplikasi web dan aplikasi Functions keduanya dikaitkan dengan paket App Service yang menyediakan instans komputer virtual (VM).

• Anda dapat menggunakan Azure Service Bus atau Azure Storage queues untuk antrean pesan. Diagram sebelumnya menggunakan antrean Penyimpanan.

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

• Azure Content Delivery Network digunakan untuk menyimpan konten statis seperti gambar, CSS, atau HTML.

• Untuk penyimpanan, pilih teknologi yang paling sesuai dengan kebutuhan aplikasi Anda. Pendekatan ini, yang dikenal sebagai persistensi poliglot, menggunakan beberapa teknologi penyimpanan dalam sistem yang sama untuk memenuhi persyaratan yang berbeda. Untuk mengilustrasikan ide ini, diagram menunjukkan Azure SQL Database dan Azure Cosmos DB.

Untuk informasi selengkapnya, lihat Aplikasi web redundan zona dengan ketersediaan tinggi dan Membangun aplikasi bisnis didorong pesan dengan NServiceBus dan Service Bus.

Pertimbangan lain

• Tidak setiap transaksi harus melalui antrean dan pekerja ke penyimpanan. Front end web dapat melakukan operasi baca dan tulis sederhana secara langsung. Pekerja dirancang untuk tugas intensif sumber daya atau alur kerja yang berjalan lama. Dalam beberapa kasus, Anda mungkin tidak memerlukan pekerja sama sekali.

• Gunakan fitur skala otomatis bawaan platform komputasi Anda untuk menskalakan jumlah instans. Jika beban pada aplikasi 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 ke dalam paket App Service terpisah sehingga dapat diskalakan secara independen.

• Gunakan paket App Service terpisah untuk produksi dan pengujian.

• Gunakan slot implementasi untuk mengelola implementasi. Metode ini memungkinkan Anda menyebarkan versi yang diperbarui ke slot penahapan, lalu menukar ke versi baru. Ini juga memungkinkan Anda menukar kembali ke versi sebelumnya jika ada masalah selama pembaruan.

Sumber daya terkait

• pola Penyeimbangan BebanQueue-Based