纵有疾风起
人生不言弃

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

简介:很多互联网公司半夜发布,只为减小用户影响,出了问题场面可控。MSE服务治理无损下线,保障了发布期间的流量,让您摆脱半夜发布的窘境。

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

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

  • 若您的应用没有上下线的问题,您的任何应用在发布的过程中会造成短暂的服务不可用,短时间内业务监控会出现大量 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

部署完毕后,阿里云容器服务上的工作负载情况如下:

揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因插图(1)

我们通过 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分钟。

  1. 观察 K8s 的事件,我们看到在17:35:21时,进行应用缩容。
    揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因插图(2)
  2. 查看性能压测报告,我们观察到从 17:35:21 开始出错,17:35:36 停止报错,其中报错时长持续15秒,总共出现469个异常。
    揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因插图(3)
  3. 其中详细过程报告如下。
    揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因插图(4)

扩容

再来看看压测态下,应用扩容的表现,我们在 500qps 压测的情况下,将 sc-a 应用从1个pod扩容到4个pod,压测时长3分钟

  1. 观察K8s的事件,我们看到在 17:47:03 时,进行应用扩容。
    揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因插图(5)
  2. 查看性能压测报告,我们观察到从 17:47:12 开始出错,17:47:19 停止报错,其中报错时长持续7秒,总共出现257个异常。
    揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因插图(6)
  3. 其中详细过程报告如下。
    揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因插图(7)

发布

在 500qps 压测的情况下,将 sc-a 应用(4个pod)进行发布,压测时长3分钟。

  1. 观察K8s的事件,我们看到在 17:53:42 时,进行应用发布。
    揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因插图(8)
  2. 查看性能压测报告,我们观察到从 17:53:42 开始出错,17:54:24 停止报错,其中报错时长持续42秒,总共出现1万多个异常。
    揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因插图(9)
  3. 其中详细过程报告如下。
    揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因插图(10)

现状与思考

可以看到大流量下应用发布的问题,刻不容缓。随着云原生架构的发展,弹性伸缩、滚动升级、分批发布等云原生能力让用户获得了资源、成本、稳定性的最优解,正是因为其弹性等特点,如果应用存在上线、下线等问题,那么这些问题将会在云原生架构下被放大。

想象一下如果每次扩容、缩容、发布都有这些不必要的错误,业务的连续性、产品的用户体验均会收到巨大的打击,如何在服务更新部署过程中保证业务无感知,是开发者必须要解决的问题,即从应用停止到重新运行,是不能影响正常业务请求的。

减少不必要的API错误是最好的客户体验。

这是一个非常痛的点,这时候有个人告诉你,我知道怎么搞定,我有着丰富的经验,知道怎么解决,你肯定很开心。

然后花高薪请进来了,确实不错,各种架构图、框架原理,框架修改点都非常清晰而且功能确实完美。最后评估对当前系统的修改成本,需要搭建三套中间件服务端,增加 4 个中间件依赖,修改几万行代码和配置。

“打扰了,还是业务重要,产品经理给的需求还没完成呢,刚刚说的场景也没那么痛苦,不就几个小问题嘛,真的没事。”

这时候 MSE 告诉你,MSE 的微服务解决方案,不需要做任何的代码和配置的修改,就能完美地解决上下线中的问题。您只需将您的应用接入MSE服务治理,您就能享受到 MSE 的无损下线的能力。

你,不心动吗?

是的,你没看错,只要你的应用是基于 Spring Cloud 或 Dubbo 最近五年内的版本开发,就能直接使用完整的 MSE 微服务治理能力,不需要修改任何代码和配置。

具备无损下线的应用发布

如何接入 MSE 无损下线

您只需将您的应用接入 MSE 服务治理,即可具备微服务治理的无损下线能力。

接入后的表现

我们看一下接入MSE服务治理后的扩缩容以及发布的表现,同样是原先的

缩容

在 500qps 压测的情况下,将 sc-a 应用从4个pod缩容到1个pod,压测时长3分钟

  1. 观察K8s的事件,我们看到在17:41:06时,进行应用缩容。
    揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因插图(11)
  2. 查看性能压测报告,我们观察到流量全程无损,其中并发稳定在30左右。
    揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因插图(12)
  3. 其中详细过程报告如下,可以看到应用缩容对业务来说完全无感知。
    揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因插图(13)

扩容

在 500qps 压测的情况下,将 sc-a 应用从1个pod扩容到4个pod,压测时长3分钟。

  1. 观察K8s的事件,我们看到在20:00:19时,进行应用扩容。
    揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因插图(14)
  2. 查看性能压测报告,无报错。
    揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因插图(15)
  3. 其中详细过程报告如下,可以看到应用缩容对业务来说无报错,但是在20:01:07开始有并发存在凸起,后续会上线无损上线功能,将完善该逻辑,使凸起平滑。
    揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因插图(16)

发布

在500qps压测的情况下,将 sc-a 应用(4个pod)进行发布,压测时长3分钟。

  1. 观察K8s的事件,我们看到在 20:08:55 时,进行应用发布。
    揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因插图(17)
  2. 查看性能压测报告,我们观察流量全程无报错。
    揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因插图(18)
  3. 其中详细过程报告如下,可以看到应用缩容对业务来说无报错,但是在20:09:39、20:10:27 有并发存在轻微凸起,后续会上线无损上线功能,将完善该逻辑,使凸起平滑。
    揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因插图(19)

对比应用在接入 MSE 服务治理前后发布过程中的表现,我们可以看到 MSE 完全解决了发布、扩缩容过程中流量报错的痛点,使业务更加稳定,产品体验更加丝滑。同时接入 MSE 服务治理后无需修改一行代码即可享受到无损下线能力。

总结

本文介绍了微服务治理下无损下线的能力,保障了发布期间的流量,让您摆脱半夜发布的窘境,您的应用只需接入MSE服务治理,无需任何操作即可享受到无损下线的能力。除了MSE(微服务引擎),无损能力还被EDAS、SAE等云产品集成,同时无损下线已经在阿里云核心业务大规模落地,助力保障云上业务稳定性,让您业务永远在线。

后面章节会详细揭秘为何只需接入MSE服务治理,您的应用就能白天大流量下发布依然如丝般顺滑的黑魔法,敬请期待

后面还会围绕白天大流量下发布丝滑的场景继续谈,该话题预计会有三到四篇文章,敬请期待!

不只是服务治理

MSE 微服务引擎不仅仅具备微服务治理能力,我们还提供托管开源注册中心、配置中心、开源网关等服务。通过托管的Baas化产品,将我们阿里云十多年微服务最佳实践能力通过云产品方式输出,助力保障云上业务稳定性,让您业务永远在线。

微服务引擎用户交流群

如果您在微服务引擎MSE使用过程中有任何疑问,欢迎您搜索钉钉群号 23371469 或者使用钉钉扫描如下二维码加入钉钉群进行反馈。

揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因插图(20)

原文链接:https://developer.aliyun.com/article/780231?

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

原文链接:https://blog.csdn.net/alitech2017/article/details/112465964

本站声明:网站内容来源于网络,如有侵权,请联系我们,我们将及时处理。

未经允许不得转载:起风网 » 揭秘 | 大流量场景下发布如『丝般顺滑』背后的原因

分享到: 生成海报
avatar

评论 抢沙发

评论前必须登录!

立即登录   注册

切换注册

登录

忘记密码 ?

切换登录

注册

我们将发送一封验证邮件至你的邮箱, 请正确填写以完成账号注册和激活