Spring 应对 IO 密集 的 web 业务系统有什么成熟的做法

[golangLover]

也写了 spring 一段时间，发现 spring 比起 event-loop 的相关框架再处理 io 密集或者并发多的时候是性能比较低。
查了相关的资料，总结出来就是

1： 直接换 vert.x，但是语法以及生态完全不同。
2: 上 spring cloud, 注册多个服务硬抗
3：spring webflux, 好像是改了 controller 那边的方法以及拦截器之类的，但其他可以复用?不知道有没有坑，以及生态怎么样
4: 多用 servlet3 返回 callable,复用处理线程。

大家在业务里最主要用的是 2 吗？其他是不是都有坑或者生态问题? 想请大家指教一下。谢谢

[golangLover]

@dqzcwxb #36 现在在用了，不过并发连接的吞吐量还是太低

[golangLover]

@zhang77555 #30 是 web 并发吞吐量觉得不是太好。

[golangLover]

@X0ray #37 如果有 async await 就最好了，cf 现在还是用的有点辛苦

[ming159]

String contenxt = File.read("path");

首先,代码运行是在 CPU 中执行;

其次,CPU 再向 IO 设备,例如内存,硬盘,或者网络发出读写指令;

最后,CPU 等待 IO 设备反馈;

此时,问题就来了,CPU 以纳秒为单位, 无论是内存,硬盘,还是网络,尤其是网络 以毫秒为单位,相差了多少倍,请自行换算.

就意味着,如果是同步 IO 模型,那在 CPU 发出读写指令后,会令当前线程

阻塞

阻塞

阻塞

等收到设备数据后,当前线程,继续往下执行.

针对以上过程,所谓的 "性能" 也好 "吞吐量" 也好,绝大多数浪费在了 CPU 等待 IO 设备反馈的时间上了. 那如何解决这个问题呢?
请自行阅读 https://segmentfault.com/a/1190000039898780 5 种 IO 模型.

所以如果想提高 "性能" 两方面入手:

1. 框架本身基于更高效的 IO 模型
2. 业务层代码,也使用更高效的 IO 模型库:

比如将 同步 IO 代码

String contenxt = File.read("path");
更换为 异步 IO 代码
String contenxt = await File.read("path");

async / await 都是语法糖,语法糖,语法糖,只是语言层面为了开发人员简化书写提供的便捷写法. 而底层 IO 机制无外乎前文中的 5 种 IO 模型