揭秘大流量场景下发布如「丝般顺滑」背后的原因

为什么很多互联网公司不敢在白天发布，都选择在半夜发布。要是能摆脱半夜发布的窘境，它不香吗？选择在半夜发布无非是为了减少对用户的影响，出了问题影响面可控。

那我们就来谈谈，发布会有哪些问题。

若您的应用没有上下线的问题，您的任何应用在发布的过程中会造成短暂的服务不可用，短时间内业务监控会出现大量 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化产品，将我们阿里云十多年微服务最佳实践能力通过云产品方式输出，助力保障云上业务稳定性，让您业务永远在线。

原文链接
本文为阿里云原创内容，未经允许不得转载。