踩坑记录：brpc Unknown error 1014 协议配置不当引发的自身问题

项目背景近期团队持续拓展新业务方向频繁对接客户端请求流量。各类业务场景逻辑各异交互请求的数据结构也存在明显区别。我们的架构设计是这样整体架构采用统一入口服务收口全量流量再按需分发至下游各微服务。该设计便于后续统一追加通用业务数据例如 AB 实验参数、用户画像信息等。架构示意如下项目现阶段处于初期阶段目前仅实现流量转发能力通用数据增补功能暂未落地。(红色proxy为路由分发服务)客户端与服务端基于 HTTP 协议完成数据交互路由服务和下游业务服务间同样采用 HTTP 协议通信。出现问题项目上线初期整体运行平稳稳定各项接口请求均可正常响应。后续随着业务持续迭代优化平台计划逐步扩容接入更多客户端流量时在此过程中系统突发异常接口请求失败率直接飙升至百分之百同时后台日志批量爆出大量报错信息。http_rpc_protocol.cpp:1044] Fail to write into Socket{id652835031979 fd1160 addr10.2.27.32:32014:50050} (0x7f1b8024efc0): Unknown error 1014 [1014]路由分发服务请求量监控路由分发服务调用下游失败率监控如图所示接口 QPS 维持在 7000 区间时业务运行一切正常。一旦在此基础上进一步放量施压服务调用下游接口的失败率便会瞬间骤升至百分之百待流量回调回落至 7000 阈值后调用异常随即消失服务状态恢复平稳。定位问题项目采用业界知名、性能表现优异的开源 BRPC 框架版本1.15。正因框架口碑与性能优势突出初期排查问题时便直接排除了框架本身存在故障的可能性。首先查询日志捕获到 brpc 抛出Unknown error 1014错误该报错表征网络连接被通信对端强制断开。随后核查下游服务监控数据发现大量请求并未正常抵达下游服务端。初步分析得出结论当 QPS 攀升至临界阈值后路由分发服务发出的大量请求均未能成功送达下游业务服务。定位代码服务与下游建立通信连接时默认采用的是 HTTP/1 协议正是这一配置成为高并发场景下的性能瓶颈。随后将通信协议调整为 HTTP/2重新发布验证后高 QPS 下请求失败率飙升的问题彻底解决服务恢复稳定运行。brpc::ChannelOptions options; options.protocol brpc::PROTOCOL_H2;知识点如有错误请见谅由此便产生疑问为何采用 HTTP1 协议通信时QPS 突破特定阈值就会触发此类异常问题HTTP/1.1 属于串行通信协议单条连接同一时刻仅能处理单个请求需等待上一次请求响应完成后才能发起下一次调用。QPS 升高后连接资源快速耗尽系统会不断新建连接当连接数触及上限便会触发连接强制断开诱因大概率为文件句柄不足或服务端主动断连。而 HTTP/2 支持单连接多路复用可在同一个 TCP 连接内并发处理多路请求连接资源利用率大幅提升。将协议切换为 HTTP/2 后该异常问题得以彻底解决。