*作者：十眠*

為什麼有了無損下線，還需要無損上線？無損上線可以解決哪些問題？

本篇文章將一一回答這些問題。

> 無損上線功能不得不說是一個客戶打磨出來的功能

我們將從一次釋出問題的排查與解決的過程說起。

## 背景

阿里雲內部某應用中心服務在釋出過程中出現了大量的 5xx 超時異常。初步懷疑是無損下線問題，於是很快便接入了 MSE 提供的無損下線功能。但是接入無損下線功能後繼續釋出，應用的釋出過程依然存在大量的超時報錯。根據業務方同學的反饋，大概應用在啟動後 5 秒左右，會有大量超時請求。

### 無損下線功能未生效？

於是拉了相關的同學開始排查。應用的呼叫情況如下：gateway - > A -> C 。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/38011a3ff2194604b872c24a2066bfd5~tplv-k3u1fbpfcp-zoom-1.image "1.png")

釋出的應用為 C 應用，釋出過程中出現大量超時報錯。我們透過相關日誌與應用的啟動情況，整理如下線索：

#### 【服務端視角】：找了一臺 C 應用的機器 xxx.xxx.xxx.60 觀察

第一階段：xxx.xxx.xxx.60 (C 應用)下線階段

-   20:27:51 開始重啟，執行重啟指令碼

-   -   同時觀察到執行了 sendReadOnlyEvent 動作，表明服務端傳送只讀事件，客戶端不會再請求該服務端
    -   在 sendReadOnlyEvent 後，開始陸續執行登出服務動作

-   20:27:54 登出所有 provider seivce 完成
-   20:28:15  應用收到 kill -15 訊號

第二階段：xxx.xxx.xxx.60 (C 應用)上線階段

-   20:28:34 服務端重新啟動
-   20:29:19 在 Dubbo 註冊中心控制檯觀察到 xxx.xxx.xxx.60 註冊完畢
-   20:29:19,257 日誌中看到 start NettyServer

#### 【客戶端視角】：找了一臺 A 應用的機器 XXX.XXX.XXX.142 觀察

-   20:27:51 received readOnly event，收到服務端傳送的只讀事件，此時該客戶端不會請求至 XXX.XXX.XXX.60 機器
-   20:27:56 close [xxx.xxx.xxx.142:0 -> /XXX.XXX.XXX.60:20880] ，關閉channel連線

#### 業務日誌報錯資訊

同時搜 C 應用的機器 XXX.XXX.XXX.60 的報錯相關的日誌，共 237 條日誌

其中最早的 time:  2020-07-30 20:29:26,524

其中最晚的 time:  2020-07-30 20:29:59,788

#### 結論

觀察這些跡象可以初步得出結論：

-   無損下線過程均符合預期，並且下線過程中並沒有出現任何報錯
-   報錯期間處於服務端應用成功啟動後且註冊成功後，與業務方觀察的現象一致

這時候懷疑是上線期間的問題，同時排查服務端相關日誌，發在報錯期間，服務端執行緒被打滿：

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/617f586d690d44a8bf360fb242256689~tplv-k3u1fbpfcp-zoom-1.image "2.png")

問題定位為上線過程中的問題，與無損下線無關。

## 無損上線實踐

我們幫助使用者解決問題的思路：幫助使用者發現問題的本質、找到問題的通用性、解決問題、將解決通用問題的能力產品化。

發現使用者 Dubbo 版本比較低，缺少自動打執行緒堆疊的能力：

-   透過 MSE 增加 Dubbo 執行緒池滿自動 JStack 能力

這是每次釋出必現的問題，透過觀察執行緒池滿時的 JStack 日誌，有助於我們定位問題。

### 阻塞在非同步連線等資源準備上

初步觀察 JStack 日誌，發現不少執行緒阻塞在 taril/druid 等非同步連線資源準備上：

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bb8e68a77b87495f966e835ffeb21b22~tplv-k3u1fbpfcp-zoom-1.image "3.png")

同時我們雲上也有有客戶遇到過，應用啟動後一段時間內 Dubbo 執行緒池滿的問題，後經過排查由於 Redis 連線池中的連線未提前建立，流量進來後大量執行緒阻塞在 Redis 連線建立上。

連線池透過非同步執行緒保持連線數量，預設在應用啟動後 30 秒建立最小連線數的連線。

#### 1、解決思路

-   提前建立連線
-   使用服務延遲釋出特性

#### 2、預建連線

以 JedisPool 預建連線為例，提前建立 Redis 等連線池連線，而不是等流量進來後開始建立連線導致大量業務執行緒等待連線建立。

```
org.apache.commons.pool2.impl.GenericObjectPool#startEvictor
protected synchronized void startEvictor(long delay) {
    if(null != _evictor) {
        EvictionTimer.cancel(_evictor);
        _evictor = null;
    }
    if(delay > 0) {
        _evictor = new Evictor();
        EvictionTimer.schedule(_evictor, delay, delay);
    }
}
```

JedisPool 透過定時任務去非同步保證最小連線數的建立，但這會導致應用啟動時，Redis 連線並未建立完成。

主動預建連線方式：在使用連線之前使用 GenericObjectPool#preparePool 方法去手動去準備連線。

在微服務上線過程中，在初始化 Redis 的過程中提前去建立 min-idle 個 redis 連線，確保連線建立完成後再開始釋出服務。

同樣有類似問題，預建資料庫連線等非同步建連邏輯，保證在業務流量進來之前，非同步連線資源一切就緒。

#### 3、延遲釋出

延遲釋出為了一些需要非同步載入的前置資源如提前準備快取資源，非同步下載資源等，需要控制服務註冊時機，即控制流量進入的時機保證服務所需的前置資源準備完成該服務才可以進行釋出，延遲釋出有兩種方式

-   透過 delay 配置方式

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2626522ff78044dcaa0be844892c63d5~tplv-k3u1fbpfcp-zoom-1.image "4.png")

透過指定 delay 大小例如 300 s，Dubbo/Spring Cloud 服務將會在 Spring 容器初始化完成後進行後等待 5 分鐘，再執行服務註冊邏輯。

-   online 命令上線

透過開啟預設不註冊服務配置項，再配合釋出指令碼等方式執行 curl 127.0.0.1:54199/online 地址觸發主動註冊。我們可以在前置資源準備完成後，透過 online 命令去註冊服務。

也可以在 MSE 例項詳情透過服務上線去註冊服務。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6983ebb9d90c4597ae7fb4a374307f57~tplv-k3u1fbpfcp-zoom-1.image "5.png")

### 阻塞在 ASMClassLoader 類載入器上

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/641ceda92a334d558b9395e7c59ec75b~tplv-k3u1fbpfcp-zoom-1.image "6.png")

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/17fed2f25f6b4f85b9ecc969a6253cfe~tplv-k3u1fbpfcp-zoom-1.image "7.png")

大量執行緒阻塞在 fastjson 的 ASMClassLoader 類載入器載入類的過程中，翻看 ClassLoader 載入類的程式碼其預設是同步類載入。在高併發場景下會導致大量執行緒阻塞在類載入上，從而影響服務端效能，造成執行緒池滿等問題。

```
private ClassLoader(Void unused, ClassLoader parent) {
    this.parent = parent;
    // 開啟並行類載入
    if (ParallelLoaders.isRegistered(this.getClass())) {
        parallelLockMap = new ConcurrentHashMap<>();
        package2certs = new ConcurrentHashMap<>();
        domains =
            Collections.synchronizedSet(new HashSet<protectiondomain>());
        assertionLock = new Object();
    } else {
        // no finer-grained lock; lock on the classloader instance
        parallelLockMap = null;
        package2certs = new Hashtable<>();
        domains = new HashSet<>();
        assertionLock = this;
    }
}
protected Class> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            ......
            return c;
        }
    }

protected Object getClassLoadingLock(String className) {
    Object lock = this;
    //如果開啟類載入器並行類載入，則鎖在所載入的類上，而不是類載入器上
    if (parallelLockMap != null) {
        Object newLock = new Object();
        lock = parallelLockMap.putIfAbsent(className, newLock);
        if (lock == null) {
            lock = newLock;
        }
    }
    return lock;
}
```

#### 1、解決思路

-   開啟類載入器並行載入

#### 2、類載入器開啟並行類載入

JDK7 上，如果呼叫下面的方法，則會開啟並行類載入功能，把鎖的級別從 ClassLoader 物件本身，降低為要載入的類名這個級別。換句話說只要多執行緒載入的不是同一個類的話，loadClass 方法都不會鎖住。

我們可以看 Classloader.registerAsParallelCapable 方法的介紹

> protected static boolean registerAsParallelCapable()
> 
> Registers the caller as parallel capable.
> 
> The registration succeeds if and only if all of the following conditions are met:
> 
> 1. no instance of the caller has been created
> 
> 2. all of the super classes (except class Object) of the caller are registered as parallel capable
> 
> Classloader.registerAsParallelCapable

它要求註冊該方法時，其註冊的類載入器無例項並且該類載入器的繼承鏈路上所有類載入器都呼叫過registerAsParallelCapable，對於低版本的 Tomcat/Jetty webAppClassLoader  以及 fastjson 的 ASMClassLoader 都未開啟類載入，如果應用裡面有多個執行緒在同時呼叫 loadClass 方法進行類載入的話，那麼鎖的競爭將會非常激烈。

MSE Agent 透過無侵入方式在類載入器被載入前開啟其並行類載入的能力，無需使用者升級 Tomcat/Jetty，同時支援透過配置動態開啟類載入並行類載入能力。

### 其他一些問題

-   JVM JIT 編譯問題引起 cpu 飆高
-   日誌同步列印導致執行緒阻塞
-   Jetty 低版本類載入類同步載入
-   K8s 場景下，微服務與 K8s Service 生命週期未對齊

#### 1、解決思路

-   服務預熱

-   -   客戶端負載均衡
    -   服務端服務分層釋出

-   業務日誌非同步化
-   提供微服務 Readiness 介面

#### 2、業務日誌非同步化

同步進行日誌列印，由於日誌列印使用的是業務執行緒，由於日誌列印過程中存在序列化、類載入等邏輯，在高併發的場景下會導致業務執行緒hang住，導致服務框架執行緒池滿等問題。MSE Agent 支援動態使用非同步日誌列印能力，將日誌列印任務與業務執行緒分開，提高業務執行緒吞吐量。

#### 3、小流量預熱

應用啟動後，大量請求進入，導致應用存在許多問題,所以需要微服務的一些能力來解決服務預熱問題：

-   JVM JIT 編譯執行緒佔用 CPU 過高，CPU/load 短期內飆高，Dubbo 處理請求效能下降
-   瞬時請求量過大，導致執行緒阻塞在類載入、快取等，從而導致 Dubbo 服務執行緒池滿

小流量預熱，MSE 服務治理透過 OneAgent 無侵入提供了以下幾種能力：

-   客戶端負載均衡

透過增強客戶端負載均衡能力，對於剛上線的需要預熱的節點進行流量權重的調整，做到剛上線的應用按照使用者所配置的規則進行小流量預熱，使用者只需指定預熱規則即可按照預期對剛上線的節點進行小流量預熱

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/73794cfd1435412d858284aa48ad7662~tplv-k3u1fbpfcp-zoom-1.image "9.png")

業務方的一臺服務端例項使用服務預熱後的效果:服務預熱開啟後，待預熱的應用將在預熱週期內透過小流量實現應用啟動過程的預熱初始化。下圖預熱時長為 120 秒，預熱曲線為 2 次的預熱效果圖：

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9c3afac1e50a4bb1a0fb6e81de9d751f~tplv-k3u1fbpfcp-zoom-1.image "10.png")

說明 該測試 Demo 是定時伸縮模擬應用啟動，因此除了預熱過程，還包含應用下線的過程。下圖預熱時長為 120 秒，預熱曲線為 5 次的預熱效果圖：

![11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/35258d74271743eb885f555d59fb609b~tplv-k3u1fbpfcp-zoom-1.image "11.png")

如上圖所示，相比於 2 次預熱過程，5 次預熱過程剛啟動的這段時間（即17:41:01~17:42:01），QPS 一直保持在一個較低值，以滿足需要較長時間進行預熱的複雜應用的預熱需求。

-   服務端分層釋出

透過修改服務註冊的邏輯，增加對應用 load 等指標的監控，對服務進行分批註冊已經回滾註冊等邏輯，保證服務註冊過程中，流量分服務進入，系統 load 始終低於閾值，並且需要在指定時長內將服務註冊上去。

缺點：在應用的服務流量平均，不存在超熱點介面的情況下，分層釋出可以很好地解決服務預熱問題。但是如果應用存在一些超熱服務，可能這個服務幾乎佔所有流量 90% 以上，那服務端分層釋出效果並不會很明顯。

注意：對於一些存在依賴的服務介面，服務分層釋出可能需要業務梳理服務分批發布的順序

#### 4、打通 K8s 與微服務生命週期

K8s 提供兩種健康檢查機制：

-   livenessProbe，用於探測不健康的 Pod，探測失敗將會重啟 Pod。
-   readinessProbe，用於探測一個 Pod 是否就緒接受流量，探測失敗將會在 Service 路由上摘取該節點。

如果不配置 readinessProbe ，預設只檢查容器內程式是否啟動執行，而對於程式的執行情況很難考量，Mse Agent 透過對外提供 readiness 介面，只有 Spring Bean 初始化完成以及非同步資源準備就緒並且開始服務註冊時， readiness 才返回 200。將微服務側的服務暴露與 K8s Service 體系打通，使 K8s 管控能感知到程式內部的服務就緒時機，從而進行正確地服務上線。

我們需要在 MSE 無損上線頁面開啟無損滾動釋出的配置：

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/875d965d9fdc42f399eb3953785f8b76~tplv-k3u1fbpfcp-zoom-1.image "12.png")

同時給應用配置 K8s 的就緒檢查介面，如果您的應用在阿里雲容器服務 ACK 上，可以在阿里雲容器 ACK 服務對應應用配置的中健康檢查區域，選中就緒檢查右側的開啟，配置如下引數，然後單擊更新。

![13.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/30641b367d394e85a57f596573ae1a96~tplv-k3u1fbpfcp-zoom-1.image "13.png")

該應用在下次重啟時，該配置即可生效。

#### 5、服務並行訂閱與註冊

透過並行的服務註冊與訂閱，可以大幅提升應用啟動的速度，解決服務啟動慢的問題。

以並行服務訂閱為例：

![14.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5bbfd98b2f9f42bdbf6968c248e4c6cf~tplv-k3u1fbpfcp-zoom-1.image "14.png")

如上圖所示，透過 Java Agent 將服務框架 refer 的流程從 SpringBean 的初始化流程中剝離出來並且透過非同步執行緒來實現服務的並行訂閱與註冊。

## 總結

透過不斷地觀察業務情況，然後進行不斷地問題分析思考與解決的嘗試，直到開啟了服務小流量預熱能力後，徹底解決了業務團隊應用在上線期間執行緒池滿導致請求有損的問題。

-   釋出期間 Exception 總量與釋出日期（包含無損上線功能陸續上線的節點）的情況如下圖

![15.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ffbd9c14dfa440629fefb643c2f7ea98~tplv-k3u1fbpfcp-zoom-1.image "15.png")

9 月 15 號釋出了服務小流量預熱能力後，釋出期間相關 Exception 下降至 2。（經業務方確認不是因為釋出引起的，可以忽略）

上線了無損上線功能後，業務團隊的應用中心持續多個月的釋出報錯問題總算告一段落，但是無損上線功能遠不止於此。還解決許多雲上客戶上線有損的情況，功能的能力與場景也在不斷地解決問題中逐漸完善與豐富。

### MSE 無損上線

MSE 服務治理一個特點是透過 Agent 無侵入地支援市面上近五年來 Dubbo、Spring Cloud 所有版本，所以無損上線這個功能也會是如此，下面會以 Dubbo 為例子無損上線的功能，當然所有能力我們都是無縫支援 Dubbo、Spring Cloud 的。

下面開始系統地介紹一下 MSE 服務治理的無損上線，我們可以先從開源的一個 Dubbo 應用上線的流程開始分析：

-   應用初始化，Spring Bean容器初始化
-   收到 ContextRefreshedEvent後，Dubbo 會去拉取 Dubbo應用所需的配置、後設資料等
-   exportServices 註冊服務

開源 Dubbo 上線流程還是非常完善與嚴謹，但是依舊存在一些場景會導致服務上線存在問題：

-   當服務資訊註冊到註冊中心後，在消費者看來該服務就是可以被呼叫的。然而，此時可能存在一些資料庫、快取資源等一些非同步資源尚未載入完畢的場景，這取決於你的系統有沒有對應的元件，它們何時載入完畢，也完全取決於你的業務。

-   如果在大流量的場景下，服務在註冊到註冊中心後，馬上有大流量進入，存在一系列問題，導致執行緒阻塞，對業務流量造成損失

-   -   比如 Redis 的 JedisPool 連線池建立後並不會立即建立連線，會在流量進來後開始建立連線，如果一開始湧進的是大流量，則導致大量執行緒阻塞在連線池重的連線的建立上
    -   FastJson 以及 Jetty/tomcat 等低版本中，並未開啟類載入器並行類載入能力，導致大量執行緒阻塞在類載入器載入類上
    -   JVM JIT 編譯問題引起 cpu 飆高
    -   執行緒阻塞在業務日誌上

-   雲原生場景下，微服務與 K8s 的生命週期未對齊的情況

-   -   滾動釋出，重啟的 pod 還未註冊至註冊中心，但是 readiness 檢查以及透過。導致第一個 pod 還未註冊至註冊中心，最後一個 pod 以及下線，導致短時間內的客戶端 NoProvider 異常

針對如上問題，MSE 服務治理不僅提供了完整的解決方案，還提供了白屏化開箱即用的能力，動態配置實時生效。

![16.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fa21b9efa5d44c89b2cc1d240f35ce6f~tplv-k3u1fbpfcp-zoom-1.image "16.png")

同時 MSE 服務治理針對無損上下線的場景還提供了完整的可觀測能力。

![17.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/34d996df7e744db58fe7523c87b97ba9~tplv-k3u1fbpfcp-zoom-1.image "17.png")

無損上線功能可以總結為以下這張圖：

![18.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/41cab88e7db84260a04adc93b96f2f8f~tplv-k3u1fbpfcp-zoom-1.image "18.png")

### 不只是無損上下線

無損上下線能力是微服務流量治理中的重要的一環，當然除了無損下線，MSE 還提供了全鏈路灰度、流控降級與容錯、資料庫治理等一系列的微服務治理能力。服務治理是微服務改造深入到一定階段之後的必經之路，在這個過程中我們不斷有新的問題出現。

-   除了無損上下線，服務治理還有沒其他能力？
-   服務治理能力有沒一個標準的定義，服務治理能力包含哪些？
-   多語言場景下，有無全鏈路的最佳實踐或者標準？
-   異構微服務如何可以統一治理？

當我們在探索服務治理的過程中，我們在對接其他微服務的時候，我們發現治理體系不同造成的困擾是巨大的，打通兩套甚者是多套治理體系的成本也是巨大的。為此我們提出了 OpenSergo 專案。OpenSergo 要解決的是不同框架、不同語言在微服務治理上的概念碎片化、無法互通的問題。

![19.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fa4009a9e2464c1e8b3625e32b190d00~tplv-k3u1fbpfcp-zoom-1.image "19.png")

OpenSergo 社群也在聯合各個社群進行進一步的合作，社群來一起討論與定義統一的服務治理標準。當前社群也在聯合 bilibili、位元組跳動等企業一起共建標準，也歡迎感興趣的開發者、社群與企業一起加入到 OpenSergo 服務治理標準共建中。歡迎大家加入 OpenSergo 社群交流群（釘釘群）進行討論：34826335

**MSE 註冊配置首購 8 折，首購 1 年及以上 7 折。MSE 雲原生閘道器預付費全規格享 9 折優惠。點選**[**此處**](https://www.aliyun.com/product/aliware/mse) **，即享優惠！**</protectiondomain>

微服務治理熱門技術揭秘：無損上線

相關文章