揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因
為什么很多互聯網公司不敢在白天發布，都選擇在半夜發布。要是能擺脫半夜發布的窘境，它不香嗎？選擇在半夜發布無非是為了減少對用戶的影響，出了問題影響面可控。
那我們就來談談，發布會有哪些問題。
- 若您的應用沒有上下線的問題，您的任何應用在發布的過程中會造成短暫的服務不可用，短時間內業務監控會出現大量 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分鐘。
擴容
再來看看壓測態下，應用擴容的表現，我們在 500qps 壓測的情況下，將 sc-a 應用從1個pod擴容到4個pod，壓測時長3分鐘
發布
在 500qps 壓測的情況下，將 sc-a 應用（4個pod）進行發布，壓測時長3分鐘。
現狀與思考
可以看到大流量下應用發布的問題，刻不容緩。隨著云原生架構的發展，彈性伸縮、滾動升級、分批發布等云原生能力讓用戶獲得了資源、成本、穩定性的最優解，正是因為其彈性等特點，如果應用存在上線、下線等問題，那么這些問題將會在云原生架構下被放大。
想象一下如果每次擴容、縮容、發布都有這些不必要的錯誤，業務的連續性、產品的用戶體驗均會收到巨大的打擊，如何在服務更新部署過程中保證業務無感知，是開發者必須要解決的問題，即從應用停止到重新運行，是不能影響正常業務請求的。
減少不必要的API錯誤是最好的客戶體驗。
這是一個非常痛的點，這時候有個人告訴你，我知道怎么搞定，我有著豐富的經驗，知道怎么解決，你肯定很開心。
然后花高薪請進來了，確實不錯，各種架構圖、框架原理，框架修改點都非常清晰而且功能確實完美。最后評估對當前系統的修改成本，需要搭建三套中間件服務端，增加 4 個中間件依賴，修改幾萬行代碼和配置。
“打擾了，還是業務重要，產品經理給的需求還沒完成呢，剛剛說的場景也沒那么痛苦，不就幾個小問題嘛，真的沒事。”
這時候 MSE 告訴你，MSE 的微服務解決方案，不需要做任何的代碼和配置的修改，就能完美地解決上下線中的問題。您只需將您的應用接入MSE服務治理，您就能享受到 MSE 的無損下線的能力。
你，不心動嗎？
是的，你沒看錯，只要你的應用是基于 Spring Cloud 或 Dubbo 最近五年內的版本開發，就能直接使用完整的 MSE 微服務治理能力，不需要修改任何代碼和配置。
具備無損下線的應用發布
如何接入 MSE 無損下線
您只需將您的應用接入 MSE 服務治理，即可具備微服務治理的無損下線能力。
接入后的表現
我們看一下接入MSE服務治理后的擴縮容以及發布的表現，同樣是原先的
縮容
在 500qps 壓測的情況下，將 sc-a 應用從4個pod縮容到1個pod，壓測時長3分鐘
擴容
在 500qps 壓測的情況下，將 sc-a 應用從1個pod擴容到4個pod，壓測時長3分鐘。
發布
在500qps壓測的情況下，將 sc-a 應用（4個pod）進行發布，壓測時長3分鐘。
對比應用在接入 MSE 服務治理前后發布過程中的表現，我們可以看到 MSE 完全解決了發布、擴縮容過程中流量報錯的痛點，使業務更加穩定，產品體驗更加絲滑。同時接入 MSE 服務治理后無需修改一行代碼即可享受到無損下線能力。
總結
本文介紹了微服務治理下無損下線的能力，保障了發布期間的流量，讓您擺脫半夜發布的窘境，您的應用只需接入MSE服務治理，無需任何操作即可享受到無損下線的能力。除了MSE（微服務引擎），無損能力還被EDAS、SAE等云產品集成，同時無損下線已經在阿里云核心業務大規模落地，助力保障云上業務穩定性，讓您業務永遠在線。
后面章節會詳細揭秘為何只需接入MSE服務治理，您的應用就能白天大流量下發布依然如絲般順滑的黑魔法，敬請期待
后面還會圍繞白天大流量下發布絲滑的場景繼續談，該話題預計會有三到四篇文章，敬請期待！
不只是服務治理
MSE 微服務引擎不僅僅具備微服務治理能力，我們還提供托管開源注冊中心、配置中心、開源網關等服務。通過托管的Baas化產品，將我們阿里云十多年微服務最佳實踐能力通過云產品方式輸出，助力保障云上業務穩定性，讓您業務永遠在線。
微服務引擎用戶交流群
如果您在微服務引擎MSE使用過程中有任何疑問，歡迎您搜索釘釘群號 23371469 或者使用釘釘掃描如下二維碼加入釘釘群進行反饋。
原文鏈接：https://developer.aliyun.com/article/780231?
版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。總結
以上是生活随笔為你收集整理的揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： CDN应用进阶 | 正确使用CDN 让你
- 下一篇： Serverless 落地之痛怎么解？