簡介：微服務(wù)發(fā)展至今，因其高內(nèi)聚、低耦合等特性，以及諸多開源方案帶來的開放性，已成為提升架構(gòu)效率的最佳實踐之一。當(dāng)一項技術(shù)或一個框架成為事實標(biāo)準(zhǔn)之后，我們會把更多的注意力聚焦在運(yùn)維效率和應(yīng)用可用性的持續(xù)提升上。相信下面這些場景大家或多或少都遇到過。

發(fā)布會傳送門

點擊了解產(chǎn)品詳情

前言

微服務(wù)發(fā)展至今，因其高內(nèi)聚、低耦合等特性，以及諸多開源方案帶來的開放性，已成為提升架構(gòu)效率的最佳實踐之一。當(dāng)一項技術(shù)或一個框架成為事實標(biāo)準(zhǔn)之后，我們會把更多的注意力聚焦在運(yùn)維效率和應(yīng)用可用性的持續(xù)提升上。相信下面這些場景大家或多或少都遇到過。

場景一，當(dāng)業(yè)務(wù)達(dá)到一定的規(guī)模之后，微服務(wù)的數(shù)量和單個微服務(wù)實例的數(shù)就會變的很多，從而導(dǎo)致微服務(wù)注冊中心需要管理很多服務(wù)地址，同時還需要給所有的上下游提供服務(wù)注冊和服務(wù)發(fā)現(xiàn)的能力。

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

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

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

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

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

面對以上這些場景，可以通過投入更多的開發(fā)和運(yùn)維資源來解決，但對于大部分希望專注于業(yè)務(wù)開發(fā)的企業(yè)來說，如果能有一款適合企業(yè)自身需求，支持組件化的商業(yè)化產(chǎn)品，將會是更好的選擇。

接下來，我們就來詳細(xì)剖析下阿里云微服務(wù)MSE是如何解決以上問題的。

一、注冊和配置中心托管

相比基于Zookeeper/Nacos/Eureka來自建注冊中心，MSE 提供了以下這些差異化競爭力。

二、如何降低應(yīng)用發(fā)布出錯率

什么是無損下線

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

1、服務(wù)發(fā)布前，消費者根據(jù)負(fù)載均衡規(guī)則調(diào)用服務(wù)提供者，業(yè)務(wù)正常。
2、服務(wù)提供者 B 需要發(fā)布新版本，先對其中的一個節(jié)點進(jìn)行操作，首先是停止 Java 進(jìn)程。
3、服務(wù)停止過程，又分為主動注銷和被動注銷，主動注銷是準(zhǔn)實時的，被動注銷的時間由不同的注冊中心決定，最差的情況會需要 1 分鐘。

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

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

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

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

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

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

MSE提供的無損下線功能會自動在發(fā)布新版本的時候做如下的增強(qiáng)，我們主要關(guān)注綠色部分的信息：

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

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

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

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

金絲雀發(fā)布再加一重保障

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

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

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

在發(fā)布一個新版本的應(yīng)用的時候，通過一個新的 Deployment 來發(fā)布，并在 Deployment 中填寫相應(yīng)的版本號

新版本啟動之后，默認(rèn)沒有流量，需要在 MSE 控制臺配置流量規(guī)則才有流量進(jìn)來，可以基于流量百分比進(jìn)行配置，也可以按照流量特征進(jìn)行配置。

配置完成后，Agent 會自動將路由規(guī)則推送到服務(wù)消費者端，服務(wù)消費者會去根據(jù)配置好的規(guī)則選擇去調(diào)用新版本或者舊版本。

比如這里我們配置 user-id 對 100 取模為 20 的會去新版本，那么 user-id=120 的這個流量就會去新版本。

三、如何避免半夜醒來重啟機(jī)器

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

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

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

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

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

如下圖所示，您可以在控制臺上對應(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、 錯誤率下限，如果某臺服務(wù)提供者返回值中，錯誤的比例超過了配置的這個值，會被判定成需要被摘除。
4、 摘除實例比例上限，為了避免摘除過多的機(jī)器節(jié)點，導(dǎo)致剩余的節(jié)點數(shù)流量過載，需要配置一個摘除比例的上限，建議不超過 50%。
5、 恢復(fù)檢測單位時間，離群節(jié)點被摘除的動作是暫時性的，經(jīng)過單位時間
后，消費者側(cè)會對此節(jié)點進(jìn)行檢測。如果節(jié)點已經(jīng)恢復(fù)，會將其放回到節(jié)點中。如果節(jié)點持續(xù)被摘除，那么它被摘除的時間會線性增加到最大值。

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

四、如何做到對自己的服務(wù)胸有成竹

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

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

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

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

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

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

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

除了支持對指定的接口添加鑒權(quán)規(guī)則之外，服務(wù)鑒權(quán)也支持對整個應(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ù)的安全。

結(jié)語

MSE 以組件化的方式來提供微服務(wù)能力，客戶既能對應(yīng)用實現(xiàn)自主可控，還能低門檻的接入注冊中心和配置中心的托管，以及高階的微服務(wù)治理能力。據(jù)悉，Spring Cloud 和Dubbo近5年的開源版本，均可0代碼修改就能接入MSE。

原文鏈接：https://developer.aliyun.com/article/767072?

版權(quán)聲明：本文中所有內(nèi)容均屬于阿里云開發(fā)者社區(qū)所有，任何媒體、網(wǎng)站或個人未經(jīng)阿里云開發(fā)者社區(qū)協(xié)議授權(quán)不得轉(zhuǎn)載、鏈接、轉(zhuǎn)貼或以其他方式復(fù)制發(fā)布/發(fā)表。申請授權(quán)請郵件developerteam@list.alibaba-inc.com，已獲得阿里云開發(fā)者社區(qū)協(xié)議授權(quán)的媒體、網(wǎng)站，在轉(zhuǎn)載使用時必須注明"稿件來源：阿里云開發(fā)者社區(qū)，原文作者姓名"，違者本社區(qū)將依法追究責(zé)任。 如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，歡迎發(fā)送郵件至：developer2020@service.aliyun.com 進(jìn)行舉報，并提供相關(guān)證據(jù)，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的从开源自治，到微服务云化，阿里云的这款产品给了一剂提升微服务幸福感的良药的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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