簡(jiǎn)介
今天主要討論一下，對(duì)于分布式服務(wù)，站點(diǎn)如何平滑的上下線問題。
分布式服務(wù)
在分布式服務(wù)下，我們會(huì)用nginx做負(fù)載均衡， 業(yè)務(wù)站點(diǎn)訪問某服務(wù)站點(diǎn)的時(shí)候， 統(tǒng)一走nginx， 然后nginx根據(jù)一定的輪詢策略，將請(qǐng)求路由到后端一臺(tái)指定的服務(wù)器上。
這樣的架構(gòu)是沒有問題的， 但是我們這里考慮幾個(gè)問題，
1. 網(wǎng)站上下線問題：我們網(wǎng)站平時(shí)更新站點(diǎn)的時(shí)候是直接覆蓋文件，然后重啟， 那這樣會(huì)造成一些請(qǐng)求中斷，如果是非核心邏輯那還好， 如果是核心邏輯，那請(qǐng)求中斷，會(huì)影響一些數(shù)據(jù)一致性，比如資金， 交易，訂單等。
2. 動(dòng)態(tài)加減機(jī)器，比如某個(gè)站點(diǎn)訪問量大，要新增機(jī)器，那就需要修改nginx的配置，然后reload， 這樣會(huì)中斷連接。 雖然reload很快，但是還是會(huì)有一瞬間的請(qǐng)求中斷。
對(duì)于第一個(gè)問題，我們可以在請(qǐng)求量少的時(shí)候去更新， 但是這種在一些服務(wù)穩(wěn)定的公司可用， 對(duì)于互聯(lián)網(wǎng)企業(yè)，可能2-3天就一個(gè)版本， 而且需要立刻上線， 如果每次都要等到凌晨4點(diǎn)去更新， 可能整個(gè)的開發(fā)節(jié)奏都被帶慢了。
對(duì)于第二個(gè)問題， 對(duì)于可以預(yù)見的流量，比如大促來臨，可以提前3天放在請(qǐng)求量少的時(shí)候更新。
最近幾年，隨著SOA的普及和微服務(wù)的出現(xiàn)，特別是dubbo的出現(xiàn)，服務(wù)治理的概念被提出來。 服務(wù)治理是一個(gè)很宏大的概念，包括服務(wù)注冊(cè)，服務(wù)自動(dòng)發(fā)現(xiàn)，服務(wù)路由，服務(wù)依賴，集群容錯(cuò)，服務(wù)降級(jí)，服務(wù)監(jiān)測(cè)，服務(wù)審批等，當(dāng)然不是每個(gè)服務(wù)中心都必須實(shí)現(xiàn)這些東西， 公司可以根據(jù)自己的實(shí)際需求來定制實(shí)現(xiàn)。
基于Nginx dyups模塊的動(dòng)態(tài)上下線
基于以上這些情況， 我計(jì)劃實(shí)現(xiàn)一個(gè)工具，這個(gè)工具首先解決站點(diǎn)上下線和動(dòng)態(tài)擴(kuò)容問題，也就是說在不需要重啟nginx的情況下，并且在保證請(qǐng)求不丟失的情況下來更新站點(diǎn)。 同時(shí)帶有部分服務(wù)治理功能。
服務(wù)上線
1. 在一個(gè)新服務(wù)上線的時(shí)候，一般會(huì)提前申請(qǐng)幾臺(tái)機(jī)器， 運(yùn)維會(huì)在nginx上新增server，并新增server對(duì)應(yīng)的upstream ，正常情況下upstream應(yīng)該配置是后端服務(wù)器的IP，但是這里不配置(如果允許，甚至這一步都可以省略)。
2. 服務(wù)部署好并啟動(dòng)，在啟動(dòng)的時(shí)候，向注冊(cè)中心注冊(cè)自身的服務(wù)信息，包括IP和端口。
3. 注冊(cè)中心收到請(qǐng)求后，會(huì)對(duì)服務(wù)進(jìn)行健康檢測(cè)，確保提供的服務(wù)沒有問題，則將服務(wù)狀態(tài)標(biāo)示為預(yù)上線狀態(tài)。
4. 在后臺(tái)管理中心，就可以將
網(wǎng)友評(píng)論
