Initial knowledge of responsive system

The first time I heard the word reactive was a few years ago. I came across the project rxjava, which seemed to open a new door for me. Rxjava is the Java implementation of reactivex. In addition to rxjava, the reactivex family also has rxjs and Rx Net, rxscala, etc.

The essence of reactivex is observer + iterator + functional programming + asynchronous. Is an event driven, asynchronous, observable sequence.

Using rxjava, asynchronous callbacks can be rewritten into chain calls. It looks very concise and clear in code. Of course, the JDK also provides completionstage, which provides a similar function to solve callback.

Rxjava is just a basic library of Java. If we want to build a responsive server, responsive web, responsive data access, or even responsive microservices, how should we deal with it?

This time I learned about vert x。 Vert. X is used to build reactive applications.

Vert. X is a product of the eclipse foundation, based on event driven and non blocking programming.

Vert. X is modular, including core, web, data access, reactive, microservices, mqtt, authentication and authorization, messaging, event bus bridge, Devops, testing, clustering, services, cloud and other modules. It has everything.

In fact, the Java community has always been approaching reactive. In addition to the new API features of JDK itself, for example, spring, which is well-known in the industry, has also added a weblux framework to spring 5, which is a reactive web framework.

What is a responsive system

In the previous section, we mentioned rxjava and vert x. There are some common keywords, such as asynchronous, event driven, observer mode, functional programming, message driven, etc. all of them are to make the modern system more robust, run faster, more flexible and better.

The system has changed from a single server long ago to the current multi server architecture, from second level response to millisecond level response. From 90% to 99.999%. Great changes have taken place in system design, architecture and program coding.

We urgently need a general 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 systems with the above four characteristics responsive systems.

Among the above four features, responsiveness is the ultimate goal of the system, resilience and elasticity are the manifestations of the system, and message driven is the means of system construction.

So we got the ultimate architecture diagram of the responsive system:

Using the architecture of responsive system can ensure the maintainability and scalability of the system, and have better tolerance in case of system problems.

Four characteristics of responsive system

When defining a responsive system, we mentioned four characteristics: responsive, resilient, elastic, and message driven.

Next, we will describe the mystery of these four characteristics.

Timely response

Responsive means that the system can respond to requests immediately, which should include two meanings.

First, the response time should be short enough. If a user requests a page, waiting for 2 seconds is estimated to be the limit. It is estimated that this user will be lost in another long time.

Times are changing and technology is also changing. It took a minute to download a few hundred K file more than a decade ago. It is estimated that even if it is very fast, it will be crazy if there is no several megabits per second now.

In modern CPU, with the rapid development of service cluster and optical fiber transmission and the great changes of page information, an ordinary page may contain more than ten or twenty requests. The time per request has been raised to milliseconds or even subtle levels. At the same time, there are many new changes in page display, such as asynchronous loading and preloading.

The ultimate goal is to create a system that can respond in time. Various technologies and new request methods behind the system serve this goal.

Second, the response time for errors is shorter.

On the one hand, for users, it is necessary to timely remind users of possible errors. Whether it is the error of the system itself or the user's use, it needs to respond in a limited time.

On the other hand, for the system itself, it 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 to find and respond to the problems of the system itself? First, we should have a perfect error recording system to make everything follow rules. The second is to have corresponding monitoring measures, so that any problem in the system can be notified and alarmed in time.

Restorative

Recoverability means that the system can still provide external services in case of failure or error.

First of all, our system is required to be robust enough to resist normal access and deal with hotspot access predictably.

Secondly, the functions of modern systems are various. There may be dozens of services in the background of a simple app. Therefore, we need to distinguish between key services and non key services. For key services, we must ensure their stability. For non critical services, we can consider them on the premise of ensuring key services first.

For example, in an order system, placing an order must be a key service, while the number of likes and comments of goods are not so important.

To distinguish between critical services and non critical services, we should distinguish and isolate them. Any error or exception of non critical services cannot affect critical services.

Thirdly, if the service sends an error, we should try to narrow the scope of influence as much as possible, and don't let a small error affect all services.

Finally, there should be recovery measures for failures, and this recovery measure should not affect other system services. For example, we can replicate the existing system. When a service fails, we can replace it with a standby service.

Only in this way can the reliability of the system be guaranteed.

Elastic

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

Now many cloud services provide dynamic expansion functions. If the system is implemented by ourselves, we need to distinguish between hot issues and non hot issues.

Only hot issues need to consider elasticity. The system can not have bottlenecks, and can be fragmented or replicated, so as to realize the distributed dynamic load function.

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

Flexibility can be achieved by software or hardware. Of course, we need to strike a balance between cost and effect.

Message driven

The essence of message driven is to send messages, receive messages and then process them. Nowadays, few large systems do not use message oriented middleware. The advantage of using these message oriented middleware is that it can be decoupled and driven asynchronously.

The benefits of asynchrony are not discussed here. It is probably that you don't have to wait all the time, but make full use of your time to do more efficient things.

The role of decoupling is even greater. Modern systems are basically composed of many services. If you want to ensure the smooth operation of so many systems, you must do decoupling operation, otherwise the failure of a service will lead to the unavailability of all services. You are afraid 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 regard these services as one person, and the communication between multiple people is through language. Language driven or message driven.

Here is another common concept in message driven: back pressure.

We know that the processing speed of sending and receiving messages is limited. When the speed of sending messages is faster than that of receiving messages, messages will be sent and blocked. When messages are blocked too much, messages may be lost or services may crash. And if too many messages have not been processed and not responded, it is also very bad for the user experience.

The concept of back pressure needs to be used here. If the message receiver cannot process 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 enables the system to respond gracefully to the load rather than crash under the load.