比如有5台服务器跑了5个node项目，然后前面使用nginx做负载均衡
比如项目访问量很大，然后增加了一些新的功能，项目需要升级 5台服务器逐个升级，怎么能保证在升级的过程中不会影响访问
例如 现在要升级A服务器上的node项目，但是A服务器上有许多请求 如果直接升级的话，请求可能就会没有响应，如果项目涉及到对数据库操作，可能会产生脏数据
我能想到的一种方案是 事先发公告 没有流量的时候再升级
我想请问还没有其它方案，在不影响用户请求的情况下对服务进行升级呢
认证0级讲师
只是無回應 (我猜是tcp連線中斷) 比較簡單，nginx切換配置時可以graceful restart的，這樣可以撤掉一台後端--升級後端--加回去。
但是"不影響存取" 不只解決這個，你還需要讓舊版的前端和新版的伺服器可以共用。
髒數據是另一個問題了。不應該期待每個請求都正常結束，清理髒資料 (現場或事後) 的機制總歸是應該有的。
當你的伺服器支援平滑重啟，這就比較方便了。平滑重啟可能是你自己實現的，也可能是框架或函式庫提供的。
你這麼想本來就是錯的，除非你5台機器上部署的是不同的項目，那麼升級只能停機，不然還能怎麼辦你說。你這個意思是5台機器上部署同一個項目，那麼升級的時候你考慮怎麼能不影響服務，你的出發點應該在這兒，那這裡就有一個問題，對於一個請求你是怎麼做分發到5台機器上的，你怎麼做的然後就在哪裡調整就是了，在低谷的時候把5台改成4台，然後升級成功之後再加回去，如果擔心升級過程中響應不過來，那麼就調整緩存時間，都5台機器了，不會沒緩存把。 。 。
升級通常都是凌晨升級，因為如果出了什麼問題，都不會影響那麼大
負責均衡下掉一台伺服器，升級，然後再up
完全不影響是不可能，只有盡可能的讓影響看不出來，你觀察一下京東就會發現，它家的伺服器經常凌晨升級，升級的時候你打開它的菜單是刷不出東西來的，就看不停的轉圈，但就是不出內容。所以基本上都是升級的時候把伺服器切換到友善的不出內容介面，升級完再換回來。
逐台升級，升級過程中把流量引導其他伺服器
我們專案是用pm2發布和做進程管理的
發佈的時候不會影響使用者是用
熱部署
灰度發表
只是無回應 (我猜是tcp連線中斷) 比較簡單，nginx切換配置時可以graceful restart的，這樣可以撤掉一台後端--升級後端--加回去。
但是"不影響存取" 不只解決這個，你還需要讓舊版的前端和新版的伺服器可以共用。
髒數據是另一個問題了。不應該期待每個請求都正常結束，清理髒資料 (現場或事後) 的機制總歸是應該有的。
當你的伺服器支援平滑重啟，這就比較方便了。平滑重啟可能是你自己實現的，也可能是框架或函式庫提供的。
你這麼想本來就是錯的，除非你5台機器上部署的是不同的項目，那麼升級只能停機，不然還能怎麼辦你說。你這個意思是5台機器上部署同一個項目，那麼升級的時候你考慮怎麼能不影響服務，你的出發點應該在這兒，那這裡就有一個問題，對於一個請求你是怎麼做分發到5台機器上的，你怎麼做的然後就在哪裡調整就是了，在低谷的時候把5台改成4台，然後升級成功之後再加回去，如果擔心升級過程中響應不過來，那麼就調整緩存時間，都5台機器了，不會沒緩存把。 。 。
升級通常都是凌晨升級，因為如果出了什麼問題，都不會影響那麼大
負責均衡下掉一台伺服器，升級，然後再up
完全不影響是不可能，只有盡可能的讓影響看不出來，你觀察一下京東就會發現，它家的伺服器經常凌晨升級，升級的時候你打開它的菜單是刷不出東西來的，就看不停的轉圈，但就是不出內容。所以基本上都是升級的時候把伺服器切換到友善的不出內容介面，升級完再換回來。
逐台升級，升級過程中把流量引導其他伺服器
我們專案是用pm2發布和做進程管理的
發佈的時候不會影響使用者是用
熱部署
灰度發表