[[327280]]

前言

隨著微服務(wù)的流行，越來越多公司使用了微服務(wù)框架，微服務(wù)以其高內(nèi)聚、低耦合等特性，提供了更好的容錯(cuò)性，也更適應(yīng)業(yè)務(wù)的快速迭代，為開發(fā)人員帶來了很多的便利性。但是隨著業(yè)務(wù)的發(fā)展，微服務(wù)拆分越來越復(fù)雜，微服務(wù)的治理也成了一個(gè)比較令人頭疼的問題，我相信下面這些場(chǎng)景大家或多或少都遇到過。

場(chǎng)景一：發(fā)布是天大的事情，每一次的發(fā)布，都會(huì)出現(xiàn)執(zhí)行到一半的請(qǐng)求中斷掉，上游繼續(xù)調(diào)用已經(jīng)下線的節(jié)點(diǎn)導(dǎo)致報(bào)錯(cuò)的現(xiàn)象。發(fā)布時(shí)收到各種報(bào)錯(cuò)，同時(shí)還影響用戶的體驗(yàn)，發(fā)布后又需要修復(fù)執(zhí)行到一半的臟數(shù)據(jù)。

上述場(chǎng)景還是在新版本沒有任何問題的情況下，如果新版本有問題，則會(huì)導(dǎo)致大量業(yè)務(wù)直接請(qǐng)求到有問題的新版本，輕則修復(fù)數(shù)據(jù)，重則嚴(yán)重影響用戶體驗(yàn)，甚至產(chǎn)生資損。最后不得不每次發(fā)版都安排在凌晨?jī)扇c(diǎn)發(fā)布，心驚膽顫，睡眠不足，苦不可言。

場(chǎng)景二：大半夜某個(gè)服務(wù)節(jié)點(diǎn)出現(xiàn)異常，上游仍舊不斷地調(diào)用，出現(xiàn)很多異常和各種報(bào)警短信。被報(bào)警吵醒后，想直接在線上修復(fù)，有點(diǎn)難，想保留現(xiàn)場(chǎng)又害怕拖垮整個(gè)應(yīng)用，只好先重啟為上。

但是這只是治標(biāo)不治本的方式，因?yàn)楹茈y復(fù)現(xiàn)從而無法有效定位，可能明天又被吵醒，繼續(xù)重啟。上述場(chǎng)景還是建立在報(bào)警系統(tǒng)比較完善的情況下，如果沒有完善的報(bào)警系統(tǒng)，嚴(yán)重情況可能整個(gè)業(yè)務(wù)系統(tǒng)都被單機(jī)異常拖垮。

場(chǎng)景三：公司業(yè)務(wù)壯大了，部門組織變復(fù)雜后，微服務(wù)模塊越來越多。我不清楚發(fā)布的服務(wù)到底被誰調(diào)用了，所以我不知道能否安全地下線一個(gè)服務(wù)。我這個(gè)應(yīng)用的這個(gè)接口是個(gè)敏感接口，我只希望得到我授權(quán)的應(yīng)用才能調(diào)用，而不是直接從服務(wù)注冊(cè)中心得到我的地址就能直接調(diào)用，但是目前好像還做不到。

以上三個(gè)場(chǎng)景確實(shí)是使用微服務(wù)之后帶來的痛點(diǎn)，這時(shí)候有個(gè)人告訴你，這些問題，我都知道怎么搞定，我有著豐富的經(jīng)驗(yàn)，知道怎么解決，你肯定很開心。

然后高薪請(qǐng)進(jìn)來了，確實(shí)不錯(cuò)，各種架構(gòu)圖、框架原理，框架修改點(diǎn)都非常清晰而且功能確實(shí)完美。最后評(píng)估對(duì)當(dāng)前系統(tǒng)的修改成本，需要搭建三套中間件服務(wù)端，增加 4 個(gè)中間件依賴，修改幾萬行代碼和配置。

“打擾了，還是業(yè)務(wù)重要，產(chǎn)品經(jīng)理給的需求還沒完成呢，剛剛說的場(chǎng)景也沒那么痛苦，不就幾個(gè)小問題嘛，真的沒事。”

這時(shí)候 EDAS 告訴你，EDAS 的微服務(wù)解決方案，不需要做任何的代碼和配置的修改，就能完美地解決上面說的三個(gè)場(chǎng)景中的問題。

你，不心動(dòng)嗎？

是的，你沒看錯(cuò)，只要你的應(yīng)用是基于 Spring Cloud 或 Dubbo 最近五年內(nèi)的版本開發(fā)，就能直接使用完整的 EDAS 微服務(wù)治理能力，不需要修改任何代碼和配置。

為什么 EDAS 用戶可以輕松發(fā)布

傳統(tǒng)的發(fā)布流程真的很容易出錯(cuò)

傳統(tǒng)的發(fā)布流程中，服務(wù)提供者停止再啟動(dòng)，服務(wù)消費(fèi)者感知到服務(wù)提供者節(jié)點(diǎn)停止的流程如下：

1、服務(wù)發(fā)布前，消費(fèi)者根據(jù)負(fù)載均衡規(guī)則調(diào)用服務(wù)提供者，業(yè)務(wù)正常。

2、服務(wù)提供者 B 需要發(fā)布新版本，先對(duì)其中的一個(gè)節(jié)點(diǎn)進(jìn)行操作，首先是停止 Java 進(jìn)程。

3、服務(wù)停止過程，又分為主動(dòng)注銷和被動(dòng)注銷，主動(dòng)注銷是準(zhǔn)實(shí)時(shí)的，被動(dòng)注銷的時(shí)間由不同的注冊(cè)中心決定，最差的情況會(huì)需要 1 分鐘。

如果應(yīng)用是正常停止，Spring Cloud 和 Dubbo 框架的 Shutdown Hook 能正常被執(zhí)行，這一步的耗時(shí)可以忽略不計(jì)。

如果應(yīng)用是非正常停止，比如直接使用 kill -9 停止，或者 Docker 鏡像構(gòu)建的時(shí)候 Java 應(yīng)用不是 1 號(hào)進(jìn)程且沒有把 kill 信號(hào)傳遞給應(yīng)用。那么服務(wù)提供者不會(huì)主動(dòng)去注銷服務(wù)節(jié)點(diǎn)，而是在超過一段時(shí)間后由于心跳超時(shí)而被動(dòng)地被注冊(cè)中心摘除。

4、服務(wù)注冊(cè)中心通知消費(fèi)者，其中的一個(gè)服務(wù)提供者節(jié)點(diǎn)已下線。包含推送和輪詢兩種方式，推送可以認(rèn)為是準(zhǔn)實(shí)時(shí)的，輪詢的耗時(shí)由服務(wù)消費(fèi)者輪詢間隔決定，最差的情況下需要 1 分鐘。

5、服務(wù)消費(fèi)者刷新服務(wù)列表，感知到服務(wù)提供者已經(jīng)下線了一個(gè)節(jié)點(diǎn)，這一步對(duì)于 Dubbo 框架來說不存在，但是 Spring Cloud 的負(fù)載均衡組件 Ribbon 默認(rèn)的刷新時(shí)間是 30 秒 ，最差情況下需要耗時(shí) 30 秒。

6、服務(wù)消費(fèi)者不再調(diào)用已經(jīng)下線的節(jié)點(diǎn)。

從第 2 步到第 6 步的過程中，Eureka 在最差的情況下需要耗時(shí) 2 分鐘，Nacos 在最差的情況下需要耗時(shí) 50 秒。在這段時(shí)間內(nèi)，請(qǐng)求都有可能出現(xiàn)問題，所以發(fā)布時(shí)會(huì)出現(xiàn)各種報(bào)錯(cuò)，同時(shí)還影響用戶的體驗(yàn)，發(fā)布后又需要修復(fù)執(zhí)行到一半的臟數(shù)據(jù)。最后不得不每次發(fā)版都安排在凌晨?jī)扇c(diǎn)發(fā)布，心驚膽顫，睡眠不足，苦不可言。

為什么 EDAS 用戶不需要修數(shù)據(jù)

當(dāng)您的應(yīng)用部署到 EDAS 之后，EDAS 的無損下線功能會(huì)自動(dòng)在發(fā)布新版本的時(shí)候做如下的增強(qiáng)，我們主要關(guān)注綠色部分的信息：

1、應(yīng)用在發(fā)布前主動(dòng)向注冊(cè)中心注銷應(yīng)用，并將應(yīng)用標(biāo)記為已下線的狀態(tài)。

2、在接收到服務(wù)消費(fèi)者請(qǐng)求時(shí)，首先會(huì)正常處理本次調(diào)用，并通知服務(wù)消費(fèi)者此節(jié)點(diǎn)已下線，服務(wù)消費(fèi)者會(huì)立即從調(diào)用列表刪除此節(jié)點(diǎn)。

3、在這之后，服務(wù)消費(fèi)者不再調(diào)用已經(jīng)下線的節(jié)點(diǎn)。

EDAS 的無損下線功能，將原來的從原來的 停止進(jìn)程階段 注銷服務(wù)變成了 prestop 階段注銷服務(wù)，將原來的依賴于 注冊(cè)中心推送，做到了服務(wù)提供者直接通知消費(fèi)者從調(diào)用列表中摘除自己。使得下線感知的時(shí)間大大減短，從原來的分鐘級(jí)別做到準(zhǔn)實(shí)時(shí)，確保您的應(yīng)用在下線時(shí)能做到業(yè)務(wù)無損。

金絲雀發(fā)布為 EDAS 用戶再加一重保障

在普通的新版本發(fā)布場(chǎng)景中，默認(rèn)情況下請(qǐng)求到各個(gè)節(jié)點(diǎn)的流量是均勻分布的。

假設(shè)服務(wù)提供者有 4 臺(tái)，只要某個(gè)節(jié)點(diǎn)一發(fā)布新版本，就會(huì)有 25% 的流量打到新版本。如果新版本存在問題，就會(huì)影響線上 25% 的流量，輕則修復(fù)數(shù)據(jù)，重則嚴(yán)重影響用戶體驗(yàn)，甚至產(chǎn)生資損。

EDAS 提供的金絲雀發(fā)布功能，支持 EDAS 用戶在發(fā)布新版本之前就提前配置好金絲雀規(guī)則，使得只有符合流量特征的流量會(huì)調(diào)用到新版本，從而可以精準(zhǔn)地控制調(diào)用到新版本的流量，進(jìn)行新版本驗(yàn)證。

如圖所示，EDAS 的用戶可以在發(fā)布之前配置好金絲雀規(guī)則。

這里以 Dubbo 為例，下圖中配置表明 調(diào)用

com.alibaba.edas.demo.EchoService.echo(String string) 的流量中，只有參數(shù)為 "helloworld" 的流量才會(huì)被路由到新版本。

在服務(wù)提供者的將服務(wù)注冊(cè)到注冊(cè)中心前，EDAS 已經(jīng)將新版本對(duì)應(yīng)的金絲雀規(guī)則推送到服務(wù)消費(fèi)者端。服務(wù)消費(fèi)者在調(diào)用的時(shí)候，會(huì)根據(jù)金絲雀規(guī)則對(duì)流量進(jìn)行分析，并與服務(wù)提供者列表中的元數(shù)據(jù)進(jìn)行比對(duì)，選擇正確的調(diào)用地址。

除了上圖中演示的簡(jiǎn)單參數(shù)比對(duì)之外，EDAS 也支持解析更復(fù)雜的結(jié)構(gòu)體進(jìn)行規(guī)則配置。當(dāng)然，如果某個(gè)場(chǎng)景只需要控制流量百分比就能滿足需求，EDAS 用戶也可以直接按比例進(jìn)行灰度。

EDAS 金絲雀發(fā)布 將路由到新版本的流量，從所占總節(jié)點(diǎn)數(shù)的百分比轉(zhuǎn)變成了根據(jù)流量特征進(jìn)行控制。您可以自由地控制路由到新版本的流量，比如只將內(nèi)部測(cè)試賬號(hào)的流量路由到新版本，從而做到小心發(fā)布、大膽驗(yàn)證。所以，趕緊來 EDAS 進(jìn)行輕松發(fā)布吧。

為什么 EDAS 用戶不需要半夜醒來重啟機(jī)器

開源框架有可能被單點(diǎn)異常拖垮整個(gè)應(yīng)用系統(tǒng)

在微服務(wù)架構(gòu)中，當(dāng)服務(wù)提供者的應(yīng)用實(shí)例出現(xiàn)異常時(shí)，服務(wù)消費(fèi)者無法及時(shí)感知，會(huì)影響服務(wù)的正常調(diào)用，進(jìn)而影響消費(fèi)者的服務(wù)性能甚至可用性。

在上圖的示例場(chǎng)景中，系統(tǒng)包含 4 個(gè)應(yīng)用，A、B、C 和 D，其中應(yīng)用 A 會(huì)分別調(diào)用應(yīng)用 B、C 和 D。當(dāng)應(yīng)用 B、C 或 D 的某些實(shí)例異常時(shí)（如圖中應(yīng)用 B、C 和 D 標(biāo)識(shí)的各有 1個(gè)和 2 個(gè)異常實(shí)例），如果應(yīng)用 A 無法感知，會(huì)導(dǎo)致部分調(diào)用失敗；如果業(yè)務(wù)代碼寫的不夠優(yōu)雅，有可能影響應(yīng)用 A 的性能甚至整個(gè)系統(tǒng)的可用性。

離群實(shí)例摘除給業(yè)務(wù)系統(tǒng)的穩(wěn)定性加把鎖

為了保護(hù)應(yīng)用的服務(wù)性能和可用性，EDAS 支持檢測(cè)應(yīng)用實(shí)例的可用性并進(jìn)行動(dòng)態(tài)調(diào)整，以保證服務(wù)成功調(diào)用，從而提升業(yè)務(wù)的穩(wěn)定性和服務(wù)質(zhì)量。

如下圖所示，EDAS 用戶可以在控制臺(tái)上對(duì)應(yīng)用 A 進(jìn)行如下配置，從而保證 A 應(yīng)用的穩(wěn)定性。

1、異常類型，網(wǎng)絡(luò)異常指的是 IOException，業(yè)務(wù)異常在 Spring Cloud 框架中指的是返回值 http 狀態(tài)碼 為 500 ，Dubbo 框架中指的是返回值中包含 Exception。

2、QPS 下限，為了避免調(diào)用次數(shù)太少，隨機(jī)性較大從而影響判斷的準(zhǔn)確性，您可以設(shè)置 QPS 的下限，只有 QPS 達(dá)到一定值后才進(jìn)行離群摘除判斷。默認(rèn)為 1 ，可以配置成 0。

3、錯(cuò)誤率下限，如果某臺(tái)服務(wù)提供者返回值中，錯(cuò)誤的比例超過了配置的這個(gè)值，會(huì)被判定成需要被摘除。

4、摘除實(shí)例比例上限，為了避免摘除過多的機(jī)器節(jié)點(diǎn)，導(dǎo)致剩余的節(jié)點(diǎn)數(shù)流量過載，需要配置一個(gè)摘除比例的上限，建議不超過 50%。

5、恢復(fù)檢測(cè)單位時(shí)間，離群節(jié)點(diǎn)被摘除的動(dòng)作是暫時(shí)性的，經(jīng)過單位時(shí)間后，消費(fèi)者側(cè)會(huì)對(duì)此節(jié)點(diǎn)進(jìn)行檢測(cè)。如果節(jié)點(diǎn)已經(jīng)恢復(fù)，會(huì)將其放回到節(jié)點(diǎn)中。如果節(jié)點(diǎn)持續(xù)被摘除，那么它被摘除的時(shí)間會(huì)線性增加到最大值。

基于離群實(shí)例摘除功能，EDAS 用戶不會(huì)因?yàn)閱螜C(jī)異常在半夜醒來重啟機(jī)器，先安心地睡一覺吧，反正業(yè)務(wù)也不會(huì)受影響。醒來之后機(jī)器現(xiàn)場(chǎng)也還在，是拿著保留的現(xiàn)場(chǎng)進(jìn)行分析，還是直接重啟，任君選擇。

為什么 EDAS 用戶對(duì)自己的服務(wù)胸有成竹

服務(wù)查詢一目了然

我們熟知的 zookeeper 組件并沒有服務(wù)查詢界面，Eureka 和 Nacos 這兩個(gè)注冊(cè)中心，雖然提供了網(wǎng)頁版的控制臺(tái)，但是在控制臺(tái)上只能查詢到服務(wù)的 IP 和 port 等基本的信息。

EDAS 用戶在使用服務(wù)查詢時(shí)，不僅能夠查詢到應(yīng)用注冊(cè)了哪些服務(wù)，對(duì)應(yīng)的 IP 和 port 是什么，還能查詢到服務(wù)包含的具體方法和參數(shù)類型，以及直觀地看到服務(wù)被其他應(yīng)用和節(jié)點(diǎn)的訂閱情況。

即使部門組織再?gòu)?fù)雜、微服務(wù)模塊再多，EDAS 的用戶也可以清晰地查詢出服務(wù)的被調(diào)用情況，做到心中有數(shù)，在梳理服務(wù)依賴以及評(píng)估影響面的時(shí)候可以做到胸有成竹。

精準(zhǔn)地控制服務(wù)調(diào)用的權(quán)限

業(yè)務(wù)發(fā)展后，服務(wù)還會(huì)遇到權(quán)限控制的需求。比如優(yōu)惠券部門的某個(gè)應(yīng)用，同時(shí)包含了優(yōu)惠券查詢接口 和優(yōu)惠券發(fā)放接口。對(duì)于優(yōu)惠券查詢接口來說，默認(rèn)公司內(nèi)部的所有應(yīng)用都有權(quán)限調(diào)用的；但優(yōu)惠券發(fā)放接口只有客服和運(yùn)營(yíng)部門的某些應(yīng)用才有權(quán)限調(diào)用。

如下圖所示，EDAS 用戶可以對(duì)自己的服務(wù)進(jìn)行權(quán)限管理，這里以 Dubbo 為例，下圖中配置表明，應(yīng)用 cartservice 發(fā)布的 com.alibaba.edas.demo.EchoService 服務(wù)的 addItemToCart 的方法，只允許 frontend 這個(gè)應(yīng)用調(diào)用。

除了支持對(duì)指定的接口添加鑒權(quán)規(guī)則之外，服務(wù)鑒權(quán)也支持對(duì)整個(gè)應(yīng)用添加鑒權(quán)規(guī)則，還支持根據(jù)調(diào)用方 IP 進(jìn)行鑒權(quán)。

精準(zhǔn)的權(quán)限管理，可以讓你更好地管理微服務(wù)調(diào)用的權(quán)限，保證業(yè)務(wù)的合規(guī)性，保障數(shù)據(jù)的安全。

EDAS 微服務(wù)治理使用成本真的很低

使用 EDAS 微服務(wù)治理的成本真的已經(jīng)低得不能再低，不需要修改任何代碼和配置，直接將應(yīng)用部署上來就可以享受完整的 EDAS 微服務(wù)治理能力。

只要你的應(yīng)用是基于 Spring Cloud 或 Dubbo 最近五年內(nèi)的版本開發(fā)，就能直接使用完整的 EDAS 微服務(wù)治理能力，趕快來體驗(yàn)吧！