*作者：嶼山、十眠*

微服務體系架構中，服務之間的依賴關係錯綜複雜，我們往往會使用負載均衡元件配合註冊中心來實現服務間的感知。而這種感知行為需要呼叫方、負載均衡元件、註冊中心、被呼叫方互相配合才能夠實現，在出現問題時我們又可能很難確定是哪一部分的問題，在常規場景中，註冊中心會有對應的控制檯可以檢視，而呼叫方、負載均衡元件、被呼叫方處則需要我們手動增加日誌列印語句並重啟應用才能得到相關的資訊，而有些元件又難以找到合適的位置新增我們日誌程式碼，使得這類問題的排查效率低下。

## 負載均衡原理剖析

我們以 Spring Cloud 應用為例分析一下，微服務負載均衡到底是怎麼一回事？

本文的 demo 包含 log-demo-spring-cloud-zuul、log-demo-spring-cloud-a、log-demo-spring-cloud-b、log-demo-spring-cloud-c 四個應用，採用最簡單的 Spring Cloud 標準用法依次呼叫，可以直接在專案上檢視原始碼：

> <https:>

以 Spring Cloud  常用的客戶端負載均衡元件 Ribbon 作為示例，其工作原理如下圖所示。

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

Ribbon 位於客戶端一側，透過服務註冊中心（本文中為 Nacos）獲取到一份服務端提供的可用服務列表。隨後，在客戶端傳送請求時透過負載均衡演算法選擇一個服務端例項再進行訪問，以達到負載均衡的目的。在這個過程中為了感知服務註冊中心的可用服務列表的變化，Ribbon 會在構造 com.netflix.loadbalancer.DynamicServerListLoadBalancer 時，啟動一個定時執行緒去迴圈呼叫 com.netflix.loadbalancer.DynamicServerListLoadBalancer#updateListOfServers 方法更新自己持有的可用服務列表。

```
  @VisibleForTesting
    public void updateListOfServers() {
        List<t> servers = new ArrayList<t>();
        if (serverListImpl != null) {
      //從註冊中心獲取可用服務列表
            servers = serverListImpl.getUpdatedListOfServers();
            LOGGER.debug("List of Servers for {} obtained from Discovery client: {}",
                    getIdentifier(), servers);

if (filter != null) {
        //根據載入的過濾器過濾地址
                servers = filter.getFilteredListOfServers(servers);
                LOGGER.debug("Filtered List of Servers for {} obtained from Discovery client: {}",
                        getIdentifier(), servers);
            }
        }
    //更新可用服務列表
        updateAllServerList(servers);
    }
```

透過程式碼可以發現，updateAllServerList(servers)方法的引數 servers 就是更新後可用服務列表，不過為了確保獲得真實的現場，我們隨著呼叫鏈繼續往下。

```
  protected void updateAllServerList(List<t> ls) {
        // other threads might be doing this - in which case, we pass
        if (serverListUpdateInProgress.compareAndSet(false, true)) {
            try {
                for (T s : ls) {
                    s.setAlive(true); // set so that clients can start using these
                                      // servers right away instead
                                      // of having to wait out the ping cycle.
                }
                setServersList(ls);
                super.forceQuickPing();
            } finally {
                serverListUpdateInProgress.set(false);
            }
        }
    }
```

可以看到只有一個執行緒能夠呼叫 setServersList(ls)方法去更新可用服務列表，之後的呼叫鏈還有一些處理邏輯。

```
com.netflix.loadbalancer.DynamicServerListLoadBalancer#updateAllServerList
  -> com.netflix.loadbalancer.DynamicServerListLoadBalancer#setServersList
  -> com.netflix.loadbalancer.DynamicServerListLoadBalancer#setServerListForZones
  -> com.netflix.loadbalancer.LoadBalancerStats#updateZoneServerMapping
```

其中 updateZoneServerMapping 方法的引數 Map<string list="">> map 基本等同於本次更新動作最後所更新的可用服務列表。也就是說，只要能列印出這個方法的引數，我們就能夠知道每次更新可用服務列表的結果，這就能夠幫助我們瞭解呼叫方以及負載均衡元件在這個場景下的真實現場。

## 無侵入的微服務洞察能力

我們是否可以提供一種能力，我們能夠動態的在任意程式碼的關鍵位置動態地列印需要的日誌，觀測到任何一部分當下的真實現場，從而輔助我們排查問題。考慮到分散式微服務應用的複雜度，這種能力需要以下一些特點：

-   **分散式特性**：滿足在分散式場景下，即使是複雜微服務體系架構下，該能力需要打通微服務鏈路、日誌調整、流量條件匹配，上下游聯動等一系列分散式場景下的能力。

-   **無侵入特性**：無需重啟應用，動態增強與解除安裝，可以動態增強整個應用或者是任意節點。

-   **完整的現場保留能力**：可以將抓取到的現場上下文等資訊，自動保留至遠端的日誌系統中。

-   **靈活的規則配** **置**：可以靈活匹配任意流量，增強任意方法點位，可以靈活控制所需的保留上下文內容。

基於以上思考，我們提供了無侵入的微服務洞察能力，可以迅速幫助我們解決微服務場景下的複雜問題的定位與診斷，可以更好地為我們的治理提供思路與幫助，助力於企業構建完整的微服務治理體系。

### 洞察 loadbalancer 還原服務發現第一現場

下面來看看如何解決微服務負載均衡能力？

將藉助微服務洞察能力，在我們尋找到的位置上儲存列印目標方法包含入參的現場。我們首先選擇 log-demo-spring-cloud-a 應用，在介面列表處選擇自定義埋點，並且填入我們所確定的目標類和目標方法。

> 目標類：
> com.netflix.loadbalancer.LoadBalancerStats 
> 目標方法：
> updateZoneServerMapping(java.util.Map)

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

由於在這個場景下不需要過濾條件，流量過濾條件部分保持預設關閉即可。在列印內容部分，由於我們所關注的內容是該方法的入參，因此勾選通用分類中的請求引數，其餘選項可以根據需求勾選。

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

目標例項根據實際需要選擇全部或是指定例項，最後開啟規則並點選確定。

### 觀察服務發現結果

在完成上述配置後，我們可以在對應的 SLS 的 LogStore 中檢視收集的日誌，其結構大致如下所示。

```
appName:log-demo-spring-cloud-a
destinationEndpoint:
end:1662541729796
endpoint:10.0.0.24
hostname:log-demo-spring-cloud-a-58b8b7ccc9-gnmsv
interface:com.netflix.loadbalancer.LoadBalancerStats:updateZoneServerMapping(java.util.Map)
ip:10.0.0.24
parameters:[{"unknown":[{"alive":true,"host":"10.0.0.125","hostPort":"10.0.0.125:20002","id":"10.0.0.125:20002","instance":{"clusterName":"DEFAULT","enabled":true,"ephemeral":true,"healthy":true,"instanceHeartBeatInterval":5000,"instanceHeartBeatTimeOut":15000,"instanceId":"10.0.0.125#20002#DEFAULT#DEFAULT_GROUP@@sc-B","ip":"10.0.0.125","ipDeleteTimeout":30000,"metadata":{"__micro.service.app.id__":"hkhon1po62@622bd5a9ab6ab48","preserved.register.source":"SPRING_CLOUD"},"port":20002,"serviceName":"DEFAULT_GROUP@@sc-B","weight":1.0},"metaInfo":{"appName":"DEFAULT_GROUP@@sc-B","instanceId":"10.0.0.125#20002#DEFAULT#DEFAULT_GROUP@@sc-B"},"metadata":{"$ref":"$[0].unknown[0].instance.metadata"},"port":20002,"readyToServe":true,"zone":"UNKNOWN"},{"alive":true,"host":"10.0.0.52","hostPort":"10.0.0.52:20002","id":"10.0.0.52:20002","instance":{"clusterName":"DEFAULT","enabled":true,"ephemeral":true,"healthy":true,"instanceHeartBeatInterval":5000,"instanceHeartBeatTimeOut":15000,"instanceId":"10.0.0.52#200...展開
parentSpanID:-1
ruleName:[237]
serviceType:DYNAMIC
spanID:4096
start:1662541729795
success:true
tag:_base
traceID:ea1a00001816625413997651001d0001
userId:1784327288677274
```

parameters 部分是被包裝成 JSON 格式的入參，將其格式化後可以看到這便是我們想要獲取的可用服務列表。

```
[
    {
        "unknown": [
            {
                "alive": true,
                "host": "10.0.0.125",
                "hostPort": "10.0.0.125:20002",
                "id": "10.0.0.125:20002",
                "instance": {
                    "clusterName": "DEFAULT",
                    "enabled": true,
                    "ephemeral": true,
                    "healthy": true,
                    "instanceHeartBeatInterval": 5000,
                    "instanceHeartBeatTimeOut": 15000,
                    "instanceId": "10.0.0.125#20002#DEFAULT#DEFAULT_GROUP@@sc-B",
                    "ip": "10.0.0.125",
                    "ipDeleteTimeout": 30000,
                    "metadata": {
                        "__micro.service.app.id__": "hkhon1po62@622bd5a9ab6ab48",
                        "preserved.register.source": "SPRING_CLOUD"
                    },
                    "port": 20002,
                    "serviceName": "DEFAULT_GROUP@@sc-B",
                    "weight": 1.0
                },
                "metaInfo": {
                    "appName": "DEFAULT_GROUP@@sc-B",
                    "instanceId": "10.0.0.125#20002#DEFAULT#DEFAULT_GROUP@@sc-B"
                },
                "metadata": {
                    "$ref": "$[0].unknown[0].instance.metadata"
                },
                "port": 20002,
                "readyToServe": true,
                "zone": "UNKNOWN"
            },
            {
                "alive": true,
                "host": "10.0.0.52",
                "hostPort": "10.0.0.52:20002",
                "id": "10.0.0.52:20002",
                "instance": {
                    "clusterName": "DEFAULT",
                    "enabled": true,
                    "ephemeral": true,
                    "healthy": true,
                    "instanceHeartBeatInterval": 5000,
                    "instanceHeartBeatTimeOut": 15000,
                    "instanceId": "10.0.0.52#20002#DEFAULT#DEFAULT_GROUP@@sc-B",
                    "ip": "10.0.0.52",
                    "ipDeleteTimeout": 30000,
                    "metadata": {
                        "__micro.service.app.id__": "hkhon1po62@622bd5a9ab6ab48",
                        "preserved.register.source": "SPRING_CLOUD",
                        "__micro.service.env__": "[{"desc":"k8s-pod-label","priority":100,"tag":"gray","type":"tag"}]"
                    },
                    "port": 20002,
                    "serviceName": "DEFAULT_GROUP@@sc-B",
                    "weight": 1.0
                },
                "metaInfo": {
                    "appName": "DEFAULT_GROUP@@sc-B",
                    "instanceId": "10.0.0.52#20002#DEFAULT#DEFAULT_GROUP@@sc-B"
                },
                "metadata": {
                    "$ref": "$[0].unknown[1].instance.metadata"
                },
                "port": 20002,
                "readyToServe": true,
                "zone": "UNKNOWN"
            }
        ]
    }
]
```

為了證明所獲取的是真實的現場，我們透過容器控制檯，將該應用所呼叫的被呼叫方，伸縮至 3 個節點。在完成擴容後，檢視日誌發現，可用服務列表按照預期由原來的 2 個例項變更為 3 個例項。

## 一鍵解決全鏈路灰度流量逃逸問題

有時某個功能發版依賴多個服務同時升級上線。我們希望可以對這些服務的新版本同時進行小流量灰度驗證，這就是微服務架構中特有的全鏈路灰度場景，透過構建從閘道器到整個後端服務的環境隔離來對多個不同版本的服務進行灰度驗證。在釋出過程中，我們只需部署服務的灰度版本，流量在呼叫鏈路上流轉時，由流經的閘道器、各個中介軟體以及各個微服務來識別灰度流量，並動態轉發至對應服務的灰度版本。如下圖：

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

上圖可以很好展示這種方案的效果，我們用不同的顏色來表示不同版本的灰度流量，可以看出無論是微服務閘道器還是微服務本身都需要識別流量，根據治理規則做出動態決策。當服務版本發生變化時，這個呼叫鏈路的轉發也會實時改變。相比於利用機器搭建的灰度環境，這種方案不僅可以節省大量的機器成本和運維人力，而且可以幫助開發者實時快速的對線上流量進行精細化的全鏈路控制。

在我們生產環境使用全鏈路灰度的過程中，我們常常會遇到一些問題：

-   我們配置全鏈路灰度的流量流向是否符合預期，我們的流量是否按照我們配置的灰度規則進行匹配。

-   我們灰度的流量出現了大量的慢呼叫、異常，我該如何確定是我們新版本程式碼的業務問題還是因為我們在流量灰度過程中考慮不全導致的系統問題，如何快速定位問題，從而實現高效的迭代。

-   在我們設計灰度系統的過程中，我們需要考慮如何對我們的灰度流量進行打標，有些時候在入口應用、微服務介面處可能難以找到合適的流量特徵（引數、headers 等攜帶的具備業務語義的標識），在這樣的場景下我們如何快捷地對我們的流量進行打標。

基於以上一些列的問題，也是我們在支援雲上客戶落地全鏈路灰度的過程中不斷碰到的問題。微服務洞察能力也就是我們在這個過程中抽象設計出來的一個能力。針對上訴的問題，我們的微服務洞察能力都能夠很好地解決。

### 洞察灰度流量，流量逃逸問題無所遁形

關於灰度流量，我們在使用全鏈路灰度中往往會關注以下三個問題：

-   我們配置全鏈路灰度的流量流向是否符合預期，有沒有流量打到了非灰度應用
-   符合灰度規則的流量是否被打上了對應的灰度標籤
-   不符合灰度規則的流量是否存在被誤打上灰度標籤的情況

因為如果發生灰度流量沒能按照預期排程，或者非灰度流量被錯誤地排程到灰度應用上的情況，不僅會影響灰度功能的測試，甚至會影響非灰度應用的正常執行。

為了回答上述的三個問題，我們需要觀測灰度流量在系統中真實的標籤和路徑的能力。為此我們可以增加自定義流量規則，在配置規則的流量過濾條件部分選中對應的全鏈路灰度標籤，並在列印內容中對應我們配置的灰度規則勾選請求引數、Headers 等資訊，所有具有該灰度標籤的流量的日誌會被自動採集並且列印。

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

透過在控制檯觀察採集的日誌中的引數、Headers 等資訊可以判斷流量匹配是否正確，不符合灰度規則的流量是否存在被誤打上灰度標籤的情況。而透過觀察灰度流量日誌中的 appName 資訊可以判斷其所經過的應用是否全部都是灰度版本，從而判斷全鏈路灰度流量的路徑是否符合預期。

對於是否有匹配的流量沒有被打上標籤這個問題，我們可以去除標籤的流量過濾條件，從而採集全部的流量，並且透過在控制檯對引數等資訊的篩選，觀察是否有符合條件的流量沒有被打上灰度標籤。

### 定位灰度流量的問題

在全鏈路灰度中，由於整體系統中執行著灰度應用和非灰度應用，相較於日常場景更加複雜。在灰度流量出現慢呼叫或者異常時，快速定位的難度也會更大，而微服務洞察的動態列印日誌能力能夠加速這一過程。

在灰度開始前，如果我們對可能會出現的問題沒有很好的預期，可以先行在入口應用處配置較粗粒度的日誌規則，方便我們觀察到問題的出現。

建立規則時選中入口應用，在目標介面列表中，我們可以新增全部的 web、rpc 介面，也可以只新增我們所關注的。隨後在流量過濾條件中選中對應的灰度標籤、開啟慢呼叫並輸入慢呼叫閾值（在此處慢呼叫可以是相對原版本較慢的呼叫而非絕對意義上的慢）或是開啟異常，隨後在列印內容中選中定位所需的資訊，比如請求引數、錯誤資訊、呼叫堆疊等。

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

由於該規則應用於入口應用，我們需要開啟後續鏈路日誌的開關，以列印該流量路徑上的所有日誌。

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

在開啟規則後，我們可以點選該規則對應的大盤，來觀察所採集的日誌。

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

符合過濾條件的請求和它後續鏈路的日誌都會被採集，我們可以在請求列表中選擇檢視某一請求的鏈路詳情，從而發現出現問題的具體位置。對於某些問題也可以看到其異常堆疊，從而確定發生異常的方法呼叫和導致該異常的可能的內部方法，隨後我們可以透過配置自定義流量規則，在目標介面中選中自定義埋點，並輸入這些嫌疑方法。

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

在列印內容中可以選擇請求引數，返回值等資訊輔助判斷。在開啟規則後便可以列印這些方法的日誌，從而判斷問題產生的原因。

## 總結

本文基於常見的服務呼叫場景，以 Ribbon 負載均衡元件為例，展示了微服務洞察能力能夠在關鍵的位置為我們還原與記錄豐富的現場資訊，使得原有的黑盒場景能夠便捷直觀地被觀測到，在微服務架構下，類似的不便觀測的重要場景還有非常多，都可以藉助微服務洞察能力來監測或是在異常時輔助排查。同時，全鏈路灰度是微服務治理中比較重要的一個場景，我們在落地全鏈路灰度的過程中最讓人頭大的兩個問題就是流量路由不生效以及流量逃逸，我們藉助於微服務洞察能力可以快速定位與解決全鏈路灰度相關的問題。

MSE 微服務洞察能力我們還在持續地打磨與完善，旨在幫助我們更好地治理我們的微服務應用，助力於雲上幫助企業構建完整的微服務體系。歡迎大家嚐鮮與體驗～</string></t></t></t></https:>

從負載均衡到路由，微服務應用現場一鍵到位

相關文章