Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

REST vs. Messaging For Microservices

72,200 views

Published on

Presentation from WJAX 2015 with Oliver Gierke. Compares REST and Messaging as an integration approach for Microservices.

Published in: Software
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

REST vs. Messaging For Microservices

  1. 1. REST VS. MessagingIntegration Approaches for Microservices Eberhard Wolff / ewolff / olivergierke Oliver Gierke
  2. 2. Microservices 2 ECommerce Order Customer Delivery Order Customer Delivery Package WAR
  3. 3. Integration 3 UI Logic Data Links Modular UI REST Messaging Replication No Common
 Schema!
  4. 4. Overview 4
  5. 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. 6. REST • Service discovery • DNS or registry & hypermedia • Load balancing • Dedicated infrastructure • So!ware load-balancer (Ribbon) 6 ? Microservice Microservice
  7. 7. Messaging • Microservices send message • Asynchronously 7 Microservice Microservice
  8. 8. Load Balancing • Can have any numbers of instances of a receiver • Load Balancing very easy 8 Microservice MicroserviceMicroserviceMicroservice
  9. 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. 10. Fire & Forget 10
  11. 11. Example 11 Order Payment Credit card booking 200€
  12. 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. 13. Safety / Idempotency 13 HTTP Method Safe Itempotent GET PUT DELETE POST PATCH
  14. 14. REST: Failure • Remote system unavailable • Can’t easily retry because of non-itempotency • Status codes to communicating semantic problems 14 ? Microservice Microservice
  15. 15. Messaging • Hand message over to messaging system • Messaging system
 guarantees delivery • Stores message • Acknowledgement • Might have duplicated messages 15 Microservice Microservice
  16. 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
  17. 17. Request & Reply 17
  18. 18. Example 18 Order Payment Validate credit card # OK / not OK
  19. 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. 20. Messaging • Send request • Expect response • Correlation • …or temporary queue • Asynchronous by design 20 Microservice Microservice
  21. 21. Resilience • Messaging can guarantee delivery • Failure just increases latency • System must deal with latency anyway 21 Microservice Microservice
  22. 22. Events 22
  23. 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. 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. 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. 26. Messaging • Publish / Subscribe e.g. JMS Topics • History of events limited • Guaranteed delivery somewhat harder 26
  27. 27. More Decoupling • Enterprise Integration Patterns (Hohpe, Woolf) • www.eaipatterns.com • Contains patterns like Router, Translator or Adapter • Create flexible messaging architectures 27
  28. 28. Code 28 @Inject OrderRepository repository; @Transactional public void order(Order order) { repository.save(order.deliver()); doCreditCardBooking(order.getCcNumber()); }
  29. 29. Transactions 29
  30. 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. 31. Microservice Messaging & Transactions (Rollback) • Database rollback • Outgoing message not sent • Incoming message retransmitted 31
  32. 32. REST & Transactions • No implicit infrastructure support • But can be built manually 32
  33. 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. 34. Evolvability 34
  35. 35. Evolvability • Core aspect of Microservices: independent deployability • Means: decoupling • Change in one system must not break downstream systems 35
  36. 36. REST • Core concepts built into the protocol • Representations • Content negotiation • Media types • Hypermedia • Discoverability 36
  37. 37. Messaging • Data format: Your choice • i.e. easy to evolve if changes backwards-compatible • But: no support for content negotation 37
  38. 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. 39. Your next project: Messaging or REST? 39
  40. 40. You’ll probably use both :-) 40

×