Reactive MicroServices
Leveraging Reactive principlesin a technology agnostic way
Lorenzo NicoraSenior Consultant @ OpenCredo
@nicusX
https://opencredo.com/author/lorenzo
“Reactive” is…
Reactive
Semantically overloaded term
adj. “Readily responsive to stimulus” [Merrian-Webster dictionary]
From Latin “reagere”: act in return
Lorenzo Nicora Reactive μServices
Reactive as…
Reactive asReactive Manifesto
Lorenzo Nicora Reactive μServices
Reactive Manifesto
Lorenzo Nicora Reactive μServices
ü 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
✗ 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
Reactive as..
Akka Spring Boot
a set of Architectural
Patterns and Principles
Not necessarilyrelated to
a specific technology
a set of technologies
Lorenzo Nicora Reactive μServices
A set of architectural patterns and principlesapplicable 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
a MicroService is..
• Communicate with others over the network
• Part of a distributed system
• Independently deployed
• Independently scalable
MicroServices
Lorenzo Nicora Reactive μServices
Macro levelat μService boundariesBetween Services; external resources
Across the MicroService Stack
Micro levelwithin the μServiceBetween internal components
Lorenzo Nicora Reactive μServices
Do not block threads
Never block a threaddoing nothing and
waiting for an Input or a Response
Threads are limited resources(Thread starving)
(React to Input / Response)Lorenzo Nicora Reactive μServices
Non-blocking à Faster
Lorenzo Nicora Reactive μServices
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
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
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
Delegation
* External components
Delegate a task asynchronouslyto 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
Delegation
* Internal component
Delegate a task asynchronouslyto 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
Parallel Delegation
Lorenzo Nicora Reactive μServices
Resilience: Stay responsive in face of failure
Resilience
Design expecting failure
Failure happens!
Fail-Safe
Lorenzo Nicora Reactive μServices
• 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
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
Resilience à Isolation + Replication
o Replication • Legacy (always valid) HA approach
• Multiple peer services
• Data Replication
Resilience: Isolation + Replication
Lorenzo Nicora Reactive μServices
Fail silent; Fail fastthen Recover, when possible
o Prevent cascading failureso Isolate failing collaborators
• Downstream μServices• External services• Resources (DB…)
Resilience: Circuit Breakers
Lorenzo Nicora Reactive μServices
Expect Failure…
Resilience: Handle failure
… Handle FailureLorenzo Nicora Reactive μServices
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
Explicitly set and handle timeoutson every asynchronous interaction
Never rely on default settings and handlingfor timeouts
Timeouts - Failures
When collaboration is asynchronous (messaging)a Failure becomes a Time-out
Lorenzo Nicora Reactive μServices
Prevent fast publishers from overrunning slow consumers
✗ Drop messages (acceptable?)✗ Cause catastrophic cascade failures
Back-pressure
Lorenzo Nicora Reactive μServices
Buffers overflow!and will not save you
Back-pressure
à BackpressureConsumer…ü Give feedback to publisherü Drive the pace
Lorenzo Nicora Reactive μServices
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
Your collaborator may be anywhereLocal or Remote
Architecture may evolveLocal à 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
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
Conclusions
Lorenzo Nicora Reactive μServices
ü Reactive as a set ofArchitectural Patterns and PrinciplesØ low latency/high throughputØ scale linearly Ø resiliencyØ …
ü When not using a ”Reactive” technologyapply discipline,but still enforce Reactive Principles
ü Keep in mind when designing both…Macro: μService architectureMicro: internal software design
Conclusions
Lorenzo Nicora Reactive μServices
Reactive Manifesto: http://www.reactivemanifesto.org/à Glossary http://www.reactivemanifesto.org/glossary
References
Lorenzo Nicora Reactive μServices
Q&A
Thanks.Lorenzo Nicora Reactive μServices
Top Related