REST vs. Messaging For Microservices
158 likes77,082 views
The document examines REST and messaging integration approaches for microservices, highlighting their architectural differences and use cases. It contrasts REST's synchronous interactions with messaging's asynchronous nature, emphasizing aspects like service discovery, resilience, and transaction management. Ultimately, it suggests that both approaches may be necessary for effective microservice design.
REST vs. Messaging For Microservices
- 1. REST VS. MessagingIntegration Approaches for Microservices Eberhard Wolff / ewolff / olivergierke Oliver Gierke
- 3. Integration 3 UI Logic Data Links Modular UI REST Messaging Replication No Common Schema!
- 4. Overview 4
- 5. REST • Architectural style • Constraints in architecture result in traits of the system • Identifiable resources, uniform interface, representations, hypermedia • Synchronous by default 5 ? Microservice Microservice
- 6. REST • Service discovery • DNS or registry & hypermedia • Load balancing • Dedicated infrastructure • So!ware load-balancer (Ribbon) 6 ? Microservice Microservice
- 7. Messaging • Microservices send message • Asynchronously 7 Microservice Microservice
- 8. Load Balancing • Can have any numbers of instances of a receiver • Load Balancing very easy 8 Microservice MicroserviceMicroserviceMicroservice
- 9. Service Discovery • Microservices send messages to queues / topics • Receiver(s) read messages • Decoupled by queues & messages • No need for service discovery 9 Microservice MicroserviceMicroserviceMicroservice
- 10. Fire & Forget 10
- 12. REST • F&F doesn’t fit naturally • Which HTTP method to use? • Requests to create side effects • DELETE, PUT, POST 12 ? Microservice Microservice
- 13. Safety / Idempotency 13 HTTP Method Safe Itempotent GET PUT DELETE POST PATCH
- 14. REST: Failure • Remote system unavailable • Can’t easily retry because of non-itempotency • Status codes to communicating semantic problems 14 ? Microservice Microservice
- 15. Messaging • Hand message over to messaging system • Messaging system guarantees delivery • Stores message • Acknowledgement • Might have duplicated messages 15 Microservice Microservice
- 16. Messaging: Failures • Message doesn’t make it into the message broker • e.g. Timeout / TCP problem • Retry • Rely on re-transmission of incoming message 16 Microservice Microservice
- 18. Example 18 Order Payment Validate credit card # OK / not OK
- 19. REST • Natural model • GET request • Support for caching built in • ETags, Last-Modified, conditional GET / PUT • Still needs care • Timeouts, resilience 19 ? Microservice Microservice
- 20. Messaging • Send request • Expect response • Correlation • …or temporary queue • Asynchronous by design 20 Microservice Microservice
- 21. Resilience • Messaging can guarantee delivery • Failure just increases latency • System must deal with latency anyway 21 Microservice Microservice
- 22. Events 22
- 23. Event Driven Architecture • Order sends events • Decoupled: no call but events • Receiver handle events as they please 23 Order New Order Event Payment: Books credit card Delivery: Ship products
- 24. Event Driven Architecture • System are built around publishing domain events • Multiple event listeners • Event listener decides what to do • Can easily add new event listener with additional business logic • Challenges • Delivery hard to guarantee • What about old events? 24
- 25. Events + REST = Feed • System stores domain events and publishes feed (e.g. Atom) • Strong consistency within the service • No additional infrastructure required • Getting closer to Event Sourcing • Clients subscribe to feed • Clients in charge of polling frequency • Server side optimizations: caching, ETags, pagination, links • Client side optimizations: conditional requests 25
- 26. Messaging • Publish / Subscribe e.g. JMS Topics • History of events limited • Guaranteed delivery somewhat harder 26
- 27. More Decoupling • Enterprise Integration Patterns (Hohpe, Woolf) • www.eaipatterns.com • Contains patterns like Router, Translator or Adapter • Create flexible messaging architectures 27
- 28. Code 28 @Inject OrderRepository repository; @Transactional public void order(Order order) { repository.save(order.deliver()); doCreditCardBooking(order.getCcNumber()); }
- 29. Transactions 29
- 30. Messaging & Transactions (Commit) • Database commit • Incoming messages acknowledged • Commit success: outgoing messages sent • Outgoing messages hopefully handled successfully. • Inconsistencies: Outgoing messages not yet processed 30 Microservice
- 31. Microservice Messaging & Transactions (Rollback) • Database rollback • Outgoing message not sent • Incoming message retransmitted 31
- 32. REST & Transactions • No implicit infrastructure support • But can be built manually 32
- 33. REST & Transactions 33 @Inject OrderRepository repository; @Inject ApplicationEventPublisher publisher; @Transactional public void order(Order order) { repository.save(order.deliver()); publisher.publish(new OrderDeliveredEvent(order)); } @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT) public void onOrder(Order order) { doCreditCardBooking(order.getCcNumber()); }
- 34. Evolvability 34
- 35. Evolvability • Core aspect of Microservices: independent deployability • Means: decoupling • Change in one system must not break downstream systems 35
- 36. REST • Core concepts built into the protocol • Representations • Content negotiation • Media types • Hypermedia • Discoverability 36
- 37. Messaging • Data format: Your choice • i.e. easy to evolve if changes backwards-compatible • But: no support for content negotation 37
- 38. Summary 38 REST Messaging Communication style synchronous asynchronous Service Discovery DNS, Service Registry Resource Discovery Message Broker Queues / Topics Strengths Content negotiation, Hypermedia More control over direct interaction Messages in Re-submission of messages
- 39. Your next project: Messaging or REST? 39
- 40. You’ll probably use both :-) 40