服務(wù)器運(yùn)維。特別對涉及操作系統(tǒng)的，比如說你在一臺服務(wù)器上是跑還是還是或者是你就得自己看著辦了，因?yàn)檫@些都要跟環(huán)境配合才能用。然后nginx集群幾十萬節(jié)點(diǎn)算是高并發(fā)量的了服務(wù)器運(yùn)維，如果是順利的話nginx會比較吃力，因?yàn)樗泻芏噢D(zhuǎn)發(fā)服務(wù)，而且業(yè)務(wù)流量每天都在翻倍增長。現(xiàn)在云主機(jī)基本上有個(gè)云環(huán)境都能搞定云服務(wù)器的問題了。

云服務(wù)器整體都能夠?qū)崿F(xiàn)很好的性能優(yōu)化、節(jié)點(diǎn)擴(kuò)展等。在之前使用過的redis,集群主要架構(gòu)中，客戶端做為服務(wù)器和內(nèi)容的連接信息，同時(shí)他們對接著多個(gè)節(jié)點(diǎn)。這對redis集群是很友好的。但redis集群如果沒有環(huán)境的話，擴(kuò)展起來是比較麻煩的。主要體現(xiàn)在以下兩點(diǎn)。一是內(nèi)存大小和數(shù)據(jù)庫備份與恢復(fù)兩方面，二是集群安全、私有環(huán)境。

一般只要是個(gè)性化需求，都會考慮使用云服務(wù)器的方式解決。如果是那種兩臺機(jī)器每臺物理服務(wù)器上跑一個(gè)集群的話服務(wù)器運(yùn)維，也要考慮架構(gòu)中可能沒有環(huán)境作為存儲和備份。即使是這樣，在這種架構(gòu)中，由于物理上的缺陷，數(shù)據(jù)庫備份也是一個(gè)比較麻煩的事情。如果是一個(gè)完整的客戶端以及一個(gè)完整的數(shù)據(jù)庫備份，考慮數(shù)據(jù)丟失的問題。

需要充分考慮到集群整體承載力和主服務(wù)器可用性。客戶端無法保證主服務(wù)器的長期可用性。另外主服務(wù)器的負(fù)載均衡問題。由于每個(gè)集群都需要相對獨(dú)立，所以即使采用自動(dòng)化的方式，對于客戶端部署也有一定的要求。需要考慮到集群配置文件和本地配置文件沖突等。同時(shí)集群可以是私有網(wǎng)絡(luò)平臺提供對外服務(wù)，也可以用公有網(wǎng)絡(luò)或公有存儲等提供服務(wù)。

這都需要視當(dāng)前規(guī)模自行評估。畢竟運(yùn)維好一個(gè)集群在目前來說，還是比較難的。當(dāng)然，也需要根據(jù)具體業(yè)務(wù)進(jìn)行評估是否能夠勝任運(yùn)維工作。一般來說，一個(gè)非特殊需求，云主機(jī)配置上考慮較少數(shù)據(jù)庫備份，網(wǎng)絡(luò)更新等，使用應(yīng)該就夠用了。而數(shù)據(jù)庫、緩存等運(yùn)維工作屬于運(yùn)維工作范疇，很難專門占用一個(gè)集群資源。

服務(wù)器運(yùn)維。運(yùn)維比較簡單，但是服務(wù)器一般意味著數(shù)百上千的節(jié)點(diǎn)，帶寬接近十個(gè)g的節(jié)點(diǎn)，負(fù)載均衡集群兩萬節(jié)點(diǎn)，每個(gè)都要單獨(dú)設(shè)置集群配置，還要考慮云服務(wù)商帶寬和硬件維護(hù)情況，面對海量的用戶請求，以及過于繁瑣的設(shè)置和算法，服務(wù)器運(yùn)維還是比較困難的。