วิธีสร้าง Event-Driven APIs ด้วย Webhooks และ Message Queues

สรุปย่อ

Event-driven API ใช้ webhooks สำหรับการแจ้งเตือนภายนอกและคิวข้อความสำหรับการประมวลผลภายใน เผยแพร่เหตุการณ์ไปยังคิว (RabbitMQ, Kafka), ประมวลผลแบบอะซิงโครนัส, และแจ้งเตือนลูกค้าผ่าน webhooks Modern PetstoreAPI ใช้รูปแบบนี้สำหรับการประมวลผลคำสั่งซื้อ, การอัปเดตสินค้าคงคลัง, และการแจ้งเตือนการชำระเงิน

บทนำ

ลูกค้าทำการสั่งซื้อ API ของคุณจำเป็นต้องเรียกเก็บเงิน, อัปเดตสินค้าคงคลัง, ส่งอีเมล, แจ้งคลังสินค้า, และเรียกใช้ webhooks คุณจะทำทั้งหมดนี้แบบซิงโครนัสทำให้ลูกค้ารอนาน 10 วินาทีหรือไม่? หรือตอบกลับทันทีและประมวลผลแบบอะซิงโครนัส?

Event-driven API ตอบสนองรวดเร็วและประมวลผลในเบื้องหลัง ปลายทางสำหรับคำสั่งซื้อจะคืนค่า 201 Created ทันที เหตุการณ์จะเรียกการประมวลผลในเบื้องหลัง Webhooks จะแจ้งเตือนลูกค้าเมื่อเสร็จสิ้น

Modern PetstoreAPI ใช้สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ (event-driven) สำหรับคำสั่งซื้อ, การชำระเงิน, และสินค้าคงคลัง

Apidog ช่วยคุณทดสอบ webhooks, ตรวจสอบความถูกต้องของโฟลว์เหตุการณ์, และจำลองการประมวลผลแบบอะซิงโครนัส

ปุ่ม

สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์

Event-driven API จะเผยแพร่เหตุการณ์เมื่อมีสิ่งต่างๆ เกิดขึ้น บริการอื่นๆ จะสมัครรับและตอบสนอง

ส่วนประกอบ

Event Producer (ผู้สร้างเหตุการณ์) - ปลายทาง API ที่เผยแพร่เหตุการณ์
Event Bus/Queue (บัส/คิวเหตุการณ์) - ส่งต่อเหตุการณ์ (RabbitMQ, Kafka, SQS)
Event Consumer (ผู้บริโภคเหตุการณ์) - เวิร์กเกอร์เบื้องหลังที่ประมวลผลเหตุการณ์
Webhooks - แจ้งเตือนลูกค้าภายนอก

ลำดับการทำงาน

Client → POST /orders → API
API → Publish "order.created" → Queue
API → Return 201 Created → Client
Worker → Consume event → Process order
Worker → Publish "order.completed" → Queue
Webhook Worker → Send webhook → Client

Webhooks สำหรับเหตุการณ์ภายนอก

Webhooks แจ้งเตือนลูกค้าภายนอกเกี่ยวกับเหตุการณ์

// Publish event when order created
app.post('/v1/orders', async (req, res) => {
  const order = await createOrder(req.body);

  await eventBus.publish('order.created', {
    orderId: order.id,
    userId: order.userId,
    total: order.total
  });

  res.status(201).json(order);
});

// Background worker sends webhooks
eventBus.subscribe('order.completed', async (event) => {
  const webhooks = await getWebhooks(event.userId, 'order.completed');

  for (const webhook of webhooks) {
    await sendWebhook(webhook.url, {
      event: 'order.completed',
      data: event
    });
  }
});

คิวข้อความสำหรับเหตุการณ์ภายใน

คิวข้อความจัดการการประมวลผลเหตุการณ์ภายใน

ตัวอย่าง RabbitMQ

// Publisher
await publishEvent('order.created', { orderId: '019b4132' });

// Consumer
await consumeEvents('order.*', async (event) => {
  await processOrder(event);
});

Modern PetstoreAPI นำ Event-Driven API มาใช้อย่างไร

การประมวลผลคำสั่งซื้อ

POST /orders คืนค่า 201 ทันที
เผยแพร่เหตุการณ์ order.created
เวิร์กเกอร์ชำระเงินประมวลผลการชำระเงิน
เวิร์กเกอร์สินค้าคงคลังอัปเดตสต็อก
เวิร์กเกอร์อีเมลส่งการยืนยัน
เวิร์กเกอร์ Webhook แจ้งเตือนลูกค้า

ดู สถาปัตยกรรมเหตุการณ์ของ Modern PetstoreAPI

การทดสอบด้วย Apidog

Apidog รองรับการทดสอบ Event-driven API:

ทดสอบการส่ง webhook
ตรวจสอบความถูกต้องของเพย์โหลดเหตุการณ์
จำลองการประมวลผลแบบอะซิงโครนัส
ทดสอบตรรกะการลองใหม่

บทสรุป

Event-driven API ช่วยปรับปรุงประสิทธิภาพและความสามารถในการปรับขนาด ใช้ webhooks สำหรับการแจ้งเตือนภายนอกและคิวข้อความสำหรับการประมวลผลภายใน Modern PetstoreAPI แสดงให้เห็นถึงรูปแบบการขับเคลื่อนด้วยเหตุการณ์ที่พร้อมใช้งานในสภาพแวดล้อมจริง

คำถามที่พบบ่อย

ความแตกต่างระหว่าง webhooks กับคิวข้อความคืออะไร?

Webhooks แจ้งเตือนลูกค้าภายนอกผ่าน HTTP คิวข้อความจัดการการสื่อสารระหว่างบริการภายใน

ควรใช้คิวข้อความใด?

RabbitMQ สำหรับความเรียบง่าย, Kafka สำหรับปริมาณงานสูง, AWS SQS สำหรับบริการที่มีการจัดการ

คุณจัดการกับข้อผิดพลาดของ webhook อย่างไร?

ใช้ตรรกะการลองใหม่ด้วย exponential backoff (ดูคู่มือความน่าเชื่อถือของ webhook ของเรา)

คุณสามารถใช้เหตุการณ์โดยไม่มีคิวข้อความได้หรือไม่?

ได้ แต่คิวจะให้ความคงทน, การลองใหม่, และการแยกส่วนประกอบ

คุณทดสอบ Event-driven API อย่างไร?

ใช้ Apidog เพื่อทดสอบ webhooks และตรวจสอบความถูกต้องของโฟลว์เหตุการณ์