Recognition of responsive systems

I first heard the word reactive a few years ago, and I came across this project called Rxjava, the Java implementation of ReactiveX, and it kind of opened a new door for me. In addition to Rxjava, the ReactiveX family includes RxJS, Rx.NET,RxScala, etc.

The essence of ReactiveX is Observer+Iterator+ function programming + asynchronous. Is an event-driven, asynchronous, observable sequence.

With RxJava, asynchronous callbacks can be rewritten as chained calls. It looks pretty neat in code. Of course, the JDK also provides complete Stage with similar functionality to handle callbacks.

For more, visit www.flydean.com

Rxjava is just a basic Java library. What if we want to build responsive servers, responsive Web, responsive data access, and even responsive microservices?

This is when I learned about vert.x. Vert.x is used to build applications to Reactive.

Vert.x is a product of the Eclipse Foundation and is based on event-driven and non-blocking programming.

Vert.x is modular and includes Core, Web, Data Access, Reactive, Microservices, MQTT, Authentication and Authorisation, Messaging, The Event bus Bridge, the conversation, Testing, Clustering, Services and Cloud module. Everything.

In fact, the Java world has been getting closer to Reactive, except for the new API features of the JDK itself. For example, the well-known Spring has added the WebFlux framework in Spring 5, which is a Reactive Web framework.

What is a responsive system

In the last section we mentioned Rxjava and vert. x, which have some common keywords, such as asynchronous, event-driven, observer mode, functional programming, message-driven, etc., all designed to make modern systems more robust, faster, more resilient, and therefore better.

The system has gone from a single server long ago to a multi-server architecture, from second response to millisecond response. From 90% available to 99.999% now available. Great changes have taken place in system design, architecture and program coding.

We urgently need a universal system architecture solution that can meet the above requirements.

So what is a responsive system?

Responsive systems need to have these characteristics: Responsive, Resilient, Elastic, and Message Driven. We call a system with the above four characteristics a responsive system.

Among the above four characteristics, Responsive is the ultimate goal of the system, Resilient and Elastic are the manifestations of the system, and Message Driven is the means of system construction.

So we get the ultimate architectural diagram of a responsive system:

Using a responsive system architecture ensures that the system is maintainable, extensible, and more tolerable in the event of a system failure.

Four characteristics of responsive system

When defining a Responsive system, we mentioned four characteristics: Responsive, Resilient, Elastic and Message Driven.

In the following paragraphs, we will describe exactly what these four characteristics are.

Responsiveness

Responsive is the system can immediately respond to requests, which should contain two aspects of the meaning.

First, the response time should be short enough. If a user requests a page, two seconds is probably the limit. A long time is estimated to lose this user.

Times are changing and technology is also changing. Ten years ago, downloading a file with hundreds of kbytes in a minute was fast. Now, without a few megabytes per second, it will definitely make people crazy.

With the rapid development of modern cpus, service clusters and fiber optic transmission, and the huge changes in the information that pages carry, a typical page may contain dozens of requests. The time per request has increased to the millisecond or even subtle level. At the same time, there are many new changes in page presentation, such as asynchronous loading and preloading techniques.

Ultimately, the goal is to create a responsive system. The various technologies behind the system and new request methods are to serve this goal.

Second, keep response times short for errors.

On the one hand, users should be reminded of possible errors in time. Both system errors and user errors require a response within a limited time.

On the other hand, the system itself should be able to quickly locate and respond to problems. This is the basic requirement to improve the stability and security of the system itself.

How do you find and respond to problems with the system itself? The first is to have a perfect error recording system, so that everything is in order to follow. The second is to have corresponding monitoring measures, so that any problems in the system can be timely notification and alarm.

Resilient

Recoverability is the ability of the system to provide services in the face of failures or errors.

First, it requires that our system be robust enough to withstand normal access and predictable hotspot access.

Secondly, the functions of modern systems are varied, and there may be dozens of services in the background of a simple APP. So we need to distinguish between critical services and non-critical services. For key services, we must ensure their stability. For non-critical services, we can consider on the premise of guaranteeing key services first.

In an order system, for example, placing an order would be a key service, while the number of likes, reviews, etc., would be less important.

Once critical and non-critical services are identified, they need to be separated and isolated. Any errors or exceptions in non-critical services cannot affect critical services.

Again, if a service sends an error, we should minimize the impact as much as possible, not a small error affecting all services.

Finally, there should be a recovery from failure that does not affect other system services. For example, we can make a copy of the existing system, and when a service fails, we can replace it with a backup service.

Only in this way can the system reliability be guaranteed.

Elastic

Resiliency means that services can be dynamically expanded when needed and deactivated when not needed to save resources.

Many cloud services now provide dynamic scalability, and if the system is implemented by ourselves, we need to distinguish hot issues from non-hot issues.

Only hotspot issues need to be flexible. The system cannot have bottlenecks and can be sharded or replicated to implement distributed dynamic load.

Load balancing technology is probably the most commonly used elastic function, but how to dynamically and automatically load balancing may be a very meaningful topic.

Flexibility can be achieved through software or hardware, but we need to strike a balance between cost and effectiveness.

Message Driven

The essence of message driving is to send messages, receive messages, and process them. Few large systems today do not use message-oriented middleware. The advantage of using these message-oriented middleware is decoupling and asynchronous drivers.

The advantage of asynchrony, which I won’t go into here, is that instead of waiting around stupidly, you can use your time to do more productive things.

Decoupling is even more important. Modern systems are basically made up of many services. To keep so many systems running smoothly, decoupling must be done. Otherwise, the failure of one service will make all services unavailable. It is frightening to think about it.

Message-driven is the bridge between these different service components. Tell them what to do and wait for their feedback.

Or we can think of these services as people, people communicating with each other through language. Language-driven or message-driven.

Here is another concept that is common in message drivers: back-pressure.

We know that the processing speed of the service sending and receiving messages is limited. When the speed of sending messages is faster than that of receiving messages, the sending messages will be blocked. When the speed of message blocking is too much, the sending messages may be lost or the service may crash. And if too many messages go unprocessed and unresponded, it can be very bad for the user experience.

The concept of back-pressure is used here. If the message receiver cannot handle the message, it can notify the message sender that it is under pressure and needs to reduce the load. Back-pressure is a message feedback mechanism that allows the system to respond gracefully to a load rather than collapse under it.

conclusion

Reactive is a very popular concept in recent years. How to design a system to meet our needs through Reactive is a problem we need to consider.

Author: Flydean program stuff

Link to this article: www.flydean.com/reactive-sy…

Source: Flydean’s blog

Welcome to pay attention to my public number: procedures those things, more wonderful waiting for you!