Gaya arsitekturQueue-Worker web
Komponen inti dari arsitektur ini adalah ujung depan web yang melayani 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 lain yang umumnya dimasukkan ke dalam arsitektur ini meliputi:
- Satu atau beberapa database.
- Cache untuk menyimpan nilai dari database untuk pembacaan 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 keduanya tanpa status. Status sesi dapat disimpan dalam cache terdistribusi. Setiap pekerjaan jangka panjang dilakukan secara asinkron oleh pekerja. Pekerja dapat dipicu oleh pesan pada antrean, atau berjalan sesuai jadwal 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 digunakan oleh aplikasi satu halaman yang melakukan panggilan AJAX, atau oleh aplikasi klien asli.
Kapan menggunakan arsitektur ini
ArsitekturQueue-Worker Web biasanya diimplementasikan 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 berjalan lama.
- Ketika Anda ingin menggunakan layanan terkelola, bukan infrastruktur sebagai layanan (IaaS).
Keuntungan
- Arsitektur relatif sederhana yang mudah dipahami.
- Mudah disebarkan dan dikelola.
- Pemisahan kekhawatiran yang jelas.
- Ujung depan dipisahkan dari pekerja menggunakan olahpesan asinkron.
- Ujung depan dan pekerja dapat diskalakan secara independen.
Tantangan
- Tanpa desain yang cermat, ujung depan dan pekerja dapat menjadi komponen monolitik besar yang sulit dipertahankan dan diperbarui.
- Mungkin ada 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 ke klien. Lihat Praktik terbaik desain API.
- Skala otomatis untuk menangani perubahan beban. Lihat praktik terbaik Autoscaling.
- Cache data semi-statis. Lihat praktik terbaik Penembolokan.
- Gunakan CDN untuk menghosting konten statis. Lihat Praktik terbaik CDN.
- Gunakan persistensi poliglot jika sesuai. Lihat [Gunakan penyimpanan data terbaik untuk pekerjaan][polyglot].
- Data partisi untuk meningkatkan skalabilitas, mengurangi ketidakcocokan, dan mengoptimalkan performa. Lihat Praktik terbaik pemartisian data.
Web-Queue-Worker di Azure App Service
Bagian ini menjelaskan arsitekturQueue-Worker Web yang direkomendasikan yang menggunakan Azure App Service.
Unduh file Visio dari 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 dikaitkan dengan paket App Service yang menyediakan instans VM.
Anda dapat menggunakan Antrean Azure Service Bus atau Azure Storage untuk antrean pesan. (Diagram 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 (persistensi poliglot). 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 Service Bus.
Pertimbangan lain
Tidak setiap transaksi harus melalui antrean dan pekerja ke penyimpanan. Front end web dapat melakukan operasi baca/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 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 penskalaan otomatis 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 App Service terpisah untuk produksi dan pengujian. Jika tidak, jika Anda menggunakan paket yang sama untuk produksi dan pengujian, itu berarti pengujian 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 menukar kembali ke versi sebelumnya, jika ada masalah dengan pembaruan.