摘要：你是不是也在网关选型上犯了难？领导要性能、业务要定制、运维要稳定，翻遍开源社区，要么是 Spring Cloud Gateway 不够灵活，要么是 Kong 二次开发成本太高，直到有人提了 “OpenResty/Nginx + 自研网关” 的路线，团队反而吵翻
你是不是也在网关选型上犯了难？领导要性能、业务要定制、运维要稳定，翻遍开源社区，要么是 Spring Cloud Gateway 不够灵活，要么是 Kong 二次开发成本太高，直到有人提了 “OpenResty/Nginx + 自研网关” 的路线，团队反而吵翻了天 —— 有人说这是重复造轮子，有人骂纯开源是技术摆烂。
其实这事没那么复杂，今天咱们就掰扯清楚两种路线的核心冲突，再给你看两个真实案例，最后帮你敲定适合自己团队的方案。
做技术选型从来不是 “非黑即白”，但 OpenResty + 自研与纯开源路线的冲突，恰恰藏在开发最关心的 3 个地方：
纯开源路线的支持者总说 “站在巨人肩膀上”，比如直接用 APISIX，开箱就能支持限流、熔断、日志收集，初期开发成本几乎为零。但做过复杂业务的都知道，一旦涉及 “定制化鉴权”“多租户流量隔离” 这类场景，改开源源码比自己写还费劲 —— 去年我们团队改 Kong 的插件系统，光是理解 Lua 脚本的执行逻辑就花了两周，最后还因为兼容性问题踩了生产事故。
而 OpenResty + 自研的逻辑是 “基础用成熟组件，核心自己掌控”。Nginx 的网络模型经过二十年验证，性能不用怀疑；OpenResty 提供的 LuaJIT 又能快速实现业务逻辑，相当于 “用成熟底盘改赛车”。但代价是初期要搭框架：路由管理、配置中心、监控告警都得自己做，小团队可能撑不住。
这是运维同学最头疼的冲突。纯开源网关比如 Spring Cloud Gateway，基于 Netty 开发，异步非阻塞模型看着美好，但在 10 万 QPS 的高压下，JVM 的 GC 停顿能让延迟从 10ms 飙到 500ms。我们之前测过，相同硬件配置下，APISIX 的单机 QPS 能到 2 万，而基于 OpenResty 自研的网关能冲到 3.5 万，差的这 1.5 万就是 Nginx 的底层优势。
可性能强不代表省心。纯开源网关有成熟的社区维护，出了问题搜搜文档就有解决方案；但自研网关的监控、扩容、故障排查全得自己扛。有个朋友的团队自研网关上线后，半夜突发流量峰值，排查半天才发现是 Lua 内存泄漏，最后只能临时扩容救场。
业务初期选纯开源的团队，大多想着 “先跑起来再说”，但跑着跑着就发现陷入了 “改不动” 的困境。比如用 Kong 做了半年，突然要加 “灰度发布按用户标签分流”，要么等社区更新，要么自己 fork 分支改 —— 后者看似快，实则埋下技术债务，后续升级社区版本时，合并代码能把人逼疯。
OpenResty + 自研的好处是 “架构可控”，想加新功能直接在框架上叠模块，不用迁就开源代码的逻辑。但前提是初期架构要搭对，比如路由规则用 ETCD 存储、配置变更热加载，这些细节没考虑好，后期迭代照样会变成 “屎山”。我见过一个团队自研网关时图省事，把配置写死在代码里，结果每次改路由都要重启服务，被业务方骂了整整一个季度。
光说理论太空洞，给你看两个我们圈子里的真实案例，说不定能照见你们团队的影子。
杭州有个做 SaaS 服务的团队，初期用 APISIX 做网关，20 人不到的技术团队，确实省了不少事。但随着客户增多，问题来了：不同客户要不同的鉴权逻辑，有的用 OAuth2，有的用 APIKey，还有的要对接企业微信，APISIX 的插件系统根本满足不了，每次加新客户都要改插件代码，还经常影响其他客户。
最崩溃的是去年双 11，一个客户突发流量暴涨，他们想给这个客户单独加限流规则，结果操作失误，把所有客户的接口都限了流，直接损失几十万订单。痛定思痛后，他们花了两个月基于 OpenResty 自研网关：用 Nginx 做转发，Lua 写业务逻辑，配置中心用 Apollo，路由规则动态更新。上线后不仅定制化需求随叫随到，单机 QPS 还比之前高了 2 倍，运维成本反而降了 —— 因为架构是自己搭的，出问题能快速定位。
某大厂的支付网关团队，早在 5 年前就放弃了纯开源路线，选择 OpenResty + 自研。他们的逻辑很简单：支付场景对延迟和稳定性要求极高，开源网关的 “通用逻辑” 无法满足 “毫秒级响应”“零丢失请求” 的需求。
他们的架构很值得借鉴：底层用 Nginx 做 TCP/IP 协议处理，OpenResty 负责 HTTP 层的路由转发，自研模块做支付特有的 “签名校验”“资金链路追踪”“风控拦截”。为了解决运维问题，他们还搭了一套完整的监控体系：Lua 脚本执行耗时、Nginx 连接数、请求失败率，每个指标都能实时告警。现在这套网关每天扛着上亿次请求，延迟稳定在 5ms 以内，去年全年故障时间不到 1 分钟。
有意思的是，他们并没有完全 “重复造轮子”，比如限流模块用了 OpenResty 的 lua-resty-limit-traffic 库，日志模块参考了 APISIX 的设计，相当于 “取开源之长，补自研之短”。
看到这，你可能已经有答案了，但还是给你总结 3 个判断标准，帮你彻底拍板：
10 人以下的小团队，业务初期没太多定制化需求？选成熟的开源网关（比如 APISIX），先把业务跑起来，别一开始就陷在自研的泥潭里。20 人以上、有 Lua/Nginx 开发经验的团队，业务有明确的定制化需求？直接上 OpenResty + 自研，初期多花点时间搭架构，后期能省无数事。业务处于爆发期，未来 1 年可能会加各种定制化功能？优先选 OpenResty + 自研，避免后期被迫转型的痛苦。业务模式稳定，短期不会有大的功能变更？纯开源网关性价比更高，把精力放在核心业务上。最后想说，网关选型没有 “最优解”，只有 “最适合”。那些骂 “自研是重复造轮子” 的，可能没踩过定制化的坑；那些喷 “开源是摆烂” 的，或许没体会过小团队的资源紧张。你所在的团队是更看重灵活性还是开发成本？欢迎在评论区聊聊你的选型经历，也可以问我具体的技术细节，咱们一起避坑～
来源：杜绝说万事