共计 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