Komponen inti dari arsitektur ini adalah bagian depan web yang melayani permintaan klien, dan pekerja yang melakukan tugas intensif sumber daya, alur kerja yang berjalan lama, atau tugas batch. Ujung depan web berkomunikasi dengan pekerja melalui antrean pesan.
Komponen lain yang umumnya dimasukkan ke dalam arsitektur ini meliputi:
- Satu atau beberapa database.
- Cache untuk menyimpan nilai dari database untuk membaca cepat.
- CDN untuk menyajikan konten statis
- Layanan jarak jauh, seperti email atau layanan SMS. Seringkali fitur-fitur ini disediakan oleh pihak ketiga.
- Penyedia identitas untuk autentikasi.
Web dan pekerja sama-sama tanpa status. Status sesi dapat disimpan dalam cache terdistribusi. Setiap pekerjaan yang sudah berjalan lama dilakukan secara asinkron oleh pekerja. Pekerja dapat dipicu oleh pesan pada antrean, atau berjalan pada jadwal untuk pemrosesan batch. Pekerja adalah komponen opsional. Jika tidak ada operasi yang berjalan lama, pekerja dapat dihilangkan.
Ujung depan mungkin terdiri dari API web. Di sisi klien, API web dapat dikonsumsi oleh aplikasi satu halaman yang membuat panggilan AJAX, atau oleh aplikasi klien asli.
Kapan harus menggunakan arsitektur ini
Arsitektur Web-Queue-Worker biasanya diterapkan menggunakan layanan komputasi terkelola, baik Azure App Service atau Azure Cloud Services.
Pertimbangkan gaya arsitektur ini untuk:
- Aplikasi dengan domain yang relatif sederhana.
- Aplikasi dengan beberapa alur kerja atau operasi batch yang sudah berjalan lama.
- Ketika Anda ingin menggunakan layanan terkelola, bukan infrastruktur sebagai layanan (IaaS).
Keuntungan
- Arsitektur yang relatif sederhana yang mudah dimengerti.
- Mudah disebarkan dan dikelola.
- Pemisahan kekhawatiran yang jelas.
- Ujung depan dipisahkan dari pekerja menggunakan olahpesan asinkron.
- Ujung depan dan pekerja dapat ditingkatkan secara independen.
Tantangan
- Tanpa desain yang cermat, ujung depan dan pekerja dapat menjadi komponen monolitik besar yang sulit dirawat dan diperbarui.
- Mungkin terdapat dependensi tersembunyi, jika ujung depan dan pekerja berbagi skema data atau modul kode.
- Ujung depan web dapat tidak berfungsi setelah berhasil bertahan ke database tetapi sebelum memancarkan pesan ke antrean. Hal ini dapat mengakibatkan kemungkinan masalah konsistensi karena pekerja tidak akan melakukan bagiannya dari logika. Teknik seperti pola kotak keluar transaksi dapat digunakan untuk membantu mengurangi masalah ini tetapi memerlukan perubahan perutean pesan keluar menjadi "loop back" terlebih dahulu melalui antrean terpisah. Salah satu pustaka yang menyediakan dukungan untuk teknik ini adalah NServiceBus Transactional Session.
Praktik terbaik
- Mengekspos API yang dirancang dengan baik kepada klien. Lihat praktik terbaik desain API.
- Skala otomatis untuk menghandel perubahan beban. Lihat Praktik terbaik Penskalaan Otomatis.
- Cache data semi-statis. Lihat Praktik terbaik dalam cache.
- Gunakan CDN untuk menghosting konten statis. Lihat praktik terbaik CDN.
- Gunakan kegigihan polyglot bila perlu. Lihat [Gunakan penyimpanan data terbaik untuk pekerjaan][polyglot].
- Partisi data untuk meningkatkan skalabilitas, mengurangi ketidakcocokan, dan mengoptimalkan kinerja. Lihat Praktik terbaik pemartisian data.
Web-Queue-Worker di Azure App Service
Bagian ini menjelaskan arsitektur Web-Queue-Worker yang direkomendasikan yang menggunakan Azure App Service.
Unduh file Visio arsitektur ini.
Alur kerja
Front end diimplementasikan sebagai aplikasi web Azure App Service , dan pekerja diimplementasikan sebagai aplikasi Azure Functions . Aplikasi web dan aplikasi fungsi keduanya terkait dengan paket App Service yang menyediakan instans VM.
Anda dapat menggunakan antrean Azure Bus Layanan atau Azure Storage untuk antrean pesan. (Diagram ini menunjukkan antrean Azure Storage.)
Azure Cache for Redis menyimpan status sesi dan data lain yang membutuhkan akses latensi rendah.
Azure CDN digunakan untuk menyimpan konten statis seperti gambar, CSS, atau HTML.
Untuk penyimpanan, pilih teknologi penyimpanan yang paling sesuai dengan kebutuhan aplikasi. Anda dapat menggunakan beberapa teknologi penyimpanan (polyglot persistence). Untuk mengilustrasikan ide ini, diagram menunjukkan Azure SQL Database dan Azure Cosmos DB.
Untuk informasi selengkapnya, lihat arsitektur referensi aplikasi web App Service dan cara membangun aplikasi bisnis berbasis pesan dengan NServiceBus dan Azure Bus Layanan.
Pertimbangan lain
Tidak setiap transaksi harus melalui antrean dan pekerja ke penyimpanan. Ujung depan web dapat melakukan operasi baca / tulis sederhana secara langsung. Pekerja dirancang untuk tugas intensif sumber daya atau alur kerja yang sudah berjalan lama. Dalam beberapa kasus, Anda mungkin tidak memerlukan pekerja sama sekali.
Gunakan fitur skala otomatis bawaan App Service untuk menskalakan jumlah instans VM. Jika beban pada aplikasi mengikuti pola yang dapat diprediksi, gunakan skala otomatis berbasis jadwal. Jika beban tidak dapat diprediksi, gunakan aturan autoscaling berbasis metrik.
Pertimbangkan untuk menempatkan aplikasi web dan aplikasi fungsi ke dalam paket App Service terpisah. Dengan begitu, mereka dapat diskalakan secara independen.
Gunakan paket Azure App Service terpisah untuk produksi dan pengujian. Jika tidak, jika Anda menggunakan rencana yang sama untuk produksi dan pengujian, itu berarti tes Anda berjalan pada VM produksi Anda.
Gunakan slot penyebaran untuk mengelola penyebaran. Metode ini memungkinkan Anda menyebarkan versi yang diperbarui ke slot penahapan, lalu menukar ke versi baru. Ini juga memungkinkan Anda bertukar kembali ke versi sebelumnya, jika ada masalah dengan pembaruan.