Large Web site architecture evolution and knowledge system _ related skills

Coupled with the recent feeling that many students are difficult to understand why a Web site requires so complex technology, so with the idea of writing this article, in this article will explain a common web site to develop into a large web site in the process of a more typical structure evolution and the knowledge system needed to master, Hope to be engaged in the Internet industry students a little preliminary concept,:), the text of the wrong place also please give a little more advice, so that this article really played a good effect.
<!--[If!supportlinebreaknewline]-->
<!--[endif]-->

Architecture Evolution First Step: physical separation of webserver and databases

In the beginning, because of some ideas, so on the internet to build a website, this time maybe even the host is leased, but because this article we only focus on the evolution of the architecture, so assume this time is already hosted a host, and has a certain bandwidth, this time because the site has a certain characteristics, Attracted some people to visit, gradually you find the system more and more pressure, response speed is more and more slow, and this time is more obvious is the database and application interaction, application problems, the database is also very easy to problem, and the database problem, the application is also easy to problem, So it goes into the first stage of evolution: separating applications and databases physically, become two machines, this time there is no new technical requirements, but you find that the effect of the system is restored to the previous response speed, and the support of higher traffic, and not because of the database and application formation of the impact of each other.

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

<!--[If!vml]-->
<!--[endif]-->

This step involves these knowledge systems:

The evolution of this framework does not require basic technical knowledge systems.
<!--[If!supportlinebreaknewline]-->
<!--[endif]-->

Architecture Evolution Step Two: Increase page caching

Not long, with more and more people visit, you find that the response speed began to slow down, find out why, found that access to the database is too much operation, resulting in fierce competition in the data connection, so the response slowed, but the database connection can not open too much, otherwise the database machine pressure will be very high So consider adopting caching mechanism to reduce the competition of database connection resources and the pressure of database reading, this time may be the first choice to use squid and other similar mechanisms to the system of relatively static pages (such as a two days will be updated page) to cache (of course, you can also use the solution to the page static), This program can not be modified, it can be very good to reduce the pressure on the webserver and reduce the competition for database connection resources, OK, so began to use squid to do relatively static caching of the page.

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

<!--[If!vml]-->
<!--[endif]-->

This step involves these knowledge systems:

Front-End page caching technology, such as squid, if you want to use good words have to thoroughly grasp the implementation of squid and cache failure algorithm.

Architecture Evolution Step Three: Increase page fragment caching

Added squid to do the cache, the overall system speed is indeed improved, webserver pressure is also beginning to decline, but with the increase in traffic, found that the system began to change a bit slow, in the taste of squid and other dynamic caching benefits, Start thinking about whether the relatively static parts of those dynamic pages are now cached, so consider using a page fragment caching strategy like ESI, OK, and start using ESI to cache the relatively static fragment portions of dynamic pages.

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

<!--[If!vml]-->
<!--[endif]-->

This step involves these knowledge systems:

Page fragment caching technology, such as ESI and so on, want to use good words also need to master the way of ESI implementation;

Architecture Evolution Step Fourth: Data caching

After using technologies such as ESI to increase the caching effect of the system again, the pressure of the system is indeed further reduced, but again, as the volume of traffic increases, the system begins to slow down, after looking, you may find that there are some duplication of data acquisition information in the system, such as access to user information, etc. This time began to consider whether this information can also be cached, so that the data cache to local memory, after the change, fully meet the expectations of the system response speed restored, the database pressure has been reduced a lot.

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

<!--[If!vml]-->
<!--[endif]-->

This step involves these knowledge systems:

Caching technology, including such as map data structure, caching algorithm, the implementation of the framework itself.

Architecture Evolution Step Fifth: Increase webserver

Not long, found that with the increase in system access, Webserver machine pressure in the peak will rise to a higher, this time began to consider adding a webserver, which is also to solve the problem of usability, to avoid a single Taiwan's webserver Down machine words can not use, after doing these considerations, decided to add a webserver, add a webserver, will encounter some problems, typically:
1, how to allow access to the two machines, this time will usually consider the scheme is the Apache with the load-balanced solution, or LVS such software load Balancing program;
2, how to maintain the status of information synchronization, such as user session, etc., this time will consider the scheme to write to the database, write storage, cookies or synchronous session information and other mechanisms;
3, how to keep the data cache information synchronization, such as previously cached user data, etc., this time will usually consider the mechanism of cache synchronization or distributed caching;
4, how to upload files of these similar functions continue to normal, this time usually consider the mechanism is the use of shared file systems or storage;
After solving these problems, finally is to add webserver to two, the system is finally restored to the past speed.

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

<!--[If!vml]-->
<!--[endif]-->

This step involves these knowledge systems:

Load balancing technology (including but not limited to hardware load balancing, software load balancing, load algorithms, Linux forwarding protocols, implementation details of selected technologies, etc.), primary standby technology (including but not limited to ARP spoofing, Linux heart-beat, etc.), State information or cache synchronization techniques (including but not limited to cookie technology, UDP protocol, status information broadcast, implementation details of selected cache synchronization technologies, etc.), shared file technology (including but not limited to NFS, etc.), storage technologies (including but not limited to storage devices, etc.).

Architecture Evolution Step Sixth: sub-Library

Enjoy a period of time system access to the rapid growth of happiness, found that the system began to slow down, this time what is the situation, after the search, found that the database write, update some of these operations database connection resources competition is very fierce, resulting in the system slows down, this how to do? The options available at this time are database clustering and library strategy. Clustering, like some database support is not very good, so the library will become a more common strategy, the library is meant to modify the original program, a change to realize the library after a good, the goal is achieved, the system to restore even faster than before.

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

<!--[If!vml]-->
<!--[endif]-->

This step involves these knowledge systems:

This step is more need to do from the business reasonable division, in order to realize the library, the specific technical details of no other requirements;

But at the same time, with the increase of data volume and the development of the library, it is necessary to do better in the design, tuning and maintenance of the database, so the technology of these aspects has put forward a high demand.

Architecture Evolution Step Seventh: Sub-table, Dal, and distributed caching
With the continuous operation of the system, data volume began to increase significantly, this time found that the query after the library will still be a bit slow, so according to the idea of the sub-Library to do the work of the table, of course, this will inevitably require some changes to the program, perhaps at this time will find the application of their own to care about the rules of the sub-table, is still somewhat complicated, and the initiation can add a common framework for data access to the sub-database, this corresponds to the DAL in the ebay architecture, which takes a relatively long time to evolve, and, of course, it is possible that the generic framework will wait until the table is finished, and At this stage, you may find that there is a problem with the previous cache synchronization scenario, because the amount of data is too large, which makes it less likely that the cache will be present locally, and then synchronized in a way that requires a distributed caching scheme, it is also a survey and torture, and finally a large number of data cache transfer to the distributed cache.

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

<!--[If!vml]-->
<!--[endif]-->

This step involves these knowledge systems:

More of the same is the division of the business, the technology involved will be dynamic hash algorithm, consistent hash algorithm, etc.

Dal involves more complex technologies, such as database connection management (timeout, exception), database operation control (timeout, exception), the packaging of the sub-table rules;

Architecture Evolution Step Eighth: add more webserver

Having done the work on the Sub-Library table, the pressure on the database has been reduced to a relatively low, and began to live every day to see the great increase in the happiness of life, and suddenly one day, the discovery system has begun to slow the trend of access, this time to first look at the database, pressure all normal, and then view webserver, found that Apache blocked a lot of requests, and the application server for each request is also relatively fast, it seems that the number of requests is too high to be queued, slow response, this is fine, in general, this time will also have some money, so add some webserver server, in this add There are several challenges that can arise from the process of webserver servers:
1, the Apache soft load or LVS soft load can not afford a huge amount of web traffic (request connection number, network traffic, etc.) scheduling, this time if the funds allow, will take the solution is to buy hardware load, such as F5, Netsclar, Athelon and so on, If the funds are not allowed, the plan is to be applied logically to do a certain classification, and then dispersed to different soft load cluster;
2, some of the original state information synchronization, file sharing and other programs may appear bottlenecks, need to improve, perhaps this time will be prepared according to the situation of the Web site business needs of the distributed file system;
After these work, began to enter a seemingly perfect era of unlimited expansion, when the site traffic increase, the solution is to constantly add webserver.

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

<!--[If!vml]-->
<!--[endif]-->

This step involves these knowledge systems:

At this point, with the increasing number of machines, the increasing amount of data and the increasing demand for system availability, this time requires a more in-depth understanding of the technology used, and needs to be tailored to the needs of the site.

Architecture Evolution Step nineth: Data read-write separation and low-cost storage scenarios

Suddenly one day, discover this perfect time also want to end, the database nightmare again appear in front of, because of add webserver too much, cause the database connection resources or not enough, and this time has already divided the storehouse, began to analyze the database pressure condition, You may find that the database reads and writes is very high, this time will often think of data read and write separation scheme, of course, this solution is not easy to implement, in addition, may find some data stored in the database is a bit wasteful, or too much to occupy database resources, So the architectural evolution that may evolve at this stage is the separation of data read and write, while writing some of the more inexpensive storage scenarios, such as BigTable.

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

<!--[If!vml]-->
<!--[endif]-->

This step involves these knowledge systems:

The separation of data from reading and writing requires a deep mastery and understanding of the strategies of database replication, standby and so on, and requires the technology to be implemented by itself.

Low-cost storage solutions require deep mastery and understanding of the file storage of the OS, as well as a deep mastery of the language used in the file block.

Architecture Evolution Step Tenth: Entering the era of large distributed applications and the Dream era of Low-cost server groups

After this long and painful process, and finally ushered in the perfect era, the constant increase in webserver can support more and more visits, for large sites, the popularity of the important undoubtedly, as the popularity of the more and more high, a variety of functional needs also began to explode the growth, This time suddenly found that the original deployment of the webserver on the Web application has been very large, when more than one team starts making changes to it, it's really inconvenient, and the reusability is pretty bad, basically because every team does something more or less repetitive, and deployment and maintenance is also quite troublesome, Because the huge application package on the n machine to copy, start all need to spend a lot of time, when things go wrong, it's not easy to find out, and another worse situation is that there's a good chance that a bug in an application will cause the whole station to be unavailable, and other things like tuning poorly (because the application on the machine is doing everything, Can not be targeted at all, and other factors, based on this analysis, began to make a decision, the system according to the responsibilities of the split, so a large distributed application was born, usually, this step takes a long time, because there will be many challenges:
1. It needs to provide a high performance and stable communication framework after being split into a distributed system, and it needs to support many different communication and remote calling modes.
2. It takes a long time to split a huge application, which needs to be sorted and controlled by the system.
3, how to operate the dimension (rely on management, health management, error tracking, tuning, monitoring and alarm, etc.) good this huge distributed application.
After this step, the architecture of the system has entered a relatively stable phase, while at the same time it has been able to start using a large number of inexpensive machines to support a huge amount of traffic and data, combining the architecture and the experience gained from so many evolutionary processes to support more and more traffic.

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

<!--[If!vml]-->
<!--[endif]-->

This step involves these knowledge systems:

This step involves a lot of knowledge system, the requirements of communication, remote call, message mechanism, such as in-depth understanding and mastery, requirements are from the theory, hardware level, operating system level and the implementation of the language has a clear understanding.

The knowledge system involved in operation and maintenance is also very much, in most cases, we need to master distributed parallel Computing, report, monitoring technology and rule strategy, etc.

It's really hard to say, the classic evolution of the entire site architecture is similar to the above, of course, each step of the program, the evolution of the steps may be different, in addition, because the site's business is different, there will be different professional and technical needs, this blog is more from the perspective of the architecture to explain the evolution of the process, of course , and many of these technologies are not mentioned here, such as database cluster, data mining, search, etc., but in the real evolution of the process will also rely on such as upgrading the hardware configuration, network environment, transformation operating system, CDN image, etc. to support greater traffic, so in the real development process there will be a lot of differences, Another large web site to do far more than these, there are like security, operation, operations, services, storage, etc., to do a large site is really not easy, write this article is more hope to be able to lead to more large-scale introduction of the evolution of the structure of the Web site,:).

PS: Finally, attach a few LiveJournal architecture evolution articles:
How to optimize the performance of large scale website from LiveJournal background development
http://blog.zhangjianfeng.com/article/743
Also from here: http://www.danga.com/words/you can find out more about the present LiveJournal website architecture.