In a cluster architecture, do servers need to perform their own duties? That is, it is divided into database server, memory server, picture server, etc.-PHP Tutorial-php.cn

Project background:
Reading is greater than writing, the ratio is about 4:1, the number of users is more than one million, and the concurrency is about 4,000 (can be high or low, high to 10K, low to 1K)
The performance of several servers is almost the same, and the load balancing can basically be evenly distributed to each server

I want them to directly face users one-to-one through load balancing (that is, ABCD can be directly accessed).

Let them perform their respective duties (assuming A and B are memory servers, C is a database, and D is an image processing server), and let them accept user access layer by layer.

Give me some advice

Reply content:

I want them to directly face users one-to-one through load balancing (that is, ABCD can be directly accessed).

Let them perform their respective duties (assuming A and B are memory servers, C is a database, and D is an image processing server), and let them accept user access layer by layer.

Give me some advice

It’s better to separate.
If they are not separated, it seems that the resources of the machine can be fully utilized, but this is not the case. Different types of services are deployed together, which increases the complexity of the server environment, easily causes problems and is difficult to locate, and is also not conducive to performance optimization.
Different types of services have different demands on resources. Memory servers focus more on memory, while image servers focus on disks. If they are deployed together, if there is a memory bottleneck, it will also have an impact on the image server, resulting in a waste of disk resources.
So it is deployed separately, the environment of each service is simple, and resources can be allocated as needed.

Each performs its own duties, and the concept of distributed clusters includes different parts of a system. The first solution only achieves load balancing, and according to the literal meaning, it seems that each machine will install the corresponding application and database service. In this case, the data synchronization and file synchronization issues will make you miserable, so adopt the classic The functional hardware subcontracting architecture (the second one you mentioned) is a more appropriate method.
Access layer: Responsible for accepting and distributing user needs, installing load balancing services, and configuring the server to prioritize network, memory, and CPU.
Application caching layer: Caching application data according to business and usage frequency. Most of this layer is page caching. Network, IO priority.
Application layer: Responsible for accepting distribution from the access layer, processing requirements, and installing specific project applications. The server is configured to give priority to memory, CPU, and IO. (For a service-oriented system, it may be further subdivided into logical layer, service layer, persistence layer, etc. Please analyze the specific project in detail).
Data caching layer: According to your project background, database indexes can be placed in this layer, and some data dictionary tables can also be placed according to business needs and specific hardware configurations. Hard disk and IO are given priority.
Data layer: Install database service and file storage service. The database service can be configured for read-write separation based on your description. If the amount of data is relatively large, you also need to consider the sub-database settings of the database. Configure hard disk and IO priority.
On top of all the above servers, the servers at each layer should be disaster-tolerant according to the active-standby principle.
Of course, all architectures outside the scope of hardware are empty talk. I don’t know what kind of server you have, but it seems to have similar configurations. Try to modify it as much as possible, and make appropriate modifications according to the needs of each layer. If there are not enough machines, you can consider cutting off virtual machines, but the virtual machines will consume part of the server resources. How to configure the specific configuration to maximize performance depends on stress testing and subsequent tuning.

It is recommended to adopt the second option.

I feel that it is not good to separate. If you are all separated, if any server crashes, your program will crash. The first thing the program must ensure is stability. As for running multiple programs on one server to increase server complexity, it depends on how you do it. As for deployment issues, individual services are actually irrelevant on the server. For troubleshooting, just make good logs. If you have four servers doing distributed balancing, your service expansion and transfer will be relatively easy. You can make them all into a single server. , it does not have the scalability of a distributed system, and if the performance encounters a bottleneck, you must make a major structural change and change it to a distributed system. Overall, I think the first option is much more flexible than the second one

As for the service level reported by the subject, it should be done in a separated manner.

There are two main considerations:

Different types of services have different requirements and consumption of various machine resources, and machines can be customized as needed. Other students upstairs have said this;
Furthermore, deploying different services together, especially services that may have potential impacts, will increase the maintenance cost and instability of the system; as an extreme example, you would consider putting the test environment Should it be deployed together with the production environment? Adjusting the test environment parameters to affect the production environment is really the last thing that should happen.

Furthermore, someone mentioned that deploying in multiple places actually has to deal with multiple problem scenarios. I think this is exactly the opposite

First of all, the business layer cannot always assume that the service layer is safe and stable. It needs to tolerate or even have a circuit breaker mechanism for service layer failures
Secondly, all services are placed on one machine. If a single machine hangs up (for example, if the disk is full and the memory is full and the CPU explodes, etc.), all services will hang. If scattered, it will only cause individual service damage.
There is also an operation and maintenance cost consideration. In the early days, the web server and back-end services may be put together. After the traffic and pressure increase in the later period, we will definitely continue to work in the direction of division of labor and specialization.

The above is mainly my personal understanding, please refer to it~

It is necessary. Of course the servers have to perform their respective duties. The server needs to be deployed in a distributed manner. Expand laterally in the face of traffic pressure. Disaster recovery servers are even needed. If one server goes down, other servers will take over.

The essence of this problem lies in horizontal scalability. If you can only access ABCD through load balancing, you will give up scalability

So I suggest separating ABCD for independent services

Then you have to analyze which part of the system is the bottleneck, and then do load balancing, machine expansion, distribution, etc.

It’s best to separate
Your application is constantly growing
It has reached this stage now
Even if you don’t separate now
You will separate in the future.