Distributed Web Server Architecture
At first, due to some ideas, a website was built on the Internet. At this time, it is even possible that the host is rented, but since we only focus on the evolution of the architecture in this article, we assume that it is already hosted at this time. There is a host with a certain bandwidth. At this time, because the website has certain characteristics, it attracts some people to visit. Gradually you find that the pressure of the system is getting higher and higher, and the response speed is getting slower and slower, and this time it is more obvious The problem is that the database and the application interact with each other. If the application has problems, the database is also prone to problems. When the database has problems, the application is also prone to problems, so it has entered the first stage of evolution: the physical separation of the application and the database. , become two machines, there are no new technical requirements at this time, but you find that it does work, the system returns to the previous response speed, and supports higher traffic, and will not Databases and applications interact with each other.
This step of architectural evolution has basically no requirements on the technical knowledge system.
The second step of architecture evolution: increase the page cache
. , so the response becomes slower, but the database connection cannot be opened too much, otherwise the pressure on the database machine will be very high, so consider adopting the caching mechanism to reduce the competition of database connection resources and the pressure on database reading. At this time, you may first choose to use squid and other similar mechanisms to cache relatively static pages in the system (for example, pages that will be updated in a day or two) (of course, the scheme of making pages static can also be used), so that the program can be easily modified without modification. It is good to reduce the pressure on the webserver and reduce the competition for database connection resources, OK, so I began to use squid to cache relatively static pages.
Front-end page caching technology, such as squid, if you want to use it well, you have to master the implementation of squid and the cache invalidation algorithm.
Step 3 of Architecture Evolution: Increase Page Fragment Cache
After adding squid as a cache, the speed of the overall system has indeed improved, and the pressure on the webserver has also begun to drop. However, with the increase in traffic, it is found that the system has become a bit slow again, and I have tasted the dynamics of squid. After the benefits of caching, I began to wonder if the relatively static parts of the dynamic pages can be cached, so I considered using a page fragment caching strategy like ESI, OK, so I began to use ESI for dynamic pages. Cache of relatively static fragment parts.
This step involves these knowledge systems:
page fragment caching technology, such as ESI, etc., if you want to use it well, you also need to master the implementation of ESI, etc.; the
fourth step of architecture evolution: data caching
uses ESI and other technologies to improve the system again. After the cache effect, the pressure of the system is indeed further reduced, but again, with the increase of traffic, the system still starts to slow down. After searching, it may be found that there are some places in the system that repeatedly obtain data information, such as obtaining user information, etc. At this time, I started to consider whether it is possible to cache the data information, so I cached the data in the local memory. After the change was completed, it was completely in line with expectations, the response speed of the system was restored, and the pressure on the database was reduced again. few.
This step involves these knowledge systems:
caching technology, including data structures like Map, caching algorithms, and the implementation mechanism of the selected framework itself.
The fifth step in the evolution of the architecture:
It is not long before adding webservers. It is found that with the increase of system traffic, the pressure on the webserver machine will rise to a relatively high level during the peak period. At this time, we start to consider adding a webserver, which is also to solve the availability problem at the same time. If you avoid the downtime of a single webserver, you will not be able to use it. After doing these considerations, it is decided to add a webserver. When adding a webserver, you will encounter some problems, the typical ones are:
1. How to assign access to these two machines. The solution that is usually considered at this time is the load balancing solution that comes with Apache, or a software load balancing solution such as LVS;
2. How to keep the synchronization of state information, such as user Session, etc. At this time, the schemes that will be considered include mechanisms such as writing to the database, writing to storage, cookies or synchronizing session information;
3. How to keep the synchronization of data cache information, such as previously cached user data, etc., this time usually considers There are cache synchronization or distributed cache mechanism;
4. How to make uploading files and similar functions continue to be normal, the mechanism that is usually considered at this time is to use shared file system or storage, etc.
After solving these problems, we finally put the webserver With the addition of two, the system finally returned to its previous speed.
This step involves these knowledge systems:
load balancing technologies (including but not limited to hardware load balancing, software load balancing, load algorithms, linux forwarding protocols, implementation details of the selected technologies, etc.), active and standby technologies (including but not limited to ARP) cheating, linux heart-beat, etc.), state information or cache synchronization technology (including but not limited to Cookie technology, UDP protocol, state information broadcasting, implementation details of the selected cache synchronization technology, etc.), shared file technology (including but not limited to but not limited to NFS, etc.), storage technology (including but not limited to storage devices, etc.).
The sixth step of architecture evolution: After the sub-database
enjoyed the happiness of the rapid growth of system access for a period of time, it was found that the system began to slow down again. What is the situation this time? After searching, it was found that these operations of database writing and updating were found. The resource competition of some database connections is very fierce, which leads to the slowdown of the system. What should I do now? At this time, the optional solutions include database clustering and sub-database strategy. In terms of clustering, some databases do not support it very well. Library will become a more common strategy, and sub-library means to modify the original program. After one modification to realize sub-library, yes, the goal has been achieved, and the system recovery speed is even faster than before.
This step involves these bodies of knowledge:
In this step, it is more necessary to make a reasonable division from the business to realize the sub-database, and there are no other requirements for the specific technical details;
but at the same time, with the increase of the data volume and the progress of the sub-database, in the design and tuning of the database And maintenance needs to be done better, so there are still high requirements for these technologies.
The seventh step of architecture evolution: sub-table, DAL and distributed cache
With the continuous operation of the system, the amount of data begins to increase significantly. At this time, it is found that the query after sub-database will still be a little slow, so the sub-table is started according to the idea of sub-database. Of course, this will inevitably require some modifications to the program. Maybe at this time, the application will find that it needs to care about the rules of sub-database and sub-table, etc. It is still a bit complicated, so it is possible to add a general framework. To achieve data access of sub-database and sub-table, this corresponds to DAL in the eBay architecture. This evolution process takes a relatively long time. Of course, it is also possible that this general framework will wait until the sub-table is completed. At the same time, at this stage, it may be found that there is a problem with the previous cache synchronization scheme, because the amount of data is too large, it is impossible to store the cache locally, and then the method of synchronization needs to adopt a distributed cache scheme, so , it was another round of investigation and torture, and finally a large amount of data cache was transferred to the distributed cache.
This step involves these knowledge systems:
more sub-tables are also business divisions. Technically, there will be dynamic hash algorithms, consistent hash algorithms, etc.;
DAL involves more complex technologies, such as database connection management. (timeout, exception), control of database operations (timeout, exception), encapsulation of sub-database sub-table rules, etc.; the
eighth step of architecture evolution: adding more webservers
After completing the work of sub-database and sub-table, the pressure on the database has been reduced to a relatively low level, and I began to live a happy life of watching the surge in traffic every day. Suddenly, one day, I found that the access to the system began to change again. The trend is slow. At this time, first check the database, the pressure is normal, and then check the webserver, and find that apache blocks a lot of requests, and the application server is also relatively fast for each request, it seems that the number of requests is too high and needs to wait in line , the response speed is slow, which is easy to handle. Generally speaking, there will be some money at this time, so add some webserver servers. In the process of adding webserver servers, there may be several challenges:
1. Apache software Loads or LVS soft loads cannot afford the scheduling of huge web traffic (number of requested connections, network traffic, etc.). At this time, if the funds allow, the plan will be to purchase hardware loads, such as F5, Netsclar, Athelon, etc. If the funds do not allow, the solution will be to classify the applications logically, and then distribute them to different soft load clusters;
2. Some of the original state information synchronization, file sharing and other solutions may appear The bottleneck needs to be improved. Maybe at this time, a distributed file system that
meets the business needs of the website will be written according to the situation; The solution is to keep adding webservers.
This step involves these knowledge systems:
at this step, with the continuous growth of the number of machines, the continuous growth of the data volume and the higher and higher requirements for system availability, this time requires a more in-depth understanding of the technologies used. understanding, and need to make more customized products according to the needs of the website.
The ninth step of architecture evolution: data read-write separation and cheap storage solution
Suddenly one day, I found that this perfect era was coming to an end, and the nightmare of the database appeared again. Because too many webservers were added, the resources for database connection were still not enough, and at this time, the database and tables were divided. Now, start to analyze the pressure status of the database, and you may find that the read-write ratio of the database is very high. At this time, you usually think of the solution of data read-write separation. Of course, this solution is not easy to implement. In addition, you may find some data storage It is a bit wasteful on the database, or it takes up too much database resources, so the architecture evolution that may be formed at this stage is to realize the separation of data read and write, and at the same time write some cheaper storage solutions, such as BigTable.
This step involves these knowledge systems:
data read-write separation requires in-depth mastery and understanding of database replication, standby and other strategies, as well as self-implemented technologies;
cheap storage solutions require in-depth understanding of OS file storage and understanding, and at the same time requires a deep grasp of the language used in the implementation of the document.
The tenth step of architecture evolution: entering the era of large-scale distributed applications and the dream era of cheap server clusters
After the above long and painful process, we finally ushered in the perfect era again. Continuously increasing webservers can support higher and higher traffic. For large websites, the importance of popularity is beyond doubt. The demand for various functions has also begun to grow explosively. At this time, I suddenly found that the web application originally deployed on the webserver was already very large. When multiple teams began to make changes to it , it is really inconvenient, and the reusability is also quite bad. Basically, each team has done more or less repetitive things, and deployment and maintenance are also quite troublesome, because the huge application package is on N machines. It takes a lot of time to copy and start, and it is not easy to check when there is a problem. Another worse situation is that there is a possibility that a bug in a certain application will cause the entire site to be unavailable. Other factors such as tuning is not easy to operate (because the applications deployed on the machine have to do everything, and it is impossible to perform targeted tuning) and other factors, according to this analysis, I began to make up my mind to split the system according to responsibilities , so a large-scale distributed application was born. Usually, this step takes a long time because it will encounter many challenges:
1. After disassembling into distributed applications, it is necessary to provide a high-performance and stable communication framework, and Need to support a variety of different communication and remote calling methods;
2. It takes a long time to split a huge application, and needs to organize business and control system dependencies;
3. How to operate and maintain (dependency management, health management, error tracking, tuning, monitoring and alerting, etc.) for this huge distributed application.
After this step, the architecture of almost the system has entered a relatively stable stage, and at the same time, a large number of cheap machines can be used to support the huge amount of access and data. Combined with this architecture and the experience learned from so many evolutions, other Various methods to support the increasing traffic.
This step involves these knowledge systems:
this step involves a lot of knowledge systems, requiring in-depth understanding and mastery of communication, remote calls, message mechanisms, etc. The implementation of the language used is clearly understood.
Operation and maintenance also involves a lot of knowledge systems. In most cases, it is necessary to master distributed parallel computing, reporting, monitoring technology, and rule strategies.
It’s really not that laborious. The classic evolution process of the entire website architecture is similar to the one above. Of course, the plans and evolution steps taken at each step may be different. In addition, due to the different business of the website, there will be different professional The needs of technology, this blog is more about the evolution process from the perspective of architecture, of course, there are many technologies that have not been mentioned here, such as database clustering, data mining, search, etc., but in the real In the process of evolution, it will also support larger traffic by improving hardware configuration, network environment, transforming operating system, CDN mirroring, etc. Therefore, there will be many differences in the real development process. Another large website has to do Far from just the above, there are also things like security, operation and maintenance, operation, service, storage, etc. It is really not easy to make a large website
Reprinted from: http://www.cnblogs.com/goto/archive/2012/11/13/2767762.html