面对流量高峰，网关怎么扛住不崩
你有没有遇到过这种情况：双十一大促刚开场，自家平台的接口突然全部超时，用户疯狂刷新页面，客服电话被打爆。排查一圈下来，问题不在数据库，也不在业务服务，而是卡在了最前面的那道门——网关上。
网关作为所有请求的统一入口，一旦扛不住高并发，整个系统就会瘫痪。而其中最关键的一环，就是路由选型。选错了，再多服务器也救不回来。
别拿Nginx当万能药
很多团队一开始都会用Nginx做反向代理，简单稳定，配置也熟。但当QPS（每秒请求数）冲到几万甚至十几万时，你会发现它的动态路由能力太弱。每次加个新服务，就得改配置、reload，一不小心就抖一下，线上请求全卡住。
比如你公司上了个直播带货功能，临时要接入一堆短视频微服务，这时候还靠手动改Nginx配置，等你改完，黄金流量早就跑了。
为什么得考虑API网关？
真正的高并发场景下，得用专门的API网关，像Kong、Zuul、Spring Cloud Gateway这些。它们支持动态路由，服务注册上去，网关自动发现，不用人工干预。
Kong基于OpenResty，用Lua写插件，性能强，适合大流量场景。我们见过一个电商平台，在大促前把Nginx换成Kong，配合Consul做服务发现，QPS从8000直接干到6万，没再出现过批量超时。
<!-- Kong路由配置示例 -->
<http>
<server>
<name>product-service</name>
<host>192.168.1.10</host>
<port>8080</port>
</server>
<route>
<paths>/api/product/*</paths>
<service>product-service</service>
</route>
</http>自研还是用现成的？
有些公司喜欢自研网关，觉得更贴合业务。但真要做起来才发现，光是路由匹配算法优化、连接池管理、熔断限流这些模块，就得搭个五人小组干半年。
除非你有极特殊的协议或性能要求，否则建议先用成熟的开源方案。Kong插件生态丰富，限流、鉴权、日志都能通过插件快速接入；Spring Cloud Gateway则和Java生态无缝集成，适合微服务架构已经成型的团队。
别忘了压测和灰度
不管选哪个方案，上线前必须做全链路压测。我们见过一个案例，某金融App换了新网关，没做足够压测，结果发红包活动一开，网关CPU直接飙到100%，整个交易流程卡死。
正确的做法是：先在测试环境模拟百万级请求，观察延迟和错误率；再通过灰度发布，让10%流量走新网关，没问题再逐步放量。这样哪怕出问题，影响也能控制住。
路由选型不是技术炫技，而是为了保障业务不掉链子。选对了，大促时你能安心吃饭；选错了，只能蹲在服务器前刷日志。