Reactive Principles and Microservices

Reactive MicroServices
Leveraging Reactive principles
in a technology agnostic way
Lorenzo Nicora
Senior 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 as
Reactive Manifesto

Reactive Manifesto

ü Responsive à Low latency
ü Resilient à Stay responsive on failure
ü Elastic à Scale as needed
ü Message-Driven à Asynchronous messages
as only communication between components
Simplifying

✗ No Blocking operation
✗ No Synchronization à No Contention
✗ No Resource hogging
Reactive Manifesto promotes
Decoupling and isolation in…
üTime à Concurrent processing
üSpace à Components location decoupling

Reactive as..
Akka Spring Boot
a set of
Architectural
Patterns and Principles
Not necessarily
related to
a specific technology
a set of technologies

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

a MicroService is..
• Communicate with others over the network
• Part of a distributed system
• Independently deployed
• Independently scalable
MicroServices

Macro level
at μService boundaries
Between Services; external resources
Across the MicroService Stack
Micro level
within the μService
Between internal components

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)

Non-blocking à Faster

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

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

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

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

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

Parallel Delegation

Resilience:
Stay responsive in face of failure
Resilience
Design expecting failure
Failure
happens!
Fail-Safe

• 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

Resilience: Isolation + Replication
Resilience à Isolation + Replication
Macro
o Deployment Isolation
o Bulkheads
• Prevent cascading failures
• Neither to peer services, nor upstream/downstream

Resilience à Isolation + Replication
o Replication
• Legacy (always valid) HA approach
• Multiple peer services
• Data Replication
Resilience: Isolation + Replication

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

Expect Failure…
Resilience: Handle failure
… Handle Failure

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

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

Prevent fast publishers
from overrunning slow consumers
✗ Drop messages (acceptable?)
✗ Cause catastrophic cascade failures
Back-pressure

Buffers overflow!
and will not save you
Back-pressure
à Backpressure
Consumer…
ü Give feedback to publisher
ü Drive the pace

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

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

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

Conclusions

ü 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

Reactive Manifesto: http://www.reactivemanifesto.org/
à Glossary http://www.reactivemanifesto.org/glossary
References

Q&A
Thanks.

Reactive Principles and Microservices

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Reactive Principles and Microservices

Ähnlich wie Reactive Principles and Microservices (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Reactive Principles and Microservices