Home  >  Article  >  Backend Development  >  Scalability design of website architecture

Scalability design of website architecture

高洛峰
高洛峰Original
2016-11-03 14:59:381046browse

In the early days of website development, we are accustomed to writing all codes into one project.

Front-end, back-end, cache, database, static resources...etc.

Physical separation of website systems

Slowly the system will become larger and larger, and it will obviously need to face high concurrent access by a large number of users and store massive data.

Many user requests cannot be completed on one server.

A lot of cached data and database data cannot be completed on one server.

At this time, the scalability architecture of the website becomes particularly important.

As shown below.

Scalability design of website architecture

Principle

We assemble multiple servers into a whole to provide services together. By continuously adding servers to the cluster, we can alleviate the rising pressure of concurrent user access and the growing demand for data storage.

The main criterion for measuring the scalability of an architecture:

How easy it is to add new servers to the cluster.

When adding a new server, can it provide the same service as the original server?

Is there a limit to the total number of servers that can be accommodated in the cluster?

Application Server Cluster

As long as no data is saved on the server, all servers are equal, and servers can be added to the cluster through load balancing devices.

Relational Database Cluster (MYSQL)

The cluster scalability solution of the relational database must be implemented outside the database. Servers with multiple data deployed are formed into a cluster through routing partitioning and other means.

For example: Mysql, etc.

Non-relational database cluster (NOSQL)

Non-relational databases are inherently prepared for massive databases, so they support scalability very well.

For example: Redis, Memcache, etc.

Cache Server Cluster

Adding new servers may cause the cache routing to become invalid, which in turn makes most of the cached data in the cluster inaccessible.

Before deployment, the cache routing algorithm needs to be improved to ensure the accessibility of cached data.

Static resource server cluster

Resources such as CSS, JS, Img, etc. are deployed to the server cluster to reduce traffic and increase page rendering speed.

Vertical separation of the website

Separate and deploy different parts of the business processing process to achieve system scalability.

As shown below.

Scalability design of website architecture

Horizontal separation of the website

Separate deployment of different business modules to achieve system scalability.

As shown below.

Scalability design of website architecture

A single function scales through the cluster size.

Separating and deploying different functions can achieve a certain degree of scalability, but as the number of website visits gradually increases, even an independent deployment of a single server separated to the latest granularity cannot meet the requirements of business scale.

Therefore, a server cluster must be used, that is, the same service is deployed on multiple servers to form a cluster for overall external services.

For example: search function.

If a server can provide 1,000 request services per second, if the website is at peak period, the number of search visits per second will be 10,000.

Then, you need to deploy 10 servers to form a cluster.

Similarly, this situation will also occur with cache servers.

In fact, when calculating the cluster size of a service, you need to consider its impact on availability, performance and the impact of associated service clusters.

Summary

Cluster scalability can be divided into application server cluster scalability and data server cluster scalability.

Due to the different management of data status, the technical implementation of these two clusters is also very different.

Everyone, you can conduct in-depth research based on each specific architectural design.

The article is borrowed from the book "Technical Architecture of Large Websites".


Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn