中国做外贸网站有哪些问题,wordpress dz论坛,怎么推广抖音,弄个小程序要多少钱为什么很多互联网公司不敢在白天发布#xff0c;都选择在半夜发布。要是能摆脱半夜发布的窘境#xff0c;它不香吗#xff1f;选择在半夜发布无非是为了减少对用户的影响#xff0c;出了问题影响面可控。
那我们就来谈谈#xff0c;发布会有哪些问题。
若您的应用没有上…为什么很多互联网公司不敢在白天发布都选择在半夜发布。要是能摆脱半夜发布的窘境它不香吗选择在半夜发布无非是为了减少对用户的影响出了问题影响面可控。
那我们就来谈谈发布会有哪些问题。
若您的应用没有上下线的问题您的任何应用在发布的过程中会造成短暂的服务不可用短时间内业务监控会出现大量 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化产品将我们阿里云十多年微服务最佳实践能力通过云产品方式输出助力保障云上业务稳定性让您业务永远在线。
原文链接 本文为阿里云原创内容未经允许不得转载。
