Microservices Architecture | 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.
Author Bio: Rick Hightower is one of the primary developers of the QBit Java Microservices Lib and well as Reakt Reactive Java Lib (with Promises, Reactor and streams).
More information on QBit
Reactive Programming, Java Microservices, Rick Hightower
More info on QBit