Download - Reactive Principles and Microservices

Transcript
Page 1: Reactive Principles and Microservices

Reactive MicroServices

Leveraging Reactive principlesin a technology agnostic way

Lorenzo NicoraSenior Consultant @ OpenCredo

@nicusX

https://opencredo.com/author/lorenzo

Page 2: Reactive Principles and Microservices

“Reactive” is…

Reactive

Semantically overloaded term

adj. “Readily responsive to stimulus” [Merrian-Webster dictionary]

From Latin “reagere”: act in return

Lorenzo Nicora Reactive μServices

Page 3: Reactive Principles and Microservices

Reactive as…

Reactive asReactive Manifesto

Lorenzo Nicora Reactive μServices

Page 4: Reactive Principles and Microservices

Reactive Manifesto

Lorenzo Nicora Reactive μServices

Page 5: Reactive Principles and Microservices

ü 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

Page 6: Reactive Principles and Microservices

✗ 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

Page 7: Reactive Principles and Microservices

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

Page 8: Reactive Principles and Microservices

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

Page 9: Reactive Principles and Microservices

a MicroService is..

• Communicate with others over the network

• Part of a distributed system

• Independently deployed

• Independently scalable

MicroServices

Lorenzo Nicora Reactive μServices

Page 10: Reactive Principles and Microservices

Macro levelat μService boundariesBetween Services; external resources

Across the MicroService Stack

Micro levelwithin the μServiceBetween internal components

Lorenzo Nicora Reactive μServices

Page 11: Reactive Principles and Microservices

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

Page 12: Reactive Principles and Microservices

Non-blocking à Faster

Lorenzo Nicora Reactive μServices

Page 13: Reactive Principles and Microservices

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

Page 14: Reactive Principles and Microservices

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

Page 15: Reactive Principles and Microservices

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

Page 16: Reactive Principles and Microservices

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

Page 17: Reactive Principles and Microservices

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

Page 18: Reactive Principles and Microservices

Parallel Delegation

Lorenzo Nicora Reactive μServices

Page 19: Reactive Principles and Microservices

Resilience: Stay responsive in face of failure

Resilience

Design expecting failure

Failure happens!

Fail-Safe

Lorenzo Nicora Reactive μServices

Page 20: Reactive Principles and Microservices

• 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

Page 21: Reactive Principles and Microservices

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

Page 22: Reactive Principles and Microservices

Resilience à Isolation + Replication

o Replication • Legacy (always valid) HA approach

• Multiple peer services

• Data Replication

Resilience: Isolation + Replication

Lorenzo Nicora Reactive μServices

Page 23: Reactive Principles and Microservices

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

Page 24: Reactive Principles and Microservices

Expect Failure…

Resilience: Handle failure

… Handle FailureLorenzo Nicora Reactive μServices

Page 25: Reactive Principles and Microservices

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

Page 26: Reactive Principles and Microservices

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

Page 27: Reactive Principles and Microservices

Prevent fast publishers from overrunning slow consumers

✗ Drop messages (acceptable?)✗ Cause catastrophic cascade failures

Back-pressure

Lorenzo Nicora Reactive μServices

Page 28: Reactive Principles and Microservices

Buffers overflow!and will not save you

Back-pressure

à BackpressureConsumer…ü Give feedback to publisherü Drive the pace

Lorenzo Nicora Reactive μServices

Page 29: Reactive Principles and Microservices

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

Page 30: Reactive Principles and Microservices

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

Page 31: Reactive Principles and Microservices

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

Page 32: Reactive Principles and Microservices

Conclusions

Lorenzo Nicora Reactive μServices

Page 33: Reactive Principles and Microservices

ü 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

Page 34: Reactive Principles and Microservices

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

References

Lorenzo Nicora Reactive μServices

Page 35: Reactive Principles and Microservices

Q&A

Thanks.Lorenzo Nicora Reactive μServices