今天主要討論一下，對(duì)于分布式服務(wù)，站點(diǎn)如何平滑的上下線問(wèn)題。
在分布式服務(wù)下，我們會(huì)用nginx做負(fù)載均衡， 業(yè)務(wù)站點(diǎn)訪問(wèn)某服務(wù)站點(diǎn)的時(shí)候， 統(tǒng)一走nginx， 然后nginx根據(jù)一定的輪詢策略，將請(qǐng)求路由到后端一臺(tái)指定的服務(wù)器上。
這樣的架構(gòu)是沒(méi)有問(wèn)題的， 但是我們這里考慮幾個(gè)問(wèn)題，
1. 網(wǎng)站上下線問(wèn)題：我們網(wǎng)站平時(shí)更新站點(diǎn)的時(shí)候是直接覆蓋文件，然后重啟， 那這樣會(huì)造成一些請(qǐng)求中斷，如果是非核心邏輯那還好， 如果是核心邏輯，那請(qǐng)求中斷，會(huì)影響一些數(shù)據(jù)一致性，比如資金， 交易，訂單等。
2. 動(dòng)態(tài)加減機(jī)器，比如某個(gè)站點(diǎn)訪問(wèn)量大，要新增機(jī)器，那就需要修改nginx的配置，然后reload， 這樣會(huì)中斷連接。 雖然reload很快，但是還是會(huì)有一瞬間的請(qǐng)求中斷。
對(duì)于第一個(gè)問(wèn)題，我們可以在請(qǐng)求量少的時(shí)候去更新， 但是這種在一些服務(wù)穩(wěn)定的公司可用， 對(duì)于互聯(lián)網(wǎng)企業(yè)，可能2-3天就一個(gè)版本， 而且需要立刻上線， 如果每次都要等到凌晨4點(diǎn)去更新， 可能整個(gè)的開(kāi)發(fā)節(jié)奏都被帶慢了。
對(duì)于第二個(gè)問(wèn)題， 對(duì)于可以預(yù)見(jiàn)的流量，比如大促來(lái)臨，可以提前3天放在請(qǐng)求量少的時(shí)候更新。
最近幾年，隨著SOA的普及和微服務(wù)的出現(xiàn)，特別是dubbo的出現(xiàn)，服務(wù)治理的概念被提出來(lái)。 服務(wù)治理是一個(gè)很宏大的概念，包括服務(wù)注冊(cè)，服務(wù)自動(dòng)發(fā)現(xiàn)，服務(wù)路由，服務(wù)依賴，集群容錯(cuò)，服務(wù)降級(jí)，服務(wù)監(jiān)測(cè)，服務(wù)審批
