Spring Webflux - 01 MVC的困境中我们提到了通过Servlet异步的方式解决性能问题的方式,但并没有解决根本性的问题。
解决问题通过自定义线程池, 但线程池中执行业务的时候也是同步阻塞的,比如 查询数据库 或者是调用第三方的API。
这个时候如果请求较多,会触发拒绝策略。但这种情况的发生其实是我们不希望发生的。 毕竟业务上是不成功的。
在有限的资源内,做更多的功能,这就是webflux要解决的问题。
举个例子,我们要使用Reactive和MySQL进行交互,该怎么办呢?
按照指导,需要通过 R2DBC 进行
https://r2dbc.io/ ,然后选择 Drivers
找到 https://github.com/mirromutth/r2dbc-mysql
当然了,这就像使用JDBC操作数据库一样,比较繁琐.
有很多好用的客户端可以代替r2dbc-mysql。 找哪里呢?
找到Clients
我们选择spring-data-r2dbc 即可
https://www.reactivemanifesto.org/zh-CN
在不同领域中深耕的组织都在不约而同地尝试发现相似的软件构建模式。 希望这些系统会更健壮、更具回弹性 、更灵活,也能更好地满足现代化的需求。
近年来,应用程序的需求已经发生了戏剧性的更改,模式变化也随之而来。仅在几年前, 一个大型应用程序通常拥有数十台服务器、 秒级的响应时间、 数小时的维护时间以及GB级的数据。 而今,应用程序被部署到了形态各异的载体上, 从移动设备到运行着数以千计的多核心处理器的云端集群。 用户期望着毫秒级的响应时间,以及服务100%正常运行(随时可用)。 而数据则以PB计量。 昨日的软件架构已经根本无法满足今天的需求。
我们相信大家需要一套贯通整个系统的架构设计方案, 而设计中必需要关注的各个角度也已被理清, 我们需要系统具备以下特质:即时响应性(Responsive)、回弹性(Resilient)、弹性(Elastic)以及消息驱动(Message Driven)。 我们称这样的系统为反应式系统(Reactive System)。
反应式系统更加灵活、松耦合和 可伸缩。 这使得它们的开发和调整更加容易。 它们对系统的失败 也更加的包容, 而当失败确实发生时, 它们的应对方案会是得体处理而非混乱无序。 反应式系统具有高度的即时响应性, 为用户提供了高效的互动反馈。
大型系统由多个较小型的系统所构成, 因此整体效用取决于它们的构成部分的反应式属性。 这意味着, 反应式系统应用着一些设计原则,使这些属性能在所有级别的规模上生效,而且可组合。世界上各类最大型的系统所依赖的架构都基于这些属性,而且每天都在服务于数十亿人的需求。现在,是时候在系统设计一开始就有意识地应用这些设计原则了, 而不是每次都去重新发现它们。