Skenario ini menjelaskan cara merancang solusi yang memproses perubahan pada data yang mendasari dalam tampilan web, tanpa perlu refresh halaman, dengan menggunakan layanan real-time. Contoh yang menggunakan skenario ini termasuk pelacakan produk dan barang secara real time, dan solusi media sosial.
Arsitektur
Unduh file Visio arsitektur ini.
Komponen
- Azure Service Bus adalah layanan olahpesan cloud yang sangat andal antara aplikasi dan layanan, bahkan ketika satu atau beberapa offline.
- Azure SignalR Service memudahkan untuk menambahkan komunikasi real-time ke aplikasi web Anda.
- Azure Functions adalah platform komputasi tanpa server berbasis peristiwa yang juga dapat memecahkan masalah orkestrasi yang kompleks.
Alternatif
Alternatif ada untuk mengatasi skenario ini, termasuk Pusher. Ini adalah pemimpin kategori dalam API yang kuat untuk pengembang aplikasi yang membangun fitur komunikasi real-time yang dapat diskalakan.
Ada juga PubNub. PubNub memudahkan Anda untuk menambahkan kemampuan real time ke aplikasi Anda, tanpa mengkhawatirkan infrastrukturnya. Buat aplikasi yang memungkinkan pengguna Anda terlibat secara real time di seluruh perangkat seluler, browser, desktop, dan server.
Ably adalah alternatif lain. Ini menyediakan pesan terbitkan/berlangganan tanpa server (pub/sub), yang menskalakan dengan andal dengan kebutuhan Anda. Olahpesan dikirimkan di tepi menggunakan WebSocket. Platform Ably menyediakan infrastruktur real-time yang sangat tersedia, dapat diskalakan secara elastis, dan didistribusikan secara global, atas panggilan API.
Meskipun Pusher, PubNub, dan Ably adalah platform yang paling banyak diadopsi untuk pesan real-time, untuk skenario ini, Anda akan melakukan semuanya di Azure. Kami merekomendasikan SignalR sebagai platform masuk, karena memungkinkan komunikasi dua arah antara server dan klien. Ini juga merupakan alat sumber terbuka, dengan 7,9 ribu bintang GitHub dan 2,2 ribu fork GitHub.
Untuk informasi selengkapnya, lihat repositori sumber terbuka SignalR di GitHub.
Detail skenario
Dalam skenario ini, Anda akan melihat cara menyiapkan layanan olahpesan real time untuk berbagi lokasi langsung transaksi layanan pengiriman makanan. Contoh ini juga dapat berguna bagi mereka yang mencoba membangun platform berbagi lokasi real time untuk aplikasi web atau seluler mereka.
Anda akan menggunakan layanan SignalR yang dikonfigurasi dalam mode tanpa server untuk diintegrasikan dengan aplikasi Azure Functions yang dipicu oleh bus layanan, semuanya dengan menggunakan .NET Core.
Potensi penggunaan kasus
Kasus penggunaan lainnya ini memiliki pola desain yang sama:
- Berbagi lokasi real-time dengan perangkat klien
- Mendorong pemberitahuan kepada pengguna
- Memperbarui garis waktu
- Membuat ruang obrolan
Pertimbangan
Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian prinsip panduan yang dapat Anda gunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.
Berikut adalah beberapa hal yang perlu diingat saat Anda mengembangkan skenario ini, termasuk cara mengonfigurasi parameter dalam string koneksi Azure Service Bus di ServiceBusTrigger:
- Hub: Hub dapat dibandingkan dengan layanan streaming video. Anda dapat berlangganan hub untuk mengirim dan menerima pesan dari dan ke hub tersebut.
- Target: Target seperti saluran radio. Mereka menyertakan semua orang yang mendengarkan saluran target, dan mereka diberi tahu saat ada pesan baru di dalamnya.
Jika Anda dapat mengingat dua fitur sebelumnya dari platform SignalR, akan mudah untuk bangun dan berjalan dengan cepat.
Ketersediaan, skalabilitas, dan keamanan
Anda dapat mencapai ketersediaan tinggi dengan solusi ini dengan mengikuti apa yang dijelaskan di dua bagian berikutnya.
Pasangan regional
Setiap wilayah Azure dipasangkan dengan wilayah lain dalam geografi yang sama. Secara umum, pilih wilayah dari pasangan wilayah yang sama (misalnya, AS Timur 2 dan AS Tengah). Manfaat melakukannya meliputi:
- Jika ada pemadaman yang luas, pemulihan setidaknya satu wilayah dari setiap pasangan diprioritaskan.
- Pembaruan sistem Azure yang direncanakan diluncurkan ke wilayah yang dipasangkan secara berurutan untuk meminimalkan kemungkinan waktu henti.
- Dalam kebanyakan kasus, pasangan wilayah berada dalam geografi yang sama untuk memenuhi persyaratan residensi data.
- Namun, pastikan kedua wilayah mendukung semua layanan Azure yang diperlukan untuk aplikasi Anda. Lihat Layanan menurut wilayah. Untuk informasi selengkapnya tentang pasangan regional, lihat Kelangsungan bisnis dan pemulihan bencana (BCDR): Azure Paired Regions.
Azure Front Door
Unduh file Visio arsitektur ini.
Azure Front Door adalah titik entri yang dapat diskalakan dan aman untuk pengiriman cepat aplikasi global Anda. Saat Anda menggunakan perutean prioritas, perutean secara otomatis gagal jika wilayah utama menjadi tidak tersedia. Arsitektur multi-wilayah dapat memberikan ketersediaan yang lebih tinggi daripada menyebarkan ke satu wilayah. Jika pemadaman wilayah mempengaruhi wilayah utama, Anda dapat menggunakan Front Door untuk melakukan failover ke wilayah sekunder.
Arsitektur ini juga dapat membantu jika subsistem individu dari solusi gagal. Hentikan serangan lapisan jaringan dan aplikasi di edge dengan Web Application Firewall dan DDoS Protection. Perkuat layanan Anda dengan menggunakan seperangkat aturan yang dikelola Microsoft, dan buat aturan Anda sendiri untuk perlindungan kustom aplikasi Anda.
Front Door adalah kemungkinan titik kegagalan dalam sistem. Jika layanan gagal, klien tidak dapat mengakses aplikasi Anda selama waktu henti. Tinjau perjanjian tingkat layanan (SLA) Front Door dan tentukan apakah menggunakan Front Door saja memenuhi persyaratan bisnis Anda untuk ketersediaan tinggi. Jika tidak, pertimbangkan untuk menambahkan solusi manajemen lalu lintas lain sebagai cadangan. Jika layanan Front Door gagal, ubah rekaman nama kanonik (CNAME) Anda di DNS untuk menunjuk ke layanan manajemen lalu lintas lainnya. Anda harus melakukan langkah ini secara manual, dan aplikasi Anda tidak akan tersedia sampai perubahan DNS disebarluaskan.
Pengoptimalan biaya
Optimalisasi biaya adalah tentang mencari cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Gambaran umum pilar pengoptimalan biaya.
Mari kita asumsikan bahwa bisnis Anda memiliki 1.000 pesanan sehari dan perlu berbagi data lokasi dengan semuanya secara bersamaan. Perkiraan penggunaan Azure Anda untuk menyebarkan skenario ini akan mendekati USD192 per bulan, berdasarkan harga pada tanggal publikasi.
| Jenis layanan | Estimasi biaya bulanan |
|---|---|
| Azure Functions | USD119,40 |
| Azure SignalR Service | USD48,97 |
| Azure Service Bus | USD23,71 |
| Total | USD192,08 |
Menyebarkan skenario ini
Pengembangan Azure Functions
Aplikasi real-time tanpa server yang dibangun dengan Azure Functions dan Azure SignalR Service biasanya memerlukan dua Azure Functions:
- Fungsi
negotiateyang dipanggil klien untuk mendapatkan token akses SignalR Service yang valid dan URL titik akhir layanan. - Satu atau beberapa fungsi yang mengirim pesan atau mengelola keanggotaan grup.
SignalRFunctionApp
SignalRFunctionApp adalah aplikasi fungsi yang membuat instans Azure Functions, dengan pemicu bus layanan dengan SignalR.
Negotiate.cs
Fungsi ini dipicu oleh permintaan HTTP. Ini digunakan oleh aplikasi klien untuk mendapatkan token dari layanan SignalR, yang dapat digunakan klien untuk berlangganan hub. Fungsi ini harus diberi nama negotiate. Untuk informasi selengkapnya, lihat Azure Functions pengembangan dan konfigurasi dengan Azure SignalR Service,
Message.cs
Fungsi ini dipicu oleh pemicu bus layanan. Fungsi ini memiliki pengikatan data dengan layanan SignalR. Fungsi ini menarik pesan dari antrean dan meneruskannya ke hub SignalR.
Instruksi
Sebelum Anda mulai:
- Pastikan Anda memiliki antrean bus layanan yang disediakan di Azure.
- Pastikan Anda memiliki layanan SignalR yang disediakan dalam mode tanpa server di Azure.
- Masukkan string koneksi Anda (Service Bus dan SignalR) di file local.settings.json .
- Masukkan URL aplikasi klien (klien SignalR) di CORS (Berbagi Sumber Daya Lintas Asal). Untuk sintaks terbaru, lihat Azure Functions pengembangan dan konfigurasi dengan Azure SignalR Service.
- Masukkan nama antrean bus layanan Anda di pemicu bus layanan di file Message.cs .
Sekarang, mari kita konfigurasikan aplikasi klien untuk mengujinya. Pertama, ambil contoh sumber dari halaman GitHub arsitektur solusi .
Klien SignalR
Ini adalah aplikasi web .NET Core sederhana untuk berlangganan hub yang dibuat oleh SignalRFunctionApp. Ini menampilkan pesan yang diterima pada antrean bus layanan secara real time. Meskipun Anda dapat menggunakan SignalRFunctionApp untuk bekerja dengan klien seluler, mari kita tetap berpegang pada klien web untuk skenario ini di repositori ini.
Petunjuk
Pastikan SignalRFunctionApp berjalan.
Salin URL yang dihasilkan oleh fungsi negosiasi. Terlihat seperti ini:
http://localhost:7071/api/.Tempelkan URL dalam file chat.js , di dalam
signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build();.Jalankan aplikasi.
Status tersambung ketika klien web berhasil berlangganan ke hub SignalR.
SendToQueue.js
Skrip node.js ini mendorong pesan ke Azure Service Bus, sehingga Anda dapat menguji penyebaran yang baru saja Anda selesaikan.
Instruksi
Instal modul node Azure Service Bus (@azure/service-bus).
Masukkan string koneksi dan nama antrean Anda di skrip.
Jalankan skrip.
Langkah berikutnya
Anda dapat mengambil skenario ini ke lingkungan produksi Anda. Namun, pastikan layanan Azure Anda diatur ke skala. Misalnya, Azure Service Bus Anda harus diatur ke paket standar atau premium.
Anda dapat menyebarkan kode ke Azure Functions langsung dari Visual Studio. Untuk mempelajari cara menerbitkan kode Anda ke Azure Functions dari Visual Studio, ikuti panduan Ini adalah cara Anda membuat perangkat lunak.
Lihat cara bekerja dengan pengikatan Azure Service Bus di Azure Functions. Azure Functions mendukung pengikatan pemicu dan output untuk antrean dan topik bus layanan.
Lihat cara mengautentikasi dan mengirim pesan real-time ke klien yang tersambung ke Azure SignalR Service, dengan menggunakan pengikatan SignalR Service di Azure Functions. Azure Functions mendukung pengikatan input dan output untuk SignalR Service.