The entire website architecture can generally be divided into application layer, service layer, data layer. In practice, the large layered structure can continue to layer, such as the application layer can continue to be divided into the view layer and business logic layer, the service layer can continue to be subdivided into the data interface layer, logical processing layer. Through layering, a huge system is cut into different parts, to facilitate the division of labor development and maintenance; the layers have a certain degree of independence from each other, in the development of the site can be adjusted according to different needs. After the logical layering, the physical deployment can also be based on demand for different strategies.

Layered architecture is not just for planning the logical structure of the software, it is especially important for the highly concurrent distributed architecture of a Web site. After layering, you can vertically split the business, according to different business modules a project is divided into different modules to a separate team to develop and deploy, after the completion of the deployment of different servers, through the link to the interconnection. Then according to different situations to different nodes for redundancy to ensure the high availability of the site, followed by caching, CDN, reverse proxy and so on optimization.

What do we need to consider for a website with high traffic and large data volumes?

1.1 Performance

First of all, performance is an important indicator of a website, unless there is no choice, just this one site, the user is absolutely not going to put up with a super slow site. Because performance problems are ubiquitous, there are a variety of ways to solve them, starting with a user request for a url, every aspect of the process can be optimized; according to the layering above, you can roughly optimize from three aspects, application layer optimization, service layer optimization, data layer optimization.

The knowledge involved is the optimization of the web front-end, the optimization of the application server side and data storage, indexing, caching, etc., which will be discussed later in the content of the respective expansion, but the performance of a website is only a necessity, in addition to the unpredictability of the site may face the pressure of the attack, but also to ensure that the site in a variety of situations (high concurrency, high load, continuous pressure) to maintain stable uneven, etc.). This includes the following aspects: performance testing metrics, performance testing methodologies, and performance optimization strategies.

Performance test metrics

The main performance test metrics are response time, concurrency, throughput, performance counters, etc.

Response time

Response time refers to the time from the beginning of the request to the receipt of data, in general, this time is very very small or even less than the error value of the test, so we can use repeated requests to get the specific response time, such as requesting 100,000 times, record the total time, and then calculate the time of a single request

Concurrency

Concurrency < /p>

The number of requests that can be processed at the same time, for the website, that is, the number of concurrent users

Throughput

is the number of requests per unit of time that can be processed, reflecting the system's overall processing capacity> there are many indicators, it can be the number of requests / number of pages per second / the number of visitors per second / number of days to deal with the number of business / hour, etc. > common quantitative indicators are TPS (transactions per second) HPS (HTTP requests per second) QPS (queries per second), etc.

Performance counters

Describes a number of performance metrics for a server or operating system, including system load (SystemLoad), number of threads, memory usage, disk and network I/O, etc., and when these values exceed a warning value (safety threshold), an alarm is sent alerts the developer to handle the exception in a timely manner.

Performance testing methodology

Performance testing is an umbrella term that can be specifically categorized into performance testing, load testing, stress testing, and stability testing. Performance testing takes the initial design metrics as the expected goal and constantly pressurizes the system to see if it can achieve the expected performance within the expected range. Load testing continually adds concurrent requests to the system to increase system pressure until one or more of the system's metrics reaches a safe threshold, at which point the system's processing capacity will be reduced by continuing to apply pressure to the system. Stress testing calculates the maximum stress tolerance of a system by continuing to apply pressure beyond the safe load until the system crashes or is no longer able to handle any requests.

Stability testing is the ability of a system to operate stably for an extended period of time under a certain amount of pressure (uneven application of pressure).

Performance optimization strategy

To locate the cause of the problem, check the logs of different links, analyze which link's response time is not in line with the expected, and then analyze the reasons affecting the performance, whether it is a code problem or an unreasonable architectural design, or insufficient system resources, and then solve the problem according to the actual problem.

1.2 Availability

For large websites, downtime is terrible, because there may be tens of millions of users, just a few minutes of downtime may lead to the site's reputation, if it is an e-commerce type of website, it may lead to the user's property damage, or even a lawsuit, then the loss of more than just money and users, so we must ensure that can provide 24 hours a day available, but in practice the server does not guarantee that 24 hours a day can run smoothly, there may be hardware problems, there may also be software problems, in short, the problem will always be there.

So the goal of our high availability design is in the case of some server downtime, but also be able to ensure that the service or application is running normally, the main means of high availability of the site is redundancy, the application is deployed on multiple servers at the same time to provide access to the data stored in a number of data servers to each other to carry out a hot backup, so that any one server downtime will not affect the service or application as a whole, and also no data loss occurs.

For application servers, multiple application servers form a cluster through a load balancing device to provide services to the outside world at the same time, when a server goes down, the service is switched to other servers to continue to execute, which ensures the website's high availability, provided that the application server is not allowed to store the user session information, which will be lost so that even if the user request is transferred to other servers, it can not continue to execute. other servers will not be able to continue execution.

For data storage servers, it is important to provide real-time backups between servers so that when a server goes down, data access is switched to other servers and data recovery and backup are performed. The measure of whether a system's architecture is designed to meet the goal of high availability is the assumption that if one or more of the servers go down and various unanticipated problems occur, the system overall is is still available.

1.3 Scalability

In the face of highly concurrent access by a large number of users and massive data storage, it is impossible to satisfy all the demands and store all the data on just one server. The so-called scalability refers to the means of constantly adding servers to the cluster to cope with the rising pressure of concurrent user access and the growing demand for data storage. For application server clusters, as long as the servers are not storing data, all servers are peer-to-peer and can be added to the cluster continuously through the use of appropriate load balancing equipment. New servers can be added to the cluster continuously by using an appropriate load balancing device.

For cache servers, adding new servers may cause cache routing to fail, resulting in most of the cached data being inaccessible, requiring improved cache routing algorithms to ensure that the cached data is accessible. Relational databases, although they support data replication, master-slave hot backups, and other mechanisms, it is difficult to achieve scalability for large-scale clusters.

1.4 Scalability

The scalability of the website is directly related to the development of the functional modules of the website, the rapid development of the website, the functions are also increasing, the main purpose of the scalability of the website architecture is to enable it to quickly respond to changes in demand, in order to be able to add new services, try to realize the existing products have no impact, do not need to change or change very little of the existing business on the new products can be online; the different services can be used for different purposes. To be able to on-line new products; the coupling between different products and businesses is very small, a product or business changes will not have an impact on other.

1.5 Security

The last thing is security. The Internet is an open platform where anyone can access a website from anywhere. The security architecture is to protect the website from malicious access and attacks, and to protect the data from being stolen.