Reactive Services, Reactive Manifesto and Microservices

Reactive Services, Reactive Manifesto and Microservices

Many disciplines of software development came to the same conclusion. They are building systems that react to modern demands on services. Reactive services live up to the Reactive Manifesto. Reactive services are built to be robust, resilient, flexible and written with modern hardware, virtualization, rich web clients and mobile clients in mind.

The Reactive Manifesto outlines qualities of Reactive Systems based on four principles: Responsive, Resilient, Elastic and Message Driven. 

Responsiveness means the service should respond in a timely manner, and never let clients or upstream services hang. A system failure should not cause a chain reaction of failures. A failure of a downstream system may cause a degraded response, but a response none-the-less. 

Resilience goes in line with responsiveness, the system should respond even in the face of failure and errors in a timely fashion. It can respond because it can detect an async response is not coming back in time and serve up a degraded response (circuit breaker). It may be able to respond in spite of failure because it can use a replicated version of a failed downstream node. Failure and recovery is built into the system. Monitoring and spinning up new instances to aid in recovery may be delegated to another highly available resource. A key component of resilience is the ability to monitor known good nodes and to perform Service Discovery to find alternative upstream and downstream services.

Elasticity works with resilience. The ability to spin up new services and for downstream and upstream services and clients to find the new instances is vital to both the resilience of the system as well as the elasticity of the system.  Reactive Systems can react to changes in load by spinning up more services to share the load. Imagine a set of services for a professional soccer game that delivers real time stats. During games, you may need to spin up many services. On non-game times, you may need just a few of these services. A reactive system is a system that can increase and decrease resources based on demand. Just like with resilience, Service Discovery aids with elasticity as it provides a mechanism for upstream and downstream services and clients to discover new nodes so the load can be spread across the services. 

Message Driven: Reactive Systems rely on asynchronous message passing. This established boundaries between services (in-proc and out of proc) which allows for loose coupling (publish/subscribe or async streams or async calls), isolation (one failure does not ripple through to upstream services and clients), and improved responsive error handling. Having messaging allows one to control throughput (re-route, spin up more services) by applying back-pressure and using back pressure events to trigger changes to shape traffic though the queues. Messaging allows for non-blocking handling of responses. 

A well written microservice is more often than not going to apply the principles of the reactive manifesto. One could argue that a microservices architecture is just an extension of the reactive manifesto that is geared towards web services. 

There are related subjects of reactive programming and functional reactive programming which are related to the reactive manifesto. A system can be a reactive system and not use a reactive programming model. Reactive programming is often used to coordinate asynchronous calls to multiple services as well as events and streams from clients and other systems.

An example: Client calls Service Z. Service Z calls Service A and Service B, but sends back only the combined results of Service A and Service C. The results of Service B are used to call Service C. Thus Z must call A, B, take the results of B and calls C, then return A/C combined back to the client. And, all of these calls must be asynchronous, non-blocking calls, but we should be able to handle errors for A, B or C, and handle timeouts such that the Client does not hang when Z calls downstream services. The orchestration of calling many services requires some sort of reactive programming coordination. Frameworks like RxJava, RxJS, etc. were conceived to provide an Object Reactive programming model to better work in an environment where there are events, streams and asynchronous calls.

QBit also provides a Reactor class to coordinate asynchronous calls using reactive programming and it uses Java 8 Lambda expression to aid in this endeavor. QBit, Java microservice lib,  is a Java-first reactive programming environment that focuses on events, service discovery, and microservices. It implements active object pattern, similar to Akka typed-actors, which is a service which lives behind a set of queues to handle events, method calls, responses, callbacks, etc. These services have location transparency as they can be in-proc of on another server node via WebSocket or the event bus. The resilience comes from replication which is readily possible with the service discovery and the event bus. The service discovery mechanism takes health of the nodes into consideration so unhealthy nodes are taken out of the service pools. QBit implements all the important parts of what it takes to build a reactive system of microservices in Java 8. QBit provides a natural environment to do reactive system development in Java. QBit is a reactive Java lib as well as a microservice lib.

Related:


Java Microservices Architecture -Rick Hightower
Microservice Service Discovery with Consul - Rick Hightower
Reactive Microservices - Rick Hightower
High Speed Microservices -Rick Hightower

More information on QBit


Reactive Programming, Java Microservices, Rick Hightower

More info on QBit

QBIt Home

[Detailed Tutorial] QBit microservice example

[Detailed Tutorial] Building a HTTP server with WebSocket support using QBit (very easy)

[Detailed Tutorial] Building a simple recommendation engine with QBit (CallBack Blocking)

[Detailed Tutorial] Building a simple recommendation engine with QBit (CallBack nonBlocking)

[Detailed Tutorial] Building a single page; Todo List Application with QBit

[Detailed Tutorial] Using event channels and strongly typed event bus with QBit (The employee example)

[Detailed Tutorial] Using QBit Microservice lib with Spring Boot

[Detailed Tutorial] Using QBit microservice lib's REST support with URI Params

[Detailed Tutorial] Using QBit's Event Bus System (The Employee example)

[Detailed Tutorial] Working with inproc MicroServices within QBit.

[Doc] QBit Java microservice lib auto flushing service queue proxies

[Doc] QBit Java microservice lib introducing EventBus replication and EventBus connectors

[Doc] QBit microservice Java lib Using auto flushing client proxies

[Doc] QBit Microservice WebSocket wire protocol draft 01 JSON ASCII method batching RPC

[Doc] Queue Callbacks for QBit queue based services

[Doc] Using QBit microservice lib's HttpClient GET, POST, et al, JSON, Java 8 Lambda

[Doc] Using QBit microservice lib's WebSocket support

[Quick Start] Building a HTTP server with WebSocket support using QBit (very easy)

[Quick Start] Building a simple recommendation engine with QBit (CallBack Blocking)

[Quick Start] Building a simple recommendation engine with QBit (CallBack nonBlocking)

[Quick Start] Building a simple Rest web microservice server with QBit

[Quick Start] Building a single page; Todo List Application with QBit

[Quick Start] building a single web page application with QBit

[Quick Start] Building a TODO web microservice client with QBit

[Quick Start] Building a TODO web microservice server with QBit

[Quick Start] Building boon for the QBit microservice engine

[Quick Start] Building QBit the microservice lib for Java

[Quick Start] Using event channels and strongly typed event bus with QBit (The employee example)

[Quick Start] Using QBit Microservice lib with Spring Boot

[Quick Start] Using QBit microservice lib's REST support with URI Params

[Quick Start] Using QBit's Event Bus System (The Employee example)

[Quick Start] Working with inproc MicroServices within QBit

[Rough Cut] Delivering up Single Page Applications from QBit Java JSON Microservice lib

[Rough Cut] QBit Java Microservice Lib Working With Workers Sharded and Pooled

[Rough Cut] QBit Microservice Lib Working With CallBacks

[Rough Cut] QBit Microservices using Service Workers and sharded service workers

[Rough Cut] Using QBit microservice lib with Spring Boot

[Rough Cut] Using QBit microservice lib's REST support with URI Params

[Rough Cut] Working with event bus for QBit the microservice engine

[Rough Cut] Working with Event Channels and strongly typed event bus with the QBit Microservice Java, JSON, WebSocket Lib

[Rough Cut] Working with inproc MicroServices

[Rough Cut] Working with private event bus for inproc microservices

[Rough Cut] Working with strongly typed event bus proxies for QBit Java Microservice lib

[Rough Cut] Working with System Manager for QBit Mircoservice lib

[Z Blog Getting Consul to run on Travis CI Server using Gradle so we can test consul integration tests]

[Z Blog] Qbit servlet support also a preview of using jetty and the QBit microservice lib together

[Z Blog] Using Consul from QBit, the Java, JSON, WebSocket and REST microservice library, for health monitoring, clustering and service discovery

[Z Dev Notes] Reactive programming for QBit Java microservices library

[Z Notebook] More benchmarking internal

[Z Notebook] Performance testing for REST

[Z Notebook] Roadmap

Introduction to QBit

Local Service Proxies

OLD Home

QBit Boon New Wave of JSON HTTP and Websocket

QBit Docs