Azure Service Bus สำหรับการส่งข้อความแบบแยกส่วน
สร้างเนมสเปซ Service Bus ที่มีคิวและหัวข้อ ส่งและรับข้อความจากแอปพลิเคชัน และกำหนดค่าคิวจดหมายตายสำหรับจัดการข้อความที่ล้มเหลว
Azure Service Bus สำหรับการส่งข้อความแบบแยกส่วน เป็นบทเรียน Azure Fundamentals ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Azure Fundamentals และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Azure Fundamentals มีบทเรียนทั้งหมด 4 บทเรียน
เหตุใดจึงควรแยกส่วนด้วยการส่งข้อความ
ในสถาปัตยกรรมที่เชื่อมโยงกันอย่างแน่นหนา บริการต่าง ๆ จะเรียกใช้กันแบบพร้อมกัน — หากบริการปลายทางทำงานช้าหรือไม่พร้อมใช้งาน ผู้เรียกใช้ก็จะถูกระงับหรือทำงานล้มเหลวไปด้วย คิวการส่งข้อความจะเพิ่มบัฟเฟอร์แบบไม่พร้อมกันระหว่างผู้ผลิตและผู้บริโภค ดังนั้นบริการปลายทางที่ทำงานช้าจะไม่ทำให้ความล้มเหลวลุกลามย้อนกลับไปยังต้นทาง Azure Service Bus เป็นบริการส่งข้อความระดับองค์กรของ Microsoft ซึ่งมีทั้งคิว (แบบจุดต่อจุด) และหัวข้อ (แบบเผยแพร่-สมัครรับข้อมูล) พร้อมความสามารถในการรับประกันการส่ง การจัดลำดับ และการส่งข้อความไปยังคิวจดหมายตีกลับ
เนมสเปซและระดับบริการของ Service Bus
เนมสเปซ Service Bus คือคอนเทนเนอร์ระดับบนสุดสำหรับเอนทิตีการส่งข้อความทั้งหมด (คิวและหัวข้อ) และมีปลายทาง FQDN (เช่น myns.servicebus.windows.net) เนมสเปซมีสามระดับ ได้แก่ Basic (รองรับเฉพาะคิว ไม่รองรับหัวข้อ ขนาดข้อความสูงสุด 256 KB), Standard (รองรับคิวและหัวข้อ ขนาดสูงสุด 256 KB) และ Premium (รองรับคิวและหัวข้อ ข้อความขนาดสูงสุด 100 MB ความจุเฉพาะ การผสานรวม VNet และการกู้คืนจากความเสียหายทางภูมิศาสตร์) จำเป็นต้องใช้ Premium สำหรับภาระงานจริงที่ต้องการประสิทธิภาพตาม SLA
# Create a Service Bus namespace (Standard tier)
az servicebus namespace create \
--resource-group myRG \
--name myservicebusns \
--location eastus \
--sku Standardคิว: การส่งข้อความแบบจุดต่อจุด
คิว Service Bus จัดเก็บข้อความตามลำดับ FIFO และส่งข้อความแต่ละรายการให้กับผู้บริโภคเพียงหนึ่งราย ผู้บริโภคจะรับข้อความโดยใช้กลไกตรวจดูและล็อก: ข้อความจะถูกซ่อนจากผู้บริโภครายอื่นชั่วคราวระหว่างการประมวลผล หากผู้บริโภคดำเนินการสำเร็จ จะเรียกใช้ CompleteMessage() เพื่อนำข้อความออกจากคิว หากการประมวลผลล้มเหลว ผู้บริโภคจะเรียกใช้ AbandonMessage() และข้อความจะกลับมาแสดงอีกครั้งเพื่อให้ลองใหม่ หลังจากพยายามส่งครบจำนวนที่กำหนดได้ ข้อความที่ไม่สามารถประมวลผลได้จะถูกย้ายไปยังคิวจดหมายตีกลับ (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หัวข้อและการสมัครรับข้อมูล
หัวข้อใช้รูปแบบเผยแพร่-สมัครรับข้อมูล: ผู้ผลิตจะส่งข้อความไปยังหัวข้อ และการสมัครรับข้อมูลจำนวนเท่าใดก็ได้ในหัวข้อนั้นจะได้รับสำเนาข้อความคนละหนึ่งชุด การสมัครรับข้อมูลสามารถมีตัวกรอง (นิพจน์ SQL หรือความสัมพันธ์) เพื่อรับเฉพาะข้อความบางส่วน — ตัวอย่างเช่น การสมัครรับข้อมูล HighPriority ที่รับเฉพาะข้อความซึ่งคุณสมบัติ Priority มีค่าเท่ากับ High วิธีนี้ทำให้หัวข้อเดียวกระจายข้อความไปยังบริการปลายทางหลายรายการได้ โดยแต่ละบริการสนใจเหตุการณ์คนละส่วน
# 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'"'"''การส่งและรับข้อความ
Azure Service Bus SDK มี ServiceBusClient สำหรับการส่งและรับข้อความ หากต้องการส่ง ให้สร้าง ServiceBusSender และเรียกใช้ SendMessageAsync() หากต้องการรับ ให้สร้าง ServiceBusReceiver และเรียกใช้ ReceiveMessageAsync() (แบบดึงข้อมูล) หรือใช้ ServiceBusProcessor พร้อมตัวจัดการเหตุการณ์สำหรับการประมวลผลต่อเนื่องแบบผลักข้อมูล การใช้ DefaultAzureCredential ร่วมกับ Service Bus SDK ช่วยขจัดความจำเป็นในการใช้สตริงการเชื่อมต่อ และยังคงรูปแบบที่ไม่ต้องใช้รหัสผ่าน
# 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')คิวจดหมายตีกลับ
คิวจดหมายตีกลับ (DLQ) คือคิวย่อยที่รับข้อความซึ่งไม่สามารถส่งได้โดยอัตโนมัติ ข้อความจะถูกส่งไปยังคิวจดหมายตีกลับเมื่อมีกรณีใดกรณีหนึ่งต่อไปนี้: ส่งเกินจำนวนครั้งสูงสุด ข้อความหมดอายุ (TTL ผ่านพ้นแล้ว) หรือไม่ผ่านการประเมินตัวกรองการสมัครรับข้อมูลของหัวข้อ การตรวจสอบ DLQ เป็นสิ่งสำคัญ — DLQ ที่เพิ่มขึ้นบ่งชี้ถึงความล้มเหลวในการประมวลผลอย่างเป็นระบบ ข้อความใน DLQ จะยังคงมีเนื้อหาเดิม พร้อมคุณสมบัติเหตุผลที่ส่งไปยังคิวจดหมายตีกลับและคำอธิบายที่ Service Bus เพิ่มให้ เพื่อช่วยวิเคราะห์สาเหตุที่แท้จริง
# Read messages from the dead-letter queue
az servicebus queue show \
--resource-group myRG \
--namespace-name myservicebusns \
--name 'orders/$DeadLetterQueue' \
--query 'countDetails.deadLetterMessageCount'เซสชันข้อความสำหรับการจัดลำดับ
เซสชันช่วยให้จัดลำดับข้อความที่อยู่ในกลุ่มเชิงตรรกะเดียวกันได้อย่างเคร่งครัด ข้อความแต่ละรายการจะติดแท็กด้วย SessionId (เช่น รหัสลูกค้าหรือรหัสคำสั่งซื้อ) และผู้บริโภคที่รองรับเซสชันจะรับข้อความทั้งหมดของเซสชันที่กำหนดตามลำดับ FIFO โดยเฉพาะ เซสชันจำเป็นสำหรับเวิร์กโฟลว์ที่ต้องดำเนินขั้นตอนตามลำดับ — เช่น การประมวลผลเหตุการณ์ทั้งหมดของคำสั่งซื้อหนึ่งรายการ: Created → PaymentReceived → Shipped → Delivered เซสชันจะถูกเปิดใช้งานเมื่อสร้างคิวหรือการสมัครรับข้อมูล
Service Bus เทียบกับ Event Grid และ Event Hubs
บริการส่งข้อความ Azure ทั้งสามรายการนี้มักถูกเข้าใจสับสนกัน: Service Bus ใช้สำหรับการส่งข้อความระดับองค์กรที่เชื่อถือได้และเป็นธุรกรรม โดยมีการจัดลำดับ เซสชัน และ DLQ เหมาะสำหรับการประมวลผลคำสั่งซื้อ ธุรกรรมทางการเงิน และการประสานงานเวิร์กโฟลว์ Event Grid ใช้สำหรับการกำหนดเส้นทางเหตุการณ์แบบตอบสนอง (มีการอัปโหลดบล็อบ หรือมีการลบ VM) และกระจายไปยังตัวจัดการหลายรายการ แต่ไม่มีการจัดลำดับหรือเล่นซ้ำ Event Hubs ใช้สำหรับการสตรีมเหตุการณ์ปริมาณงานสูง (หลายล้านเหตุการณ์ต่อวินาที) พร้อมความสามารถในการเล่นซ้ำ เหมาะสำหรับข้อมูลการวัดระยะไกลจาก IoT และการรับข้อมูลบันทึก โปรดเลือกตามข้อกำหนดด้านการจัดลำดับ ปริมาณงาน และความคงทน
การกู้คืนจากความเสียหายทางภูมิศาสตร์
การกู้คืนจากความเสียหายทางภูมิศาสตร์ของ Service Bus (Geo-DR) จะจำลองข้อมูลเมตาของเนมสเปซ (คิว หัวข้อ การสมัครรับข้อมูล และนโยบายการเข้าถึง) ไปยังภูมิภาครอง ภูมิภาคที่จับคู่กันจะใช้ชื่อโฮสต์นามแฝงเดียวกัน หากภูมิภาคหลักล้มเหลว คุณจะเริ่มกระบวนการสลับไปใช้ระบบสำรอง และนามแฝงจะชี้ไปยังภูมิภาครอง โปรดทราบว่าข้อมูลข้อความ (ข้อความที่อยู่ระหว่างการส่ง) จะไม่ถูกจำลองในระดับ Standard — เฉพาะ Geo-DR ของระดับ Premium เท่านั้นที่จำลองข้อความ สำหรับการส่งข้อความที่มีความสำคัญต่อภารกิจ ให้ใช้ Premium + Geo-DR เพื่อให้เป็นไปตามข้อกำหนด RTO และ RPO
การปรับขนาดและเอนทิตีแบบแบ่งพาร์ติชัน
สำหรับสถานการณ์ที่มีปริมาณงานสูง ให้เปิดใช้การแบ่งพาร์ติชันในคิวและหัวข้อขณะสร้าง เอนทิตีแบบแบ่งพาร์ติชันจะใช้ตัวรับส่งข้อความและส่วนจัดเก็บหลายชุดภายใน เพื่อเพิ่มความจุของปริมาณงานเป็นทวีคูณ ในระดับ Standard เอนทิตีแบบแบ่งพาร์ติชันมีขนาดรวมสูงสุด 80 GB ข้อความแต่ละรายการจะถูกส่งไปยังพาร์ติชันตามคุณสมบัติ PartitionKey (ค่าเริ่มต้นคือรหัสเซสชัน หากเปิดใช้เซสชัน) การแบ่งพาร์ติชันเป็นการตัดสินใจเพียงครั้งเดียวตอนสร้าง — คุณไม่สามารถแบ่งพาร์ติชันคิวที่มีอยู่แล้วได้ ใช้ระดับ Premiumสำหรับปริมาณงานที่รับประกันสูงสุดโดยไม่ต้องจัดการความซับซ้อนของการแบ่งพาร์ติชัน
# Create a partitioned queue (Standard tier)
az servicebus queue create \
--resource-group myRG \
--namespace-name myservicebusns \
--name orders-partitioned \
--enable-partitioning trueการตรวจสอบสถานะ Service Bus
เมตริกสำคัญของ Service Bus ที่ควรตรวจสอบใน Azure Monitor ได้แก่ Active Messages (ความลึกของคิว — ความลึกที่เพิ่มขึ้นบ่งชี้ว่าผู้บริโภคประมวลผลไม่ทัน), Dead-lettered Messages (ความล้มเหลวในการประมวลผล), Server Errors และ User Errors (ปัญหาการตรวจสอบสิทธิ์และการจำกัดอัตรา) และ Incoming Requests (ปริมาณงานโดยรวม) ให้กำหนดค่าการแจ้งเตือนเมตริกเพื่อให้ทีมปฏิบัติการได้รับการแจ้งเตือนเมื่อคิวจดหมายตีกลับเพิ่มขึ้นเกินเกณฑ์ หรือเมื่อไม่มีการรับข้อความที่ใช้งานอยู่เป็นระยะเวลาต่อเนื่อง
ตรวจสอบความเข้าใจอย่างรวดเร็ว
ทดสอบความเข้าใจแนวคิด Microsoft Azure Fundamentals (AZ-900) จากบทเรียนนี้
สรุปบทเรียน
ในบทเรียนนี้ คุณได้เรียนรู้ว่า คิว Service Busมอบการส่งข้อความแบบจุดต่อจุดด้วยการส่งแบบตรวจดูและล็อก พร้อมคิวจดหมายตีกลับสำหรับข้อความที่ล้มเหลว, หัวข้อและการสมัครรับข้อมูลช่วยกระจายข้อความไปยังผู้บริโภคหลายรายด้วยกฎตัวกรอง และเซสชันช่วยให้ประมวลผลข้อความของกลุ่มเชิงตรรกะเดียวกันตามลำดับ ต่อไปเราจะสำรวจ Azure Container Apps สำหรับการปรับใช้ไมโครเซอร์วิสสมัยใหม่
คำถามที่พบบ่อย
บทเรียน “Azure Service Bus สำหรับการส่งข้อความแบบแยกส่วน” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “Azure Service Bus สำหรับการส่งข้อความแบบแยกส่วน” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Azure Fundamentals ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Azure Fundamentals มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “Azure Service Bus สำหรับการส่งข้อความแบบแยกส่วน”
สร้างเนมสเปซ Service Bus ที่มีคิวและหัวข้อ ส่งและรับข้อความจากแอปพลิเคชัน และกำหนดค่าคิวจดหมายตายสำหรับจัดการข้อความที่ล้มเหลว คุณปฏิบัติ Azure Fundamentals ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Azure Fundamentals หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Azure Fundamentals บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน
บทเรียน “Azure Service Bus สำหรับการส่งข้อความแบบแยกส่วน” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Azure Fundamentals นี้ได้ไหม
ได้ บทเรียน Azure Fundamentals ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- ข้อมูลประจำตัวที่จัดการเพื่อการยืนยันตัวตนแบบไร้รหัสผ่าน
- Azure Service Bus สำหรับการส่งข้อความแบบแยกส่วน
- Azure Container Apps
- เวิร์กโฟลว์นักพัฒนาแบบต้นจนจบ