สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์
สำรวจหลักการและการนำระบบที่ขับเคลื่อนด้วยเหตุการณ์ไปใช้ โดยใช้คิวข้อความและตัวกลางรับส่งข้อความใน Clojure
สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ เป็นบทเรียน Clojure Functional Programming & JVM Backend Development ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Clojure Functional Programming & JVM Backend Development และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Clojure Functional Programming & JVM Backend Development มีบทเรียนทั้งหมด 4 บทเรียน
บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ
Intro to Event-Driven Systems
Event-Driven Architecture (EDA) is a design pattern where components communicate by emitting and reacting to events. Instead of directly calling functions, parts of your system publish events when something interesting happens.
This approach helps create systems that are:
- Decoupled: Components don't need to know about each other.
- Scalable: Easily add more consumers without changing producers.
- Resilient: Failures in one part are less likely to bring down the whole system.
Events: The Core Message
An event is a record of something that happened. It's usually a small, immutable message containing data about the event, but not the command to perform an action.
Think of it like a newspaper headline: "User Signed Up" or "Order Placed".
Key characteristics:
- Fact: It describes something that has occurred.
- Immutable: Once published, an event doesn't change.
- Informative: Contains relevant data (e.g., user ID, timestamp).
Roles: Producers & Consumers
In an EDA, there are two main roles:
- Producers: These are components that create and publish events. When a user signs up, the "User Service" might produce a "User Signed Up" event.
- Consumers: These are components that subscribe to and react to events. A "Welcome Email Service" might consume "User Signed Up" events to send a welcome email.
The producer doesn't care who consumes the event, and consumers don't care who produced it. This enables powerful decoupling!
Message Brokers: The Hub
How do producers and consumers find each other? That's where a message broker comes in. A broker acts as an intermediary, receiving events from producers and delivering them to interested consumers.
It provides:
- Decoupling: Producers and consumers don't directly communicate.
- Durability: Events can be stored until consumers are ready.
- Routing: Directs events to the correct consumers based on rules.
Common examples include RabbitMQ, Apache Kafka, and AWS SQS.
Clojure & Message Libraries
Clojure, with its focus on immutability and concurrency, is well-suited for event-driven systems. We often use dedicated client libraries to interact with message brokers.
For RabbitMQ, a popular choice in Clojure is langohr. It provides a straightforward API to connect, publish, and consume messages.
Let's look at how to set up a basic connection and publish an event using langohr (conceptually, as full setup is complex for a tiny snippet).
Publishing an Event
To publish an event, we connect to the message broker and send our event data to a specific exchange. An exchange is like a post office that routes messages.
Here's a simplified example of publishing a "user.signed-up" event to a topic exchange named "events":
(ns coddykit.producer
(:require [langohr.core :as lc]
[langohr.channel :as lch]
[langohr.exchange :as le]
[langohr.basic :as lb]
[cheshire.core :as json]))
(defn -main [& args]
(let [conn (lc/connect {:host "localhost"})
ch (lch/open conn)
event-data {:user-id 123 :username "Alice" :timestamp (str (java.time.Instant/now))}]
(le/declare ch "events" "topic" {:durable true}) ; Declare topic exchange
(lb/publish ch "events" "user.signed-up" (json/generate-string event-data)
{:content-type "application/json"})
(println "Published user.signed-up event: " event-data)
(lc/close ch)
(lc/close conn)))Consuming an Event
Consumers connect to the broker and declare a queue. They then bind this queue to an exchange with a routing key to receive specific types of events. When an event arrives, a handler function processes it.
This example shows a consumer listening for "user.signed-up" events:
(ns coddykit.consumer
(:require [langohr.core :as lc]
[langohr.channel :as lch]
[langohr.queue :as lq]
[langohr.basic :as lb]
[langohr.consumers :as lcons]
[cheshire.core :as json]))
(defn handle-message [ch metadata payload]
(let [event (json/parse-string (String. payload "UTF-8") true)]
(println "Received event: " event)
(println "User" (:username event) "signed up! Sending welcome email...")
; Acknowledge the message to remove it from the queue
(lb/ack ch (:delivery-tag metadata))))
(defn -main [& args]
(let [conn (lc/connect {:host "localhost"})
ch (lch/open conn)
queue-name "welcome-email-queue"]
(lq/declare ch queue-name {:durable true :exclusive false :auto-delete false})
(lq/bind ch queue-name "events" {:routing-key "user.signed-up"}) ; Bind to topic exchange
(println "Waiting for messages. To exit, press Ctrl+C...")
(lcons/create-default ch queue-name handle-message {:auto-ack false})
; Keep the main thread alive to listen for messages
(while true (Thread/sleep 1000))))Why EDA is Powerful
Beyond simple decoupling, EDA offers significant advantages for complex systems:
- Scalability: Easily add more consumers to process events in parallel, or scale producers independently.
- Resilience: If a consumer fails, the message broker holds events until it recovers, preventing data loss.
- Auditability: Events can be logged, providing a clear audit trail of system activities.
- Real-time Processing: React to changes instantly across different services.
It's a foundational pattern for microservices and distributed systems.
Event Sourcing Concept
A powerful related concept is Event Sourcing. Instead of storing the current state of an application, you store all changes as a sequence of immutable events.
The application state can then be reconstructed by replaying these events. This provides a complete historical record and simplifies complex state management in some scenarios.
While related, EDA focuses on communication between services, whereas Event Sourcing focuses on how a single service manages its own state.
Quick Check: EDA Principles
Consider a system where a user places an order. Which of the following statements best describes an event-driven approach?
Recap & Next Steps
Great job! You've explored the fundamentals of Event-Driven Architectures.
- We learned that events are immutable facts about things that happened.
- Producers publish events, and consumers react to them.
- A message broker facilitates this communication, ensuring decoupling and resilience.
- Clojure libraries like
langohrmake it easy to integrate with brokers like RabbitMQ.
EDA is a crucial pattern for building scalable, resilient, and decoupled backend systems. Keep practicing with messaging systems to solidify your understanding!
คำถามที่พบบ่อย
บทเรียน “สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Clojure Functional Programming & JVM Backend Development ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Clojure Functional Programming & JVM Backend Development มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์”
สำรวจหลักการและการนำระบบที่ขับเคลื่อนด้วยเหตุการณ์ไปใช้ โดยใช้คิวข้อความและตัวกลางรับส่งข้อความใน Clojure คุณปฏิบัติ Clojure Functional Programming & JVM Backend Development ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Clojure Functional Programming & JVM Backend Development หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Clojure Functional Programming & JVM Backend Development บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน
บทเรียน “สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Clojure Functional Programming & JVM Backend Development นี้ได้ไหม
ได้ บทเรียน Clojure Functional Programming & JVM Backend Development ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- การสร้าง RESTful API
- สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์
- รูปแบบการออกแบบระบบและการขยายขนาด
- การยืนยันตัวตนและการอนุญาต