什么时候该上负载均衡

负载均衡很少是拍脑袋上的，多数是单机扛不住之后的必然选择。它解决的问题是：一台机器的容量到了头，把请求分给多台。上早了是浪费，上晚了是事故，判断时机看几个明确信号。 单机到顶的信号 一是 CPU 或内存长期在 70% 以上，升配已经到顶，机型升到 16 核还盖不住高峰；二是响应时间劣化，高峰时段 P95 响应（最慢的 5% 请求所在的耗时线）从 200 毫秒涨到 1 秒以上，用户可感知卡顿；三是单点焦虑，这台机器一重启全站就断，业务已经接受不了。占两条就可以规划横向扩展。这些数字不用精确测量，云控制台的监控图表看一周就有结论：曲线天天顶着上限走，就是明确的扩容信号。 会话保持是第一道坎 Web 应用一旦部署两台，登录态就出问题：用户在 A 机登录，下一个请求落到 B 机就被踢出。两条路：负载均衡层配会话保持，比如 Nginx 里用 hash $cookie_jsessionid 让同一用户固定落同一台；或者干脆把 session 外置，PHP 配置里改 session.save_handler = redis，两台机器共享一个 Redis（内存缓存服务），以后扩到八台也不用再改。后者更彻底，推荐。 成本账怎么算 两台 4 核加负载均衡，通常比一台 8 核贵一点，多买的不只是算力，还有可用性：一台故障另一台继续接流量，发布时逐台更新可以做到不断服。负载均衡还自带健康检查，后端机器挂了自动摘除，故障从用户可感知变成后台一条告警，这个价值往往比省下的机器钱更实在。业务只是偶发高峰，先把单机升满往往更划算；高峰是常态、停机损失大，负载均衡才是正解。 机器与配套 后端节点配置一致最省心，比如两台顺云 S4 做双节点。负载均衡本身从软件方案起步即可，Nginx 的 upstream 十几行配置就能跑起来，不必一上来就追求复杂架构。 上负载均衡之前，先把 session 外置和静态资源分离做完，扩展会顺利得多。