1. 高并发场景的“真需求”到底长什么样1.1 并发场景的分层拆解高并发这个词现在几乎被用烂了。很多人一开口就是“我们系统要支持百万并发”可真问下去连“百万并发”是同时在线、每秒请求数QPS还是网关瞬时峰值都没说清楚。做过几年后端的人都清楚同样叫高并发场景拆分出来完全是几种不同的活。我习惯把并发场景分成三层来聊。第一层是接入层处理的是海量连接维持比如网关、长连接服务、消息推送这层考验的是连接数的承载能力典型的例子是IM系统里几十万甚至上百万的TCP连接同时挂着但每条连接实际的消息频率并不高。第二层是计算层处理的是请求的快速响应场景包括商品查询、订单处理、支付回调这类请求短平快考验的是CPU的吞吐能力以及框架在这类短请求下有没有额外开销。第三层是数据层涉及缓存、数据库、消息队列之间的协作这里往往会成为真正的瓶颈因为框架再快下游一慢就全卡住。同一个系统里这三类场景可能同时存在。比如一个电商App用户打开首页是计算层请求进入直播间是接入层长连接下单扣库存又要走数据层。如果一个框架只在某一层表现好另一个层表现很平庸那它就不是一个合适的选择。所以选型之前我建议先做一件很多人忽略的事把线上请求按“连接密度”和“消息频率”画一个坐标图看看你的场景到底落在哪个象限。接入层重、计算轻的场景事件驱动模型是明显占优的反之计算重、连接短传统的线程池模型未必差甚至更好维护。1.2 性能指标不是越多越好先定“北极星指标”做性能对比时最怕的就是指标铺一大堆最后谁都说服不了谁。我见过太多团队在选型会上摆出二三十个指标吞吐量、平均延迟、P99、P999、内存占用、GC频率、启动时间、包大小、学习成本……最后讨论两个小时没有结论。真正的做法是选定一个北极星指标其他指标只做筛选条件。北极星指标必须紧扣业务如果是网关或接入层核心指标是“每核心每秒处理的请求数req/s”因为单位算力的产出决定了扩容成本如果是交易系统核心指标是P99延迟因为用户对单次请求的慢比整体吞吐更敏感如果是推送系统核心指标则是单机可维持的连接数和推送扇出能力。我在做选型对比时有个习惯把北极星指标放在第一优先剩下的指标先设成“及格线”比如“P99必须小于100ms”“内存占用不能超过1.5GB”“单机吞吐不低于5000 req/s”。及格线全部通过的框架才进入横向对比这样能快速缩小候选范围。如果有一个框架吞吐拉满但P99抖动严重它在交易类场景里就直接出局根本不需要再看别的参数。还有一点想提醒平均延迟在很多高并发场景里是极具欺骗性的指标。一次GC停顿可能拉长尾延迟但平均延迟只被拉高一点点单看平均值你会以为系统很健康实际P99已经到秒级了。所以只要涉及用户体验请务必盯住百分位延迟至少看到P99最好是P999。1.3 从业务模型倒推技术形态这一步我认为是最关键也是最容易被跳过的。很多人选框架是先定技术堆栈再套业务顺序反了。框架必须服务于业务的特定瓶颈而不是反过来让业务迁就框架的偏好。举一个我自己踩过的例子。早年间做一个爬虫调度服务业务特征是单次任务执行时间从几十毫秒到几十秒不等而且执行期间大量阻塞在远程网站上。当时选的是纯异步框架理由是“高并发必须上异步”结果遇到阻塞操作就得自己做异步封装代码复杂度瞬间拉高调试难度也上升了一个量级。后来重新评估才发现这个场景的并发瓶颈根本不在框架本身而在于IO等待时间太长与其在框架层面硬扛不如控制好并发上限加轻量线程模型更划算。这类思考可以归纳成一张简单的映射表实时互动场景比如在线客服、弹幕、协作白板选事件驱动框架因为连接密度高且消息需要低延迟广播高吞吐计算场景比如报表、任务调度选线程模型充足且线程隔离好的框架因为单个任务计算时间较长异步化收益不大混合场景则需要考虑框架是否支持“局部异步”而不是强制全链路异步。把业务模型定清楚再选型后面所有性能数据才有意义否则测了半天根本不是你的真实负载形态。2. 主流候选框架的能力边界Netty、Vert.x、Spring WebFlux、Node.js、Go2.1 事件驱动与异步非阻塞的本质在看数据之前先理解底层模型否则数据在你眼里只是数字一旦场景变化你就不知道怎么调。传统线程池模型里一个请求占用一个线程线程执行期间无论是在等数据库结果还是在做计算别的请求都用不了它。当并发数超过线程数多余请求就在队列里排队看起来就是延迟飙升。这种模型在连接数少、请求计算快的时候非常稳定逻辑也好写但你不敢把线程数调得太高因为JVM里一个线程栈默认就要占用1MB左右而且线程切换会带来上下文切换的成本。事件驱动模型完全换了个思路。它不是“一人一职”地干等而是靠一个事件循环不断检查“哪些IO有数据了、哪些事件到时间了”发现有响应就处理没有就立刻回去处理别的。拿NIO的Selector举例它能把成千上万个连接交给很少的IO线程管理做到“少量线程、海量连接”。Netty就是这套机制的典型实现Vert.x和Spring WebFlux底层也依赖类似的事件循环机制Node.js更是把事件循环作为语言层面的核心调度方式。但事件驱动不是没有代价。它要求你的业务逻辑里不能有阻塞调用比如不能同步读文件、不能等待数据库连接池一旦阻塞整个事件循环就卡住后续所有请求跟着遭殃。所以写了几年异步代码后我越来越倾向于说一句话异步框架适合IO密集型场景但要求开发者具备极强的纪律性别说“就一个同步调用无所谓”在事件循环线程里任何同步阻塞都是事故。2.2 框架横向能力对比下面这张表是我在做选型对比时经常用的一张总结表列出的不是绝对结论而是各框架在同样保证“优化到位”时呈现出的特性倾向。我把它们放在一起对比方便你快速判断哪个方向更接近自己的场景。框架核心模型最适合场景典型瓶颈需要重点关注的坑NettyNIO事件驱动自定义TCP/长连接协议、网关、IM推送业务逻辑中的阻塞调用事件循环线程里严禁耗时操作Vert.x多事件循环Actor分布式网关、微服务、多语言混用代码分散后排错困难上下文在线程间切换导致丢上下文Spring WebFluxReactor式响应式全异步环形系统、高IO密度微服务链路中任一下游阻塞会传导心智负担高调试相对复杂Node.js单线程事件循环轻计算、重IO、高连接数场景CPU密集型任务会让吞吐暴跌必须用worker_threads分离计算任务GogoroutineM:N调度轻量线程同时支持高连接和高并发计算框架生态不如Java丰富全局变量易触发数据竞争需注意锁粒度Netty是五者中最“底层”的选择它本身不是应用框架更像是一个高性能网络引擎。你可以基于它构建各种协议服务如RPC框架、游戏服务器、IM服务几乎所有Java系的知名框架在底层传输层都是Netty。它的性能天花板很高代价是你需要自己管理协议解析、编解码、连接状态属于高付出高回报。Vert.x在Netty上面做了大量封装提供了HTTP、WebSocket、事件总线、服务发现能力。它特别喜欢“多个事件循环线程各管一组连接”的设计可以避免单事件循环把多核CPU浪费掉。实际使用中它的吞吐量比Netty略低但已经碾压大量老式阻塞框架开发效率则高出一个数量级。Spring WebFlux适合本来就深度绑定Spring生态的团队。它最大的价值是让Spring项目能直接进入响应式世界与Spring Web MVC形成两种可以共存的Web处理模型。但要说纯性能它并没有比Vert.x跑得更高反而因为Spring生态的重量级抽象带来一部分额外开销。Node.js在事件驱动领域的地位很特殊。它单线程处理事件循环处理轻计算、重IO、高连接数场景确实不弱但一旦碰上CPU密集型的序列化、加解密、图片处理吞吐量就明显下滑。我的经验是Node.js做BFF层、网关聚合层非常好用但如果核心业务是重计算还是别用它。Go相比前面几个Java系框架走的是另一条路。它用goroutine来替代线程一个goroutine的栈初始只有几KB可以轻松创建数万个并发单位而且调度器负责将它们映射到操作系统的线程上。好处是你不需要用回调式异步来规避阻塞写起来像同步代码性能却接近异步框架。它的单位并发成本低特别适合“连接又多、计算也不少”的混合场景。2.3 从源码层面看性能差异的几个关键点光看框架宣传口径不够我自己看源码时会特别关注三个地方。第一个是I/O模型的选择方式。Java NIO中默认的IO多路复用在不同平台上实现方式不同Linux下可能是epollWindows下则是IOCP或NIO的select模型同样的代码部署在不同操作系统表现天差地别。Netty通过Native transport层做了统一适配使用epoll时性能明显优于普通NIO这在长连接场景下尤其明显。如果你的线上环境明确固定Linux选型时一定要确认候选框架是否支持epoll而非仅靠缺省NIO。第二个是任务的调度策略。很多框架说的是异步实际内部调度还是离不开线程池。线程池的参数怎么设、任务队列是无限还是有界、拒绝策略是什么直接影响峰值表现。Vert.x默认事件循环池的大小通常是CPU核数的两倍Netty的EventLoopGroup也类似这些参数看似简单但设置不对时性能会大幅下降。比如在8核机器上你硬把事件循环数调成32线程切换开销上去了吞吐不升反降。第三个是零拷贝和缓冲区管理。高性能框架都在“减少内存拷贝”上下了大功夫。Netty的CompositeByteBuf可以把多个缓冲区拼在一起而无需合并拷贝FileRegion可以直接把文件发送到网络通道。如果你没有这种级别的缓冲区控制那么每次读写都可能带来额外的内存复制在大流量下这会表现为CPU浪费和频繁GC。在对比框架时文档里标着“零拷贝支持”和真正实现零拷贝之间是有差距的最好去看源码或者跑大数据包传输测试。讲这些底层机制是想说明一个道理框架的性能从来不是某一行代码决定的而是I/O模型、任务调度、内存管理三者的合力。选型时如果只看宣传语里的“百万并发”会漏掉大量真正影响线上表现的细节。3. 性能数据怎么测才能支撑技术决策3.1 先设计场景再动手测不然就是白测关于性能测试我看到的最常见现象是拿wrk往服务上压一批GET请求测完并发量就说框架A比框架B强。这种测法也不是没用但它的结论只能限定在“极短连接、极简响应”的范围内和你的真实业务可能差了十万八千里。我建议在做框架对比时先把业务场景拆成几个标准负载模型再针对每个模型设计测试。比如IM场景要测的是“10万连接下每条消息广播的延迟和吞吐”推送场景要测的是“连接数固定时扇出比从1到100的吞吐衰减曲线”普通API场景要测的是“固定延迟目标下能撑住的QPS”。场景不匹配数据就失去参考意义。我之前做网关选型时设计过这样一套压测流程先用wrk压短连接接口测出各框架的起步吞吐然后用ghz这类gRPC压测工具测固定连接数下的长连接负载再用自研脚本模拟“连接数缓慢上升”的场景观察框架在连接数接近上限时是否有退化比如Netty可能出现连接数过高但消息处理能力下滑的情况。每个场景至少跑三遍取稳定值第一遍预热让JIT编译、连接池初始化都完成第二第三遍采集中位值和百分位数据。压测脚本本身也要做参数控制别让压测端变成瓶颈。wrk默认使用单线程压高吞吐框架时很容易出现压测端CPU先满的情况建议在压测机开启多线程每个线程维持独立连接并且用远程机器压被测机器别把压测服务和被测服务部署在同一台物理机上。压测机和被测机之间的网络延迟直接影响你对数据的判断尽量在同一个内网环境里做对比。3.2 数据解读看吞吐更要看曲线形态拿到压测数据后我是按“三步走”来解读的。第一步看单机吞吐量的绝对水平。这里要特别注意吞吐量单位是“每秒请求数”还是“每秒事务数”两者含义不同前者可以只算一次HTTP响应后者可能包含多个子步骤不要在看数据时被单位糊弄过去。第二步看吞吐量随并发变化的曲线。理想框架的曲线应该先近乎线性上升到达拐点之后平滑回落如果出现突然断崖式下跌说明框架内部的某个组件在临界点被击穿了比如无界队列撑爆内存、或者事件循环线程被某个阻塞任务拖住。曲线的形状往往比绝对值更有诊断价值。第三步看性能数字的稳定性。同一压测场景下连续跑三遍如果P99抖动超过两倍说明框架内部调度不稳定可能是GC、缓冲扩容、或者线程池拒绝策略引起。这种抖动的危害比平均值低更大线上流量可不像压测那么均匀稍有波动就会暴露出严重的长尾问题。顺手再说一下GC数据。Java系框架的压测必须连着GC日志一起看观察压测过程中是否出现频繁的Young GC或较长的Full GCGC停顿对性能的影响很多时候框架本身的高效调度都被一次Full GC打残了。使用JDK 17以上版本时我会在压测JVM参数中加上-Xlog:gc*:filegc.log:time,level来记录GC日志之后再对比不同框架的GC压力。很多框架本身有对象池或堆外内存设计他们之间的GC表现差异在中间几十GB内存、百万连接级别的场景中会直接成为选型决定性因素。3.3 压测结束后的几个坑预热、超时和连接复用压测里有一个很经典的坑没有让框架完成“预热”就直接记录数据。JVM有JIT编译框架的代码经过多次执行后热点代码会被编译成本地机器码性能可以提升数倍。所以压测数据必须要等吞吐量稳定后再记录一般先加压并维持至少30秒等曲线平稳了再读取数据。还有连接复用策略的问题。同一个被测框架如果压测工具使用HTTP keep-alive连接复用与每次都新建TCP连接测出来的结果差别极大。新连接要经过三次握手还要经过内核的状态初始化若带宽充裕但连接数高这类开销会被显著放大。在真实业务中长连接比例各有不同所以在压测脚本里要分别跑“高连接复用率”和“低连接复用率”两种模式然后再根据你的业务场景来判断哪种数据更可信。超时参数的设置在对比中也容易被忽略。默认的连接超时、读超时会在瞬时高压力下触发大量超时重试这会降级框架在压测工具侧看到的吞吐量容易被误判为“框架性能不行”。对比多个框架时超时参数必须保持一致否则数据的可比性会很差。4. 从数据到决策一次完整的高并发框架选型实录4.1 场景背景一个私有化IM网关的选型过程用一段真实项目经历来讲我会更踏实。过去我有一个项目是私有化部署的企业即时通讯网关需要支持单机10万以上的长期连接同时要处理消息下行推送每个用户发送一条消息可能被推送到数百个订阅者也就是扇出比很高。团队技术栈以Java为主但不是所有成员都精通响应式编程。当时进入候选名单的框架有三个Vert.x、Spring WebFlux和基于Netty自研薄封装。为什么Go的goroutine方案被排除我们有些代理子服务已经用Go写过一些独立模块但核心团队更熟悉Java的运维设施和监控体系引入Go会同时增加两套技术栈的维护成本。所以技术本身的性能只是一方面团队现状必须放在决策桌面上。4.2 实测数据连接保持、推送扇出、短请求三组测试我们在同一台物理机上跑了三组对比测试硬件配置是32核CPU、64GB内存、万兆内网。这里不追求绝对精确的数值重要的是对比之间的相对差异。每组测试都预热后取稳定数据压测工具使用ghz和自研长连接模拟脚本。第一组测连接保持能力模拟8万条空闲TCP连接在线持续2小时观察内存和CPU消耗。测试结果让我很意外Vert.x和基于Netty的薄封装表现几乎持平连接本身占用的内存主要在框架的读写缓冲区上只要不设置过高水位两者都能轻松支撑。Spring WebFlux在同样连接数下CPU占用略低但也不成问题。第二组测消息扇出固定1万在线连接广播一条消息要求全部收到。这里差距就表现出来了。基于Netty薄封装的方式最灵活可以自己控制广播迭代逻辑扇出1万时P99大约35msVert.x通过EventBus方式进行广播在单机内靠线程间队列传递消息扇出1万时P99到了55msSpring WebFlux的响应式流在这种广播场景下没有专门的原语需要自己额外压测調试P99约为70ms。Netty的薄封装在此时优势明显。第三组测短请求处理模拟登录、状态同步这类带点业务逻辑的短请求。由于我们的自研封装做了不少业务性的协议解析完整链路比Vert.x和WebFlux要“重”短请求处理能力反而不如Vert.x具体数据是Netty薄封装单核QPS约2800Vert.x约3600Spring WebFlux约3100。4.3 最终选型逻辑与妥协细节这三组数据放在一起其实并没有一个框架在所有维度都是第一。最后决策的关键就不再是数字本身而是业务优先级。我们的核心业务是长连接和推送短请求接口数量有限可以单独拆开交给其他服务处理。因此优先选择了“连接保持能力、广播推送能力、扇出高并发下延迟”最优的自研Netty薄封装方案。至于它的短请求吞吐劣势通过前置一层API网关来分担过滤掉不需要长连接处理的普通短请求核心接入层只保留真正的长连接流量。这个决策过程的“妥协细节”值得一提。最终选择不是“性能王”的框架而是“性能足够满足核心场景且团队能把控演进方向”的方案。Spring WebFlux在第三组数据中其实不差但如果要做广播推送原语的自定义需要走整个Spring生态的抽象改动代价大Vert.x的EventBus适合跨实例分布式广播但单机场景下它的调度开销比直接自研大也要额外学习其集群模式。我们不想为了一个明确单一的需求引入一整套复杂抽象。选型过程中第二个明显倾向性选择是底层通信统一用Netty而不是让每个业务组件各自选框架。这样服务与服务的通信格式、连接管理方式等了然于胸后面再出问题排查链路会清晰很多。项目上线后这套架构跑了接近两年高峰期集群共有40万在线连接单机维持12万整体推送P99一直控制在50ms以内。5. 选型避坑指南与技术决策的长期维护5.1 “只看跑分”与“只看名气”都不可取回到最开头的问题高并发框架到底怎么选。我的答案其实浓缩成一句话选型是性能数据、业务场景、团队能力三者的交集而不是某一个维度的最优值。只看跑分容易选到“测试巨星、生产哑炮”。调用链极短、响应极小的基准测试根本体现不了真实业务中的编解码、业务逻辑、数据库交互和日志输出成本。我甚至见过一个项目压测时只压了空壳接口看起来吞吐5万以上上线后加上业务逻辑和下游依赖整条链路跌到2000。反过来说只看名气也会入坑。某个框架再好如果团队不熟悉它的运行机制出了问题无从下手等于背上一个黑盒依赖。我建议在技术选型评审时不要把“性能”和“成本控制”分开看。全面的评估应该翻成一张评分表性能占40%团队上手成本占20%生态运维占20%长期演进空间占20%。性能当然重要但它不应该高到忽略一切。5.2 团队兼容性与运维成本必须提前评估有一次我给一个小团队做技术咨询业务场景适合用Vert.x写异步网关但成员全都是学过传统Spring MVC的工程师。他们看了一个星期的Vert.x文档后写出的事件处理代码遇到异常时没有正确处理线程上下文压测一上就频繁丢上下文P99直接崩到300ms。不是Vert.x不行是团队准备不足。所以我会特别强调选型前做一次团队技能盘点。如果核心成员没有处理过事件循环、背压、线程上下文切换就一定要考虑第一步的“培训成本”比如计划2—3周的技术预研和一对一带教。否则上线初期你会付出比性能差异更大的代价去填人肉bug。运维侧同样重要。很多高性能框架在开发环境和小流量下看不出区别但在“索引监控、日志采集、链路追踪”这些维度上差异就会被放大。比如响应式框架的调用栈天然不连续链路追踪工具得支持跨线程的上下文传播如果现有监控体系压根不认识响应式线程你在问题上单排查时的体验会非常痛苦。选框架前请先把运维工具的兼容性问清楚。5.3 高并发方案的长期演进给未来留一条退路最后聊一个容易忽略的问题高并发框架选型不是一次性决定做好之后还得长期演进。框架的生命周期、社区活跃度、版本兼容性都会影响你后面几年的事。以前有人选了某小众社区的高性能网络库性能确实优秀但维护者后来停止更新遇到JDK新版本的兼容问题只能自己打补丁这种额外成本无法预估。相对而言Netty、Vert.x这类社区活跃的框架版本迁移路线清晰踩坑的同行也比较多。我还会建议在核心链路做“端口抽象”不要让业务代码直接绑死框架特有类型。以Netty为例自定义的Decoder/Encoder不要在里面写太多业务逻辑尽量把协议解析结果转换成项目内的通用消息对象交给上层处理。这样即使将来要换框架需要改的只有网络接入层业务逻辑能保持不变。我在项目里坚持这种做法后来重构接入协议时非常省心。还有一点很多团队容易忽略预留备用方案不要把所有能力都放在一个框架上。网关类服务我会设计成“可以同时运行两种接入模型”的架构比如主模型是Netty长连接另留一个基于普通Servlet的兜底HTTP接入模型。平时兜底模型几乎不承担流量只做健康检查和紧急切换。这样在高并发框架出现不可控的事故时至少有一条能让业务维持基本功能的路径。5.4 踩过几次坑之后的个人体会每次做选型翻来覆去思量最后胜出的往往不是跑分最高的而是“所有参与方都觉得能长久合作”的那一个。性能数据是决策的必要输入而不是全部答案。让小组的一天性能扑腾全部集中到压测数据报表上会把所有维度吐到极窄的纵深里反而遗忘了业务存活在真实流量之中的本质。如果只让我留一个判断框架值不值得用的“土办法”我会看两个点一是它在两倍流量峰值下能不能保持P99不崩溃二是团队里最普通水平的那名成员能不能在一个月内独立排查线上问题。这两点通过性能再低也有底线这两点不过性能再高也只是一颗定时炸弹。高并发的世界从来不缺跑得快的框架缺的是能在快的时候还稳得住、出问题时有人接得住的整套技术判断。