Azure Fundamentals · Pelajaran

Azure Service Bus untuk Pesan yang Terpisah

Buat namespace Service Bus dengan antrean dan topik, kirim dan terima pesan dari aplikasi, lalu konfigurasikan antrean surat mati untuk menangani pesan yang gagal.

Azure Service Bus untuk Pesan yang Terpisah adalah pelajaran Azure Fundamentals gratis di CoddyKit. Ini adalah pelajaran 2 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar Azure Fundamentals, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus Azure Fundamentals mencakup 4 pelajaran total.

Mengapa Menggunakan Perpesanan untuk Mengurangi Ketergantungan?

Dalam arsitektur yang sangat saling bergantung, layanan saling memanggil secara sinkron — jika layanan hilir lambat atau tidak aktif, pemanggil juga akan terhenti atau gagal. Antrean perpesanan menyediakan penyangga asinkron antara produsen dan konsumen, sehingga layanan hilir yang lambat tidak menyebabkan kegagalan berantai ke hulu. Azure Service Bus adalah layanan perpesanan tingkat perusahaan dari Microsoft yang menyediakan antrean (titik ke titik) dan topik (publikasi-langganan) dengan kemampuan pengiriman terjamin, pengurutan, dan pengiriman ke antrean pesan mati.

Namespace dan Tingkatan Service Bus

Sebuah namespace Service Bus adalah wadah tingkat teratas untuk semua entitas perpesanan (antrean dan topik) dan menyediakan titik akhir FQDN (misalnya, myns.servicebus.windows.net). Namespace tersedia dalam tiga tingkatan: Dasar (hanya antrean, tanpa topik, ukuran pesan maksimum 256 KB), Standard (antrean + topik, maksimum 256 KB), dan Premium (antrean + topik, pesan hingga 100 MB, kapasitas khusus, integrasi VNet, pemulihan bencana geografis). Premium diperlukan untuk beban kerja produksi yang membutuhkan kinerja yang didukung SLA.

# Create a Service Bus namespace (Standard tier)
az servicebus namespace create \
  --resource-group myRG \
  --name myservicebusns \
  --location eastus \
  --sku Standard

Antrean: Perpesanan Titik ke Titik

Sebuah antrean Service Bus menyimpan pesan dalam urutan FIFO dan mengirimkan setiap pesan tepat kepada satu konsumen. Konsumen menerima pesan menggunakan mekanisme peek-lock: pesan disembunyikan sementara dari konsumen lain selama diproses. Jika konsumen berhasil menyelesaikan pemrosesan, konsumen memanggil CompleteMessage() untuk menghapus pesan dari antrean. Jika pemrosesan gagal, konsumen memanggil AbandonMessage() dan pesan kembali terlihat untuk dicoba lagi. Setelah jumlah percobaan pengiriman yang dapat dikonfigurasi tercapai, pesan yang tidak dapat diproses dipindahkan ke antrean pesan mati (DLQ).

# Create a Service Bus queue with DLQ enabled
az servicebus queue create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --name orders \
  --max-delivery-count 5 \
  --default-message-time-to-live P7D \
  --dead-lettering-on-message-expiration true

Topik dan Langganan

Topik menerapkan pola publikasi-langganan: produsen mengirim pesan ke sebuah topik, dan sejumlah langganan pada topik tersebut masing-masing menerima salinan pesan. Langganan dapat memiliki filter (ekspresi SQL atau korelasi) untuk hanya menerima sebagian pesan — misalnya, langganan HighPriority yang hanya menerima pesan dengan properti Priority bernilai High. Hal ini memungkinkan satu topik menyebarkan pesan ke banyak layanan hilir, yang masing-masing tertarik pada subset peristiwa yang berbeda.

# Create a topic and two subscriptions with filters
az servicebus topic create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --name order-events

az servicebus topic subscription create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --topic-name order-events \
  --name high-priority-sub

az servicebus topic subscription rule create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --topic-name order-events \
  --subscription-name high-priority-sub \
  --name PriorityFilter \
  --filter-sql-expression 'Priority = '"'"'High'"'"''

Mengirim dan Menerima Pesan

Azure Service Bus SDK menyediakan ServiceBusClient untuk mengirim dan menerima pesan. Untuk mengirim, buat ServiceBusSender dan panggil SendMessageAsync(). Untuk menerima, buat ServiceBusReceiver dan panggil ReceiveMessageAsync() (berbasis penarikan), atau gunakan ServiceBusProcessor dengan penangan peristiwa untuk pemrosesan berkelanjutan berbasis dorongan. Penggunaan DefaultAzureCredential dengan Service Bus SDK menghilangkan kebutuhan akan string koneksi dan mempertahankan pola tanpa kata sandi.

# Python: Send a message to a Service Bus queue
from azure.servicebus import ServiceBusClient, ServiceBusMessage
from azure.identity import DefaultAzureCredential

credential = DefaultAzureCredential()
client = ServiceBusClient(
  fully_qualified_namespace='myservicebusns.servicebus.windows.net',
  credential=credential
)
with client.get_queue_sender(queue_name='orders') as sender:
    msg = ServiceBusMessage('{ 'orderId': '12345', 'amount': 99.99 }')
    sender.send_messages(msg)
    print('Message sent')

Antrean Pesan Mati

Antrean pesan mati (DLQ) adalah subantrean yang secara otomatis menerima pesan yang tidak dapat dikirimkan. Pesan dikirim ke antrean pesan mati ketika: jumlah pengirimannya melebihi batas maksimum, masa berlakunya habis (TTL berlalu), atau pesan gagal dalam evaluasi filter langganan topik. Pemantauan DLQ sangat penting — DLQ yang terus bertambah menunjukkan kegagalan pemrosesan yang sistematis. Pesan DLQ mempertahankan konten aslinya, ditambah properti alasan pengiriman ke antrean pesan mati dan deskripsi yang ditambahkan oleh Service Bus untuk membantu mendiagnosis akar masalah.

# Read messages from the dead-letter queue
az servicebus queue show \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --name 'orders/$DeadLetterQueue' \
  --query 'countDetails.deadLetterMessageCount'

Sesi Pesan untuk Pengurutan

Sesi memungkinkan pengurutan ketat pesan yang termasuk dalam grup logis yang sama. Setiap pesan diberi tag SessionId (misalnya, ID pelanggan atau ID pesanan), dan konsumen yang mendukung sesi menerima semua pesan untuk sesi tertentu secara eksklusif dalam urutan FIFO. Sesi sangat penting untuk alur kerja yang langkah-langkahnya harus dijalankan secara berurutan — seperti memproses semua peristiwa untuk pesanan tertentu: Created → PaymentReceived → Shipped → Delivered. Sesi diaktifkan saat pembuatan antrean atau langganan.

Service Bus vs. Event Grid vs. Event Hubs

Ketiga layanan perpesanan Azure ini sering tertukar: Service Bus digunakan untuk perpesanan perusahaan yang andal dan transaksional, dengan pengurutan, sesi, dan DLQ — sesuai untuk pemrosesan pesanan, transaksi keuangan, dan orkestrasi alur kerja. Event Grid digunakan untuk perutean peristiwa reaktif (sebuah blob diunggah, sebuah VM dihapus) dengan penyebaran ke beberapa penangan, tetapi tanpa pengurutan atau pemutaran ulang. Event Hubs digunakan untuk pengaliran peristiwa berthroughput tinggi (jutaan peristiwa per detik) dengan kemampuan pemutaran ulang — sesuai untuk telemetri IoT dan penyerapan log. Pilih berdasarkan kebutuhan pengurutan, throughput, dan ketahanan.

Pemulihan Bencana Geografis

Pemulihan Bencana Geografis (Geo-DR) Service Bus mereplikasi metadata namespace (antrean, topik, langganan, dan kebijakan akses) ke wilayah sekunder. Wilayah yang dipasangkan menggunakan satu nama host alias; jika wilayah utama gagal, Anda memulai failover dan alias tersebut diarahkan ke wilayah sekunder. Perhatikan bahwa data pesan (pesan yang sedang diproses) tidak direplikasi pada tingkat Standard — hanya Geo-DR tingkat Premium yang mereplikasi pesan. Untuk perpesanan yang sangat penting, gunakan Premium + Geo-DR untuk memenuhi persyaratan RTO dan RPO.

Penskalaan dan Entitas yang Dipartisi

Untuk skenario throughput tinggi, aktifkan partisi pada antrean dan topik saat pembuatan. Entitas yang dipartisi menggunakan beberapa broker pesan dan fragmen penyimpanan secara internal sehingga kapasitas throughput meningkat berlipat ganda. Pada tingkat Standard, entitas yang dipartisi memiliki ukuran total hingga 80 GB. Setiap pesan dirutekan ke partisi berdasarkan properti PartitionKey (secara bawaan menggunakan ID sesi jika sesi diaktifkan). Partisi adalah keputusan satu kali saat pembuatan — Anda tidak dapat mempartisi antrean yang sudah ada. Gunakan tingkat Premium untuk throughput terjamin tertinggi tanpa kerumitan partisi.

# Create a partitioned queue (Standard tier)
az servicebus queue create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --name orders-partitioned \
  --enable-partitioning true

Memantau Kesehatan Service Bus

Metrik utama Service Bus yang perlu dipantau di Azure Monitor: Active Messages (kedalaman antrean — kedalaman yang meningkat menunjukkan keterlambatan konsumen), Dead-lettered Messages (kegagalan pemrosesan), Server Errors dan User Errors (masalah autentikasi dan pembatasan laju), serta Incoming Requests (throughput keseluruhan). Konfigurasikan peringatan metrik agar tim operasional diberi tahu ketika antrean pesan mati bertambah melampaui ambang batas atau ketika pesan aktif tidak dikonsumsi selama periode yang berkelanjutan.

Pemeriksaan Singkat

Uji pemahaman Anda tentang konsep Microsoft Azure Fundamentals (AZ-900) dari pelajaran ini.

Rangkuman Pelajaran

Dalam pelajaran ini Anda telah mempelajari: antrean Service Bus menyediakan perpesanan titik ke titik dengan pengiriman peek-lock dan antrean pesan mati untuk pesan yang gagal, topik dan langganan menyebarkan pesan ke banyak konsumen dengan aturan filter, dan sesi memungkinkan pemrosesan berurutan untuk pesan yang termasuk dalam grup logis yang sama. Selanjutnya kita akan mempelajari Azure Container Apps untuk menerapkan layanan mikro modern.

Pertanyaan yang Sering Diajukan

Apakah pelajaran “Azure Service Bus untuk Pesan yang Terpisah” gratis?

Ya — teks lengkap “Azure Service Bus untuk Pesan yang Terpisah” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus Azure Fundamentals, upgrade ke CoddyKit PRO. Kursus Azure Fundamentals mencakup 4 pelajaran total.

Apa yang akan aku pelajari di “Azure Service Bus untuk Pesan yang Terpisah”?

Buat namespace Service Bus dengan antrean dan topik, kirim dan terima pesan dari aplikasi, lalu konfigurasikan antrean surat mati untuk menangani pesan yang gagal. Kamu berlatih Azure Fundamentals dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.

Apakah aku perlu pengalaman untuk memulai Azure Fundamentals?

Tidak diperlukan pengalaman sebelumnya. Azure Fundamentals di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 2 dari 4.

Berapa lama pelajaran “Azure Service Bus untuk Pesan yang Terpisah” memakan waktu?

Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.

Bisakah aku menulis dan menjalankan kode dalam pelajaran Azure Fundamentals ini?

Ya. Setiap pelajaran Azure Fundamentals menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.

Semua pelajaran dalam kursus ini

Managed Identity untuk Autentikasi Tanpa Kata Sandi
Azure Service Bus untuk Pesan yang Terpisah
Azure Container Apps
Alur Kerja Pengembang Menyeluruh

← Kembali ke Azure Fundamentals