目錄

前言

正文

統計數據/屬性

成員方法

狀態/指標信息使用場景舉例

默認值不合理

代碼示例

總結

---

前言

我們知道Ribbon它是一個客戶端負載均衡器，因此它內部維護著一個服務器列表ServerList，當實例出現問題時候，需要將這部分異常的服務Server從負載均衡列表中T除掉，那么Ribbon是以什么作為參考，決定T除/不T除Server的呢？？？這就是本文將要講述的服務器狀態的管理：ServerStats。

負載均衡LB需要依賴這些統計信息做為判斷的策略，負載均衡器的統計類主要是LoadBalancerStats，其內部持有ServerStats對每個Server的運行情況做了相關統計如：平均響應時間、累計失敗數、熔斷（時間）控制等。

---

正文

Stat中文釋義：統計，Statistic單詞的簡寫形式。另外，希望讀者在閱讀本文之前，已經了解了netflix-statistics的知識，你可以參考這篇文章：[享學Netflix] 四十四、netflix-statistics詳解，手把手教你寫個超簡版監控系統

服務狀態。在LoadBalancer中捕獲每個服務器(節點)的各種狀態，每個Server就對應著一個ServerStats實例。ServerStats表示一臺Server的狀態，各種緯度的統計數據才能使得你最終挑選出一個最適合的Server供以使用，以及計算其當前訪問壓力（并發數）、成功數、失敗數、是否熔斷、熔斷了多久等等。

---

統計數據/屬性

到底統計了哪些數據呢？對Server進行多維度的數據統計，均體現在它的成員屬性上：

public class ServerStats {private final CachedDynamicIntProperty connectionFailureThreshold;private final CachedDynamicIntProperty circuitTrippedTimeoutFactor;private final CachedDynamicIntProperty maxCircuitTrippedTimeout;private static final DynamicIntProperty activeRequestsCountTimeout = DynamicPropertyFactory.getInstance().getIntProperty("niws.loadbalancer.serverStats.activeRequestsCount.effectiveWindowSeconds", 60 * 10);long failureCountSlidingWindowInterval = 1000; private MeasuredRate serverFailureCounts = new MeasuredRate(failureCountSlidingWindowInterval);private MeasuredRate requestCountInWindow = new MeasuredRate(300000L);Server server;AtomicLong totalRequests = new AtomicLong();AtomicInteger successiveConnectionFailureCount = new AtomicInteger(0);AtomicInteger activeRequestsCount = new AtomicInteger(0);AtomicInteger openConnectionsCount = new AtomicInteger(0);private volatile long lastConnectionFailedTimestamp;private volatile long lastActiveRequestsCountChangeTimestamp;private AtomicLong totalCircuitBreakerBlackOutPeriod = new AtomicLong(0);private volatile long lastAccessedTimestamp;private volatile long firstConnectionTimestamp = 0; }

對這些統計數據/屬性分別做如下解釋說明：

• connectionFailureThreshold：連接失敗閾值，默認值3（超過就熔斷）
  • 默認值配置：niws.loadbalancer.default.connectionFailureCountThreshold此key指定
  • 個性化配置："niws.loadbalancer." + name + ".connectionFailureCountThreshold"
• circuitTrippedTimeoutFactor：斷路器超時因子，默認值10s。
  • 默認值配置： niws.loadbalancer.default.circuitTripTimeoutFactorSeconds
  • 個性化配置："niws.loadbalancer." + name + ".circuitTripTimeoutFactorSeconds"
• maxCircuitTrippedTimeout：斷路器最大超時秒數（默認使用超時因子計算出來），默認值是30s。
  • 默認值配置：niws.loadbalancer.default.circuitTripMaxTimeoutSeconds
  • 個性化配置："niws.loadbalancer." + name + ".circuitTripMaxTimeoutSeconds"
• ?
• totalRequests：總請求數量。每次請求結束/錯誤時就會+1。
• successiveConnectionFailureCount：連續（successive）請求異常數量（這個連續發生在Retry重試期間）。
  • 在重試期間，但凡有一次成功了，就會把此參數置為0（失敗的話此參數就一直加）
  • 說明：只有在異常類型是callErrorHandler.isCircuitTrippingException(e)的時候，才會算作失敗，才會+1
    • 默認情況下只有SocketException/SocketTimeoutException這兩種異常才算失敗哦~
• activeRequestsCount：活躍請求數量（正在請求的數量，它能反應該Server的負載、壓力）。
  • 但凡只要開始執行Sever了，就+1
  • 但凡只要請求完成了/出錯了，就-1
  • 注意：它有時間窗口的概念，后面講具體邏輯
• openConnectionsCount：暫無任何使用處，可忽略。
• ?
• lastConnectionFailedTimestamp：最后一次失敗的時間戳。至于什么叫失敗，參考successiveConnectionFailureCount對失敗的判斷邏輯
• lastActiveRequestsCountChangeTimestamp：簡單的說就是activeRequestsCount的值最后變化的時間戳
• totalCircuitBreakerBlackOutPeriod：斷路器斷電總時長（連續失敗>=3次，增加20~30秒。具體增加多少秒，后面有計算邏輯）。
• lastAccessedTimestamp：最后訪問時間戳。和lastActiveRequestsCountChangeTimestamp的區別是，它增/減都update一下，而lastAccessedTimestamp只有在增的時候才會update一下。
• firstConnectionTimestamp：首次連接時間戳，只會記錄首次請求進來時的時間。
• ?
• failureCountSlidingWindowInterval：失敗次數統計時間窗。默認值1000ms
• serverFailureCounts：上一秒失敗次數（上一秒是因為failureCountSlidingWindowInterval默認自是1000ms）
  • successiveConnectionFailureCount增它就增，只不過它有時間窗口(1s)
• requestCountInWindow：一個窗口期內的請求總數，窗口期默認為5分鐘（300秒）
  • activeRequestsCount增它就增，只不過它有時間窗口(300s)

當然，它還有幾個基于netflix-statistics數據統計的指標屬性：

ServerStats：// 默認60s（1分鐘）publish一次數據private static final int DEFAULT_PUBLISH_INTERVAL = 60 * 1000; // = 1 minute// 緩沖區大小。這個默認大小可謂非常大呀，就算你QPS是1000，也能抗1分鐘private static final int DEFAULT_BUFFER_SIZE = 60 * 1000; // = 1000 requests/sec for 1 minuteint bufferSize = DEFAULT_BUFFER_SIZE;int publishInterval = DEFAULT_PUBLISH_INTERVAL;private static final double[] PERCENTS = makePercentValues();private DataDistribution dataDist = new DataDistribution(1, PERCENTS);private DataPublisher publisher = null;private final Distribution responseTimeDist = new Distribution();

• PERCENTS：百分比，可參見枚舉類Percent：[10,20…,90…,99.5]
• dataDist：它是一個DataAccumulator，數據累加器。
• publisher：定時publish發布數據，默認1分鐘發布一次
• responseTimeDist：它是個Distribution類型，因為它僅僅只需要持續累加數據，然后提供最大最小值、平均值的訪問而已

dataDist和responseTimeDist統一通過noteResponseTime(double msecs)來記錄每個請求的響應時間，dataDist按照時間窗口統計，responseTimeDist一直累加。

---

成員方法

已經知道了每個字段的含義，再來看其提供的方法，就輕松很多了。

ServerStats：// 默認構造器：connectionFailureThreshold等參數均使用默認值 該構造器默認無人調用public ServerStats() { ... }// 參數值來自于lbStats，可以和ClientName掛上鉤// 它在LoadBalancerStats#createServerStats()方法里被唯一調用public ServerStats(LoadBalancerStats lbStats) { ... }// 初始化對象，開始數據收集和報告。**請務必調用此方法** 它才是一個完整的實例public void initialize(Server server) {serverFailureCounts = new MeasuredRate(failureCountSlidingWindowInterval);requestCountInWindow = new MeasuredRate(300000L);if (publisher == null) {dataDist = new DataDistribution(getBufferSize(), PERCENTS);publisher = new DataPublisher(dataDist, getPublishIntervalMillis());// 啟動任務：開始發布數據。1分鐘發布一次publisher.start();}// 和Server關聯this.server = server;}// 停止數據方法public void close() {if (publisher != null)publisher.stop();}// 收集每一次請求的響應時間public void noteResponseTime(double msecs){dataDist.noteValue(msecs);responseTimeDist.noteValue(msecs);}// 獲得當前時間的活躍請求數（也就是Server的當前負載）public int getActiveRequestsCount() {return getActiveRequestsCount(System.currentTimeMillis());}// 強調：如果當前時間currentTime距離上一次請求進來已經超過了時間窗口60s，那就返回0// 簡單一句話：如果上次請求距今1分鐘了，那就一個請求都不算（強制歸零）public int getActiveRequestsCount(long currentTime) {int count = activeRequestsCount.get();if (count == 0) {return 0;} else if (currentTime - lastActiveRequestsCountChangeTimestamp > activeRequestsCountTimeout.get() * 1000 || count < 0) {activeRequestsCount.set(0);return 0; } else {return count;}}

這些是ServerStats提供的基本方法，能訪問到所有的成員屬性。下面介紹分別介紹兩個主題方法：

---

CircuitBreaker斷路器的原理

本處的斷路器解釋：當有某個服務存在多個實例時，在請求的過程中，負載均衡器會統計每次請求的情況（請求響應時間，是否發生網絡異常等），當出現了請求出現累計重試時，負載均衡器會標識當前服務實例，設置當前服務實例的斷路的時間區間，在此區間內，當請求過來時，負載均衡器會將此服務實例從可用服務實例列表中暫時剔除（其實就是暫時忽略此Server），優先選擇其他服務實例。

該斷路器和Hystrix無任何關系，無任何關系，無任何關系。它是ServerStats內部維護的一套熔斷機制，體現在如下方法上：

ServerStats：// 看看該斷路器到哪個時間點戒指（關閉）的時刻時間戳// 比如斷路器要從0點開30s，那么返回值就是00:00:30s這個時間戳唄private long getCircuitBreakerTimeout() {long blackOutPeriod = getCircuitBreakerBlackoutPeriod();if (blackOutPeriod <= 0) {return 0;}return lastConnectionFailedTimestamp + blackOutPeriod;}// 返回需要中斷的持續時間（毫秒值）private long getCircuitBreakerBlackoutPeriod() {int failureCount = successiveConnectionFailureCount.get();int threshold = connectionFailureThreshold.get();if (failureCount < threshold) {return 0;}int diff = (failureCount - threshold) > 16 ? 16 : (failureCount - threshold);int blackOutSeconds = (1 << diff) * circuitTrippedTimeoutFactor.get();if (blackOutSeconds > maxCircuitTrippedTimeout.get()) {blackOutSeconds = maxCircuitTrippedTimeout.get();}return blackOutSeconds * 1000L;}

目前斷路器統計失敗是靠連續失敗次數去判斷斷路邏輯的。此方法邏輯可總結如下：

若連續失敗次數還小于閾值（默認3次），那么就不用斷路。否則打開斷路，執行計算要斷開多久的邏輯

計算失敗基數，最大不能超過16（就算你連續失敗100次，此基數也是16）

根據超時因子circuitTrippedTimeoutFactor（默認是10）計算出時間值blackOutSeconds，該值不能大于上限connectionFailureCircuitTimeout（默認30s）

也就是說保證了斷路器最長不能打開超過30s

此方法不僅判斷了斷路器的打開與否，若打開順便打開斷路器應該打開多長時間（單位s）的方法，有了這個方法的理論做支撐，判斷當前斷路器是否開啟就非常簡單了：

ServerStats：public boolean isCircuitBreakerTripped() {return isCircuitBreakerTripped(System.currentTimeMillis());}public boolean isCircuitBreakerTripped(long currentTime) {long circuitBreakerTimeout = getCircuitBreakerTimeout();if (circuitBreakerTimeout <= 0) {return false;}return circuitBreakerTimeout > currentTime;}

當觸發了熔斷器（連續失敗次數過多），斷路器開啟的時間范圍是：

• 最大值：1<<16 * 10 = 320s
• 最小值：1<<1 * 10 =100s

當然這值是根據配置走的，并且還有最大時間30s的限制哦~

在Server被熔斷期間，負載均衡器都將忽略此Server。

---

斷路器如何閉合？

倘若斷路器打開了，它如何恢復呢？有如下3種情形它會恢復到正常狀態：

不是連續失敗了，也就是成功了一次，那么successiveConnectionFailureCount就會立馬歸0，所以熔斷器就閉合了

即使請求失敗了，但是并非是斷路器類異常，即不是RetryHandler#isCircuitTrippingException這種類型的異常時（比如RuntimeException就不是這種類型的異常），那就也不算連續失敗，所以也就閉合了

到時間了，斷路器自然就自動閉合了

---

該斷路器和Hystrix的斷路器有何區別？

很明顯，該斷路器規則非常簡單，開啟與否完全由連續失敗來決定，而是否算失敗由RetryHandler#isCircuitTrippingException來決定，默認它只認為SocketException/SocketTimeoutException（或者其子類異常）屬于該種類型的異常哦~

所以：你的程序在執行時的任何業務異常（如NPE）和此斷路器沒有半毛錢關系。

當然它們最大最大的區別是斷的對象不一樣：

• 本斷路器斷的是Server，也就是遠程服務器
• Hystrix斷路器斷的是Client，也就是客戶端的調用

當然，關于Hystrix斷路器的內容詳解請參考：[享學Netflix] 二十七、Hystrix何為斷路器的半開狀態？HystrixCircuitBreaker詳解

---

獲取響應時間邏輯

一個Server服務器的響應是最重要的衡量指標，因此它提供了大量的獲取響應時間的方法：

ServerStats：// 重要。獲取累計的，累計的，平均響應時間// responseTimeDist里獲得的均是所有請求累計的public double getResponseTimeAvg() {return responseTimeDist.getMean();}public double getResponseTimeMax() {return responseTimeDist.getMaximum();}...// 樣本大小（每次獲取的值可能不一樣的哦，因為dataDist是時間窗口嘛）public int getResponseTimePercentileNumValues() {return dataDist.getSampleSize();}// 這段時間窗口內（1分鐘）的平均響應時間public double getResponseTimeAvgRecent() {return dataDist.getMean();}// ========下面是各個分位數的值======public double getResponseTime10thPercentile() {return getResponseTimePercentile(Percent.TEN);}...public double getResponseTime99point5thPercentile() {return getResponseTimePercentile(Percent.NINETY_NINE_POINT_FIVE);}

---

狀態/指標信息使用場景舉例

統計信息都是非常有用的，這里先簡單介紹，過個眼癮即可。它的使用均在負載均衡策略上，舉例：

• WeightedResponseTimeRule：使用指標ServerStats.responseTimeDist，獲取該Server的平均響應時間來決策
• AvailabilityFilteringRule：它用到了兩個指標信息
  • 通過ServerStats.isCircuitBreakerTripped()判斷當前斷路器是否打開作為該Server是否可用的判斷
  • ServerStats.activeRequestsCount找個活躍請求數最小的Server
• ZoneAvoidanceRule：使用到了ServerStats.upServerListZoneMap和LoadBalancerStats.getZoneSnapshot
• …

---

默認值不合理

private static final int DEFAULT_PUBLISH_INTERVAL = 60 * 1000; private static final int DEFAULT_BUFFER_SIZE = 60 * 1000;

這兩個默認值決定了樣本量，以及樣本時間窗口。按這么設置：每收集一次持續1分鐘（問題不大），但是樣本大小是60 * 1000這個太高了：單臺機器QPS1000持續1分鐘才能填滿此窗口，我相信絕大部分情況下都是這么高的QPS的，所以此默認值并不合理。

但是，但是，但是：ServerStats的唯一創建地方是LoadBalancerStats里：

protected ServerStats createServerStats(Server server) {ServerStats ss = new ServerStats(this);//configure custom settingsss.setBufferSize(1000);ss.setPublishInterval(1000); ss.initialize(server);return ss; }

兩個值均為1000，說明：每秒鐘收集一次（這個頻率太高了吧），然后樣本1000表示這1s內要有1000的請求打進來能打滿（QPS1000，也特高了）。所以實際上的默認值真的也很不合理，它們均只適合高并發場景。。。

坑爹的是，這兩個值并沒有提供鉤子or外部化配置讓我們可以隨意更改，唯一的鉤子是它是個protected方法，你只能通過繼承 + 復寫才行，而實際上我們很小概率回去復寫它（它在BaseLoadBalancer里創建）。

說明：若你想更好的監控，使得負載均衡效果更好點，那么作為架構師的你可以考慮定制定制哦~

---

代碼示例

@Test public void fun4() throws InterruptedException {ServerStats serverStats = new ServerStats();// 緩沖區大小最大1000。 若QPS是200，5s能裝滿它 這個QPS已經很高了serverStats.setBufferSize(1000);// 5秒收集一次數據serverStats.setPublishInterval(5000);// 請務必調用此初始化方法serverStats.initialize(new Server("YourBatman", 80));// 多個線程持續不斷的發送請求request(serverStats);// 監控ServerStats狀態monitor(serverStats);// hold主線程TimeUnit.SECONDS.sleep(10000); }// 單獨線程模擬刷頁面，獲取監控到的數據 private void monitor(ServerStats serverStats) {new Thread(() -> {ScheduledExecutorService executorService = Executors.newScheduledThreadPool(1);executorService.scheduleWithFixedDelay(() -> {System.out.println("=======時間：" + serverStats.getResponseTimePercentileTime() + "，統計值如下=======");System.out.println("請求總數(持續累計)：" + serverStats.getTotalRequestsCount());System.out.println("平均響應時間：" + serverStats.getResponseTimeAvg());System.out.println("最小響應時間：" + serverStats.getResponseTimeMin());System.out.println("最大響應時間：" + serverStats.getResponseTimeMax());System.out.println("樣本大小(取樣本)：" + serverStats.getResponseTimePercentileNumValues());System.out.println("樣本下的平均響應時間：" + serverStats.getResponseTimeAvgRecent());System.out.println("樣本下的響應時間中位數：" + serverStats.getResponseTime50thPercentile());System.out.println("樣本下的響應時間90分位數：" + serverStats.getResponseTime90thPercentile());}, 5, 5, TimeUnit.SECONDS);}).start(); }// 模擬請求（開啟5個線程，每個線程都持續不斷的請求） private void request(ServerStats serverStats) {for (int i = 0; i < 5; i++) {new Thread(() -> {while (true) {// 請求之前 記錄活躍請求數serverStats.incrementActiveRequestsCount();serverStats.incrementNumRequests();long rt = doSomething();// 請求結束， 記錄響應耗時serverStats.noteResponseTime(rt);serverStats.decrementActiveRequestsCount();}}).start();} }// 模擬請求耗時，返回耗時時間 private long doSomething() {try {int rt = randomValue(10, 200);TimeUnit.MILLISECONDS.sleep(rt);return rt;} catch (InterruptedException e) {e.printStackTrace();return 0L;} }// 本地使用隨機數模擬數據收集 private int randomValue(int min, int max) {return min + (int) (Math.random() * ((max - min) + 1)); }

運行程序，控制臺打印：

=======時間：Tue Mar 17 21:27:49 CST 2020，統計值如下======= 請求總數(持續累計)：240 平均響應時間：103.43404255319149 最小響應時間：10.0 最大響應時間：199.0 樣本大小(取樣本)：225 樣本下的平均響應時間：102.38666666666667 樣本下的響應時間中位數：105.0 樣本下的響應時間90分位數：178.5 =======時間：Tue Mar 17 21:27:54 CST 2020，統計值如下======= 請求總數(持續累計)：465 平均響應時間：106.75869565217391 最小響應時間：10.0 最大響應時間：199.0 樣本大小(取樣本)：225 樣本下的平均響應時間：110.59555555555555 樣本下的響應時間中位數：115.5 樣本下的響應時間90分位數：185.0 =======時間：Tue Mar 17 21:27:59 CST 2020，統計值如下======= 請求總數(持續累計)：701 平均響應時間：106.35488505747126 最小響應時間：10.0 最大響應時間：200.0 樣本大小(取樣本)：235 樣本下的平均響應時間：105.39574468085107 樣本下的響應時間中位數：105.0 樣本下的響應時間90分位數：179.0 =======時間：Tue Mar 17 21:28:04 CST 2020，統計值如下======= 請求總數(持續累計)：939 平均響應時間：105.98929336188436 最小響應時間：10.0 最大響應時間：200.0 樣本大小(取樣本)：240 樣本下的平均響應時間：104.45 樣本下的響應時間中位數：104.0 樣本下的響應時間90分位數：181.0 =======時間：Tue Mar 17 21:28:09 CST 2020，統計值如下======= 請求總數(持續累計)：1187 平均響應時間：104.72673434856176 最小響應時間：10.0 最大響應時間：200.0 樣本大小(取樣本)：246 樣本下的平均響應時間：101.32926829268293 樣本下的響應時間中位數：103.0 樣本下的響應時間90分位數：177.0

稍微核對一下數據：

• 平均rt大概100ms，所以1s鐘可以收到10次請求，5s的窗口就是收到50次請求
• 公開啟5個線程，所以每個窗口內收到的請求是50 * 5 = 250個左右
• 觀察每次樣本大小數：250左右

可以看到數值都是吻合的，證明我們的示例木有啥問題。從控制臺看到Server的歷史持續狀態、抽樣的狀態值一覽無余，這就是監控，這就是負載均衡的“糧食”。

---

總結

關于Ribbon對服務器狀態的管理ServerStats的介紹就到這了。本文花大篇幅介紹了很少人關注的Server狀態統計這塊的知識點，是因為這對理解Ribbon的核心非常之重要，對Ribbon是如何負載均衡選擇Server的策略研究更是非常關鍵。

建議小伙伴可以不僅局限于當個“配置工程師”，而是花時間花精力深入其內了解起來，內部才是星辰大海，才有財富寶石。

總結

以上是生活随笔為你收集整理的Ribbon服务器状态：ServerStats及其断路器原理的全部內容，希望文章能夠幫你解決所遇到的問題。

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