微服務(wù)架構(gòu)下，穩(wěn)定性和高可用性一個永恒的話題，在實際的治理過程中，我們有可能會遇到以下場景：

• 某個應(yīng)用灰度發(fā)布，先上了幾臺機器，由于代碼邏輯寫的有問題，造成線程池滿，出現(xiàn)運行異常。
• 服務(wù)端集群中，某幾臺機器由于磁盤滿，或者是宿主機資源爭搶導(dǎo)致 load 過高，客戶端出現(xiàn)調(diào)用超時。
• 服務(wù)端集群中，某幾臺機器由于線程池滿，造成 Full Garbage Collection。

在以上 3 種場景中，由于客戶端并不法感知已經(jīng)出現(xiàn)問題的那些服務(wù)端，依然會發(fā)送請求到這些機器上，造成業(yè)務(wù)調(diào)用報錯，上游的機子將會被下游的某臺機子的短暫故障拖垮，造成應(yīng)用雪崩的風(fēng)險。

面對這種場景，如果僅僅為此而進行服務(wù)降級，對應(yīng)用的傷害未免過大，但如果我們可以檢測出服務(wù)集群中某些故障機子，并對其進行短暫隔離，即可有效保障服務(wù)的高可用與系統(tǒng)的穩(wěn)定性，同時給運維人員提供了寶貴的緩沖時間，用于問題定位，排除故障。

本文將作為《微服務(wù)治理實踐》系列篇的第一篇，為大家介紹如何實現(xiàn)離群實例摘除。該系列文章是基于阿里云商業(yè)化產(chǎn)品 EDAS 的微服務(wù)實踐，如果您團隊具備較強的微服務(wù)治理能力，那么希望我們在微服務(wù)治理方面的實踐和背后的思考，可以為您提供一些參考。

企業(yè)級分布式服務(wù) EDAS 重磅升級，12月17日下午15:00--17:00中間件小師妹在直播間等你，攜開發(fā)工程師十眠為您詳細介紹 EDAS 離群實例摘除等微服務(wù)治理能力。還有禮品送不停，直播間地址點擊“傳送門”。

Microservice Outlier Ejection （微服務(wù)離群實例摘除）

• 什么是離群實例摘除

當(dāng)單點發(fā)生夯機異常時，consumer 能主動判斷，并將對應(yīng)的 provider 實例短時間剔除，不再請求，在一定時間間隔后再繼續(xù)訪問。同時，具有全局異常判斷能力，當(dāng) provider 異常實例的數(shù)量過多時，并且超過一定的控制比例，說明此時 provide 整體服務(wù)質(zhì)量低下，該機制僅保持摘除一定的比例。

• 離群實例摘除的功能

從服務(wù)層容錯能力上，對業(yè)務(wù)穩(wěn)定性進行增強，有效解決單點故障的問題。

• 與熔斷的區(qū)別

熔斷是指當(dāng)服務(wù)的輸入負載激增時， 避免服務(wù)被迅速壓垮導(dǎo)致雪崩效應(yīng)，而對負載進行斷路的一種方式 。 熔斷一般由熔斷請求判斷算法，熔斷恢復(fù)機制，熔斷報警等模塊組成。隔離是指，為了避免在依賴的服務(wù)故障時候造成的故障擴散，而采取的將系統(tǒng)進行單元化設(shè)計的一種架構(gòu)方法。

若僅僅由于服務(wù)端集群中單點異常問題，就采用熔斷降級方案，將會對應(yīng)用的傷害過大，離群實例摘除可以有效地解決單點異常問題從而保證服務(wù)質(zhì)量。若?provider 整體服務(wù)質(zhì)量低下時，離群摘除效果不再明顯，此時可以采用熔斷降級功能。

• 離群實例摘除支持的版本

只要您的應(yīng)用版本在列表中，您無需改動一行代碼就可以使用到離群實例摘除功能。

?目前支持版本開發(fā)中版本（即將支持）

Dubbo	2.5.0～2.7.3	< 2.5.0 dubbox 版本
Spring Cloud	D、E、F、G、H	C

目前已經(jīng)覆蓋了市面上大部分微服務(wù)場景，后續(xù)我們將會持續(xù)支持開源最新的 Dubbo/Spring Cloud 版本。

我們提供了 Dubbo 和 Spring Cloud 兩種場景的離群摘除功能，本文將先介紹一下 Dubbo Microservice Outlier Ejection 的實踐與效果。

下面將通過在 EDAS 上通過演示 Dubbo 離群摘除功能及效果。

企業(yè)級分布式應(yīng)用服務(wù)EDAS（Enterprise Distributed Application Service）是一個應(yīng)用托管和微服務(wù)管理的 PaaS 平臺，提供應(yīng)用開發(fā)、部署、監(jiān)控、運維等全棧式解決方案，同時支持 Dubbo、Spring Cloud 等微服務(wù)運行環(huán)境。

https://www.aliyun.com/product/edas

準(zhǔn)備

接下來以微服務(wù)Demo為例子示范離群摘除功能，讀者可以從github中下載驗證

https://github.com/aliyun/alibabacloud-microservice-demo/tree/master/src

微服務(wù)Demo是一個簡單的電商項目，下圖為項目結(jié)構(gòu)，cartservice 為 Dubbo 框架的購物車服務(wù) provider，productservice 為Spring Cloud提供的商品詳情服務(wù) provider，frontend 為web controller即前端展示頁面，可以理解為consumer。

我們將以cartservice服務(wù)即Dubbo服務(wù)端為例子，展示離群實例摘除功能。

EDAS 上部署微服務(wù) Demo

首先?cd cartservice切換到 cartservice 目錄下，再通過?mvn clean install?打包，通過?cd cartservice-provider/target?切換到target目錄下，我們可以看到新生成的 cartservice-provider-1.0.0-SNAPSHOT.jar 包，然后在 EDAS上 創(chuàng)建一個 cartservice 應(yīng)用。

點擊下一步后，上傳剛才打包的jar包，即 cartservice-provider/target/ cartservice-provider-1.0.0-SNAPSHOT.jar?然后下一步，記住登陸密碼，直到創(chuàng)建應(yīng)用成功。

然后啟動應(yīng)用，到目前為止，我們啟動了一個 cartservice-provider。點擊按此實例規(guī)格擴容，該服務(wù)我們部署在兩個實例上。

我們在這個 provider 的?com.alibabacloud.hipstershop.provider.CartServiceImpl?類中可以看到，這個 provider 是提供了viewCart 和 addItemToCart 的兩個關(guān)于購物車的服務(wù)，我們在 viewCart 中加入一些模擬運行時異常的邏輯。

@Value("${exception.ip}")private String exceptionIp;@Overridepublic List<CartItem> viewCart(String userID) {if (exceptionIp != null && exceptionIp.equals(getLocalIp())) {throw new RuntimeException("運行時異常");}return cartStore.getOrDefault(userID, Collections.emptyList());}

其中 exceptionIp 為 ACM 配置中心的exception.ip的配置項，若該項配置為本機ip時，該服務(wù)throw RuntimeException，用于模擬業(yè)務(wù)異常的場景。

• 為什么將 cartservice 擴容到兩個實例，想必大家也猜到了，運行時通過配置ACM配置中心指定其中一個實例的IP，模擬出一個實例異常的場景。

接下來，我們需要部署 frontend /?productservice 兩個服務(wù)，方式一樣，分別上傳 frontend/target/frontend-1.0.0-SNAPSHOT.jar 和 productservice/productservice-provider/target/productservice-provider-1.0.0-SNAPSHOT.jar

從下圖可以看到，我們的微服務(wù)Demo在EDAS部署上去了。

模擬業(yè)務(wù)異常

進入到?frontend 應(yīng)用中，我們看到其實例的公網(wǎng) ip 為 47.99.150.33。

進入瀏覽器訪問?http://47.99.150.33:8080/

點擊View Cart 訪問至?http://47.99.150.33:8080/cart

可以看到，此時服務(wù)都是正常的。

我們?nèi)?ACM 配置中心 配置 exception.ip 為 172.16.205.180（即cartservice的其中某個實例的IP）。

然后繼續(xù)訪問?http://47.99.150.33:8080/cart?，發(fā)現(xiàn) 50 % 的概率錯誤頁面

此時，我們寫一個腳本，定時大量訪問?http://47.99.150.33:8080/cart?模擬請求。

while : doresult=`curl $1 -s`if [[ "$result" == *"500"* ]]; thenecho `date +%F-%T` $resultelseecho `date +%F-%T` "success"fisleep 0.1 done

然后?sh curlservice.sh http://47.99.150.33:8080/cart

我們看到不斷重復(fù)的每秒鐘 10 次的 50% 的調(diào)用成功率。

其實也可以理解到，下游的服務(wù)質(zhì)量隨著上游的某臺機子的異常而急劇下降，甚至可能導(dǎo)致下游服務(wù)被上游某些機子的（系統(tǒng)、業(yè)務(wù)）異常給拖垮。

開啟離群摘除策略

下面我將演示離群摘除的策略的開啟及其效果的展示。

創(chuàng)建

我們進入到 EDAS 左側(cè)列表的 [微服務(wù)管理] 下的 [離群實例摘除] 界面中，并選擇創(chuàng)建離群實例摘除策略。

然后按照提示一步步創(chuàng)建離群摘除的策略。

基本信息

如上圖可以選擇命名空間、填寫策略名稱、選擇該策略支持的框架類型（Dubbo/Spring Cloud）。

選擇生效應(yīng)用

按照目前的調(diào)用方式，我們只需要配置 frontend 應(yīng)用，保護下游應(yīng)用 consumer。

配置策略

這些參數(shù)都提供了默認(rèn)值，需要根據(jù)自己應(yīng)用的具體情況調(diào)整最合適的值，由于需要保護的 RuntimeException 屬于業(yè)務(wù)異常于是選上 網(wǎng)絡(luò)異常+業(yè)務(wù)異常。（需要注意的是即使摘除實例比例上限配得特別低，向下取整數(shù)小于1，當(dāng)集群中實例數(shù)目大于1，且某一實例異常，我們也會摘除一實例）。

創(chuàng)建完成

可以看到策略的信息，創(chuàng)建完成。

策略

看到了我們創(chuàng)建的離群摘除策略，且是針對Dubbo框架，并且針對的是 網(wǎng)絡(luò)異常+業(yè)務(wù)異常 的異常類型。

驗證離群摘除效果

這時，我們看到，再感知到異常后，離群摘除功能生效，請求調(diào)用一陣子后，均返回正確結(jié)果。

不斷刷新瀏覽器訪問?http://47.99.150.33:8080/cart?也均正常

客戶端感知到某臺服務(wù)端機子異常后，主動摘除。僅僅調(diào)用業(yè)務(wù)正常的 Provider 實例，同時我們也可以通 ARMS（EDAS監(jiān)控系統(tǒng)） 監(jiān)控看到服務(wù)質(zhì)量的上升，以及流量從異常 Provider 中摘除。

Dubbo框架可以從 /home/admin/.opt/ArmsAgent/logs 目錄下的日志中，搜索日志中的 “OutlierRouter” 關(guān)鍵字可以看到一系列離群實例摘除的事件日志。

修改/關(guān)閉離群摘除策略

對于EDAS的應(yīng)用我們支持通過控制臺動態(tài)修改和刪除離群摘除策略。

• 對應(yīng)策略規(guī)則的修改

點擊 修改生效應(yīng)用 或者 編輯策略。

然后增加刪除應(yīng)用或者調(diào)整參數(shù)，確定后均立即生效

• 刪除對應(yīng)策略

控制臺的操作，對應(yīng)用中的配置都是實時生效的，若刪除策略后，默認(rèn)關(guān)閉相關(guān)策略。

若我們打開ARMS監(jiān)控觀察具體的調(diào)用情況。

ARMS監(jiān)控

若我們開啟監(jiān)控，將會直觀看到流量與請求錯誤等信息。

開啟離群摘除前

如下圖方式開啟，然后跳轉(zhuǎn)至ARMS（EDAS監(jiān)控系統(tǒng)）應(yīng)用監(jiān)控頁面，我們需要把三個應(yīng)用都開啟高級監(jiān)控。

我們可以從下圖即ARMS（EDAS監(jiān)控系統(tǒng)）應(yīng)用監(jiān)控頁面直觀地看到結(jié)果。

從以下拓撲圖中我們看到，流量不斷地訪問到cartservice服務(wù)上。

開啟離群摘除后

離群摘除效果通過簡單的例子就看到了，當(dāng)然可以通過 ARMS （EDAS監(jiān)控系統(tǒng)）的監(jiān)控可以明顯觀察到服務(wù)質(zhì)量的提升。

可以看到，在開啟了離群摘除的那個點只后，錯誤率從50%明顯下降。

其中兩個小的起伏毛刺是因為，離群摘除一段時間后會重新嘗試訪問被摘除的 endPoint ，若依舊錯誤率高于閾值，繼續(xù)隔離，且間隔時間更長。

離群實例摘除具體控制邏輯

前面我們看到了，離群實力摘除對應(yīng)用穩(wěn)定性提高帶來的幫助，下面我們將具體分析離群實例摘除的控制邏輯，有助于您更好地理解其各種參數(shù)的意義，以及可以根據(jù)自己的應(yīng)用情況，通過調(diào)整參數(shù)，配置出最合適自己的離群摘除策略。

對于 Dubbo/SpringCloud 框架：

• 默認(rèn)QPS下限為1

只有當(dāng)前某實例的調(diào)用QPS大于1才會開始離群實例摘除保護。

• 默認(rèn)錯誤率下限 50%

只有當(dāng)前某實例的調(diào)用錯誤率高于 50% ，則系統(tǒng)會認(rèn)為該服務(wù)端集群的當(dāng)前某實例處于異常狀態(tài)。

• 默認(rèn)摘除實例比例上限 20%

若當(dāng)前服務(wù)集群中，有大于20%的實例節(jié)點處于異常狀態(tài)，則系統(tǒng)只會摘除異常狀態(tài)的實例數(shù)占集群總數(shù)的50%。

• 異常類型

若異常類型為 網(wǎng)絡(luò)異常 ，則系統(tǒng)僅僅把網(wǎng)絡(luò)異常的錯誤算進錯誤率統(tǒng)計中，忽略掉業(yè)務(wù)異常；反之，若選擇了 網(wǎng)絡(luò)異常 + 業(yè)務(wù)異常 則系統(tǒng)會將所有異常當(dāng)成錯誤算進錯誤率統(tǒng)計中。

• 關(guān)于恢復(fù)檢測單位時間（默認(rèn)30000ms即30s）與未恢復(fù)累計次數(shù)上限（默認(rèn)40）的解釋

其中第一次摘除時長為 0.5 分鐘，時間到了之后 consumer 會繼續(xù)訪問該 provider ，若該 provider 服務(wù)質(zhì)量依舊低下，則會繼續(xù)摘除，摘除時長隨著連續(xù)被摘除次數(shù)的增加線性遞增每次增加 0.5 分鐘，每次最多摘除 20 分鐘。當(dāng)然，若繼續(xù)調(diào)用之后，服務(wù)質(zhì)量恢復(fù)了，則會當(dāng)成健康服務(wù)，下一次又出現(xiàn)異常導(dǎo)致服務(wù)質(zhì)量低下問題時，會重新隔離 0.5 分鐘，并繼續(xù)上述規(guī)則。

• 兜底

但是當(dāng)客戶端調(diào)用的服務(wù)僅有1個實例提供服務(wù)提供則不會隔離這個實例。

若當(dāng)前客戶端調(diào)用的服務(wù)實例大于1個，且當(dāng)前離群摘除隔離比例計算出的實例數(shù)小于1，若服務(wù)端集群出現(xiàn)單點故障，則會摘除1個實例。

上面所有的實例可以理解為endpoint（ip+port為緯度）

• 通用最佳實踐

可以配置相對的錯誤率閾值（50%）與過低的摘除實例比例上限（10%），全鏈路開啟。

離群實例摘除技術(shù)細節(jié)

無侵入技術(shù)

無侵入方案即通過agent技術(shù)來實現(xiàn)，一句話來說就是通過字節(jié)碼增強技術(shù)，運行時插入我們的代碼，改變應(yīng)用的原有邏輯，可以理解為運行時AOP，通過在Dubbo的鏈路中插入Filter/Router，在Spring Cloud中增強LoadBalance邏輯，來實現(xiàn)我們期望的路由控制邏輯。同時因為是agent增強的，再加上 Dubbo 各個版本的鏈路整體基本沒大的變化，Spring Cloud 模型的統(tǒng)一性，因此我們可以花少的代價將能力基本覆蓋到所有版本。

Dubbo Agent 方案技術(shù)架構(gòu)

對于用戶來說，無需改動一行代碼，一行配置，即可享受到穩(wěn)定性增強的能力。

離群實例摘除技術(shù)

Outlier Detection 離群檢測

均是基于時間窗口的數(shù)據(jù)統(tǒng)計。

兩種實現(xiàn)
1、Dubbo 2.7 版本通過向鏈路中嵌入一個MetricsFilter，對于鏈路的每個request/response做打點處理，統(tǒng)計rt、調(diào)用成功與否、異常類型，并且已endpoint（ip+port）為key存儲

2、在 Agent 底座中統(tǒng)計經(jīng)過的http請求，通過url、rt、狀態(tài)碼、異常類型等數(shù)據(jù)結(jié)果，統(tǒng)計最近時間窗口的數(shù)據(jù)（目前寫死 10 秒，暫時不透出）

實時統(tǒng)計前N秒的調(diào)用信息，作為離群實例摘除動作的依據(jù)。

Outlier Ejection 離群摘除

Dubbo 基于 Dubbo Router 實現(xiàn)，對于調(diào)用的上游服務(wù)對應(yīng)的所有 invokers 中，拉黑掉“不健康”的節(jié)點，同時記錄拉黑的信息。

Dubbo-Router控制邏輯
每次請求過來僅僅check一下并標(biāo)記狀態(tài)，后臺有專門兩個線程將標(biāo)記的流量進行判斷是否進入隔離列表或從中剔除，修改拉黑信息等耗時操作，最大程度上保證請求的實時性。

Spring Cloud 基于 擴展 LoadBalace 實現(xiàn)，原理相似。

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的微服务治理实践：如何对单点异常进行自动摘除的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。