簡介：很多互聯(lián)網(wǎng)公司半夜發(fā)布，只為減小用戶影響，出了問題場面可控。MSE服務(wù)治理無損下線，保障了發(fā)布期間的流量，讓您擺脫半夜發(fā)布的窘境。

為什么很多互聯(lián)網(wǎng)公司不敢在白天發(fā)布，都選擇在半夜發(fā)布。要是能擺脫半夜發(fā)布的窘境，它不香嗎？選擇在半夜發(fā)布無非是為了減少對用戶的影響，出了問題影響面可控。

那我們就來談?wù)?#xff0c;發(fā)布會有哪些問題。

• 若您的應(yīng)用沒有上下線的問題，您的任何應(yīng)用在發(fā)布的過程中會造成短暫的服務(wù)不可用，短時間內(nèi)業(yè)務(wù)監(jiān)控會出現(xiàn)大量 io 異常報錯，對業(yè)務(wù)的連續(xù)性造成困擾。
• 發(fā)布是整個功能更新到線上的最后一個環(huán)節(jié)，一些研發(fā)過程中累計的問題，在最后發(fā)布環(huán)節(jié)才會觸發(fā)。如果此時是白天大流量的場景，極小的問題由于大流量的因素都會被快速放大，影響面難以控制。
• 發(fā)布若涉及到多個應(yīng)用，如何進(jìn)行合理地發(fā)布并且不會有版本問題導(dǎo)致流量受損。

所有發(fā)布的問題大致總結(jié)為以上三條，接下來我會分幾篇文章詳細(xì)講一下為什么會有這些問題，已經(jīng)我們?nèi)绾谓鉀Q這些問題。也希望大家都可以早點下班，擺脫半夜發(fā)布的窘境，抽出時間多陪陪家人。

本文將圍繞實例上下線場景，講述發(fā)布過程中的問題。

大流量下的應(yīng)用發(fā)布現(xiàn)狀

應(yīng)用 Demo

Demo 以 Spring Cloud 為例，我們準(zhǔn)備了如下demo。流量是阿里云性能測試服務(wù)PTS發(fā)起，通過開源的Zuul網(wǎng)關(guān)流入我們的系統(tǒng)

PTS使用文檔：https://pts.console.aliyun.com/

其中其服務(wù)調(diào)用鏈路如下圖所示：

圖中流量從 Netflix Zuul 對應(yīng)的 Ingress 進(jìn)來，會調(diào)用 SC-A 應(yīng)用對應(yīng)的服務(wù)，SC-A 應(yīng)用內(nèi)部調(diào)用 SC-B 應(yīng)用的服務(wù)，SC-B 應(yīng)用內(nèi)部調(diào)用 SC-C 應(yīng)用的服務(wù)。

Helm 部署 Demo

helm install mse/mse-samples
Demo為純開源Spring Cloud架構(gòu)，項目地址：

https://github.com/aliyun/alibabacloud-microservice-demo/tree/master/microservice-doc-demo/traffic-management

部署完畢后，阿里云容器服務(wù)上的工作負(fù)載情況如下：

我們通過 while true; do curl http://{ip:port}/A/a;echo;done shell 命令不斷地去訪問 Spring Cloud 服務(wù)，我們可以看到我們 demo 的作用僅僅是打印當(dāng)前服務(wù)的ip，我們可以看到我們 demo 的作用僅僅是打印當(dāng)前服務(wù)的 ip，我們可以看到整體調(diào)用的鏈路。

while true; do curl http://{ip:port}/A/a;echo;done A[10.0.0.81] -> B[10.0.0.82] -> C[10.0.0.68] A[10.0.0.179] -> B[10.0.0.82] -> C[10.0.0.50] A[10.0.0.80] -> B[10.0.0.82] -> C[10.0.0.68] A[10.0.0.49] -> B[10.0.0.82] -> C[10.0.0.50] A[10.0.0.81] -> B[10.0.0.175] -> C[10.0.0.68] A[10.0.0.179] -> B[10.0.0.175] -> C[10.0.0.50] A[10.0.0.80] -> B[10.0.0.175] -> C[10.0.0.68] A[10.0.0.49] -> B[10.0.0.175] -> C[10.0.0.50] A[10.0.0.81] -> B[10.0.0.82] -> C[10.0.0.68] ...

配置壓測 500 qps，并在壓測的過程中分別進(jìn)行應(yīng)用縮容、擴(kuò)容以及發(fā)布，并觀察壓測的情況。

大流量下開源應(yīng)用的表現(xiàn)

縮容

在 500qps 壓測的情況下，將 sc-a 應(yīng)用從4個pod縮容到1個pod，壓測時長3分鐘。

觀察 K8s 的事件，我們看到在17:35:21時，進(jìn)行應(yīng)用縮容。

查看性能壓測報告，我們觀察到從 17:35:21 開始出錯，17:35:36 停止報錯，其中報錯時長持續(xù)15秒，總共出現(xiàn)469個異常。

其中詳細(xì)過程報告如下。

擴(kuò)容

再來看看壓測態(tài)下，應(yīng)用擴(kuò)容的表現(xiàn)，我們在 500qps 壓測的情況下，將 sc-a 應(yīng)用從1個pod擴(kuò)容到4個pod，壓測時長3分鐘

觀察K8s的事件，我們看到在 17:47:03 時，進(jìn)行應(yīng)用擴(kuò)容。

查看性能壓測報告，我們觀察到從 17:47:12 開始出錯，17:47:19 停止報錯，其中報錯時長持續(xù)7秒，總共出現(xiàn)257個異常。

其中詳細(xì)過程報告如下。

發(fā)布

在 500qps 壓測的情況下，將 sc-a 應(yīng)用（4個pod）進(jìn)行發(fā)布，壓測時長3分鐘。

觀察K8s的事件，我們看到在 17:53:42 時，進(jìn)行應(yīng)用發(fā)布。

查看性能壓測報告，我們觀察到從 17:53:42 開始出錯，17:54:24 停止報錯，其中報錯時長持續(xù)42秒，總共出現(xiàn)1萬多個異常。

其中詳細(xì)過程報告如下。

現(xiàn)狀與思考

可以看到大流量下應(yīng)用發(fā)布的問題，刻不容緩。隨著云原生架構(gòu)的發(fā)展，彈性伸縮、滾動升級、分批發(fā)布等云原生能力讓用戶獲得了資源、成本、穩(wěn)定性的最優(yōu)解，正是因為其彈性等特點，如果應(yīng)用存在上線、下線等問題，那么這些問題將會在云原生架構(gòu)下被放大。

想象一下如果每次擴(kuò)容、縮容、發(fā)布都有這些不必要的錯誤，業(yè)務(wù)的連續(xù)性、產(chǎn)品的用戶體驗均會收到巨大的打擊，如何在服務(wù)更新部署過程中保證業(yè)務(wù)無感知，是開發(fā)者必須要解決的問題，即從應(yīng)用停止到重新運行，是不能影響正常業(yè)務(wù)請求的。

減少不必要的API錯誤是最好的客戶體驗。

這是一個非常痛的點，這時候有個人告訴你，我知道怎么搞定，我有著豐富的經(jīng)驗，知道怎么解決，你肯定很開心。

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

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

這時候 MSE 告訴你，MSE 的微服務(wù)解決方案，不需要做任何的代碼和配置的修改，就能完美地解決上下線中的問題。您只需將您的應(yīng)用接入MSE服務(wù)治理，您就能享受到 MSE 的無損下線的能力。

你，不心動嗎？

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

具備無損下線的應(yīng)用發(fā)布

如何接入 MSE 無損下線

您只需將您的應(yīng)用接入 MSE 服務(wù)治理，即可具備微服務(wù)治理的無損下線能力。

接入后的表現(xiàn)

我們看一下接入MSE服務(wù)治理后的擴(kuò)縮容以及發(fā)布的表現(xiàn)，同樣是原先的

縮容

在 500qps 壓測的情況下，將 sc-a 應(yīng)用從4個pod縮容到1個pod，壓測時長3分鐘

觀察K8s的事件，我們看到在17:41:06時，進(jìn)行應(yīng)用縮容。

查看性能壓測報告，我們觀察到流量全程無損，其中并發(fā)穩(wěn)定在30左右。

其中詳細(xì)過程報告如下，可以看到應(yīng)用縮容對業(yè)務(wù)來說完全無感知。

擴(kuò)容

在 500qps 壓測的情況下，將 sc-a 應(yīng)用從1個pod擴(kuò)容到4個pod，壓測時長3分鐘。

觀察K8s的事件，我們看到在20:00:19時，進(jìn)行應(yīng)用擴(kuò)容。

查看性能壓測報告，無報錯。

其中詳細(xì)過程報告如下，可以看到應(yīng)用縮容對業(yè)務(wù)來說無報錯，但是在20:01:07開始有并發(fā)存在凸起，后續(xù)會上線無損上線功能，將完善該邏輯，使凸起平滑。

發(fā)布

在500qps壓測的情況下，將 sc-a 應(yīng)用（4個pod）進(jìn)行發(fā)布，壓測時長3分鐘。

觀察K8s的事件，我們看到在 20:08:55 時，進(jìn)行應(yīng)用發(fā)布。

查看性能壓測報告，我們觀察流量全程無報錯。

其中詳細(xì)過程報告如下，可以看到應(yīng)用縮容對業(yè)務(wù)來說無報錯，但是在20:09:39、20:10:27 有并發(fā)存在輕微凸起，后續(xù)會上線無損上線功能，將完善該邏輯，使凸起平滑。

對比應(yīng)用在接入 MSE 服務(wù)治理前后發(fā)布過程中的表現(xiàn)，我們可以看到 MSE 完全解決了發(fā)布、擴(kuò)縮容過程中流量報錯的痛點，使業(yè)務(wù)更加穩(wěn)定，產(chǎn)品體驗更加絲滑。同時接入 MSE 服務(wù)治理后無需修改一行代碼即可享受到無損下線能力。

總結(jié)

本文介紹了微服務(wù)治理下無損下線的能力，保障了發(fā)布期間的流量，讓您擺脫半夜發(fā)布的窘境，您的應(yīng)用只需接入MSE服務(wù)治理，無需任何操作即可享受到無損下線的能力。除了MSE（微服務(wù)引擎），無損能力還被EDAS、SAE等云產(chǎn)品集成，同時無損下線已經(jīng)在阿里云核心業(yè)務(wù)大規(guī)模落地，助力保障云上業(yè)務(wù)穩(wěn)定性，讓您業(yè)務(wù)永遠(yuǎn)在線。

后面章節(jié)會詳細(xì)揭秘為何只需接入MSE服務(wù)治理，您的應(yīng)用就能白天大流量下發(fā)布依然如絲般順滑的黑魔法，敬請期待

后面還會圍繞白天大流量下發(fā)布絲滑的場景繼續(xù)談，該話題預(yù)計會有三到四篇文章，敬請期待！

不只是服務(wù)治理

MSE 微服務(wù)引擎不僅僅具備微服務(wù)治理能力，我們還提供托管開源注冊中心、配置中心、開源網(wǎng)關(guān)等服務(wù)。通過托管的Baas化產(chǎn)品，將我們阿里云十多年微服務(wù)最佳實踐能力通過云產(chǎn)品方式輸出，助力保障云上業(yè)務(wù)穩(wěn)定性，讓您業(yè)務(wù)永遠(yuǎn)在線。

微服務(wù)引擎用戶交流群

如果您在微服務(wù)引擎MSE使用過程中有任何疑問，歡迎您搜索釘釘群號 23371469 或者使用釘釘掃描如下二維碼加入釘釘群進(jìn)行反饋。

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

版權(quán)聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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