做系统开发或者运维的时候，经常会听到“这儿有性能瓶颈”“那儿卡住了”。可到底什么是性能瓶颈？它又跟路由设置有啥关系？其实没那么玄乎，咱们用大白话把几个常见术语掰扯清楚。
响应延迟（Latency）
你点个按钮，页面半天不动，等得都想刷新了——这就是高延迟。在路由层面，可能是请求经过的节点太多，转发链条太长，数据绕了远路。比如微服务架构里，A服务调B服务再调C服务，中间任何一个环节慢下来，用户端就感觉“卡”。
吞吐量（Throughput）
简单说就是单位时间内能处理多少请求。好比高速收费站，每分钟只能通过10辆车，哪怕车不多也不堵，但整体通行效率上不去。在API网关或负载均衡路由中，如果后端服务吞吐能力不足，路由再智能也救不了场。
并发连接数（Concurrent Connections）
想象一下客服热线，同时只能接20个电话，第21个打进来就占线。服务器和路由设备也有类似限制。当大量用户同时访问，连接数超过阈值，新的请求就会被丢弃或排队，这时候你就得查是不是路由层的连接池配置太保守。
CPU/内存占用率过高
这就像手机开太多App，风扇狂转还发烫。服务器CPU跑满100%，很可能是因为路由规则太复杂，比如正则匹配写得太重，每次请求都要做大量计算判断。这种情况别光想着加机器，先看看能不能简化路由策略。
阻塞点（Bottleneck Point）
系统像水管，某个地方突然变细，水流就被卡住了。这个“变细”的位置就是阻塞点。比如某个微服务实例响应特别慢，上游所有依赖它的请求都会堆积，导致整个调用链瘫痪。通过路由设置可以实现熔断、降级，绕开这个“堵点”。
背压（Backpressure）
上游拼命发数据，下游处理不过来，结果越堆越多，最终崩掉。这在消息队列和流式路由中很常见。合理的路由设计应该能感知下游压力，自动减缓流量输入，就像快递分拣中心看到仓库满了，就暂时放缓收件速度。
代码示例：简单的限流路由配置
以Nginx为例，通过路由规则限制每个IP的请求频率，防止突发流量拖垮后端：
limit_req_zone $binary_remote_addr$ zone=api_limit:10m rate=10r/s;
location /api/ {
limit_req zone=api_limit burst=20 nodelay;
proxy_pass http://backend;
}这段配置的意思是：按客户端IP做限流，平均每秒不超过10次请求，突发最多放行20次。超出的部分直接拒绝，保护后端服务不被冲垮。
冷启动问题
新服务刚上线，缓存没热起来，数据库连接没建好，第一波请求特别慢。这时候路由如果不懂缓冲，直接把流量切过去，用户体验就是一顿猛如虎的加载动画。聪明的路由会逐步放量，等服务“热”了再全量接入。
资源争用（Resource Contention）
多个服务共用同一个数据库或缓存，谁都想抢着读写，结果谁也快不起来。路由层可以通过隔离策略，把不同业务线的流量导向不同的资源池，减少打架。