Evolution of large-scale website architecture

Today, let's talk about how a website builds the system architecture step by step. Although we hope that the website can have a good architecture at the beginning, however, Marx told us that things are constantly evolving, and the website architecture is constantly improved with the expansion of business and user needs. The following is a basic process for the gradual development of the website architecture.

Today, let's talk about how a website builds a system step by step.ArchitectureAlthough we hope that the website can have a good architecture at the beginning, Marx tells us that things are constantly advancing in the development, the website architecture is also constantly improved with the expansion of business and user needs. The following is a basic process for the gradual development of the website architecture. After reading this article, please think about the stage at which you are now.

Architecture Evolution Step 1: physically separate WebServer and database

At the beginning, due to some ideas, a website was built on the Internet. At this time, even hosts may be rented. However, as this article only focuses on the evolution of the architecture, therefore, it is assumed that a host has been hosted at this time, and there is a certain amount of bandwidth. At this time, because the website has certain characteristics and attracts some people to visit, you gradually find that the system is under increasing pressure and the response speed is getting slower and slower, at this time, it is obvious that the database and application are mutually affected, and the application has problems, and the database is also prone to problems. In the case of database problems, the application is also prone to problems. So we entered the first stage of evolution: physically separating applications and databases into two machines. At this time, there were no new technical requirements, however, you find that the results are indeed effective, and the system returns to the previous response speed, and supports higher traffic, and will not affect each other because of databases and applications.

Take a look at the system diagram after this step is completed:

Step 2 of Architecture Evolution: add page Cache

It is not a long time. As more and more people access the database, you find that the response speed starts to slow down again. Looking for the reason, you find that there are too many operations to access the database, resulting in fierce competition for data connections, and the response slows down. However, the database connection cannot be opened too much. Otherwise, the pressure on the database machine will be high. Therefore, we should consider using a cache mechanism to reduce the competition for database connection resources and the pressure on Database reading. At this time, you may choose to use squIdAnd other similar mechanisms to cache relatively static pages in the system (for example, pages updated in a day or two) (of course, static pages can also be used ), in this way, you can reduce the pressure on WebServer and reduce the competition for database connection resources without modifying the program. OK, so you began to use squid for relatively static page cache.

Take a look at the system diagram after this step is completed:

This step involves these knowledge systems:

Front-end page cache technology, such as squid. If you want to use it well, you must have a thorough understanding of squid implementation methods and cache failure algorithms.

Step 3 of Architecture Evolution: add page fragment Cache

After squid is added for caching, the overall system speed is indeed improved, and the pressure on WebServer is also decreasing. However, as the access volume increases, it is found that the system has started to slow down. After learning about the benefits of Dynamic Caching such as squid, I began to think about how to make the static parts of the dynamic pages cached, therefore, we consider using a page fragment caching policy like ESI, Which is OK, so we began to use ESI to cache relatively static parts of dynamic pages.

Take a look at the system diagram after this step is completed:

This step involves these knowledge systems:

Page fragment caching technology, such as ESI, also needs to master the implementation method of ESI if you want to use it well;

Step 4 of Architecture Evolution: data caching

After using ESI and other technologies to improve the system's cache effect again, the system's pressure is indeed further reduced. However, as the access volume increases, the system continues to slow down. After searching, you may find that there are some places in the system that repeatedly obtain data information, such as getting user information. At this time, consider whether the data information can be cached, therefore, the data is cached to the local memory. After the change, the response speed of the system is restored and the pressure on the database is reduced.

Take a look at the system diagram after this step is completed:

This step involves these knowledge systems:

Cache Technology, including Map data structures, cache algorithms, and implementation mechanisms of the framework itself.