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

那我們就來談談，發布會有哪些問題。

若您的應用沒有上下線的問題，您的任何應用在發布的過程中會造成短暫的服務不可用，短時間內業務監控會出現大量 io 異常報錯，對業務的連續性造成困擾。
發布是整個功能更新到線上的最后一個環節，一些研發過程中累計的問題，在最后發布環節才會觸發。如果此時是白天大流量的場景，極小的問題由于大流量的因素都會被快速放大，影響面難以控制。
發布若涉及到多個應用，如何進行合理地發布并且不會有版本問題導致流量受損。
所有發布的問題大致總結為以上三條，接下來我會分幾篇文章詳細講一下為什么會有這些問題，已經我們如何解決這些問題。也希望大家都可以早點下班，擺脫半夜發布的窘境，抽出時間多陪陪家人。

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

大流量下的應用發布現狀
應用 Demo
Demo 以 Spring Cloud 為例，我們準備了如下demo。流量是阿里云性能測試服務PTS發起，通過開源的Zuul網關流入我們的系統

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

其中其服務調用鏈路如下圖所示：

圖中流量從 Netflix Zuul 對應的 Ingress 進來，會調用 SC-A 應用對應的服務，SC-A 應用內部調用 SC-B 應用的服務，SC-B 應用內部調用 SC-C 應用的服務。

Helm 部署 Demo
helm install mse/mse-samples
Demo為純開源Spring Cloud架構，項目地址：

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

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

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

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，并在壓測的過程中分別進行應用縮容、擴容以及發布，并觀察壓測的情況。

大流量下開源應用的表現
縮容
在 500qps 壓測的情況下，將 sc-a 應用從4個pod縮容到1個pod，壓測時長3分鐘。

觀察 K8s 的事件，我們看到在17:35:21時，進行應用縮容。

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

其中詳細過程報告如下。

擴容
再來看看壓測態下，應用擴容的表現，我們在 500qps 壓測的情況下，將 sc-a 應用從1個pod擴容到4個pod，壓測時長3分鐘

觀察K8s的事件，我們看到在 17:47:03 時，進行應用擴容。

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

其中詳細過程報告如下。

發布
在 500qps 壓測的情況下，將 sc-a 應用（4個pod）進行發布，壓測時長3分鐘。

觀察K8s的事件，我們看到在 17:53:42 時，進行應用發布。

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

其中詳細過程報告如下。

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

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

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

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

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

“打擾了，還是業務重要，產品經理給的需求還沒完成呢，剛剛說的場景也沒那么痛苦，不就幾個小問題嘛，真的沒事。”

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

你，不心動嗎？

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

具備無損下線的應用發布
如何接入 MSE 無損下線
您只需將您的應用接入 MSE 服務治理，即可具備微服務治理的無損下線能力。

接入后的表現
我們看一下接入MSE服務治理后的擴縮容以及發布的表現，同樣是原先的

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

觀察K8s的事件，我們看到在17:41:06時，進行應用縮容。

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

其中詳細過程報告如下，可以看到應用縮容對業務來說完全無感知。

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

觀察K8s的事件，我們看到在20:00:19時，進行應用擴容。

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

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

發布
在500qps壓測的情況下，將 sc-a 應用（4個pod）進行發布，壓測時長3分鐘。

觀察K8s的事件，我們看到在 20:08:55 時，進行應用發布。

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

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

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

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

后面章節會詳細揭秘為何只需接入MSE服務治理，您的應用就能白天大流量下發布依然如絲般順滑的黑魔法，敬請期待

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

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

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。