Basically any large-scale distributed applications are from the initial application to a single step of evolution that does not mean that can not start the design of a large and complex distributed system, which is the initial capital investment and product line speed related enterprises, to know the market is changing, that you can not keep up the development progress, the product can not be earlier than the competitors on the line late comeback would like the possibility of Polar, which is directly related to a project can succeed or fail.
After the on-line project, with the increasing volume of users and traffic, the system will usher in a variety of issues. Content business logic problem is not here to discuss, we talk about the main issues when it comes to system availability and high concurrency encountered (such as excessive access due to system failures), these problems make the system architecture is why the latter toward distributed to do to change the direction.
It is assumed that a you are a restaurateur, and then you have great ambition, hungry bothered to use what the United States Merchant Services group, the entire self-determine their own foreign selling food system, would not consider the room link. This contains the most basic user module, dishes module, order module. Here is my own divided several stages of evolution, it may not be accurate or does not apply to every project, but the original aim, the last to be toward the development of a distributed architecture.
The first phase: a typical single stand-alone application architecture
This is the beginning of the general architecture of the system, that is, the entire system and database on the same server. Just started small number of users, the peak may also be complicated by the amount of two or three, even if your business is heavy business system (cpu require more computing resources), a single 4-core 8G server should be able to carry the live . But with the increasing amount of users, the peak concurrency started to grow, the load application system also increases. A look at the server status, CPU / Memory / IO and other system resources are almost exhausted, database applications with two brothers fight to grab resources are full, user feedback often say often going round in circles is not displayed on the app, which makes being cooking you lost in thought ......
Phase II: the application data separation and
To address the problem the first phase, you will be applications and databases are deployed on two servers, respectively known as the application server and database server, so that applications and databases to live their own house will not seize up system resources. We use the most simple way to solve the problem of system performance, and the whole system basically do not do anything changes, you may only need to modify the code in the database connection string to get. As your business is more prosperous, you earn more and more, more and more natural user, but until troubles but again: there are always situations when you can not load the content of user feedback Read dishes, or single failed / no response and the like. This time, was counting the money you start to realize: The application server could not carry .
The third stage: load balancing
Since an application server could not carry, then we take two or three or a lot of units, not bad money. You calculate a lot based on the current amount of data, we decided to add two application servers. Here you start using load balancing technology Niubi Hong Hong, all client requests are load balanced by shunting forward to your application server three, three servers work better than a strong look to enhance the load on the system ability. Of course, here are some other questions, such as how to maintain user access state visit, because you have three application servers, you can ensure that each user is accessing the same server, so you have to solve shared problems session, here not to proceed to say, under tomcat / memcache / redis has a corresponding implementation.
Phase IV: the use of a database and write cache separation
With the increasing amount of users you have added several application servers, but a similar problem but the user feedback before the addition of up, careful thought you looked at the status of each server, database server turned out to be a problem, it would have been before only one application server to find it to read and write data, and now these days, more than a few find it good to read and write, it is busy here. After your analysis found that most requests for the database is basically a read request, and the large amount of duplicate data query, you decide to use caching (such as Redis) to reduce database read requests pressure, which corresponds with the database in the application system the middle one more buffer, high-frequency data to be queried in the cache (cache update policies and persistent Please inform yourself about), you do not always have to read to the database.
With the addition of the cache, you thought, why the database could not carry large part because of problems reading and writing lock system IO bottlenecks and conflicts, you have hands to do a database separate read and write, one master server, N Taiwan is responsible from the server, the primary database server processes write requests, read requests from the database server is responsible for master-slave database synchronization to keep data consistency through the data. A mention here: preference cache cluster using other technologies and middleware (for example, MQ) to enhance the ability of the system corresponding to high concurrent , the database itself will thousands of concurrent carrying capacity, is not suitable as a high concurrent vehicle treated, and the database server (especially write server) more expensive, can not be too prodigal.
Phase V: the vertical and horizontal split split database
Even if your system has been able Kangzhu high concurrent requests, and caching also help you filter once, but some still have to request last fall to this level database, the database will still increasing pressure, such as user registration and meal orders, which are to be written to the database. Here you begin a vertical split database , you put the user table and the Order table were put on two independent database server. Since the database schema changed, before the Lord that also changes from architecture, not go into here.
Your meal outside selling point system has been running, more and more amount of data, such as your order form, single-table data volume almost reached the bottleneck of database tables, this time you decide to horizontal split database , the Orders table split assigned to the plurality of databases (a common horizontal resolution and range resolution program has split the hash, understand your own).
After the database resolution, the ability to improve the system for processing data, the processing can be faster and more applications to send data operation request to reduce the client latency.
Stage 6: Application of Service
As more and more of our users, application system pressure is also growing, and the system function will certainly grow in size to accommodate the diverse needs of users, but the huge system is always complex and difficult to maintain. This time you turn resorted to secret operation: demolition! We ripped out the relevant user as a customer service center, the order-related content ripped out the orders as a service center, this time you begin to spend a distributed application framework (such as Dubbo), as required between the various services communication (such as order service definitely need the user's data), distributed application framework can help you solve this problem. Specifically how to split the business boundaries demarcated according to your specific project. With the application brought by the split application services, database schema can not run away for a vertical split, split out of general application has its own separate database, how to achieve the lowest split here is a coupling according to the actual needs problem situation to decide. If you do not much consider this in our foreign selling food system, the user table is split out a separate independent database belonging to the user of the service.
The actual development project evolve or use of distributed evolution always varied, there is the wrong place to correct me thank you!
