我花了两周把客户旧系统的定时轮询改成了WebSocket长连接光部署就踩了三个大坑。最近帮一个做供应链监控的客户做系统升级。他们之前用Spring Boot 定时任务每10秒拉一次数据库里的订单状态变更。业务量小的时候还行上个月并发涨到5000数据库连接池直接打满了客服后台刷新页面要转圈等8秒。客户老板急得直拍桌子说再不动手就要换供应商了。说实话当时我觉得加个Redis缓存就能糊弄过去试了一圈发现治标不治本。每次轮询都要查全量数据哪怕只有一条变化也要走网络传输前端还得自己diff。这方案在QPS破万的场景下纯属浪费带宽。最后不得不咬牙做WebSocket迁移把“拉”改成“推”。选型纠结与架构落地最开始我纠结是用Spring框架自带的SimpMessagingTemplate还是引入Netty原生。前者开发快注解一下就行后者性能好但得自己管连接生命周期。我选了Spring Native方案因为团队全是Java背景没人熟悉Netty的ChannelHandler管道模型。但坑就出在这儿——默认实现用的是内存Map存Session一断线重连就容易内存泄漏。javaConfigurationpublic class WebSocketConfig implements WebSocketMessageBrokerConfigurer {Overridepublic void registerStompEndpoints(StompWebSocketHandlerRegistry registry) {registry.addEndpoint(/ws).setAllowedOrigins(*).withSockJS();}Overridepublic void configureMessageBroker(MessageBrokerRegistry config) {config.enableSimpleBroker(/topic);config.setApplicationDestinationPrefixes(/app);}}关键改动在消息发布端。原来定时任务扫描完直接log.info(更新成功)现在改成往/topic/order发JSON。但这里有个隐蔽问题Stomp默认心跳间隔是10秒网络抖动超过这个时间连接就断了。我把heartbeat-atm调到5秒同时前端加了重连逻辑。有意思的是测试环境一切正常上线后凌晨三点告警炸了。排查发现Nginx反向代理默认proxy_read_timeout是60秒长连接空闲超过这个时间就被强制断开。改完proxy_read_timeout 3600s才稳住。生产环境的血泪教训最惨的是压测阶段。用JMeter模拟3000个并发用户发现服务端GC频率异常高。用JVisualVM一看老年代占用率90%Full GC耗时2.3秒。当时我觉得这样就行结果发现错了——不是GC策略问题是消息序列化用的Jackson默认配置太蠢。每条消息都带着完整ClassLoader反射信息内存碎片化严重。我做了两个调整一是改用ObjectMapper并配置PropertyNamingStrategy减少不必要的getter调用二是把消息体瘦身只推orderId和status两个字段详情让前端按需查API。javapublic class OrderStatusDTO {private String orderId;private Integer status;// 只保留必要字段避免序列化膨胀}还有个没写进文档的坑浏览器同一域名限制6个连接。如果用户开了多个监控页面第7个WebSocket就会pending。我在网关层加了LimitRequestRate限制单IP最多3个活跃连接超出就返回429。最后交付时P99延迟从8.2秒降到300ms以内数据库QPS降了70%。客户技术总监拍我肩膀说“早知道早改了白扛了三个月。”本文基于实际项目经验整理欢迎在评论区交流技术问题。
我花了两周把客户旧系统的定时轮询改成了WebSocket长连接光部署就踩了三个大坑。最近帮一个做供应链监控的客户做系统升级。他们之前用Spring Boot 定时任务每10秒拉一次数据库里的订单状态变更。业务量小的时候还行上个月并发涨到5000数据库连接池直接打满了客服后台刷新页面要转圈等8秒。客户老板急得直拍桌子说再不动手就要换供应商了。说实话当时我觉得加个Redis缓存就能糊弄过去试了一圈发现治标不治本。每次轮询都要查全量数据哪怕只有一条变化也要走网络传输前端还得自己diff。这方案在QPS破万的场景下纯属浪费带宽。最后不得不咬牙做WebSocket迁移把“拉”改成“推”。选型纠结与架构落地最开始我纠结是用Spring框架自带的SimpMessagingTemplate还是引入Netty原生。前者开发快注解一下就行后者性能好但得自己管连接生命周期。我选了Spring Native方案因为团队全是Java背景没人熟悉Netty的ChannelHandler管道模型。但坑就出在这儿——默认实现用的是内存Map存Session一断线重连就容易内存泄漏。javaConfigurationpublic class WebSocketConfig implements WebSocketMessageBrokerConfigurer {Overridepublic void registerStompEndpoints(StompWebSocketHandlerRegistry registry) {registry.addEndpoint(/ws).setAllowedOrigins(*).withSockJS();}Overridepublic void configureMessageBroker(MessageBrokerRegistry config) {config.enableSimpleBroker(/topic);config.setApplicationDestinationPrefixes(/app);}}关键改动在消息发布端。原来定时任务扫描完直接log.info(更新成功)现在改成往/topic/order发JSON。但这里有个隐蔽问题Stomp默认心跳间隔是10秒网络抖动超过这个时间连接就断了。我把heartbeat-atm调到5秒同时前端加了重连逻辑。有意思的是测试环境一切正常上线后凌晨三点告警炸了。排查发现Nginx反向代理默认proxy_read_timeout是60秒长连接空闲超过这个时间就被强制断开。改完proxy_read_timeout 3600s才稳住。生产环境的血泪教训最惨的是压测阶段。用JMeter模拟3000个并发用户发现服务端GC频率异常高。用JVisualVM一看老年代占用率90%Full GC耗时2.3秒。当时我觉得这样就行结果发现错了——不是GC策略问题是消息序列化用的Jackson默认配置太蠢。每条消息都带着完整ClassLoader反射信息内存碎片化严重。我做了两个调整一是改用ObjectMapper并配置PropertyNamingStrategy减少不必要的getter调用二是把消息体瘦身只推orderId和status两个字段详情让前端按需查API。javapublic class OrderStatusDTO {private String orderId;private Integer status;// 只保留必要字段避免序列化膨胀}还有个没写进文档的坑浏览器同一域名限制6个连接。如果用户开了多个监控页面第7个WebSocket就会pending。我在网关层加了LimitRequestRate限制单IP最多3个活跃连接超出就返回429。最后交付时P99延迟从8.2秒降到300ms以内数据库QPS降了70%。客户技术总监拍我肩膀说“早知道早改了白扛了三个月。”本文基于实际项目经验整理欢迎在评论区交流技术问题。
