2026-11-14 08:23:13 k73游戏之家 作者：testai
反向代理这台机器经常被当成配角：反正只是转发，随便找台空闲的机器顶上就行。真跑起来才发现，白天还好，一到晚间高峰连接数堆上去，内存被啃干、CPU 被加密握手占满，后面所有业务跟着卡。到底要给它多少内存、要不要单独一台、什么情况下该拆成两台，这些问题得按真实负载来算，拍脑袋配的容量撑不过一个活动。
每一条活跃连接都占资源，大头在内存。连接建立之后，代理层要保存连接状态、读写缓冲区、TLS 会话信息，每条连接几百 KB 到一两 MB 不等，一万条并发就是几个 GB，这还不算应用层的请求头和响应缓存。
CPU 的消耗集中在加密和压缩。TLS 握手、内容压缩、协议转换都在这里，握手是突发型的，连接数一涌上来 CPU 的使用率会瞬间冲高。开了压缩更明显，文本类内容压缩比高但很吃单核性能，机器核数不够就会排在握手后面。
磁盘基本不参与，除非开了缓存。把这台机器配一块很大的机械盘意义不大，反而拖慢日志写入。固态小盘足够，日志单独挂一个卷、按天切分，别让日志把主盘写满，这个坑在流量大的站点上很常见。
网络才是这类机器真正的价值所在。代理层是流量的第一道关口，端口带宽、线路质量、丢包率直接决定用户体验，一台内存刚好够用但线路差的机器，比一台内存充裕但线路稳的机器差得远。挑机型的时候把线路放在配置前面考虑。
连接表的大小也要看。系统层面能维护的并发连接有上限，默认值往往偏小，需要按实际需求调大文件句柄数和连接跟踪表。不调这两项，机器内存再多也接不住请求，表现是连接被直接拒掉，看起来像被打挂了。
监控指标要挑对的看。活跃连接数、握手耗时、上游响应时间、内存占用曲线，这四个能覆盖大部分问题。只看 CPU 使用率容易被误导，很多卡顿发生在 CPU 没满但连接排队的时候。
经验算法是峰值并发乘以单连接开销，再留五成余量，这个余量不是浪费，是给突发流量、连接残留和内存碎片留的缓冲，算得太满的机器一遇高峰就开始回收内存，响应会断崖式下滑。单连接开销可以实测：空载时记一次内存，压到目标并发再记一次，差值除以并发数就是每条连接的实际占用，测试时把业务完整跑起来，别只用一个空接口压测，真实业务里的请求头和响应体都是要占内存的，压测结果才算数。这个数比任何估算都准，各家的配置和模块不同，差别不小，同一台机器开不开缓存、开不开压缩，单连接开销能差出一倍，所以要按你实际用的那套配置来测。
并发不等于在线人数。一个人开着页面可能产生十几条连接，图片、接口、长连接各占一条，算容量的时候要按连接数而不是人数，浏览器复用连接之后这个比例会降一些，但别指望降到一比一。看着只有两千人在线，实际连接数可能已经上万，这是最容易低估的一项，估容量的时候按连接数打八折算可用余量更稳。
长连接会持续占内存。即时通讯、推送、直播弹幕这类业务，连接建立后长时间不断开，内存占用只增不减。这类场景的容量规划要按最长驻留时间算，还要防住那只连接不读不写的死连接，配个心跳和空闲回收，别让僵尸连接慢慢把内存啃光。
放在最外层做统一入口是最常见的做法：证书集中管理、访问控制集中做、后端换机器不影响用户。这样一台机器承担全部流量入口，配置得好效率很高，缺点是它成了单点，一旦挂了全站不可用，所以外层单点就得靠备用机和快速切换来兜。
也可以放在内层做业务网关。外层交给 CDN 或者云厂商的负载均衡，内层这台北向转发、做鉴权和限流。这种分层的好处是外层可以靠服务商兜住攻击，内层按业务需要精细控制，代价是多一跳，延迟略微上升，跨境业务要把这一跳的耗时算进预算里。
如果后端是多个不同业务，按业务拆网关比堆在一台上更好。每个业务的限流策略、超时时间、缓存规则都不一样，混在一起配置会互相克制。拆开之后每台压力小，出问题的影响面也小，配置也能各自调优，不用为了一个业务的特殊需求影响全部站点，维护窗口也更容易安排，改动的影响可预期。
放在数据库前面做读写分离的入口也很常见，这一层的稳定性直接决定数据库能不能扛住。这类网关要做连接池复用，后端连接数是固定的，前端并发再高也不会把数据库连接打爆，排队会发生在网关而不是数据库，救火的位置也更好找，这个价值比转发本身更大，数据库的连接数是最贵的资源，用网关把它锁住，比给数据库加内存划算得多。
证书轮换要在网关做，不要在每个后端各做一遍。集中做的好处是一处更新全站生效，坏处是更新那一刻的缓存和会话要处理好，否则会出现部分用户证书校验失败。更新前先在备用端口验证一遍，再切主入口。
会话票据的密钥要同步。多台网关做同一组后端的前端时，密钥不一致会让客户端在机器之间跳转时反复完整握手，握手开销翻倍。这类问题不报错，只表现为高峰期延迟变高，很难一眼看出来。
健康检查的间隔别设太短。一两秒一次的检查在几十台后端上就是持续的额外请求，后端本来就忙的时候等于自己给自己加压。五秒左右，连续三次失败再摘除，这个参数在多数场景够用。
被动检查和主动检查要配合。主动检查能提前发现后端不可用，被动检查能在真实请求失败时立即摘除。只做其中一种都会有盲区，主动检查发现不了的慢响应，被动检查能抓到；被动检查抓不到的彻底宕机，主动检查能提前发现。
摘除和恢复要防抖。后端刚恢复就立刻放量，很容易把它再次打挂，形成反复抖动。恢复时先放少量流量，观察一小段时间再全量，这个渐进过程能避免大部分二次故障。
超时时间要分层设置。客户端到网关、网关到后端、后端到数据库，三段超时不能一样长，后一段要比前一段短，这样出错时能快速失败并给出明确错误，而不是所有层一起等。全部设成同一个值是最常见的配置错误。
重试策略要谨慎。默认对失败请求自动重试，遇到非幂等接口会造成重复提交，用户在页面上看到两次扣款。只对读请求重试，写请求交给业务层自己处理，这条规则写死在配置里更安全。
先分段计时，把每一段都量出来再动手。客户端到网关、网关内部处理、网关到后端，三段各记一个耗时，哪段突出一目了然，慢在网关内部就要看配置和连接状态，慢在后端就得往业务侧查。网关日志里加上这三个时间戳，成本很低，排查效率提升非常明显，也不用每次出问题都靠猜。
再看连接复用这一项，它经常是隐藏的瓶颈，不开的时候看不出来，一压就露。网关到后端如果不复用连接，每个请求都要新建一次，后端会被握手和连接建立拖慢。开启长连接并设定合理的空闲回收时间，后端压力能降一个档，代价是后端要保持一定数量的常驻连接，容量规划里要算进去，空闲回收时间设得太短等于白开。
接着看队列。慢往往不是算得慢，而是排队排得久。把当前等待处理的请求数和等待时长监控起来，队列长度一旦持续上升，说明容量到顶了，加配置或者加机器就是这时候该做的事，早一步处理比事后救火省心，也能避免一个网关拖垮全部业务。
再往下看 DNS 和上游解析。后端地址如果用域名，解析慢或者解析结果过期会带来偶发的长尾延迟，表现是大部分请求很快、少数请求特别慢。把解析结果缓存住并定期刷新，这类尖刺会消失，顺手把上游地址写成多个备用，解析失败时还能切过去，别把上游全部写成同一个域名。
先看可用性要求。对外服务的站点，网关是单点，挂了全站打不开，这种场景基本要两台。内部系统或者低频后台，一台加快速恢复预案也能接受，把预算花在别处更值。
两台要注意会话一致性。做同一组后端的前端，配置要完全一致，否则用户在机器之间跳转会出现登录态丢失。配置用版本管理统一推送，别手工在两台上改。
再算成本。两台中配往往比一台顶配便宜，故障时仍有一半容量可用，切换窗口短。云途 700 元档那台做前端网关足够，64GB 内存撑住上万并发没问题；真要扛大规模入口，SixTyNet 的大内存机型更适合把缓存和连接池都放在同一台机器上。
别忘了后端也要有余量。网关扩容之后压力会全部传导到后端，后端扛不住等于白扩。扩容前先确认后端的连接数和处理能力，两边一起加才不会出现「前端很顺、后端排队」的尴尬。
留一套降级方案。两台网关同时出问题时，能不能直接让用户访问后端地址，或者切到静态维护页，这个预案平时演练一次，真出事的时候能省下大量解释成本。预案写在文档里、脚本存在机器上，别只存在某个人脑子里。
容量要定期复算。业务在长，连接数每个季度都在变，一年前算出来的容量今年可能已经不够。把复算排进例行维护，比等到报警再临时扩容从容得多，也能提前发现线路和配置上的短板。
