Reactive Principles and Microservices
3 likes696 views
Reactive principles promote responsive, resilient, and elastic microservices. At a macro level between services, this includes non-blocking communication using messaging and delegation. At a micro level within services, it involves non-blocking processing using futures, promises, and actors. Designing services for failure includes isolation, replication, circuit breakers, timeouts, and backpressure to prevent cascading failures. Services should also enable location transparency through discovery and load balancing.
![“Reactive” is…
Reactive
Semantically overloaded term
adj. “Readily responsive to stimulus” [Merrian-Webster dictionary]
From Latin “reagere”: act in return
Lorenzo Nicora Reactive μServices](https://image.slidesharecdn.com/reactivemicroservices-1-161124205033/85/Reactive-Principles-and-Microservices-2-320.jpg)
Reactive Principles and Microservices
- 1. Reactive MicroServices Leveraging Reactive principles in a technology agnostic way Lorenzo Nicora Senior Consultant @ OpenCredo @nicusX https://opencredo.com/author/lorenzo
- 2. “Reactive” is… Reactive Semantically overloaded term adj. “Readily responsive to stimulus” [Merrian-Webster dictionary] From Latin “reagere”: act in return Lorenzo Nicora Reactive μServices
- 3. Reactive as… Reactive as Reactive Manifesto Lorenzo Nicora Reactive μServices
- 4. Reactive Manifesto Lorenzo Nicora Reactive μServices
- 5. ü Responsive à Low latency ü Resilient à Stay responsive on failure ü Elastic à Scale as needed ü Message-Driven à Asynchronous messages as only communication between components Simplifying Lorenzo Nicora Reactive μServices
- 6. ✗ No Blocking operation ✗ No Synchronization à No Contention ✗ No Resource hogging Reactive Manifesto promotes Decoupling and isolation in… üTime à Concurrent processing üSpace à Components location decoupling Lorenzo Nicora Reactive μServices
- 7. Reactive as.. Akka Spring Boot a set of Architectural Patterns and Principles Not necessarily related to a specific technology a set of technologies Lorenzo Nicora Reactive μServices
- 8. A set of architectural patterns and principles applicable to MicroServices ü Non-blocking processing ü Message-based communication ü Asynchronous delegation ü Resilience: Isolation & Replication; Backpressure ü Elasticity ü Location transparency Reactive as Architectural Patterns Lorenzo Nicora Reactive μServices
- 9. a MicroService is.. • Communicate with others over the network • Part of a distributed system • Independently deployed • Independently scalable MicroServices Lorenzo Nicora Reactive μServices
- 10. Macro level at μService boundaries Between Services; external resources Across the MicroService Stack Micro level within the μService Between internal components Lorenzo Nicora Reactive μServices
- 11. Do not block threads Never block a thread doing nothing and waiting for an Input or a Response Threads are limited resources (Thread starving) (React to Input / Response) Lorenzo Nicora Reactive μServices
- 12. Non-blocking à Faster Lorenzo Nicora Reactive μServices
- 13. Non-blocking Communication Macro (at service boundaries) ✗ Limit Request/Response pattern üOne-way messaging (fire and forget) üPrefer messaging protocols rather than HTTP Non-blocking Lorenzo Nicora Reactive μServices
- 14. Non-blocking Communication and IO Micro (within the Service) ✗ Limit blocking/direct method calls üFutures, Promises, Callbacks üInternal messaging (e.g. Actor model) üNon-blocking IO and drivers Non-blocking Lorenzo Nicora Reactive μServices
- 15. Non-blocking + Blocking = Blocking ✗ Many resources only provide blocking API • Prefer technologies with non-blocking API ✗ Do not block on a Future… • To extract the result • To handle exceptions ❗ Know where your thread come from • Thread pools Non-blocking pitfalls Lorenzo Nicora Reactive μServices
- 16. Delegation * External components Delegate a task asynchronously to other components* Macro (at Service boundaries) o Delegate tasks to other μServices o Send Request as a Message o When required, Response come back as a Message Lorenzo Nicora Reactive μServices
- 17. Delegation * Internal component Delegate a task asynchronously to other components* Micro (within the Service) o Execute sub-tasks in separate threads • Futures/Promises, Callbacks… o Run multiple tasks in parallel Lorenzo Nicora Reactive μServices
- 18. Parallel Delegation Lorenzo Nicora Reactive μServices
- 19. Resilience: Stay responsive in face of failure Resilience Design expecting failure Failure happens! Fail-Safe Lorenzo Nicora Reactive μServices
- 20. • Failure (e.g. connection failure, timeout…) • Unexpected event • Not recoverable • No meaningful response to your client • Error (e.g. user input error) • Expected condition • A specific response to the client (your protocol) Failure ≠ Error Lorenzo Nicora Reactive μServices
- 21. Resilience: Isolation + Replication Resilience à Isolation + Replication Macro o Deployment Isolation o Bulkheads • Prevent cascading failures • Neither to peer services, nor upstream/downstream Lorenzo Nicora Reactive μServices
- 22. Resilience à Isolation + Replication o Replication • Legacy (always valid) HA approach • Multiple peer services • Data Replication Resilience: Isolation + Replication Lorenzo Nicora Reactive μServices
- 23. Fail silent; Fail fast then Recover, when possible o Prevent cascading failures o Isolate failing collaborators • Downstream μServices • External services • Resources (DB…) Resilience: Circuit Breakers Lorenzo Nicora Reactive μServices
- 24. Expect Failure… Resilience: Handle failure … Handle Failure Lorenzo Nicora Reactive μServices
- 25. Handle Errors and Failures separately Consistently report Errors to your client Error is part of your “protocol” (business logic) Gracefully degrade on Failure Avoid ”All or nothing” logic à Partial Responses Handling Failure Lorenzo Nicora Reactive μServices
- 26. Explicitly set and handle timeouts on every asynchronous interaction Never rely on default settings and handling for timeouts Timeouts - Failures When collaboration is asynchronous (messaging) a Failure becomes a Time-out Lorenzo Nicora Reactive μServices
- 27. Prevent fast publishers from overrunning slow consumers ✗ Drop messages (acceptable?) ✗ Cause catastrophic cascade failures Back-pressure Lorenzo Nicora Reactive μServices
- 28. Buffers overflow! and will not save you Back-pressure à Backpressure Consumer… ü Give feedback to publisher ü Drive the pace Lorenzo Nicora Reactive μServices
- 29. Ability to scale when required Macro ü Scale services and resources • Add/Remove VM, Container, Cluster nodes ❗ Scaling data (application state) • Only Partitioning, Sharding Elasticity Scaling: an infrastructure concern, but application must be designed for it Lorenzo Nicora Reactive μServices
- 30. Your collaborator may be anywhere Local or Remote Architecture may evolve Local à Remote “There ain’t no such thing as a transparent synchronous remotisation” Async Messaging work the same local and remote Location Transparency Lorenzo Nicora Reactive μServices
- 31. You need to find your collaborator o Service Discovery • Dynamic service registration • Heartbeat, Gossip, Health Check (is a service dead?) • DNS o Load Balancers Location Transparency Lorenzo Nicora Reactive μServices
- 32. Conclusions Lorenzo Nicora Reactive μServices
- 33. ü Reactive as a set of Architectural Patterns and Principles Ø low latency/high throughput Ø scale linearly Ø resiliency Ø … ü When not using a ”Reactive” technology apply discipline, but still enforce Reactive Principles ü Keep in mind when designing both… Macro: μService architecture Micro: internal software design Conclusions Lorenzo Nicora Reactive μServices
- 34. Reactive Manifesto: http://www.reactivemanifesto.org/ à Glossary http://www.reactivemanifesto.org/glossary References Lorenzo Nicora Reactive μServices
- 35. Q&A Thanks. Lorenzo Nicora Reactive μServices