preface
“Like it before you watch it.
Almost all large applications start with a small application. Good Internet products are developed slowly, not at the beginning, so let’s talk about the evolution of application architecture.
How to build a highly available, high-performance, easily scalable application? First, let’s look at the characteristics of large applications:
- High availability (HA) : The system must provide services continuously without single points of failure
- High concurrency: The system still provides services stably under the impact of heavy traffic
- Big data: Applications generate a large amount of data every day, which needs to be stored and managed
The simplest architecture
At the beginning, the application didn’t have much traffic, so only one server was needed. The architecture at this point was as follows:
Applications, files, and databases are often deployed on a single server. The application can be developed in Java, deployed on a Tomcat server, and the database can use open source MySQL
Application and data service separation
As the application services become more complex and the number of visits increases, the performance deteriorates and the storage space is severely insufficient. At this time, we consider increasing the number of services to three (problems that can be solved by adding more machines are not problems). 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
- Database server needs to store a large amount of data and fast retrieval, so disk retrieval speed and large storage space
- File servers need to store uploaded files and need larger disks. Nowadays, third-party storage services are usually used
Based on the scenario of each server, the application performance can be greatly improved after the server is configured to better support service development. However, with the development of services and the increase of traffic volume, this architecture will face challenges again. As a result, the processing capability of application servers decreases and the storage space is insufficient
Application Server Cluster
In the case of high concurrency and heavy traffic, one server is certainly unable to handle it. At this time, more servers are added and clusters are deployed to provide services to share the pressure of each server. Another advantage of cluster deployment is the scalability of rows. For example, in the case of double 11 heavy traffic, the server can allocate more traffic. After Double 11 is over, the server can reduce costs. The structure is as follows:
If the application server is Tomcat, you can deploy a Tomcat cluster and an external load balancer to distribute user requests to different application service clusters using random, polling, or consistent hashing algorithms. The common free load balancer of choice is Nginx. In this architecture, the load of application server will not be the bottleneck of the whole application;
While the processing speed of the application is greatly improved under this architecture, another problem is exposed. The database is greatly stressed, resulting in access response delays and affecting the overall performance of the application. A problem with this architecture is that applications are usually stateful and need to record user login information. If each user request is randomly routed to the back-end application server, the user’s session will be lost. There are two solutions to this problem:
- A consistent hash is used to route user requests to the same Tomcat, and if a server kneels, the user information on that server will be lost
- Session replication is configured for Sharing between Tomcat clusters. This solution is inefficient
Neither plan is very good, so is there any other plan? Keep reading
The cache
According to this principle, 80% of the business are centralized access to 20% of the data, the 20% of the data is often referred to as hot spots, but the memory is not little occupied 20% of the data, if each application server to store a, some waste of storage space, so this time need to consider to join distributed cache server (commonly used is Redis); When the distributed cache server is introduced, the problem of the above solution can be solved. Storing user sessions in the cache server can not only prevent the loss of user data, but also not low efficiency. The architecture diagram is as follows:
Because the distributed cache server is stored remotely after all, it needs to go through the network, so it still takes a little time to fetch data; Local cache access is faster, but memory is limited, and applications compete for resources. So this architecture combines distributed caches with local caches, which hold a small amount of frequently used hotspot data, and de-centralized caches when there are no hits in the local cache
After the introduction of cache, the database access pressure can be relieved to a certain extent
Database read/write separation
Although after joining the cache, part of the data can directly go cache, do not need to access the database, but still there will be some requests, will access the database, such as: cache failure, cache missed; When there is a lot of traffic, the number of visits to the database is not small. At this time we need to consider building database cluster, read and write separation
When the application server has a write operation, it accesses the master library. When the application program has a read operation, it accesses the secondary library. In most applications, the read operation is much more than the write operation. Therefore, you can configure a database to share the database load. In order to make the application not aware of the corresponding master and slave libraries, it is usually necessary to introduce some read/write separation framework to make a unified data access module.
This architecture usually needs to be aware of a problem is the master-slave delay, when in a high concurrency scenario, the master database has just been written successfully, the database has not successfully completed the synchronization of the slave database, at this time another request to read data does not exist; The liberation solution is to set up a forced off primary library query in the scenario of high concurrency in the application
Brothers, please don’t white whoring oh, half of the article, please like first
Reverse proxy and CDN
With the continuous expansion of business, our application will be used all over the country. Due to different network conditions in different regions, some people have fast response speed and some people have slow response speed, which will seriously affect the user experience. In order to improve the response speed, reverse proxy and CDN should be introduced. CDN and reverse proxy are used for caching purposes:
- Present the data to the user as quickly as possible
- Reduce the stress on back-end servers
The architecture diagram is as follows:
CDN: deployed in the computer room of the network provider, when the user comes to visit, the data will be returned from the server nearest to the user and presented to the user as soon as possible; Normally, static resources (HTML, JS, CSS) are cached in CDN to achieve static and static separation. But sometimes encountered some of the data traffic particularly big, the back-end generates static resources into the CDN, such as: the mall homepage, each user enter the need to access the page, if every request into the back end, the server pressure is not small, this case will be the home page to generate a static file cache to the CDN and reverse proxy server
Reverse proxy: deployed in the central equipment room of an application, it is usually a cached static resource. If a user does not receive required data through the CDN, the reverse proxy server is used first. If any data is cached, it is directly returned to the user. There are also special cases. For hotspot data in some scenarios, it is obtained from the distributed cache server according to the user’s request and returned directly if it can be obtained.
This architecture has brought caching up to level 4
- Level 1: CDN cache 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
Usually after these four levels of caching, there are not many requests to the database, which relieves the pressure on the database
Search engines and NoSQL
With the continuous expansion of business, the demand for data storage and query is also more and more complex, usually we need to introduce non-relational databases, such as search engines and NoSQL databases
Sometimes we query scenarios are complex, and requires a lot of data query table, after a series of calculation to complete, this time can be considered through the data synchronization tools (such as a canal) to data to the big data platform, using batch framework offline calculation, the output into the search engine results stored or no (database, The application queries the results directly and returns them to the user. It is also possible that we need to aggregate data from multiple tables to create a single wide table for easy application queries
Due to the increasing number of data storage methods introduced, the unified data access module needs to be packaged to reduce the trouble of managing multiple data sources in the application. If Java is used, spring-Data can be considered
Vertical separation of services
Internet companies are usually small step iterative trial and error is the goal of the run, when the development of the business is large enough, for single applications to achieve this objective is difficult, with the development of the business, the application is more and more big, the research and development, the cost of maintenance, publishing is becoming more and more big, this time will need to be considered according to the business split the monomer used for multiple services, Services can complete user requests together through RPC remote calls and message queues.
Because services are split, databases are usually split accordingly to achieve the ideal state of one service for one database
Benefits of introducing MQ:
- Improved system availability: When the consuming server sends a failure, the message remains in the message queue and data is not lost
- Faster response to requests: When a user request arrives at the server, the data that can be processed asynchronously in the request is put into MQ so that the system can consume it one by one without requiring the user to wait, which speeds up the response time
- Peak clipping: When a large number of requests enter the system at the same time, they are all put into the message queue, and the system consumes them one by one without causing a great impact on the system
conclusion
There is also a case that is not discussed, is the database split horizontal, which is the last method of database splitting, only when the single table data is too large to meet the needs of the business. The most popular method is to split database services vertically to store data of different services in the database on different physical servers.
What architecture to choose must be flexibly chosen according to actual business needs. The main driving force for the development of technical architecture is business development, not technology for technology’s sake.
Write in the last
- First of all, thank you for reading this patiently. Pay attention and don’t get lost
- Of course, there may be more or less deficiencies and mistakes in the article, suggestions or opinions are welcome to comment and exchange.
- Finally, white piao is not good, creation is not easy, I hope friends can like the comments pay attention to three even, because these are all the power source I share 🙏
Original is not easy to reprint please indicate the source: silently9527. Cn/archives / 64
Reference: Technical Architecture for Large Web Sites