It’s just unresponsive (I guess the tcp connection is interrupted). It’s relatively simple. You can gracefully restart nginx when switching configurations. In this way, you can remove a backend-upgrade the backend-and add it back.
But "without affecting access" not only needs to solve this, you also need to make the old version of the front end and the new version of the server shareable.
Dirty data is another problem. You should not expect every request to end normally, and there should always be a mechanism to clean up dirty data (on-site or afterward).
This is more convenient when your server supports smooth restart. Smooth restart may be implemented by yourself, or it may be provided by a framework or library.
You are wrong to think so. Unless you deploy different projects on 5 machines, then the upgrade can only cause downtime. Otherwise, what else can you do? What you mean is to deploy the same project on 5 machines. Then when upgrading, you consider how to not affect the service. Your starting point should be here. Then there is a question here. How do you distribute a request to 5 machines? On the machine, just adjust it according to how you did it. At the low point, change the 5 machines to 4 machines, and then add them back after the upgrade is successful. If you are worried about not being able to respond during the upgrade process, then adjust the cache time. , there are 5 machines, there will be no cache. . .
It is impossible not to have any impact at all. The only way is to make the impact as invisible as possible. If you observe JD.com, you will find that its servers are often upgraded early in the morning. When upgrading, you cannot open its menu and nothing will appear. I kept watching and spinning around, but the content just didn’t come out. So basically when upgrading, the server is switched to a friendly interface that does not display content, and then switched back after the upgrade.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
It’s just unresponsive (I guess the tcp connection is interrupted). It’s relatively simple. You can gracefully restart nginx when switching configurations. In this way, you can remove a backend-upgrade the backend-and add it back.
But "without affecting access" not only needs to solve this, you also need to make the old version of the front end and the new version of the server shareable.
Dirty data is another problem. You should not expect every request to end normally, and there should always be a mechanism to clean up dirty data (on-site or afterward).
This is more convenient when your server supports smooth restart. Smooth restart may be implemented by yourself, or it may be provided by a framework or library.
You are wrong to think so. Unless you deploy different projects on 5 machines, then the upgrade can only cause downtime. Otherwise, what else can you do? What you mean is to deploy the same project on 5 machines. Then when upgrading, you consider how to not affect the service. Your starting point should be here. Then there is a question here. How do you distribute a request to 5 machines? On the machine, just adjust it according to how you did it. At the low point, change the 5 machines to 4 machines, and then add them back after the upgrade is successful. If you are worried about not being able to respond during the upgrade process, then adjust the cache time. , there are 5 machines, there will be no cache. . .
Upgrades are usually done early in the morning, because if something goes wrong, it won’t have such a big impact
Responsible for balancing and downgrading a server, upgrading it, and then upping it again
It is impossible not to have any impact at all. The only way is to make the impact as invisible as possible. If you observe JD.com, you will find that its servers are often upgraded early in the morning. When upgrading, you cannot open its menu and nothing will appear. I kept watching and spinning around, but the content just didn’t come out. So basically when upgrading, the server is switched to a friendly interface that does not display content, and then switched back after the upgrade.
Upgrade one server at a time, directing traffic to other servers during the upgrade process
Our project uses pm2 for release and process management
Publishing will not affect users’ usage
Hot deployment
Grayscale release