本文將通過(guò)介紹 MSE 微服務(wù)治理在三月的最新功能來(lái)告訴您答案。文章主要分為三部分，首先是 MSE 微服務(wù)治理的簡(jiǎn)介，然后是 MSE 全面消除變更態(tài)風(fēng)險(xiǎn)的回顧 ，最后是如何借助 MSE 微服務(wù)治理輕松應(yīng)對(duì)線上偶發(fā)異常。

MSE 微服務(wù)治理簡(jiǎn)介

首先看一下微服架構(gòu)的總覽，相信讀者朋友們對(duì)微服務(wù)都不陌生。在 JAVA 中比較主流的微服務(wù)框架就是 Dubbo 和 Spring Cloud，同時(shí)現(xiàn)在也有很多公司采用 Go、Rust 這些語(yǔ)言去構(gòu)建自己的微服務(wù)。下圖中淺綠色的這一部分都是純開源的內(nèi)容，除了微服務(wù)框架本身外，還包含了服務(wù)注冊(cè)發(fā)現(xiàn)、服務(wù)配置中心、負(fù)載均衡等一系列的組件。

大家也發(fā)現(xiàn)，在微服務(wù)實(shí)施的過(guò)程中，隨著微服務(wù)的增多、調(diào)用鏈路的復(fù)雜化，出問(wèn)題和故障的可能性都在增加，問(wèn)題定位的難度也成倍上升。比如說(shuō)在可觀測(cè)領(lǐng)域，需要使用到應(yīng)用監(jiān)控、鏈路追蹤、日志管理等功能，才能放心地將應(yīng)用部署到線上，以免出現(xiàn)問(wèn)題無(wú)法定位。

更進(jìn)一步，微服務(wù)本身更需要引入微服務(wù)治理。在開發(fā)態(tài)，需要通過(guò)服務(wù) mock、服務(wù)測(cè)試、服務(wù)元數(shù)據(jù)等治理功能去保證微服務(wù)的快速迭代；在變更態(tài)，需要借助無(wú)損上下線和全鏈路灰度功能去保證發(fā)布時(shí)的穩(wěn)定性，以及業(yè)務(wù)的連續(xù)性；在運(yùn)行態(tài)，微服務(wù)可能遇到各式各樣的偶發(fā)異常，需要借助治理功能去實(shí)現(xiàn)流量的自愈，保證我們的業(yè)務(wù)穩(wěn)定、流暢地運(yùn)行。很難想象一個(gè)線上的微服務(wù)應(yīng)用沒(méi)有治理是個(gè)什么場(chǎng)景，可以說(shuō)是無(wú)治理、不生產(chǎn)。

隨著使用微服務(wù)架構(gòu)的公司越來(lái)越多，大家也都意識(shí)到微服務(wù)治理非常重要，但是在實(shí)施微服務(wù)治理的過(guò)程中，大家還是遇到了比較多的痛點(diǎn)和難點(diǎn)。我們總結(jié)了一下，企業(yè)在實(shí)施微服務(wù)的過(guò)程中遇到的三類問(wèn)題，分別是穩(wěn)定、成本和安全。

1. 首先是穩(wěn)定的問(wèn)題

1. 微服務(wù)在發(fā)布的過(guò)程中特別容易出現(xiàn)問(wèn)題，每次發(fā)布都得熬夜以避開業(yè)務(wù)高峰期，而且還是免不了出現(xiàn)業(yè)務(wù)中斷。

2. 當(dāng)遇到難得的業(yè)務(wù)爆發(fā)式增長(zhǎng)時(shí)，應(yīng)用因?yàn)闊o(wú)法承載流量高峰導(dǎo)致整體宕機(jī)，錯(cuò)失了業(yè)務(wù)爆發(fā)的機(jī)會(huì)。

3. 在出現(xiàn)一些偶發(fā)異常的時(shí)候，應(yīng)用沒(méi)有完善的防護(hù)和治愈手段，可能會(huì)因?yàn)榕及l(fā)的小異常，不斷的滾雪球，最終去拖垮我們整個(gè)集群和整個(gè)服務(wù)。

4. 遇到偶發(fā)問(wèn)題的無(wú)法準(zhǔn)確定位和徹底解決，只能重啟方式規(guī)避，從而使得我們微服務(wù)的隱患越積越多，風(fēng)險(xiǎn)越來(lái)越大。

2. 第二是成本的問(wèn)題

1. 微服務(wù)治理功能在開源沒(méi)有完善的解決方案，這個(gè)時(shí)候可能是需要去招聘大量精通微服務(wù)的人才，才能自建一套微服務(wù)治理體系，但是也無(wú)法覆蓋完整的治理場(chǎng)景。這會(huì)使得人力成本非常高。

2. 引入了微服務(wù)之后，基本都會(huì)有一些敏捷開發(fā)、快速迭代的訴求。在這個(gè)過(guò)程中，需要維護(hù)多套環(huán)境以維持一個(gè)并行開發(fā)迭代的需求，這會(huì)使得機(jī)器成本非常高。

3. 傳統(tǒng)的開發(fā)模式，當(dāng)需要引入一個(gè)治理功能升級(jí)的時(shí)候，需要先升級(jí)基礎(chǔ)組件，再對(duì)所有的應(yīng)用進(jìn)行代碼改造，依次發(fā)布才能完成升級(jí)，改造的周期長(zhǎng)、風(fēng)險(xiǎn)大。這會(huì)使得時(shí)間成本非常高。

3. 最后是安全的問(wèn)題

1. 經(jīng)常會(huì)有一些開源的框架的安全漏洞被暴露出來(lái)，這個(gè)時(shí)候需要對(duì)依賴進(jìn)行升級(jí)以修復(fù) Bug，走一次完整的發(fā)布才能實(shí)現(xiàn)，成本高，時(shí)效性差。

2. 零信任安全的解決方案正在被越來(lái)越多的公司采用，去保障整體的業(yè)務(wù)安全。不僅是在流量入口層對(duì)業(yè)務(wù)進(jìn)行安全的保障，在應(yīng)用間的內(nèi)部調(diào)用也需要有完整的鑒權(quán)和保障機(jī)制。

那么 MSE微服務(wù)治理是怎么去解決這三個(gè)問(wèn)題的？

MSE 的微服務(wù)治理基于開源的 OpenSergo 標(biāo)準(zhǔn)實(shí)現(xiàn)了無(wú)侵入的微服務(wù)治理。對(duì)于使用者來(lái)說(shuō)升級(jí)成本是零，業(yè)務(wù)是完全無(wú)侵入感知的。

目前已經(jīng)可以做到是五分鐘接入，半小時(shí)內(nèi)就學(xué)會(huì)完整的使用，保障微服務(wù)應(yīng)用在變更態(tài)和運(yùn)行時(shí)的穩(wěn)定性。因?yàn)?OpenSergo 是全面開源標(biāo)準(zhǔn)，不會(huì)有任何的廠商綁定的問(wèn)題。

從上圖中可以看出，微服務(wù)應(yīng)用可以通過(guò) Java Agent 或 Sidecar 的方式接入MSE 微服務(wù)治理。在接入治理后，可以通過(guò) MSE 微服引擎的控制面配置治理規(guī)則的配置。應(yīng)用收到規(guī)則之后會(huì)實(shí)時(shí)生效，及時(shí)地保護(hù)應(yīng)用。

全面消除變更態(tài)風(fēng)險(xiǎn)的回顧

現(xiàn)在來(lái)回顧一下，變更態(tài)存在哪些問(wèn)題，以及 MSE 是如何全面消除變更態(tài)風(fēng)險(xiǎn)的。

首先問(wèn)大家一個(gè)問(wèn)題，當(dāng)你的代碼沒(méi)有問(wèn)題的時(shí)候，是不是在發(fā)布的過(guò)程中就一定不會(huì)影響到業(yè)務(wù)？答案其實(shí)是否定的，因?yàn)檫@個(gè)時(shí)候可能會(huì)遇到無(wú)損上下線的問(wèn)題。

為什么會(huì)出現(xiàn)無(wú)損下線問(wèn)題？第一個(gè)原因是服務(wù)消費(fèi)者無(wú)法實(shí)時(shí)感知到服務(wù)提供者已經(jīng)下線了，仍舊會(huì)去調(diào)用一個(gè)已經(jīng)下線的地址，從而出現(xiàn)一個(gè)影響業(yè)務(wù)的報(bào)錯(cuò)。同時(shí)服務(wù)提供者也可能會(huì)在請(qǐng)求處理到一半的時(shí)候就直接停止了，從而導(dǎo)致業(yè)務(wù)報(bào)錯(cuò)，甚至出現(xiàn)數(shù)據(jù)不一致的問(wèn)題。

為什么會(huì)出現(xiàn)無(wú)損上線的問(wèn)題？一個(gè)新啟動(dòng)的節(jié)點(diǎn)，有可能在還沒(méi)完全啟動(dòng)前就注冊(cè)到注冊(cè)中心了，進(jìn)而導(dǎo)致這時(shí)候過(guò)來(lái)的流量無(wú)法被正確處理導(dǎo)致報(bào)錯(cuò)；另一種情況是，雖然應(yīng)用啟動(dòng)完成了，但是還沒(méi)有處理大流量的能力，可能直接被大流量壓垮，需要先進(jìn)行預(yù)熱，才能處理大流量的請(qǐng)求。除此之外，目前 K8s 的普及率已經(jīng)非常高了，如果微服務(wù)的生命周期沒(méi)有與 K8s 生命周期做一個(gè)的 readiness 對(duì)齊的話，發(fā)布過(guò)程也容易出現(xiàn)無(wú)損上線問(wèn)題。

當(dāng)然更普遍的情況是，誰(shuí)都不敢拍著胸脯保證我的代碼沒(méi)有問(wèn)題。如果沒(méi)有穩(wěn)定的灰度機(jī)制，對(duì)只有兩個(gè)節(jié)點(diǎn)的應(yīng)用來(lái)說(shuō)，發(fā)布一臺(tái)就會(huì)影響 50% 的業(yè)務(wù)。發(fā)現(xiàn) bug 之后需要回顧，可怕的是回滾的速度還非常慢，甚至回滾的時(shí)候還出現(xiàn)了更大的問(wèn)題。

那么 MSE 是如何去解決這兩個(gè)問(wèn)題的。首先我們看一下這個(gè)無(wú)損下線的這個(gè)問(wèn)題。對(duì)于一個(gè)已經(jīng)接入了MSE 微服務(wù)治理的應(yīng)用，無(wú)損下線功能是默認(rèn)開啟的，我們可以在 MSE 的控制臺(tái)中看到無(wú)損下線的完整的流程。

1. 首先在無(wú)損下線開始時(shí)，sc-B 這個(gè)服務(wù)的提供者 10.0.0.242 會(huì)提前向注冊(cè)中心發(fā)起注銷動(dòng)作。

2. 注銷之后，10.0.0.242 會(huì)去主動(dòng)去通知它的服務(wù)消費(fèi)者當(dāng)前節(jié)點(diǎn)已下線。上圖中的例子，服務(wù) sc-B 的消費(fèi)者 10.0.0.248 和 10.0.0.220 這兩個(gè)消費(fèi)者收到了下線通知。

3. 10.0.0.248 和 10.0.0.220 在收到下線通知后，都會(huì)把 10.0.0.242 的地址維護(hù)在 offlineServerIp 列表中，并且找到 sc-B 對(duì)應(yīng)的調(diào)用列表，在調(diào)用列表中移除 10.0.0.242 這個(gè) IP

4. 同時(shí)，10.0.0.242 在停止的過(guò)程中會(huì)做一個(gè)自適應(yīng)的等待，確保所有在途請(qǐng)求都處理完畢才停止應(yīng)用。

我們?cè)倏匆幌逻@個(gè)無(wú)損上線的這個(gè)問(wèn)題。對(duì)于一個(gè)已經(jīng)接入了 MSE 微服務(wù)治理的應(yīng)用，可以通過(guò)控制臺(tái)開啟無(wú)損上線功能，開啟后，我們可以在 MSE 的控制臺(tái)中看到無(wú)損上線的完整的流程。

從上圖中我們可以看到，應(yīng)用配置的延遲注冊(cè)時(shí)間是 10S，預(yù)熱時(shí)間是 120S，預(yù)熱曲線是擬合二次曲線。根據(jù) QPS 數(shù)據(jù)可以看到，應(yīng)用在注冊(cè)完成之后才有流量進(jìn)入，同時(shí)在預(yù)熱開始后 120S 內(nèi)，流量是一個(gè)緩慢上升的過(guò)程，直到預(yù)熱結(jié)束之后，流量才開始進(jìn)入平穩(wěn)的狀態(tài)。

看完了在代碼沒(méi)問(wèn)題的情況下如何保證變更態(tài)的穩(wěn)定性，我們?cè)诳纯串?dāng)代碼可能存在問(wèn)題的時(shí)候，如何保障變更態(tài)的穩(wěn)定性。

拿一個(gè)簡(jiǎn)單的架構(gòu)作為例子，微服務(wù)的整體調(diào)用鏈路是網(wǎng)關(guān)調(diào)用 A，A 調(diào)用 B ，B 再調(diào)用 C 這么一個(gè)鏈路。某次迭代中，有個(gè)特性的修改需要同時(shí)修改 A 和 C 這兩個(gè)應(yīng)用。

在發(fā)布的過(guò)程中，需要通過(guò)全鏈路灰度發(fā)布來(lái)驗(yàn)證 A 的新版本和 C 的新版本的正確性。假設(shè) x-user-id 為 120 的用戶是我們一個(gè)不那么重要的用戶。那么我們可以配置只有 x-user-id 為 120 的這一個(gè)用戶，他才會(huì)訪問(wèn)新版本。

在具體的調(diào)用中，網(wǎng)關(guān)會(huì)先訪問(wèn) A 的灰度版本，A 在調(diào)用 B 的時(shí)候發(fā)現(xiàn) B 沒(méi)有一個(gè)灰度的版本，所以只是 fall back 到 B 的基線版本。但是 B 在調(diào)用 C 的時(shí)候，還是記住了 x-user-id 為 120 的流量屬于一個(gè)灰度流量。同時(shí)又發(fā)現(xiàn) C 存在灰度節(jié)點(diǎn)，流量還是會(huì)重新回到 C 的灰度節(jié)點(diǎn)。

如上圖所示，可以通過(guò) MSE 全鏈路灰度控制新版本的影響面。將參與到全鏈路灰度的應(yīng)用添加到泳道組后，配置如上圖所示的規(guī)則，只有 x-user-id 為 120 的這個(gè)用戶他才會(huì)被路由到新版本。也就是說(shuō)即使這個(gè)新版本問(wèn)題再大，那只是這一個(gè)用戶會(huì)受到影響。同時(shí)做一個(gè)回滾的動(dòng)作也是非常方便的，只需要把灰度規(guī)則關(guān)閉或者刪除即可，就不會(huì)有流量被路由到新版版本。經(jīng)過(guò)灰度的謹(jǐn)慎驗(yàn)證后，可以視情況繼續(xù)擴(kuò)大灰度的影響面，或者直接全量發(fā)布，從而實(shí)現(xiàn)安全的版本變更。

剛才我們也提到過(guò)，全鏈路灰度其實(shí)是一個(gè)非常復(fù)雜的過(guò)程，除了 RPC 的灰度外，還包含了前端灰度、消息灰度、異步任務(wù)灰度、數(shù)據(jù)庫(kù)灰度等場(chǎng)景，這些場(chǎng)景 MSE 都做了一些探索和支持。以消息灰度為例， MSE 已經(jīng)完整地支持了 RocketMQ 的灰度，實(shí)現(xiàn)了全鏈路灰度的閉環(huán)，是一個(gè)久經(jīng)生產(chǎn)考驗(yàn)的全鏈路灰度。

以上是 MSE 全面消除變更態(tài)風(fēng)險(xiǎn)的回顧。

如何輕松應(yīng)對(duì)偶發(fā)異常

在回顧了一下 MSE 是如何做到全面消除變更態(tài)風(fēng)險(xiǎn)之后。我們來(lái)看一下 MSE 微服務(wù)治理在三月份新上線的這些功能，如何幫助大家輕松應(yīng)對(duì)偶發(fā)異常。

我們做了大致的總結(jié)和歸類，將偶發(fā)異常的情況分為了兩部分：異常流量和不穩(wěn)定服務(wù)依賴。

接下來(lái)我們將面向這兩個(gè)大類下五個(gè)小類的場(chǎng)景，來(lái)闡述如何借助 MSE 微服務(wù)治理三月份發(fā)布的新功能去解決這些偶發(fā)異常的。

接口限流

首先我們看一下激增流量這一塊。拿一個(gè)具體的場(chǎng)景來(lái)說(shuō)，業(yè)務(wù)方精心準(zhǔn)備了一個(gè)大促活動(dòng)，活動(dòng)非?；鸨诨顒?dòng)開始的一瞬間，遠(yuǎn)遠(yuǎn)超過(guò)系統(tǒng)承載預(yù)期的用戶進(jìn)來(lái)?yè)屬?gòu)秒殺，如果沒(méi)有微服務(wù)治理能力，服務(wù)可能由于扛不住流量直接被打掛，甚至在重啟的過(guò)程還不斷被打掛。精心準(zhǔn)備的活動(dòng)由于系統(tǒng)宕機(jī)導(dǎo)致效果非常差，在遇到難得的業(yè)務(wù)爆發(fā)式增長(zhǎng)機(jī)會(huì)時(shí)，卻因?yàn)閼?yīng)用的宕機(jī)錯(cuò)失了爆發(fā)的機(jī)會(huì)。

在這個(gè)場(chǎng)景下，可以借助 MSE 的流控能力對(duì)關(guān)鍵接口配置流控規(guī)則保護(hù)應(yīng)用整體的可用性。只讓容量范圍內(nèi)的請(qǐng)求被處理，超出容量范圍外的請(qǐng)求被拒絕，相當(dāng)于這是一個(gè)安全氣囊的作用。

如上圖所示， /a 這個(gè)接口是我們應(yīng)用的關(guān)鍵接口，我們識(shí)別到單機(jī)閾值是 200 后，配置上流控防護(hù)規(guī)則，使得這個(gè)關(guān)鍵接口最大的通過(guò) QPS 是 200，超出閾值的流量會(huì)直接被拒絕，從而保護(hù)應(yīng)用整體的可用性。

精準(zhǔn)限流

接下來(lái)我們?cè)倏匆幌戮珳?zhǔn)限流，拿一個(gè)具體的場(chǎng)景來(lái)說(shuō)，由于在配置優(yōu)惠活動(dòng)的時(shí)候沒(méi)有配置好最大次數(shù)，或者存在規(guī)則上的漏洞。在被黑產(chǎn)發(fā)現(xiàn)后不斷地進(jìn)行在刷單，業(yè)務(wù)損失嚴(yán)重。在這個(gè)場(chǎng)景下，我們可以借助 MSE 的精準(zhǔn)限流能力實(shí)現(xiàn)防黑產(chǎn)刷單。

MSE 的精準(zhǔn)限流可以在 API 的維度基礎(chǔ)上，基于流量的特征值來(lái)進(jìn)行限流，比如根據(jù)調(diào)用端的 IP，參數(shù)中的某一個(gè)參數(shù)的值，或者說(shuō) HTTP 請(qǐng)求里 header 的特征等。

如上圖所示，當(dāng)我們識(shí)別到黑產(chǎn)用戶的特征之后，可以根據(jù) header 里面 key 為 user-id 的值來(lái)進(jìn)行精準(zhǔn)的業(yè)務(wù)限流，這里配置的規(guī)則為每天只能通過(guò)一次，也就意味著黑產(chǎn)流量被識(shí)別到之后，一天內(nèi)超出一次的調(diào)用都會(huì)被拒絕，這樣就能有效地防止黑產(chǎn)刷單保護(hù)業(yè)務(wù)。

并發(fā)隔離

第三部分是并發(fā)隔離，拿一個(gè)具體的場(chǎng)景來(lái)說(shuō)，假設(shè)我們的應(yīng)用依賴了一個(gè)第三方的支付渠道，但是因?yàn)榍辣旧淼脑虺霈F(xiàn)了大量的慢調(diào)用，進(jìn)而導(dǎo)致了應(yīng)用全部的線程池都被調(diào)用該支付渠道的調(diào)用占滿了，沒(méi)有線程去處理其他正常的業(yè)務(wù)流程。而且這個(gè)第三方的支付其實(shí)只是我們其中的一個(gè)支付渠道。我們其他的支付渠道都是正常的。

MSE 可以對(duì)應(yīng)用作為客戶端的流量進(jìn)行并發(fā)隔離，限制同時(shí)調(diào)用這個(gè)第三方支付渠道的最大并發(fā)數(shù)，從而留下充足的資源來(lái)處理正常的業(yè)務(wù)流量。

如上圖所示，我們配置了并發(fā)數(shù)閾值是 5，每個(gè)應(yīng)用節(jié)點(diǎn)最多同時(shí)存在 5個(gè)并發(fā)去調(diào)用第三方支付服務(wù)，當(dāng)調(diào)用數(shù)超過(guò)了 5 的時(shí)候，請(qǐng)求在發(fā)起前就會(huì)直接被拒絕。通過(guò)并發(fā)隔離，把不穩(wěn)定的支付渠道隔離到有限的影響面，而不會(huì)擠占其他正常支付渠道的資源，這樣來(lái)保障我們一個(gè)業(yè)務(wù)的穩(wěn)定性。

SQL 防護(hù)

第四部分是 SQL 防護(hù)，拿一個(gè)具體的場(chǎng)景來(lái)說(shuō)，應(yīng)用更新后出現(xiàn)了慢 SQL 的語(yǔ)句，處理的時(shí)間比較長(zhǎng)的，這個(gè)時(shí)候需要快速定位慢 SQL ，然后防止我們這個(gè)應(yīng)用去被這個(gè)慢 SQL 拖垮了?；蛘咴陧?xiàng)目的初期可能沒(méi)有對(duì)這個(gè) SQL 的性能做一個(gè)很好的考量，然后隨著業(yè)務(wù)的發(fā)展，業(yè)務(wù)量級(jí)的增加，然后導(dǎo)致線上遺留老 SQL 逐漸腐化，成為了一個(gè)慢 SQL。

MSE 的數(shù)據(jù)庫(kù)治理功能，可以自動(dòng)統(tǒng)計(jì)應(yīng)用的 SQL語(yǔ)句，以及 SQL 的 QPS、平均耗時(shí) 和最大并發(fā)等數(shù)據(jù)，并針對(duì)于 SQL 進(jìn)行一個(gè)防護(hù)。

如上圖所示，在平均耗時(shí)中找到慢 SQL，點(diǎn)擊右邊的 SQL 防護(hù)按鈕，通過(guò)配置并發(fā)隔離規(guī)則來(lái)進(jìn)行保護(hù)應(yīng)用不被慢 SQL 拖垮。

服務(wù)熔斷

最后我們?cè)賮?lái)看一下服務(wù)熔斷。拿一個(gè)具體的場(chǎng)景來(lái)說(shuō)，在業(yè)務(wù)高峰期查詢積分服務(wù)達(dá)到性能瓶頸，導(dǎo)致響應(yīng)速度慢、報(bào)錯(cuò)增多。但是它并不是一個(gè)關(guān)鍵的服務(wù)，這時(shí)不能因?yàn)闊o(wú)法查詢積分余額而導(dǎo)致整個(gè)流程都無(wú)法進(jìn)行。正確的邏輯應(yīng)該是積分余額暫時(shí)不顯示，但是除此之外其他主流程都能正常完成。

MSE 的服務(wù)熔斷功能，可以很好地解決上述的問(wèn)題。MSE 支持通過(guò)慢調(diào)用的比例，或者錯(cuò)誤數(shù)去衡量一個(gè)服務(wù)是否處于正常狀態(tài)，當(dāng)識(shí)別到服務(wù)已經(jīng)不正常的時(shí)候就自動(dòng)觸發(fā)熔斷。熔斷后消費(fèi)者不會(huì)再去調(diào)用出問(wèn)題的服務(wù)了，而是直接返回 Mock 值。

如上圖所示，配置當(dāng)異常比例超過(guò) 80% 的時(shí)候自動(dòng)觸發(fā)熔斷，不再去調(diào)用不正常的服務(wù)。一方面消費(fèi)者不再去調(diào)用不正常的弱依賴服務(wù)，不會(huì)因?yàn)槿跻蕾嚨膯?wèn)題導(dǎo)致主流程不正常。另一方面，熔斷也給了不穩(wěn)定的下游一些喘息的時(shí)間，讓它有機(jī)會(huì)去恢復(fù)。

我們最后再來(lái)總結(jié)一下 MSE 微服治理是如何助您輕松應(yīng)對(duì)線上偶發(fā)異常的，針對(duì)我們剛才總結(jié)的這五類場(chǎng)景：

1. 當(dāng)遇到激增流量的時(shí)候，我們應(yīng)該使用接口限流。

2. 當(dāng)我們遇到黑產(chǎn)刷單等問(wèn)題的時(shí)候，我們應(yīng)該使用精準(zhǔn)限流。

3. 當(dāng)?shù)谌椒?wù)不響應(yīng)，占滿線程池的時(shí)候，我們應(yīng)該使用并發(fā)隔離。

4. 當(dāng)應(yīng)用存在慢 SQL 的時(shí)候，我們應(yīng)該使用 SQL 防護(hù)。

5. 當(dāng)應(yīng)用的弱依賴出現(xiàn)異常，影響我們核心業(yè)務(wù)流程的時(shí)候，我們應(yīng)該使用服務(wù)熔斷。

通過(guò)這五個(gè)功能，MSE 微服務(wù)治理可以助您去輕松去應(yīng)對(duì)上述場(chǎng)景的一些偶發(fā)異常，后續(xù) MSE 也會(huì)持續(xù)不斷地去探索和拓展更多場(chǎng)景，更全面地保障您應(yīng)用的運(yùn)行時(shí)的穩(wěn)定性。

結(jié)語(yǔ)

MSE 微服務(wù)治理致力于幫用戶低成本構(gòu)建安全、穩(wěn)定的微服務(wù)。由于篇幅原因，更多的功能就不在這里給大家詳細(xì)介紹了，關(guān)于 MSE 更多的詳情，讀者可以通過(guò)查看?MSE 幫助文檔的了解詳情。