Ereignisgesteuerte Microservices
Dienste über einen Broker mit Spring Cloud Stream verbinden, sodass sie über Ereignisse statt fragiler Direktaufrufe kommunizieren.
Deutsche Übersetzung in Arbeit
Diese Lektion ist noch nicht ins Deutsche übersetzt und wird daher auf Englisch angezeigt. Der Rest der Seite ist vollständig lokalisiert.
Auf dieser Seite
In the Reactive & Messaging module you learned brokers - Kafka and RabbitMQ. In a microservice system, event-driven communication becomes the preferred way for services to talk, because direct calls make services brittle and tightly coupled. Spring Cloud Stream gives you a broker-agnostic way to wire services together with events.
Events over direct calls
Recall the trade-off from the resilience lesson: if lending calls notification directly and notification is down, lending suffers. Publish an event instead, and lending doesn't care who's listening or whether they're up right now - the broker holds the event until they are:
// producer: lending emits an event
@Bean
Supplier<BookBorrowedEvent> bookBorrowed() { ... }
// consumer: notification reacts, in a separate service
@Bean
Consumer<BookBorrowedEvent> handleBorrow() {
return event -> sendNotification(event);
}Spring Cloud Stream binds these Supplier/Consumer/Function beans to broker destinations
(a Kafka topic or RabbitMQ queue) via configuration - so your code is just plain functions, and
the wiring is external.
Broker-agnostic by design
The same functional code runs on Kafka or RabbitMQ by swapping a binder dependency and some config - you don't rewrite your producers and consumers. That means you can choose (or change) the broker without touching business logic.
You don't hard-wire a lamp directly into another lamp; you plug both into the mains, and they work regardless of what else is plugged in. Spring Cloud Stream is the mains socket for services: each publishes to or consumes from shared destinations through a standard "plug" (the binder), so services connect through the broker rather than wiring directly to each other.
The same event, now distributed
BookVault's in-process BookBorrowedEvent from the messaging module is the seed of this. As a
microservice, lending publishes that event to a broker via Spring Cloud Stream, and a separate
notification service consumes it. The event you designed in-process scales straight out to
services - which is exactly why you learn event-driven thinking before distributing.
As a monolith, BookVault's borrow publishes an in-process event a notifier handles. Split into a lending service and a notification service, describe how Spring Cloud Stream connects them, and one resilience benefit versus lending calling notification directly over HTTP.
What does Spring Cloud Stream provide for microservices?
Key takeaways
- In microservices, event-driven communication is preferred over direct calls, which couple services and spread failure.
- Spring Cloud Stream binds Supplier/Consumer/Function beans to broker destinations via config, so business code stays plain functions.
- It's broker-agnostic: the same code runs on Kafka or RabbitMQ by swapping a binder and config.
- Publishing events decouples producers from consumers in time - a down consumer doesn't fail the producer; the broker holds the event.
- An in-process application event scales straight out to a distributed event via Cloud Stream.