看到這個應用上下線方式,不禁感嘆:優雅,太優雅了!
摘要: 本文講述基於Sermant Agent接入的SpringCloud應用實現優雅上下線功能。
什麼是優雅上下線
試想一個A場景,系統中執行著一個消費者(客戶端)和兩個服務提供者(服務端),消費者可負載均衡呼叫服務提供者。假設某個服務提供者因業務更新或其他場景需要滾動升級,若此時存在大量併發流量,便會出現以下問題:
- 大量TCP連線因服務提供者升級下線操作,導致大量請求錯誤。
- 由於消費者(客戶端)存在登錄檔延遲重新整理的問題,後續流量依舊會分配到已經下線的提供者,導致大量請求錯誤。
以上便是一個典型的“不優雅”場景。
於是,為了規避諸如此類的問題,服務優雅上下線應運而生,主要針對服務的重啟、上線、下線等操作提供保護。
服務運維常見問題
- 服務自身存在大量懶載入機制(例如負載均衡初始化),在服務剛上線時,因併發流量請求湧入,導致大量請求同時進行懶載入,以至於請求響應慢,執行緒阻塞,甚至最終導致服務崩潰。
- 服務無法做到優雅下線,就如前面提到的A場景,服務端下線而客戶端服務無法及時感知,導致流量流入已下線的例項,從而丟失大量流量。
優雅上下線提供了什麼樣的能力
服務端預熱能力
服務端預熱是基於客戶端實現的,當流量進入時,Sermant Agent會動態調整流量,根據服務的預熱配置,對流量進行動態分配。對於開啟服務預熱的例項,在剛啟動時,相對於其他已啟動的例項,分配的流量會更少,流量將以曲線方式隨時間推移增加直至與其他例項*乎持*。目的是採用少流量對服務例項進行初始化,防止服務崩潰。
優雅下線能力
優雅下線結合服務端與客戶端實現,主要實現點如下:
- 反註冊

當服務端被要求下線時,Sermant Agent會動態根據當前註冊中心進行反註冊操作,及時重新整理登錄檔,然而即使登錄檔已重新整理,但是上游消費端因快取問題卻無法及時感知,從而引入下線通知。
- 下線通知

進行反註冊後,Sermant Agent會採用介面通知與響應通知的方式告知所有上游,並主動同步重新整理provider例項快取。
- 黑名單

為保證流量不再呼叫已下線例項,引入黑名單機制。在客戶端接收到下線通知後,自動將下線例項拉入黑名單,在執行流量分配時,自動過濾黑名單(已下線)例項,不再呼叫已下線例項。說明:黑名單採用定時重新整理機制,預設為2分鐘,即針對同一個IP例項,標記下線後,等待2分鐘即可重新發現。
- 流量統計
為確保當前請求已全部處理完成,在服務下線時,Sermant Agent會嘗試等待30s(可配置),定時統計和判斷當前例項請求是否均處理完成,處理完成後最終下線。
如何使用優雅上下線能力
虛機場景
容器場景
基於Demo驗證優雅上下線能力
以Nacos demo應用為例,通過Sermant Agent接入CSE,並在CCE叢集上驗證優雅上下線功能,參考 自定義優雅上下線 。
- 記一次批量更新整型型別的列 → 探究 UPDATE 的使用細節
- 編碼中的Adapter,不僅是一種設計模式,更是一種架構理念與解決方案
- 執行緒池底層原理詳解與原始碼分析
- 30分鐘掌握 Webpack
- 線性迴歸大結局(嶺(Ridge)、 Lasso迴歸原理、公式推導),你想要的這裡都有
- Django 之路由層
- 【前端必會】webpack loader 到底是什麼
- day42-反射01
- 中心化決議管理——雲端分析
- HashMap底層原理及jdk1.8原始碼解讀
- 詳解JS中 call 方法的實現
- 列印 Logger 日誌時,需不需要再封裝一下工具類?
- 初識設計模式 - 代理模式
- 設計模式---享元模式
- 密碼學奇妙之旅、01 CFB密文反饋模式、AES標準、Golang程式碼
- [ML從入門到入門] 支援向量機:從SVM的推導過程到SMO的收斂性討論
- 從應用訪問Pod元資料-DownwardApi的應用
- Springboot之 Mybatis 多資料來源實現
- Java 泛型程式設計
- CAS核心思想、底層實現