問題描述

比如有5臺(tái)服務(wù)器跑了5個(gè)node項(xiàng)目，然后前面使用nginx做負(fù)載均衡

比如項(xiàng)目訪問量很大，然后增加了一些新的功能，項(xiàng)目需要升級(jí) 5臺(tái)服務(wù)器逐個(gè)升級(jí)，怎么能保證在升級(jí)的過程中不會(huì)影響訪問

例如 現(xiàn)在要升級(jí)A服務(wù)器上的node項(xiàng)目，但是A服務(wù)器上有許多請(qǐng)求 如果直接升級(jí)的話，請(qǐng)求可能就會(huì)沒有響應(yīng)，如果項(xiàng)目涉及到對(duì)數(shù)據(jù)庫(kù)操作，可能會(huì)產(chǎn)生臟數(shù)據(jù)

我能想到的一種方案是 事先發(fā)公告 沒有流量的時(shí)候再升級(jí)

我想請(qǐng)問還沒有其它方案，在不影響用戶請(qǐng)求的情況下對(duì)服務(wù)進(jìn)行升級(jí)呢

問題解答

只是無響應(yīng) (我猜是tcp連接中斷) 比較簡(jiǎn)單，nginx切換配置時(shí)可以graceful restart的，這樣可以撤掉一臺(tái)后端--升級(jí)后端--加回去。

但是'不影響訪問' 不止要解決這個(gè)，你還需要讓舊版本的前端和新版本的服務(wù)器可以共用。

臟數(shù)據(jù)是另一個(gè)問題了。不應(yīng)該期待每個(gè)請(qǐng)求都正常結(jié)束，清理臟數(shù)據(jù) (現(xiàn)場(chǎng)或事后) 的機(jī)制總歸是應(yīng)該有的。

當(dāng)你的服務(wù)器支持平滑重啟，這就比較方便了。平滑重啟可能是你自己實(shí)現(xiàn)的，也可能是框架或者庫(kù)提供的。

你這么想本來就是錯(cuò)的，除非你5臺(tái)機(jī)器上部署的是不同的項(xiàng)目，那么升級(jí)只能停機(jī)，不然還能怎么辦你說。你這個(gè)意思是5臺(tái)機(jī)器上部署同一個(gè)項(xiàng)目，那么升級(jí)的時(shí)候你考慮怎么能不影響服務(wù)，你的出發(fā)點(diǎn)應(yīng)該在這兒，那這里就有一個(gè)問題，對(duì)于一個(gè)請(qǐng)求你是怎么做分發(fā)到5臺(tái)機(jī)器上的，你怎么做的然后就在哪里調(diào)整就是了，在低谷的時(shí)候把5臺(tái)改成4臺(tái)，然后升級(jí)成功之后再加回去，如果擔(dān)心升級(jí)過程中響應(yīng)不過來，那么就調(diào)整緩存時(shí)間，都5臺(tái)機(jī)器了，不會(huì)沒緩存把。。。

升級(jí)一般都是凌晨升級(jí)，因?yàn)槿绻隽耸裁磫栴}，都不會(huì)影響那么大

負(fù)責(zé)均衡下掉一臺(tái)服務(wù)器，升級(jí)，然后再up

完全不影響是不可能，只有盡可能的讓影響看不出來，你觀察一下京東就會(huì)發(fā)現(xiàn)，它家的服務(wù)器經(jīng)常凌晨升級(jí)，升級(jí)的時(shí)候你打開它的菜單是刷不出東西來的，就看不停的轉(zhuǎn)圈，但是就是不出內(nèi)容。所以基本都是升級(jí)的時(shí)候把服務(wù)器切換到友好的不出內(nèi)容界面，升級(jí)完再換回來。

逐臺(tái)升級(jí)，升級(jí)過程中把流量引導(dǎo)其他服務(wù)器

我們項(xiàng)目是用pm2發(fā)布和做進(jìn)程管理的

發(fā)布的時(shí)候不會(huì)影響用戶是用

熱部署

灰度發(fā)布