心跳监测与服务剔除
目錄
- 社保中心的憂桑
- 感受你的心跳
- 心電圖里的信息
- 兩個(gè)核心指標(biāo)
- 服務(wù)剔除
- 支付寶也敵不過挖掘機(jī)一鏟子
- 那么問題來了 - ~~挖掘機(jī)技術(shù)哪家強(qiáng)~~ ?
- 小結(jié)
假如志玲姐姐親了你一口,你卻沒有心動(dòng)的感覺,那么一定是你停止了心跳
社保中心的憂桑
今天社保中心來了一位釘子戶,90多歲的王大爺又興高采烈的來給自己快120歲的老父親領(lǐng)社保了!
工作人員這一想,好像哪里不對(duì)啊,這老父親120歲的年紀(jì)都可以上吉尼斯世界紀(jì)錄了,要不咱幫老爺子去申請(qǐng)一下?王大爺一聽可慌了,連連表示使不得使不得,就來領(lǐng)個(gè)社保而已。但是本著負(fù)責(zé)的態(tài)度,社保中心還是決定實(shí)地走訪一下。
眼看要穿幫,王大爺只好老實(shí)交代,原來王大爺?shù)睦细赣H早就沒了十好幾年,墳頭草都快長(zhǎng)成非洲大草原了,但是在社保中心沒有銷戶,這才造成了這么一個(gè)BUG。
不光社保中心有這個(gè)情況,眼下Eureka的注冊(cè)中心也有同樣的問題,昨天就有幾臺(tái)服務(wù)器中暑了,沒了響應(yīng),很多調(diào)用請(qǐng)求不停報(bào)404,那Eureka有什么行之有效的手段來解決這個(gè)問題呢?
感受你的心跳
心跳不息,生命不止。大道至簡(jiǎn)的SpringCloud就借助這生命的本源,也就是“心跳”,來知曉服務(wù)的可用性。我們來看一下心跳檢測(cè)有哪些特點(diǎn):
我們前面說過Eureka的注冊(cè)中心是一個(gè)運(yùn)籌帷幄的角色,足不出戶辦天下事,所以心跳服務(wù)是由一個(gè)個(gè)服務(wù)節(jié)點(diǎn)根據(jù)配置的時(shí)間主動(dòng)發(fā)起的。
我們說的“心跳”不光要告訴注冊(cè)中心“我還活著”,還要告訴他我活的好不好,是現(xiàn)在快不行了(OUT_OF_SERVICE狀態(tài))還是生龍活虎(UP狀態(tài))
現(xiàn)在輪到注冊(cè)中心做點(diǎn)事情了,對(duì)一段時(shí)間無響應(yīng)的服務(wù),反映到心電圖上就是一根直線跌停板,那便要主動(dòng)從注冊(cè)列表中剔除,以防服務(wù)調(diào)用方請(qǐng)求失敗。
也許大家還不知道,服務(wù)續(xù)約底層也是靠著心跳來實(shí)現(xiàn)的,但包含了一套“臟數(shù)據(jù)”處理流程,老師在服務(wù)續(xù)約章節(jié)會(huì)詳細(xì)講解。
心電圖里的信息
心跳檢測(cè)之于服務(wù)注冊(cè)來說,就像做心電圖檢查之于辦入院手續(xù),入院手續(xù)需要做全方位的檢查,因此要同步數(shù)十個(gè)屬性到注冊(cè)中心,而做一個(gè)心電圖,僅僅需要以下這些信息就夠了
- 訪問地址
也就是Eureka注冊(cè)中心的地址,如http://localhost:20000/eureka/ - 訪問路徑
為了防止注冊(cè)中心把我的心電圖當(dāng)做了別人的,給人治錯(cuò)了病,我還要主動(dòng)告訴注冊(cè)中心我是誰(shuí)。不同于服務(wù)注冊(cè)流程中把個(gè)人信息放到POST請(qǐng)求的body,心跳包把這個(gè)信息放到了訪問的URL中,例如apps/ a p p n a m e / {app_name}/ appn?ame/{instance_id},這里的appname是服務(wù)注冊(cè)時(shí)提供的服務(wù)名,而instance_id則是當(dāng)前這個(gè)服務(wù)節(jié)點(diǎn)的唯一編號(hào),比如9527。 - 服務(wù)狀態(tài)
心跳能反映出一個(gè)人的身體狀況,對(duì)服務(wù)節(jié)點(diǎn)也一樣,一個(gè)節(jié)點(diǎn)的服務(wù)狀態(tài)有以下幾種UP, DOWN, STARTING, OUT_OF_SERVICE, UNKNOWN - 最后一次同步注冊(cè)的時(shí)間
lastDirtyTimeStamp,這是心跳檢測(cè)環(huán)節(jié)最復(fù)雜的一個(gè)知識(shí)點(diǎn),它是當(dāng)前服務(wù)節(jié)點(diǎn)最后一次與服務(wù)中心失去同步時(shí)的時(shí)間,InstanceInfo封裝了該屬性以及另一個(gè)搭檔isInstanceInfoDirty,當(dāng)isInstanceInfoDirty=true的時(shí)候,表示當(dāng)前節(jié)點(diǎn)自從lastDirtyTimeStamp以后的時(shí)間都處于未同步的狀態(tài)。
兩個(gè)核心指標(biāo)
## 客戶端指標(biāo) eureka.instance.lease-renewal-interval-in-seconds=10 eureka.instance.lease-expiration-duration-in-seconds=20這兩個(gè)指標(biāo)都配置在服務(wù)節(jié)點(diǎn)上,分別表示了以下的含義
- 第一個(gè)指標(biāo)決定了每隔多久向服務(wù)器發(fā)送一次心跳包
- 第二個(gè)參數(shù)告訴服務(wù)器,如果我在x秒內(nèi)都沒有心跳,那就代表我掛掉了
通常第一個(gè)時(shí)間一定是小于第二個(gè)時(shí)間的,否則還沒等到發(fā)送第二個(gè)心跳,就被注冊(cè)中心推進(jìn)太平間了。畢竟兩次心跳之間的間隔時(shí)間,還得再多加幾秒的網(wǎng)絡(luò)延遲,才是判斷服務(wù)是否掛掉的最小時(shí)間。
服務(wù)剔除
支付寶也敵不過挖掘機(jī)一鏟子
大家通過一個(gè)案例,思考一下在極端情況下服務(wù)剔除的作用。2015年5月份,因市政施工導(dǎo)致杭州支付寶機(jī)房的光纜被挖斷,隨后全國(guó)部分用戶陸續(xù)出現(xiàn)支付寶無法登陸的情況。支付寶隨后緊急通過技術(shù)手段,將用戶請(qǐng)求切換到其他機(jī)房,這才在近2個(gè)小時(shí)后使受影響用戶逐漸恢復(fù)。
那么問題來了 - 挖掘機(jī)技術(shù)哪家強(qiáng) ?
假設(shè)我們自己的應(yīng)用也碰到了類似情況,當(dāng)一部分服務(wù)因?yàn)榫W(wǎng)絡(luò)問題導(dǎo)致不可用,那么如何在盡可能短的時(shí)間內(nèi),剔除不可用的節(jié)點(diǎn)?
這就要借助Eureka的服務(wù)剔除功能,服務(wù)剔除是心跳檢測(cè)的后手,正是為了讓無心跳響應(yīng)的服務(wù)節(jié)點(diǎn)自動(dòng)下線,讓我們來看一下Eureka的服務(wù)剔除流程
注冊(cè)中心在啟動(dòng)的時(shí)候也會(huì)同步開啟一個(gè)后臺(tái)任務(wù),默認(rèn)每間隔60秒觸發(fā)服務(wù)剔除任務(wù),當(dāng)然我們也可以通過在服務(wù)端```eureka.server.eviction-interval-timer-in-ms=30000``做如下參數(shù)配置修改觸發(fā)間隔,這里將間隔設(shè)置成了30秒。此處建議不要設(shè)置的時(shí)間過短。
不像服務(wù)注冊(cè)的山路十八彎,服務(wù)剔除比較直接了當(dāng),通過AbstractInstanceRegistry的eviction方法直接運(yùn)行。
- 自保開啟 服務(wù)自保是注冊(cè)中心的保命招,后面課程會(huì)詳細(xì)介紹,這里大家只要知道一旦自保開啟,則注冊(cè)中心就會(huì)中斷服務(wù)剔除操作。
- 已被標(biāo)記為過期(evictionTimestamp > 0)
- 最后一次心跳時(shí)間 + 服務(wù)端配置的心跳間隔時(shí)間 < 當(dāng)前時(shí)間
所有服務(wù)是否能被全部剔除呢?當(dāng)然不是,服務(wù)中心也要顧及自身的穩(wěn)定性,因此他設(shè)置了一個(gè)系數(shù)(默認(rèn)0.85),可剔除的服務(wù)數(shù)量,不能大于已注冊(cè)服務(wù)的總數(shù)量乘以這個(gè)系數(shù)。比如當(dāng)前有100個(gè)服務(wù),其中99個(gè)已經(jīng)斷了氣,那么注冊(cè)中心實(shí)際上只能剔除100*0.85 = 85個(gè)服務(wù)節(jié)點(diǎn),而不是99個(gè)。
哦呦,這一招老厲害了,亂序剔除,亂拳打死老師傅。這里你就當(dāng)做是歌單隨機(jī)播放,隨到哪個(gè)過期服務(wù)就把它踢下線。
小結(jié)
本節(jié)帶大家學(xué)習(xí)了關(guān)于心跳檢測(cè)和服務(wù)剔除的知識(shí)
接下來,我們帶大家學(xué)習(xí)另一個(gè)和心跳密切相關(guān)的流程 - 服務(wù)續(xù)約
總結(jié)
- 上一篇: GMT绘图学习记录(2)
- 下一篇: 个人中心功能