Then the article continues
After the expansion meets the basic performance requirements, we will gradually pay attention to "availability" (that is, the SLA that we usually listen to when others brag, a few 9). How to ensure true "high availability" is also a difficult problem.
Almost mainstream large and medium-sized Internet companies will use similar architectures, but the number of nodes is different.
There is another trick that is used more often, and that is the separation of movement and static. It may require the cooperation of developers (put static resources under an independent site), or it may not require the cooperation of developers (use a 7-layer reverse proxy to process, and determine the resource type based on information such as the suffix name). With a separate static file server, storage is also a problem and needs to be expanded. How can the files of multiple servers be kept consistent, and what should I do if I cannot afford shared storage? The distributed file system also comes in handy.
There is also a very common technology CDN acceleration currently used at home and abroad. At present, the competition in this field is fierce, and it is already relatively cheap. The domestic North-South Internet problem is relatively serious, and the use of CDN can effectively solve this problem.
The basic principle of CDN is not complicated. It can be understood as a smart DNS+Squid reverse proxy cache, and then a lot of computer room nodes are required to provide access.
So far, no changes have been made to the architecture of the application, or to be more popular, there is no need to modify the code in a large area.
What if all of the above methods are used up and still cannot be supported? Is it not a solution to keep adding machines?
As the business becomes more and more complex, the website has more and more functions. Although the deployment level is a cluster, the application architecture level is still "centralized", which will lead to a lot of coupling, which is not convenient for development, maintenance, and easy "Every glory is lost." Therefore, the website is usually divided into different sub-sites for separate hosting.
The applications are all dismantled. Due to the connection of a single database, QPS, TPS, I/O processing capabilities are very limited, and the DB level can also be used for vertical sub-database operations
After splitting the application and DB, there are still many problems. Different sites may have the same logic and function codes. Of course, for some basic functions, we can encapsulate DLL or Jar packages to provide references everywhere, but this strong dependency can also easily cause some problems (version problems, dependencies, etc., are very troublesome to deal with). In this way, the value of the legendary SOA has been reflected.
There will still be some dependency problems between applications and services. At this time, a high-throughput decoupling weapon appears
Finally, I also introduce a unique skill used by large Internet companies-sub-database and sub-table. Personal experience is not a business start and all aspects are very urgent, do not take this step lightly.
Because everyone can do the sub-library and sub-table, the key is what to do after the disassembly. At present, there is no completely open source and free solution on the market that allows you to solve the database split problem once and for all.
