共计 3607 个字符，预计需要花费 10 分钟才能阅读完成。
为什么很多互联网公司不敢在白天公布，都抉择在中午公布。要是能解脱中午公布的困境，它不香吗？抉择在中午公布无非是为了缩小对用户的影响，出了问题影响面可控。
那咱们就来谈谈，发布会有哪些问题。
- 若您的利用没有高低线的问题，您的任何利用在公布的过程中会造成短暂的服务不可用，短时间内业务监控会呈现大量 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 化产品，将咱们阿里云十多年微服务最佳实际能力通过云产品形式输入，助力保障云上业务稳定性，让您业务永远在线。
原文链接
本文为阿里云原创内容，未经容许不得转载。
