Thinking of web system architecture

capabilities required for large systems

As a large-scale web system, it has the ability of large-scale system, can be more advantageous in business logic to deal with a variety of "big" (large amount of data, large concurrency, complex system logic, demand development iterative fast) problem. So what is the ability of such a system?

The processing power, that is, from a non-technical level embodies a system performance problem. As the boss tells you, this system should be fast, good, stable, real-time monitoring data and so on! And for a technician, how do you implement the boss's standards for the system?

In this article, I will compare a system architecture to a river, and more accurately, it should be a river network composed of rivers, lakes, dams, etc.

About the processing power of the system I summed up the following points:

ability to handle high concurrency

Concurrent processing capability is an important factor in system evaluation. The general scenario requires a request of ten million / Second, and a special scenario requires A request of up to a second. The river's ability to handle water is supposed to be the capacity of the river to flow.

1. first of all, based on the problem of system processing capability, the first step is to set the system to a maximum value. If the system is compared to a river, where the flow of water in the river, no matter how much need to have an upper limit, at the source limit the amount of water. The river does not cause the river overflow the important safeguard.

The cluster Web Server requests a high-value setting, and now the main Web Server (apache,nginx,iis ) can be based on the processing power of the cluster server to the design process request of the line value.

The maximum number of cluster cache component connections is set.

Master-Slave database connection number on-line value setting.

2. The system's ability to handle the upper limit of the setting is essentially, only the system concurrency protection. There is no substantive solution to the problem of dealing with high concurrency. Or take the river to say things, the boss said you this river to deal with 5 million cubic meters per hour of water. How do you do that? Think of the control variables, if the river width and depth are already a fixed value (our single server processing capacity is already a fixed value), it can only handle 1 million per hour of water. The idea is to increase the number of rivers, and to tackle the river, but I have to deal with many rivers. In the system architecture, we can also classify requests according to the business domain of our specific system, and the different domain requests are given to the server to deal with, that is, the idea of the domain divide and conquer. The distribution of the system request and the result of the request are returned to the requesting client, which is what we call the load balancer and the reverse proxy. To achieve load balancing is a hardware load balancing, the other is the proxy server to do load balancing. Look at the system size, moderate on the line. Not blindly pursuing high availability, the larger the system, the more costs and problems will arise. General large-scale system, with proxy server for load balancing and reverse proxy is fully sufficient. If the requirements are not met, there are other problems with the magnitude of the system (the request link length problem, we may need to be deployed according to the region problem of the requesting user). Whether it's a request from outside the system or an internal SOA Service request, all I want to say is the load balancing of the requests and the domain divide and conquer.

the ability to quickly process requests

For a single request, how do we improve its processing speed. Take the logic of a commodity trade as an example, you initiate a payment request, the most basic condition you can pay. But what are the conditions that can be paid for? Legitimate users, legitimate merchants, there are order numbers, there are goods, you have to have money, and then you have to write down the behavior of your purchase, you have to return and so on. The conditions here are still some very general conditions. The need to meet these conditions may require more logical validation. Analysis of this logic, we do not need each time the user to buy products to re-judge the time he is a legitimate user, we do not need users to buy goods, and again to settle his amount. Here's what I want to say:

1. As far as possible to streamline the main process, asynchronous as far as possible asynchronous processing, can preprocess preprocessing.

2. Some functions that can be processed asynchronously, such as log information logging, careful push and so on, as far as possible to use asynchronous processing, do not block the main process.

3. Can preprocess the information, as far as possible pretreatment.

4. Use the cache as much as possible instead of unnecessary duplication calculations. In fact, the code logic also needs to consider this point. This is actually a lot of situations that need to be associated with preprocessing.

5. Consider whether multiple unrelated and validating complex logic can be processed concurrently, when these logic is necessary for validation and not good for preprocessing.

ability to expand function modules quickly and easily according to business needs

The so-called functional module has excellent rapid development ability, there will be no reaching situation. In the architecture of the underlying service, the architect defines and divides the domain, and the abstraction of each layer is justified. This ability is largely dependent on the architect's personal development qualities and knowledge of the business scenario.

ability to submit system performance through hardware devices

The hardware solves the system performance problem, is a system performance outstanding main performance, is also the most cost-effective way. The technology involved here is mainly clustering. If the system is simple and the traffic is huge, we can add the application server to settle the request volume problem. If the underlying logic of the system is complex, the application server can withstand a certain amount of requests, while the underlying service cannot meet the processing of this data volume request. There are two ways in which we can solve this problem. When this business scenario is ongoing and needs to be dealt with in a timely manner, we can increase the processing capacity of the underlying service machines that cannot be processed. If the scene is something that does not need to be processed in real time and the situation is intermittent. We can consider the data queue up, methodical processing. In the case of a river, it is equivalent. All the water I let him into the pond, I get the water through the pond. Process data according to my processing power. I do not care about the high who if I can deal with or beyond my ability to deal with.

Thinking of web system architecture