Preface
Like it before watching it, have good habits
Almost all large-scale applications start from a small application. Good Internet products are slowly operated, not developed at the beginning, so in this article we will talk about the evolution of application architecture.
How to create a highly available, high-performance, and easily scalable application? First of all, we understand the characteristics of large-scale applications:
- High availability: The system needs to provide uninterrupted services without a single point of failure
- High concurrency: under the impact of large traffic, the system still provides services stably
- Big data: The application generates a large amount of data every day, which needs to be stored and managed well
The simplest architecture
At the beginning, the application did not have much traffic, so only one server is needed. The architecture at this time is as follows:
Applications, files, and databases are often deployed on one server. The application can be developed in Java and deployed on the Tomcat server, and the database can use open source MySQL
Application and data service separation
As the business of the application becomes more and more complex, the amount of application visits is increasing, resulting in worse performance and serious shortage of storage space. At this time, we consider increasing the service to three (the problems that can be solved by adding machines are not Question); separate the application server, database server, and file server.
- The application server needs to handle a lot of access, so it needs a better CPU
- The database server needs to store a large amount of data and fast retrieval, so the retrieval speed of the disk needs to be faster and the storage space is large
- File servers need to store uploaded files and need larger disks; nowadays, third-party storage services are usually selected
According to the scenario corresponding to each server, the performance of the application can be greatly improved after the server is configured, which better supports the development of the business. However, with the development of business and the increase in traffic, this architecture will face challenges again, the processing power of application servers will decline, and the storage space will be insufficient.
Application server cluster
In the case of high concurrency and large traffic, one server will definitely not be able to handle it. At this time, add servers and deploy clusters to provide services to share the pressure of each server. Another advantage of deploying clusters is scalability. For example, when you encounter a large traffic scenario on Double 11, you can increase server allocation traffic. After Double 11, reduce servers to save costs. The structure is as follows:
If the application server is Tomcat, then a Tomcat cluster can be deployed, and a load balancer can be deployed externally. Random, round-robin or consistent hashing algorithms can be used to distribute user requests to different application service clusters; usually free of charge The load balancer is nginx. Under this architecture, the load of the application server will not be the bottleneck of the entire application;
Although the processing speed of the application has been improved a lot under this architecture, another problem will be exposed. The pressure on the database is greatly increased, resulting in a delay in access response and affecting the performance of the entire application.
There is another problem with this architecture. Usually the application is stateful and needs to record the user's login information. If each user's request is randomly routed to the back-end application server, the user's session will be lost; two solutions to this problem Plans:
- Use consistent hash to route user requests to the same Tomcat. If a server kneels, then user information on this server will be lost
- By configuring session replication between Tomcat clusters to achieve sharing, this solution is less efficient
Neither plan is very good, so is there any other plan? please watch the following part
Cache
According to the 28th principle, 80% of the business is focused on accessing 20% of the data. This 20% of the data is usually called hot data, but the memory occupied by the 20% of the data will not be small. If each application server has Storing a copy will waste storage space, so you need to consider adding a distributed cache server (usually Redis); when the distributed cache server is introduced, the problem of the above solution can be solved, and the user’s The session is stored in the cache server, which can not only prevent the loss of user data, but also the efficiency is not low; the architecture diagram is as follows:
After all, the distributed cache server is stored remotely and needs to go through the network, so it takes a while to fetch the data; the local cache access speed is faster, but the memory space is limited, and there will be competition for resources with the application; so this architecture It is equipped with distributed cache and local cache. The local cache stores a small amount of commonly used hot data. When there is no hit in the local cache, the
After the introduction of caching, the access pressure of the database can be relieved to a certain extent
Database read and write separation
Although after adding the cache, some data can be directly cached without accessing the database, but there will still be some requests that will access the database, such as: cache invalidation, cache miss; when the traffic is heavy, the amount of database access Not small. At this time, we need to consider building a database cluster with separation of read and write
When the application server has a write operation, access the main library, when the application has a read operation, access the slave library; most applications have read operations far greater than write operations, so you can configure the database to share the database with one master and multiple slaves In order to make the application unaware of the main library and the slave library, it is usually necessary to introduce some frameworks that separate read and write to make a unified data access module.
One problem that this architecture usually needs to be vigilant about is the master-slave delay. In a high-concurrency scenario, the master database has just been written successfully, and the database has not successfully synchronized the slave database. At this time, another request enters to read the data and finds that it does not exist; The liberation scheme is to set mandatory main database query in high concurrency scenarios in the application
Brothers, please don’t use prostitutes for nothing, please give me a thumbs up first
Reverse proxy and CDN
If as the business continues to expand, our applications will be used all over the country. Due to the different network conditions in each region, some people request a fast response speed, and some people request a slow response speed, which will seriously affect users' Experience. In order to improve the response speed, it is necessary to introduce reverse proxy and CDN; both CDN and reverse proxy are caches used for:
- Present data to users as quickly as possible
- Reduce the pressure on the back-end server
The architecture diagram is as follows:
CDN: Deployed in the computer room of the network provider. When the user comes to visit, the data is returned from the server closest to the user and presented to the user as soon as possible; usually, static resources (html, js, css) are cached in the CDN. To achieve the separation of dynamics and statics; but sometimes when some data is particularly visited, the backend will generate static resources and put them into the CDN, such as the homepage of the mall, and the page that each user needs to visit when entering. All enter the backend, then the pressure on the server is certainly not small, in this case, the static files generated on the homepage will be cached to the CDN and reverse proxy server
Reverse proxy: Deployed in the central computer room of the application, it is usually a cached static resource. When the user does not request the required data through the CDN, first enter the reverse proxy server. If there is cached data accessed by the user, it is directly returned to the user ; There are special circumstances here. For the hot data in some scenarios, it is obtained from the distributed cache server according to the user's request and returned directly when it is available.
This architecture has achieved level 4 cache
- Level 1: CDN caching static resources
- Level 2: Reverse proxy caches static resources and some hot data
- Level 3: Local cache of the application server
- Level 4: Distributed Cache Server
Under normal circumstances, after these 4 levels of cache, there are not many requests that can enter the database, which relieves the pressure on the database.
Search engine and NoSQL
With the continuous expansion of business, the requirements for data storage and query are becoming more and more complex. Usually we need to introduce non-relational databases, such as search engines and NoSQL databases.
Sometimes our query scenarios are very complicated, and many data tables need to be queried, which can be completed after a series of calculations. At this time, we can consider using data synchronization tools (such as canal) to pull data to the big data platform, and use the batch processing framework for offline calculation. The output result is stored in a search engine or NoSQL database, and the application program directly queries and calculates the result and returns it to the user. It is also possible that we need to summarize the data of multiple tables to make a wide table to facilitate application query
Due to the increase in data storage methods introduced, in order to reduce the trouble of managing multiple data sources for applications, it is necessary to encapsulate a unified data access module. If you are using Java, you can consider spring-data
Business vertical split
The usual purpose of Internet companies is to iterate and run in small steps. When the business is large enough, it is difficult for a single application to achieve this purpose. With the development of the business, the application program is getting bigger and bigger, research and development, Maintenance and release costs are also increasing. At this time, it is necessary to consider splitting a single application into multiple services according to the business. Services can use RPC remote calls and message queues to complete user requests together.
Due to the split of the business, the database will usually be split accordingly to achieve the ideal state of one service corresponding to one database
The benefits of introducing MQ:
- Improve the availability of the system: when the consumer server fails to send, the message is still in the message queue, and the data will not be lost
- Speed up the response of the request: When the user request arrives at the server, the data that can be processed asynchronously in the request is put into MQ, so that the system consumes one by one without the user waiting, which speeds up the response.
- Peak shaving and valley filling: When a large number of requests enter the system at the same time, they will all be put into the message queue, and the system will consume one by one without causing a great impact on the system
to sum up
There is another situation that has not been mentioned, that is, the horizontal split of the database, which is also the last resort for database splitting. It is used only when the single table data is too large to meet the needs of the business. The most used one is to split the business of the database vertically and place the data of different businesses in the database on different physical servers.
What architecture is currently selected for the application must be flexibly selected according to actual business needs. The main driving force for the development of technical architecture is still business development, not technology for the sake of technology.
Write at the end
- First of all, thank you all for your patience to read here. Pay attention, don't get lost
- Of course, there may be more or less deficiencies and mistakes in the article. If you have suggestions or opinions, you are welcome to comment and exchange.
- In the end, it’s not good for prostitution and it’s not easy to create . I hope that friends can like and comment and follow Sanlian, because these are all the sources of motivation for my sharing.
The original is not easy to reprint, please indicate the source: https://silently9527.cn/archives/64
Reference Materials "Technical Architecture of Large Websites"