为什么很多互联网公司不敢在白天发布，都选择在半夜发布。要是能摆脱半夜发布的窘境，它不香吗？选择在半夜发布无非是为了减少对用户的影响，出了问题影响面可控。
那我们就来谈谈，发布会有哪些问题
若您的应用没有上下线的问题，您的任何应用在发布的过程中会造成短暂的服务不可用，短时间内业务监控会出现大量 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架构，项目地址：
部署完毕后，阿里云容器服务上的工作负载情况如下:
我们通过 while true; do curl http://{ip:port}/A/a;echo;doneshell 命令不断地去访问 Spring Cloud 服务，我们可以看到我们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]
...我们去PTS上面配置压测 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化产品，将我们阿里云十多年微服务最佳实践能力通过云产品方式输出，助力保障云上业务稳定性，让您业务永远在线。
