Expandable type of system

Highly scalable design

Split , Break down the complex system into independent 、 A single responsibility module .
Pay attention to different types of modules , The principle of splitting is different . If you design a know , How many modules will there be ？ At least 5 A module .
user ： Responsible for maintaining community user information , register , Landing, etc ;
Relationship ： Attention between users 、 Good friends 、 Maintenance of relations such as La Hei ;
Content ： Content sent by the community , Just like the content of circle of friends or microblog ;
Comment on 、 Fabulous ： There are two general interactions that users may have ;
Search for ： User search , Content search .

The deployment method follows the simplest three-tier deployment architecture

Load balancing is responsible for the distribution of requests
The application server is responsible for the processing of business logic
The database is responsible for data storage
The business code of all modules is mixed , There is also a database for all data .

Scalability of the storage layer

Whether it's the amount of data stored , Or concurrent traffic , The magnitude of different business modules varies greatly .
For example, Zhihu , The amount of relational data is much larger than the amount of user data , However, the access volume of user data is much larger than that of relational data . So if the current bottleneck of storage is capacity , You only need to split the data of the relationship module , Without splitting the user module data . Therefore, the first consideration of storage splitting is the business dimension .

After break up , This simple community system has a user library 、 Content library 、 Comment Library 、 The library of praise and the library of relations . This also isolates faults , If a library hangs, it will not affect other DB.

Press DB Deployment architecture after business split

Business splitting improves the system scalability to a certain extent , But after a long run , Single business DB The capacity and concurrent requests will still exceed the single machine limit . Need for DB Make a second split .

This split is done horizontally according to the data characteristics , For example, add two nodes to the user library , Then split the user data into libraries .

After horizontal split , You can break through the single machine limit . Nodes cannot be added randomly , Because once you add nodes, you need to migrate data manually . Therefore, in the long run, it is best to add enough nodes at one time , Avoid frequent expansion .

When DB Split by business and data dimensions , Try not to use transactions . Because when a transaction updates different at the same time DB, A two-stage submission is required , To coordinate all DB Or all updates are successful , Or all updates fail .

Business layer scalability

Generally, the splitting scheme of the business layer is considered from three dimensions

Business latitude
Importance latitude
Request source latitude
First, you need to split the same business services into separate business pools , For example , It can be split into user pools according to business dimensions 、 Content pool 、 Relationship pool 、 Comment pool 、 Like pool and search pool .

Each business depends on its own DB resources , Will not rely on other businesses . In this way, when a business interface becomes a bottleneck , Just expand the business pool , And identify upstream and downstream dependent parties , Greatly reduce the expansion complexity .
According to the importance of business interface , Divide the business into core pool and non core pool . For example, relationship pool ：

Focus on 、 It's relatively important to ignore the interface , Can be placed in the core pool
The operations of black pulling and canceling black pulling are relatively less important , It can be placed in the non core pool
This gives priority to core pool performance , When the overall flow increases, priority is given to expanding the core pool , Demote some non core pool interfaces , So as to ensure the stability of the whole system .

Diagram of relationship pool splitting

You can also split the service pool according to the type of access client . For example, serve

The service of the client interface can be defined as the external network pool
A small program or HTML5 The business of the page can be defined as H5 pool
The business of other internal departments can be defined as intranet pool .

summary

The system that has not been split is not scalable , But simple , No matter what development 、 Operation and maintenance don't need much energy . After break up , Requirements development needs to span multiple systems and teams , Troubleshooting also involves multiple systems , Each subsystem of operation and maintenance shall be in the charge of a specially assigned person , Therefore, the recruitment of large factories also requires strong communication and cooperation ability .

Expansibility analysis of collection subsystem ：
1. Split the main table into four sub tables corresponding to the dimension according to the business dimension

advantage ：
This also isolates faults , If a library hangs, it will not affect other DB.
shortcoming ：
Large amount of code changes