目錄

• 社保中心的憂桑
• 感受你的心跳
• 心電圖里的信息
• • 兩個核心指標
• 服務剔除
• • 支付寶也敵不過挖掘機一鏟子
  • 那么問題來了 - ~~挖掘機技術哪家強~~ ?
• 小結

假如志玲姐姐親了你一口，你卻沒有心動的感覺，那么一定是你停止了心跳

社保中心的憂桑

今天社保中心來了一位釘子戶，90多歲的王大爺又興高采烈的來給自己快120歲的老父親領社保了！

工作人員這一想，好像哪里不對啊，這老父親120歲的年紀都可以上吉尼斯世界紀錄了，要不咱幫老爺子去申請一下？王大爺一聽可慌了，連連表示使不得使不得，就來領個社保而已。但是本著負責的態度，社保中心還是決定實地走訪一下。

眼看要穿幫，王大爺只好老實交代，原來王大爺的老父親早就沒了十好幾年，墳頭草都快長成非洲大草原了，但是在社保中心沒有銷戶，這才造成了這么一個BUG。

不光社保中心有這個情況，眼下Eureka的注冊中心也有同樣的問題，昨天就有幾臺服務器中暑了，沒了響應，很多調用請求不停報404，那Eureka有什么行之有效的手段來解決這個問題呢？

感受你的心跳

心跳不息，生命不止。大道至簡的SpringCloud就借助這生命的本源，也就是“心跳”，來知曉服務的可用性。我們來看一下心跳檢測有哪些特點：

客戶端發起
我們前面說過Eureka的注冊中心是一個運籌帷幄的角色，足不出戶辦天下事，所以心跳服務是由一個個服務節點根據配置的時間主動發起的。

同步狀態
我們說的“心跳”不光要告訴注冊中心“我還活著”，還要告訴他我活的好不好，是現在快不行了（OUT_OF_SERVICE狀態）還是生龍活虎（UP狀態）

服務剔除
現在輪到注冊中心做點事情了，對一段時間無響應的服務，反映到心電圖上就是一根直線跌停板，那便要主動從注冊列表中剔除，以防服務調用方請求失敗。

服務續約
也許大家還不知道，服務續約底層也是靠著心跳來實現的，但包含了一套“臟數據”處理流程，老師在服務續約章節會詳細講解。

心電圖里的信息

心跳檢測之于服務注冊來說，就像做心電圖檢查之于辦入院手續，入院手續需要做全方位的檢查，因此要同步數十個屬性到注冊中心，而做一個心電圖，僅僅需要以下這些信息就夠了

• 訪問地址
  也就是Eureka注冊中心的地址，如http://localhost:20000/eureka/
• 訪問路徑
  為了防止注冊中心把我的心電圖當做了別人的，給人治錯了病，我還要主動告訴注冊中心我是誰。不同于服務注冊流程中把個人信息放到POST請求的body，心跳包把這個信息放到了訪問的URL中，例如apps/$ap{p}_{n}ame/${instance_id}，這里的appname是服務注冊時提供的服務名，而instance_id則是當前這個服務節點的唯一編號，比如9527。
• 服務狀態
  心跳能反映出一個人的身體狀況，對服務節點也一樣，一個節點的服務狀態有以下幾種UP, DOWN, STARTING, OUT_OF_SERVICE, UNKNOWN
• 最后一次同步注冊的時間
  lastDirtyTimeStamp，這是心跳檢測環節最復雜的一個知識點，它是當前服務節點最后一次與服務中心失去同步時的時間，InstanceInfo封裝了該屬性以及另一個搭檔isInstanceInfoDirty，當isInstanceInfoDirty=true的時候，表示當前節點自從lastDirtyTimeStamp以后的時間都處于未同步的狀態。

兩個核心指標

## 客戶端指標 eureka.instance.lease-renewal-interval-in-seconds=10 eureka.instance.lease-expiration-duration-in-seconds=20

這兩個指標都配置在服務節點上，分別表示了以下的含義

• 第一個指標決定了每隔多久向服務器發送一次心跳包
• 第二個參數告訴服務器，如果我在x秒內都沒有心跳，那就代表我掛掉了

通常第一個時間一定是小于第二個時間的，否則還沒等到發送第二個心跳，就被注冊中心推進太平間了。畢竟兩次心跳之間的間隔時間，還得再多加幾秒的網絡延遲，才是判斷服務是否掛掉的最小時間。

服務剔除

支付寶也敵不過挖掘機一鏟子

大家通過一個案例，思考一下在極端情況下服務剔除的作用。2015年5月份，因市政施工導致杭州支付寶機房的光纜被挖斷，隨后全國部分用戶陸續出現支付寶無法登陸的情況。支付寶隨后緊急通過技術手段，將用戶請求切換到其他機房，這才在近2個小時后使受影響用戶逐漸恢復。

那么問題來了 - 挖掘機技術哪家強 ?

假設我們自己的應用也碰到了類似情況，當一部分服務因為網絡問題導致不可用，那么如何在盡可能短的時間內，剔除不可用的節點？

這就要借助Eureka的服務剔除功能，服務剔除是心跳檢測的后手，正是為了讓無心跳響應的服務節點自動下線，讓我們來看一下Eureka的服務剔除流程

啟動定時任務
注冊中心在啟動的時候也會同步開啟一個后臺任務，默認每間隔60秒觸發服務剔除任務，當然我們也可以通過在服務端```eureka.server.eviction-interval-timer-in-ms=30000``做如下參數配置修改觸發間隔，這里將間隔設置成了30秒。此處建議不要設置的時間過短。

調用evict
不像服務注冊的山路十八彎，服務剔除比較直接了當，通過AbstractInstanceRegistry的eviction方法直接運行。

• 自保開啟 服務自保是注冊中心的保命招，后面課程會詳細介紹，這里大家只要知道一旦自保開啟，則注冊中心就會中斷服務剔除操作。

遍歷過期服務 接下來注冊中心會遍歷所有服務節點，揪出所有過期服務。如何判斷一個服務是過期服務呢，只要滿足以下兩點中任意一點就可以當做過期

• 已被標記為過期（evictionTimestamp > 0）
• 最后一次心跳時間 + 服務端配置的心跳間隔時間 < 當前時間

計算可剔除的服務總個數
所有服務是否能被全部剔除呢？當然不是，服務中心也要顧及自身的穩定性，因此他設置了一個系數（默認0.85），可剔除的服務數量，不能大于已注冊服務的總數量乘以這個系數。比如當前有100個服務，其中99個已經斷了氣，那么注冊中心實際上只能剔除100*0.85 = 85個服務節點，而不是99個。

亂序剔除服務
哦呦，這一招老厲害了，亂序剔除，亂拳打死老師傅。這里你就當做是歌單隨機播放，隨到哪個過期服務就把它踢下線。

小結

本節帶大家學習了關于心跳檢測和服務剔除的知識

心跳檢測的作用，心跳包含的內容以及控制參數

注冊中心服務剔除操作的核心流程

接下來，我們帶大家學習另一個和心跳密切相關的流程 - 服務續約

總結

以上是生活随笔為你收集整理的心跳监测与服务剔除的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。