[[404368]]

本文轉(zhuǎn)載自微信公眾號「無敵碼農(nóng)」，作者無敵碼農(nóng) 。轉(zhuǎn)載本文請聯(lián)系無敵碼農(nóng)公眾號。

在微服務(wù)架構(gòu)中，隨著服務(wù)調(diào)用鏈路變長，為了防止出現(xiàn)級聯(lián)雪崩，在微服務(wù)治理體系中，熔斷、限流作為服務(wù)自我保護(hù)的重要機(jī)制，是確保微服務(wù)架構(gòu)穩(wěn)定運(yùn)行的關(guān)鍵手段之一。

那么什么是熔斷、限流?在傳統(tǒng)Spring Cloud微服務(wù)、以及新一代Service Mesh微服務(wù)架構(gòu)中，它們分別又是怎么實現(xiàn)的?本文將對此進(jìn)行闡述!

服務(wù)熔斷、限流概述

先理解下熔斷、限流的基本概念以及它們的應(yīng)用場景。說起熔斷這個詞，大家印象深刻的可能是股市交易熔斷、或者電路保險絲斷開這樣的場景；而微服務(wù)中的熔斷本質(zhì)上和這些場景中所描述的理念是一致的。都是為了在極端情況下，保證系統(tǒng)正常運(yùn)行而設(shè)計的一種自我保護(hù)機(jī)制。

熔斷的基本邏輯就是隔離故障。在微服務(wù)架構(gòu)盛行的今天，服務(wù)之間的調(diào)用鏈路相比單體應(yīng)用時代變得更長了，服務(wù)化拆分帶來系統(tǒng)整體能力提升的同時，也增加了服務(wù)級聯(lián)故障出現(xiàn)的概率。例如調(diào)用鏈路“A->B->C->D”，如果服務(wù)D出現(xiàn)問題，那么鏈路上的A、B、C都可能會出現(xiàn)問題，這一點也很好理解，因為出現(xiàn)故障的服務(wù)D，必然會在某個時間段內(nèi)阻塞C->D的調(diào)用請求，并最終蔓延至整個鏈路。而服務(wù)連接資源又是有限的，這種增加的調(diào)用耗時，會逐步消耗掉整個鏈路中所有服務(wù)的可用線程資源，從而成為壓垮整個微服務(wù)體系的幕后黑手。

而為了防止故障范圍的擴(kuò)大，就需要對故障服務(wù)D進(jìn)行隔離，隔離的方式就是服務(wù)C在感知到對D的調(diào)用頻繁出現(xiàn)故障(超時或錯誤)后，主動斷掉對D的連接，直接返回失敗調(diào)用結(jié)果。以此類推，如果微服務(wù)中的所有鏈路都設(shè)置這樣的熔斷機(jī)制，那么就能逐級實現(xiàn)鏈路的分級保護(hù)效果。

熔斷機(jī)制雖然解決不了故障，但卻能在故障發(fā)生時盡量保全非故障鏈路上的服務(wù)接口能被正常訪問，從而將故障范圍控制在局部。當(dāng)然被熔斷的服務(wù)也不會一直處于熔斷狀態(tài)，在熔斷機(jī)制的設(shè)計中還要考慮故障恢復(fù)處理機(jī)制。

說完熔斷，再來說說限流。熔斷的主要目的是隔離故障，而引起故障的原因除了系統(tǒng)本身的問題外，還有一種可能就是請求量達(dá)到了系統(tǒng)處理能力的極限，后續(xù)新進(jìn)入的請求會持續(xù)加重服務(wù)負(fù)載，最終導(dǎo)致資源耗盡，從而引起系統(tǒng)級聯(lián)故障、導(dǎo)致雪崩。而限流的目的就是拒絕多余流量、保證服務(wù)整體負(fù)載始終處于合理水平。

從限流范圍上看，微服務(wù)體系中的每個服務(wù)都可以根據(jù)自身情況設(shè)置合理的限流規(guī)則，例如調(diào)用鏈路“A->B->C->D”，B服務(wù)的承受力是1000QPS，如果超過該閥值，那么超出的請求就會被拒絕，但這也容易引起A對B的熔斷，所以對于微服務(wù)設(shè)置限流規(guī)則的設(shè)置最好還是根據(jù)壓測結(jié)果確定。

在實際場景中，對單個節(jié)點的微服務(wù)分別設(shè)置限流，雖然從邏輯上沒啥毛病，但實際操作起來卻并不容易，這主要是因為限流規(guī)則分散不好統(tǒng)一控制，另外對于單節(jié)點閥值的評估，在全鏈路環(huán)境下并不能得出“1+1=2”的結(jié)果。所以，一般做法是根據(jù)全鏈路壓測結(jié)果，在服務(wù)網(wǎng)關(guān)統(tǒng)一進(jìn)行集群級別的限流處理。

接下來將分別介紹在Spring Cloud傳統(tǒng)微服務(wù)體系，以及新一代Service Mesh微服務(wù)體系中，熔斷、限流的基本實現(xiàn)原理，并重點演示基于Istio的微服務(wù)熔斷、限流邏輯具體實踐!

Spring Cloud微服務(wù)對熔斷/限流的處理

說起Spring Cloud微服務(wù)中的熔斷、限流，最先想到的肯定是Hystrix、Sentinel這樣的技術(shù)組件。關(guān)于這兩種著名的熔斷、限流組件，在筆者早先的文章<>以及<>中都曾詳細(xì)介紹過，細(xì)節(jié)就不再贅述，感興趣的朋友可以翻閱下。這里只從微服務(wù)架構(gòu)的宏觀視角，來對比分析下其與服務(wù)網(wǎng)格(Service Mesh)在架構(gòu)上的區(qū)別。

從本質(zhì)上說Hystrix與Sentinel并無實質(zhì)差別，它們都是以SDK的形式附著在具體微服務(wù)進(jìn)程之上的、實現(xiàn)了熔斷/限流功能的本地工具包。具體示意圖如下：

在Spring Cloud微服務(wù)中，Hystrix、Sentinel等熔斷、限流組件通過嵌入微服務(wù)進(jìn)程，統(tǒng)計微服務(wù)一段時期內(nèi)的入口流量及依賴服務(wù)的錯誤調(diào)用次數(shù)、并根據(jù)組件的所提供功能及規(guī)則配置，來決定是否觸發(fā)限流或熔斷降級邏輯。這樣的過程完全是附著在微服務(wù)進(jìn)程本身完成的，雖然限流/熔斷組件本身也提供了線程池隔離之類資源隔離手段，但從服務(wù)治理的角度來看，這樣的方式顯然還是侵入了業(yè)務(wù)、占用了業(yè)務(wù)系統(tǒng)資源;并且分散于應(yīng)用的規(guī)則配置，也不利于微服務(wù)體系的整體管控。

Service Mesh微服務(wù)熔斷/限流實現(xiàn)

前面簡單概述了Spring Cloud微服務(wù)體系中實現(xiàn)熔斷、限流機(jī)制的基本框架及存在的弊端。接下來將具體分析下同樣的邏輯在Service Mesh微服務(wù)架構(gòu)中是如何實現(xiàn)的?

關(guān)于Service Mesh微服務(wù)架構(gòu)如果你還比較陌生，可以先通過筆者之前的文章<<干貨|如何步入Service Mesh微服務(wù)架構(gòu)時代>><<實戰(zhàn)|Service Mesh微服務(wù)架構(gòu)實現(xiàn)服務(wù)間gRPC通信>>進(jìn)行了解，這兩篇文章從概念到實踐詳細(xì)介紹了基于Istio的Service Mesh微服務(wù)架構(gòu)的具體玩法。本文所依賴的操作環(huán)境及示例代碼均依賴于該文章所演示的案例。

而回到本文的主題，要了解Service Mesh微服務(wù)架構(gòu)中熔斷、限流的實現(xiàn)機(jī)制，還是需要從整體上理解服務(wù)網(wǎng)格實現(xiàn)的基本架構(gòu)，具體如下圖所示：

如上圖所示，Service Mesh架構(gòu)總體上由控制面(Control Plane)、數(shù)據(jù)面(Data Plane)這兩部分組成。其中控制面主要承擔(dān)整個微服務(wù)體系治理信息的集中管控；而數(shù)據(jù)面則負(fù)責(zé)具體執(zhí)行由控制面下發(fā)的各類服務(wù)治理信息及規(guī)則。例如服務(wù)節(jié)點信息的發(fā)現(xiàn)、以及本文所講述的熔斷、限流規(guī)則等都是通過控制面統(tǒng)一下發(fā)至各數(shù)據(jù)面節(jié)點的。

數(shù)據(jù)面就是一個個代理服務(wù)，在Service Mesh體系下每個具體的微服務(wù)實例都會自動創(chuàng)建一個與之對應(yīng)的代理，這個代理服務(wù)就是我們俗稱的邊車(SideCar)。這些代理會主動劫持所代理的微服務(wù)實例的入口流量和出口流量，從而根據(jù)控制面下發(fā)的服務(wù)治理信息實現(xiàn)路由發(fā)現(xiàn)、負(fù)載均衡、熔斷、限流等系列邏輯。

從中可以看出，在Service Mesh微服務(wù)架構(gòu)中，各個具體的微服務(wù)之間不再直接發(fā)生連接，而是轉(zhuǎn)由各自的SideCar代理實現(xiàn)，因此在應(yīng)用形態(tài)上就形成了一組由代理所組成的網(wǎng)狀交互結(jié)構(gòu)，這就是服務(wù)網(wǎng)格名稱的由來。具體如下圖所示：

將微服務(wù)治理邏輯從原先具體的微服務(wù)進(jìn)程中抽離出來，并實現(xiàn)由統(tǒng)一控制面管理、代理數(shù)據(jù)面執(zhí)行的體系結(jié)構(gòu)，這就是Service Mesh微服務(wù)體系與Spring Cloud傳統(tǒng)微服務(wù)體系在架構(gòu)上最大的區(qū)別。

本文所提到的熔斷、限流邏輯，也是在這樣的架構(gòu)模式下實現(xiàn)的。而控制面與數(shù)據(jù)面之間的具體通信則是通過一組被稱為xDS協(xié)議的數(shù)據(jù)交互方式實現(xiàn)。xDS協(xié)議的核心是定義了一套可擴(kuò)展的通用微服務(wù)控制API，這些API不僅可以做到服務(wù)發(fā)現(xiàn)、還可以做到路由發(fā)現(xiàn)，可以說Service Mesh微服務(wù)體系中所有與服務(wù)治理相關(guān)的配置都可以通過xDS所提供的發(fā)現(xiàn)方式來實現(xiàn)，控制面與數(shù)據(jù)面之間正是通過這種全新的方案實現(xiàn)了各類數(shù)據(jù)的獲取、及動態(tài)資源的變更。

而具體來說xDS包含LDS(監(jiān)聽發(fā)現(xiàn)服務(wù))、CDS(集群發(fā)現(xiàn)服務(wù))、EDS(節(jié)點發(fā)現(xiàn)服務(wù))、SDS(密鑰發(fā)現(xiàn)服務(wù))和RDS(路由發(fā)現(xiàn)服務(wù))。xDS中的每種類型都會對應(yīng)一個發(fā)現(xiàn)資源，而本文所要講述的熔斷、限流邏輯則是由RDS(路由發(fā)現(xiàn)服務(wù))實現(xiàn)。由于篇幅的關(guān)系，就不展開講了，感興趣的讀者可以看看官方文檔，大家對此有個印象即可!

Istio服務(wù)網(wǎng)格熔斷、限流實踐

前面從整體架構(gòu)的角度簡單分析了Service Mesh微服務(wù)治理體系的基本原理，接下來將基于Istio并結(jié)合微服務(wù)實戰(zhàn)案例，從實踐角度具體演示如何實現(xiàn)微服務(wù)之間的熔斷、限流配置。以下操作假設(shè)你已經(jīng)在Kubernetes集群安裝了Istio，并正常部署了<<干貨|如何步入Service Mesh微服務(wù)架構(gòu)時代>><<實戰(zhàn)|Service Mesh微服務(wù)架構(gòu)實現(xiàn)服務(wù)間gRPC通信>>所演示的微服務(wù)案例。

Istio無需對代碼進(jìn)行任何更改就可以為應(yīng)用增加熔斷和限流功能。Istio中熔斷和限流在DestinationRule的CRD資源的TrafficPolicy中設(shè)置，通過設(shè)置連接池(connectionPool)實現(xiàn)限流、設(shè)置異常檢測(outlierDetection)實現(xiàn)熔斷。

限流邏輯演示

在Istio中，微服務(wù)的限流主要是通過設(shè)置connectionPool參數(shù)實現(xiàn)。該參數(shù)可以對上游服務(wù)的并發(fā)連接數(shù)和請求數(shù)進(jìn)行限制(適用于TCP和HTTP)，從而實現(xiàn)限流功能。例如要在API服務(wù)層實現(xiàn)限流，鏈路示意圖如下：

在Istio中實現(xiàn)此類限流邏輯，步驟如下：

1)、創(chuàng)建統(tǒng)一管理路由規(guī)則的配置文件(destination-rule-all.yaml)，如:

--- 
apiVersion: networking.istio.io/v1alpha3 
kind: DestinationRule 
metadata: 
  name: micro-api 
spec: 
  host: micro-api 
  trafficPolicy: 
    connectionPool: 
      tcp: 
        maxConnections: 1 
      http: 
        http1MaxPendingRequests: 1 
        maxRequestsPerConnection: 1 
--- 

上述規(guī)則文件定義了針對mico-api服務(wù)的限流規(guī)則，其中maxConnections(最大連接數(shù)為1)、http1MaxPendingRequests(最大等待請求數(shù)為1)，如果連接和并發(fā)請求數(shù)超過1個，那么該服務(wù)就會觸發(fā)限流規(guī)則。

創(chuàng)建規(guī)則資源，命令如下：

$ kubectl apply -f destination-rule-all.yaml  
destinationrule.networking.istio.io/micro-api unchanged 

規(guī)則創(chuàng)建完后可以通過命令查看規(guī)則，命令如下:

$ kubectl get destinationrule micro-api -o yaml 
apiVersion: networking.istio.io/v1beta1 
kind: DestinationRule 
metadata: 
  ... 
spec: 
  host: micro-api 
  trafficPolicy: 
    connectionPool: 
      http: 
        http1MaxPendingRequests: 1 
        maxRequestsPerConnection: 1 
      tcp: 
        maxConnections: 1 

可以看到，規(guī)則資源已經(jīng)成功創(chuàng)建!

2)、部署壓測工具，驗證限流效果

接下來，通過部署Istio提供的壓測工具fortio，模擬調(diào)用微服務(wù)并觸發(fā)限流規(guī)則。部署fortio命令如下：

$ kubectl apply -f samples/httpbin/sample-client/fortio-deploy.yaml 

找到Istio安裝目錄“samples/httpbin/sample-client”后執(zhí)行上述部署命令。

接下來通過fortio工具模擬壓測mico-api服務(wù)接口，命令如下：

#將fortio服務(wù)pod信息寫入系統(tǒng)變量 
$ export FORTIO_POD=$(kubectl get pods -lapp=fortio -o 'jsonpath={.items[0].metadata.name}') 
 
#通過設(shè)置2個線程，并發(fā)調(diào)用20次進(jìn)行壓測 
$ kubectl exec "$FORTIO_POD" -c fortio -- /usr/bin/fortio load -c 2 -qps 0 -n 20 -loglevel Warning -H "Content-Type:application/json" -payload '{"businessId": "51210428001784966", "amount":100, "channel":1}' http://10.211.55.12:31107/api/order/create  

壓測數(shù)據(jù)效果如下：

11:18:54 I logger.go:127> Log level is now 3 Warning (was 2 Info) 
Fortio 1.11.3 running at 0 queries per second, 2->2 procs, for 20 calls: http://10.211.55.12:31107/api/order/create 
Starting at max qps with 2 thread(s) [gomax 2] for exactly 20 calls (10 per thread + 0) 
11:18:54 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503) 
11:18:54 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503) 
11:18:54 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503) 
11:18:54 W http_client.go:693> Parsed non ok code 503 (HTTP/1.1 503) 
Ended after 262.382465ms : 20 calls. qps=76.225 
Aggregated Function Time : count 20 avg 0.025349997 +/- 0.01454 min 0.001397264 max 0.049622545 sum 0.506999934 
# range, mid point, percentile, count 
>= 0.00139726 <= 0.002 , 0.00169863 , 15.00, 3 
> 0.003 <= 0.004 , 0.0035 , 20.00, 1 
> 0.016 <= 0.018 , 0.017 , 25.00, 1 
> 0.018 <= 0.02 , 0.019 , 30.00, 1 
> 0.02 <= 0.025 , 0.0225 , 50.00, 4 
> 0.025 <= 0.03 , 0.0275 , 65.00, 3 
> 0.03 <= 0.035 , 0.0325 , 70.00, 1 
> 0.035 <= 0.04 , 0.0375 , 80.00, 2 
> 0.04 <= 0.045 , 0.0425 , 95.00, 3 
> 0.045 <= 0.0496225 , 0.0473113 , 100.00, 1 
# target 50% 0.025 
# target 75% 0.0375 
# target 90% 0.0433333 
# target 99% 0.048698 
# target 99.9% 0.0495301 
Sockets used: 6 (for perfect keepalive, would be 2) 
Jitter: false 
Code 200 : 16 (80.0 %) 
Code 503 : 4 (20.0 %) 
Response Header Sizes : count 20 avg 148.8 +/- 74.4 min 0 max 186 sum 2976 
Response Body/Total Sizes : count 20 avg 270.8 +/- 2.4 min 266 max 272 sum 5416 
All done 20 calls (plus 0 warmup) 25.350 ms avg, 76.2 qps 

在可以看到20次請求，共成功16次，4次被限流后返回了503。查看istio-proxy狀態(tài)日志，命令如下：

$ kubectl exec "$FORTIO_POD" -c istio-proxy -- pilot-agent request GET stats | grep micro-api | grep pending 
cluster.outbound|19090||micro-api.default.svc.cluster.local.circuit_breakers.default.rq_pending_open: 0 
cluster.outbound|19090||micro-api.default.svc.cluster.local.circuit_breakers.high.rq_pending_open: 0 
cluster.outbound|19090||micro-api.default.svc.cluster.local.upstream_rq_pending_active: 0 
cluster.outbound|19090||micro-api.default.svc.cluster.local.upstream_rq_pending_failure_eject: 0 
cluster.outbound|19090||micro-api.default.svc.cluster.local.upstream_rq_pending_overflow: 0 
cluster.outbound|19090||micro-api.default.svc.cluster.local.upstream_rq_pending_total: 0 

從上述日志可以看出micro-api服務(wù)的限流規(guī)則被觸發(fā)了!

熔斷邏輯演示

熔斷是減少服務(wù)異常、降低服務(wù)延遲的一種設(shè)計模式，如果在一定時間內(nèi)服務(wù)累計發(fā)生錯誤的次數(shù)超過了預(yù)定義閥值，Istio就會將該錯誤的服務(wù)從負(fù)載均衡池移除，當(dāng)超過一段時間后，又會將服務(wù)再移回服務(wù)負(fù)載均衡池。

具體來說Istio引入了異常檢測來完成熔斷功能，通過周期性的動態(tài)異常檢測來確定上游服務(wù)(被調(diào)用方)中的某些實例是否異常，如果發(fā)現(xiàn)異常就將該實例從連接池中隔離出去，這就是異常值檢測。例如對于HTTP服務(wù)，如果API調(diào)用連續(xù)返回5xx錯誤，則在一定時間內(nèi)連接池拒絕此服務(wù);而對于TCP服務(wù)，一個主機(jī)連接超時/失敗次數(shù)達(dá)到一定次數(shù)就認(rèn)為是連接錯誤。

隔離不是永久的，會有一個時間限制。當(dāng)實例被隔離后會被標(biāo)記為不健康，并且不會被加入到負(fù)載均衡池中。具體的隔離時間等于envoy中“outlier_detection.baseEjectionTime”的值乘以實例被隔離的次數(shù)。經(jīng)過規(guī)定的隔離時間后，被隔離的實例將會自動恢復(fù)過來，重新接受調(diào)用方的遠(yuǎn)程調(diào)用。

回到熔斷演示案例，假設(shè)micro-pay服務(wù)不穩(wěn)定，micro-order服務(wù)要實現(xiàn)對該服務(wù)的熔斷策略，鏈路示意圖如下：

與限流配置類似，Istio的熔斷邏輯也是基于“DestinationRule”資源。針對micro-pay微服務(wù)的熔斷規(guī)則配置如下(可在destination-rule-all.yaml文件增加配置)：

--- 
 
apiVersion: networking.istio.io/v1alpha3 
kind: DestinationRule 
metadata: 
  name: micro-pay 
spec: 
  host: micro-pay 
  trafficPolicy: 
    #限流策略 
    connectionPool: 
      tcp: 
        maxConnections: 1 
      http: 
        #http2MaxRequests: 1 
        http1MaxPendingRequests: 1 
        maxRequestsPerConnection: 1 
    #熔斷策略 
    outlierDetection: 
      consecutive5xxErrors: 1 
      interval: 1s 
      baseEjectionTime: 3m 
      maxEjectionPercent: 100 
--- 

如上配置，為了演示micro-pay的報錯情況，這里也針對該微服務(wù)配置了限流規(guī)則。而熔斷策略配置的意思是：“每1秒鐘(interval)掃描一次上游主機(jī)(mico-pay)實例的情況，連續(xù)失敗1次返回5xx碼(consecutive5xxErrors)的所有實例，將會被移除連接池3分鐘(baseEjectionTime)”。

應(yīng)用該規(guī)則，命令如下：

$ kubectl apply -f destination-rule-all.yaml  

之后可通過壓測工具(與限流方式類似)，測試觸發(fā)熔斷規(guī)則的情況。具體查看方式如下：

# kubectl exec -it $FORTIO_POD  -c istio-proxy  -- sh -c 'curl localhost:15000/stats' | grep micro-pay | grep outlier 

如觸發(fā)成功，則可以查看到的信息如下：

cluster.outbound|18888||micro-pay.default.svc.cluster.local.outlier_detection.ejections_active: 1 
cluster.outbound|18888||micro-pay.default.svc.cluster.local.outlier_detection.ejections_consecutive_5xx: 0 
cluster.outbound|18888||micro-pay.default.svc.cluster.local.outlier_detection.ejections_detected_consecutive_5xx: 2 
cluster.outbound|18888||micro-pay.default.svc.cluster.local.outlier_detection.ejections_detected_consecutive_gateway_failure: 0 
cluster.outbound|18888||micro-pay.default.svc.cluster.local.outlier_detection.ejections_detected_consecutive_local_origin_failure: 0 
cluster.outbound|18888||micro-pay.default.svc.cluster.local.outlier_detection.ejections_detected_failure_percentage: 0 
cluster.outbound|18888||micro-pay.default.svc.cluster.local.outlier_detection.ejections_detected_local_origin_failure_percentage: 0 
cluster.outbound|18888||micro-pay.default.svc.cluster.local.outlier_detection.ejections_detected_local_origin_success_rate: 0 
cluster.outbound|18888||micro-pay.default.svc.cluster.local.outlier_detection.ejections_detected_success_rate: 0 
cluster.outbound|18888||micro-pay.default.svc.cluster.local.outlier_detection.ejections_enforced_consecutive_5xx: 0 
cluster.outbound|18888||micro-pay.default.svc.cluster.local.outlier_detection.ejections_enforced_consecutive_gateway_failure: 0 
cluster.outbound|18888||micro-pay.default.svc.cluster.local.outlier_detection.ejections_enforced_consecutive_local_origin_failure: 0 
cluster.outbound|18888||micro-pay.default.svc.cluster.local.outlier_detection.ejections_enforced_failure_percentage: 0 
cluster.outbound|18888||micro-pay.default.svc.cluster.local.outlier_detection.ejections_enforced_local_origin_failure_percentage: 0 
cluster.outbound|18888||micro-pay.default.svc.cluster.local.outlier_detection.ejections_enforced_local_origin_success_rate: 0 
cluster.outbound|18888||micro-pay.default.svc.cluster.local.outlier_detection.ejections_enforced_success_rate: 0 
cluster.outbound|18888||micro-pay.default.svc.cluster.local.outlier_detection.ejections_enforced_total: 1 
cluster.outbound|18888||micro-pay.default.svc.cluster.local.outlier_detection.ejections_overflow: 0 
cluster.outbound|18888||micro-pay.default.svc.cluster.local.outlier_detection.ejections_success_rate: 0 
cluster.outbound|18888||micro-pay.default.svc.cluster.local.outlier_detection.ejections_total: 0 

具體的觸發(fā)需要模擬上游服務(wù)失敗的情況，可以通過編寫錯誤代碼的方式進(jìn)行模擬!

后記 

本文從原理到實踐比較詳細(xì)地介紹了以Istio為代表的Service Mesh微服務(wù)架構(gòu)實現(xiàn)熔斷、限流的基本方法。希望本文可以幫助各位老鐵進(jìn)一步理解服務(wù)網(wǎng)格的架構(gòu)內(nèi)涵，并打開大家學(xué)習(xí)Service Mesh微服務(wù)架構(gòu)的大門!