Reactive Principles and Microservices

download Reactive Principles and Microservices

of 35

  • date post

    19-Jan-2017
  • Category

    Software

  • view

    109
  • download

    2

Embed Size (px)

Transcript of Reactive Principles and Microservices

  • 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 inTime 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 aint 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 bothMacro: 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