@
byte10 兄弟,你可以先看下我 4 楼里说的场景,还可以自己稍微测一下 go 标准库的 net.Conn 对比 epoll 这类的内存占用情况以及连接数很多时候的情况比如至少 1w 连接起步、稍微配置好点的硬件来个 5w 起步的连接数(连接数少则协程数量少、异步框架相比 go runtime 没什么优势)
你实测到一些数据,还可以再看下系统编程类的书籍,并且最好也深入理解下 go 的并发模型,20 多年前互联网早期 server 的进程池线程池模型、异步 IO 、以及异步模型比如 C/C++、同步模型比如 erlang 、golang 这些的发展史
万变不离其宗的是系统层的资源的有限,不管语言层面提供何种模型,系统资源始终是那些,语言层的同步模型需要消耗的内存和调度的 CPU 成本,对应得到的同步模型的便利,这二者在中小业务量级的场景可以兼得,但是面对大业务量级会存在一些平衡点,协程数量多时,打破了平衡,就会显得浪费、吃力
与 CAP 类似,现实中也有很多其他事情类似,影响一件事情的多个因素,此消彼长,打破了平衡,就损失了整体的收益
看一下星爷的《功夫》,看一下那个理发师小哥,然后再想想高手该怎么定义,多读书
ps:我也不是什么少年,十几年经验、奔 40 的人了,日常做系统架构、底层框架基础设施,如果标准库性能足够且好用,我就不自己手撸这些了