共计 1666 个字符,预计需要花费 5 分钟才能阅读完成。
“solon.web.flux” 是 solon v2.3.6 新推出的生态插件,为 solon web 提供响应式接口反对 (io.projectreactor) 。为什么叫这个名呢?因为 用户群里投票 说,这个名大家一看就晓得是干啥的!
这个插件,反对所有 solon 已适配的 http server 插件,包含 jdk 自带的 sun http server。状况如下:
插件 | 适配框架 | 包大小 | 信号协定反对 | 响应式反对 | 备注 |
---|---|---|---|---|---|
solon.boot.jdkhttp | jdk-httpserver (bio) | 0.2Mb | http | 反对 | 摸拟了异步机制 |
solon.boot.jlhttp | jlhttp (bio) | 0.3Mb | http | 反对 | 摸拟了异步机制 |
solon.boot.smarthttp | smart-http (aio) | 0.7Mb | http, ws | 反对 | |
solon.boot.jetty | jetty (nio) | 2.2Mb | http, ws | 反对 | |
solon.boot.undertow | undertow (nio) | 4.5Mb | http, ws | 反对 |
因为应用的是“io.projectreactor:reactor-core”的接口,所以 io.projectreactor 的相干组件都不便用,比方:
- io.projectreactor.rabbitmq:reactor-rabbitmq
- io.projectreactor.kafka:reactor-kafka
- 等等 …
也能够对接其它响应式接口,比方 vert.x 的组件,简略转换后也可应用。
性能状况
目前还没有零碎测试过。不过,在一个用户的测试案例里:
- “solon.boot.jlhttp” 和 “solon.boot.smarthttp” 体现得比 vertx 好很多(有点小意外)
- “solon.boot.jetty” 却比 vertx 差很多(一时,还没明确为什么是这样)
当然 vertx 必定是更业余的,人家封装了一批的响应式组件。Solon 是能够用很小的包去反对响应式,又是有本人的 Bean 容器。而且能够自在切换不同的 http server 适配组件,不同的利用场景,应该会有不同的最优选。
响应式的简略示例
这个能力,与原来的 Mvc 并不抵触(能够说是原来 Mvc 能力的扩大)。能够一起用,按需抉择。比方上面这样:
@Controller
public class DemoController {
// 经典的套路
@Mapping("/hello1")
public String hello1(String name) {return "Hello" + name;}
// 响应式的套路
@Mapping("/hello2")
public Mono<String> hello2(String name) {return Mono.just("Hello" + name);
}
}
总体上跟原来的开发区别不大,只是返回类型变了。
Solon 是什么开源我的项目?
一个,Java 新的生态型利用开发框架 。它从零开始构建,有本人的标准规范与凋谢生态(历时五年,已有寰球第二级别的生态)。与其余框架相比, 它解决了两个重要的痛点:启动慢,费内存。
解决痛点?
因为 Solon Bean 容器的独特设计,不会因为扩大依赖变多而启动很慢(开发调试时,省时、痛快)!以出名开源我的项目“小诺”为例:
- “snowy-spring 版”启动 30-50 秒
- “snowy-solon 版”启动 3 - 5 秒,内存省了 1 /3(有趣味的,欢送拉取代码体验)
所谓:“工夫就是生命,效率就是金钱”,“天下文治,唯快不破”。
绝对于 Spring Boot 和 Spring Cloud 的我的项目,有什么特点?
- 启动快 5 ~ 10 倍。(更快)
- qps 高 2~ 3 倍。(更高)
- 运行时内存节俭 1/3 ~ 1/2。(更少)
- 打包能够放大到 1/2 ~ 1/10;比方,300Mb 的变成了 23Mb。(更小)
- 同时反对 jdk8, jdk11, jdk17, jdk20, graalvm native
我的项目仓库地址?
- gitee:https://gitee.com/noear/solon
- github:https://github.com/noear/solon
正文完