全链路异步,让你的 SpringCloud 性能优化10倍+

文章介绍了如何将SpringCloud微服务架构中的全链路同步模式升级为全链路异步模式,以提升系统性能。通过网关纯异步化、Web服务异步化、RPC调用异步化和Cache异步化等步骤,展示了性能的显著提升,如Web服务在2W并发场景下性能提升超过20倍。文章强调了响应式编程和使用Netty、WebFlux等技术的重要性,并提供了实操案例和性能对比数据。

背景

随着业务的发展,微服务应用的流量越来越大,使用到的资源也越来越多。

在微服务架构下,大量的应用都是 SpringCloud 分布式架构,这种架构,总体是全链路同步模式

同步编程模式不仅造成了资源的极大浪费,并且在流量发生激增波动的时候,受制于系统资源而无法快速的扩容。

全球后疫情时代,降本增效是大背景。

如何降本增效?

可以通过技术升级,全链路同步模式 ,升级为 全链路异步模式

尼恩作为40岁资深老架构师,带大家来做一把全链路异步模式改造,给大家看看研究成果,一定会惊到大家目瞪口呆。

本文作为 全链路异步架构的知识,收录在尼恩《尼恩Java面试宝典》的架构专题中

注:本文以 PDF 持续更新,最新尼恩 架构笔记、面试题 的PDF文件,请从这里获取:码云


全链路同步模式架构图

先回顾一下全链路同步模式架构图

全链路同步模式 ,如何升级为 全链路异步模式, 就是一个一个 环节的异步化。

40岁老架构师尼恩,持续深化自己的3高架构知识宇宙,当然首先要去完成一次牛逼的全链路异步模式 微服务实操,下面是尼恩的实操过程、效果、压测数据。

全链路异步模式

网关纯异步化(提升 9倍以上)

网关层的特点:

  • 不需要访问业务数据库只做协议转换和流量转发
  • 特点是 IO 密集型,特别适合纯异步的架构,可以极大的节省资源。

如何进行网关异步化?

使用高性能的通信框架Netty,这是一个基于NIO 非阻塞IO+ Reactor 纯异步线程模型的纯异步化框架。

网关的技术选型主要有 zuul,SpringCloud GetWay 。

  • zuul 1虽然使用的同步io,zuul2它也是使用异步的netty,但是没有和SpringCloud 框架集成
  • springcloud getway 它是基于spring 5.0 、spring boot 2.0 和spring reacter,为微服务提供一个简单有效的网关API路由接口。和SpringCloud 框架完美集成,目标是为了代替zuul

SpringCloud GetWay 是基于webFlux框架实现的,而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。所以最终还是基于IO的王者组件Netty。

如果大家使用Zuul 1,那么 升级为 SpringCloud GetWay,性能可以提升 9倍以上,

以上结论,是来自于尼恩的读者群(50+),如有疑问,可以来单挑。

总体来说,这个环节,是纯异步化最容易的。

这个环节,大部分已经升级到了 springcloud getway 已经使用了纯异步的架构;

Web 服务异步化(2W并发场景提升 20倍以上)

Web 服务作为微服务体系内的重要组成,服务节点众多,

Springboot的Web 服务默认为 Tomcat + Servlet 不支持纯异步化编程,

Tomcat + Servlet模式的问题:总体上没有使用Reactor 反应器模式, 每一个请求是阻塞处理的,属于同步 Web 服务类型。

Servlet 有异步的版本,可惜没有用起来。具体请参考 40岁老架构师尼恩为大家整理的深度文章:

京东一面:20种异步,你知道几种? 含协程

所以:跑在 大家生产环境上的,还是Tomcat + Servlet 同步 Web 服务。

如何实现 Web 服务异步化:

  • 方式一:基于 Netty 实现web服务
  • 方式二:使用 WebFlux (还是 Netty 实现web服务)

Spring WebFlux是一个响应式堆栈 Web 框架 ,它是完全非阻塞的,支持响应式流(Reactive Stream)背压,并在Netty,Undertow和Servlet 3.1 +容器等服务器上运行

我们再来看一下对于 WebFlux 的对比测试数据 (来自于参考文献1):

可见,非阻塞的处理方式规避了线程排队等待的情况,从而可以用少量而固定的线程处理应对大量请求的处理。

还有更绝的,小伙伴又一步到位直接测试了一下20000用户的情况:

  1. 对 mvc 的测试由于出现了许多的请求fail,最终以失败告终;
  2. 而 WebFlux 应对20000用户已然面不改色心不慌,吞吐量达到7228 req/sec

注意:正好是10000用户下的两倍,绝对是真实数据!也就是说, 2W并发场景提升 20倍以上

95%响应时长仅117ms。

最后,再给出两个吞吐量和响应时长的图,更加直观地感受异步非阻塞的WebFlux是如何一骑绝尘的吧:

此时,我们更加理解了Nodejs的骄傲,不过我们大Java语言也有了Vert.x和现在的Spring WebFlux。

RPC 调用异步化(提升 9倍以上)

异步RPC 调用,等待upstream 上游 response 返回时,线程不处于block 状态

作为微服务架构中数据流量最大的一部分,RPC 调用异步化的收益巨大;

RPC 调用主要的框架有:

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值