负载均衡解决的是“流量分发”不是所有性能问题。前言在企业业务访问量增长后很多技术团队都会想到一个方案负载均衡于是架构变成用户↓负载均衡↓多台服务器看起来非常合理。甚至已经具备了高可用横向扩展流量分发能力。但很多企业上线后却发现服务器压力依然很大。甚至CPU持续高负载数据库响应变慢用户访问卡顿为什么会这样问题往往不在负载均衡本身。一、负载均衡≠压力消失这是最大的误区。很多人认为原来一台服务器承担100%的流量。部署三台服务器后。每台只承担33%。理论上没错。但现实情况是请求被分散了问题没有消失负载均衡只是把流量分配出去。并不会减少业务总量。例如原来1000个请求↓1台服务器现在1000个请求↓3台服务器请求依然是1000个。二、数据库才是真正的瓶颈这是企业最常见的问题。架构负载均衡↓Web服务器 × 多台↓数据库 × 1台看起来已经集群化。但实际上所有请求最终都要访问数据库。结果Web压力下降了。数据库压力暴涨。很多项目最后发现CPU最高的不是应用服务器。而是数据库服务器。三、应用程序本身效率太低很多团队把性能问题归结于服务器。实际上问题可能出在代码。例如一个页面请求执行50次SQL查询。即使部署10台服务器。问题依然存在。因为低效代码会被复制到每台服务器。负载均衡无法优化代码。四、缓存体系缺失很多企业部署了负载均衡。却没有部署缓存。结果每个请求都访问数据库。用户访问首页查数据库。用户刷新页面再查数据库。用户搜索继续查数据库。数据库压力持续增加。常见缓存方案RedisMemcachedCDN缓存往往比增加服务器更有效。五、会话Session配置错误这是很多企业忽略的问题。用户登录后请求被分发到不同服务器。如果Session没有共享用户会频繁掉线。很多团队为了避免这个问题开启会话保持。结果大量请求被固定到某一台服务器。负载均衡失去意义。出现部分服务器很闲。部分服务器很忙。六、负载均衡算法选择错误常见算法轮询Round Robin最少连接Least ConnectionsIP Hash不同业务适合不同算法。例如长连接业务。使用普通轮询。可能导致负载极不均衡。最终流量没有均匀分布。七、健康检查配置不合理很多企业配置健康检查间隔过长。服务器已经异常。负载均衡却没有及时发现。结果大量请求继续发送到故障节点。用户访问失败。看起来像服务器压力很大。实际上流量分配已经失衡。八、带宽成为新瓶颈很多人只关注CPU内存却忽略网络带宽尤其是图片站下载站视频站即使服务器性能充足。带宽被占满后。用户依然会感觉网站很慢。九、负载均衡之后监控不到位很多企业部署完负载均衡后只看整体流量。却不知道哪台机器压力最高。哪台机器异常。最终问题被隐藏。直到故障发生才发现。十、架构扩容不等于性能优化这是最核心的一点。很多企业认为服务器不够↓增加服务器↓问题解决实际上性能问题可能来自数据库缓存网络程序存储如果真正瓶颈没有解决。增加服务器只是延后问题。十一、什么情况下负载均衡最有效负载均衡最适合Web服务API服务高并发访问无状态应用这类场景可以很好地实现横向扩展。十二、真正正确的优化思路成熟企业通常按照顺序优化第一步定位瓶颈第二步优化程序第三步增加缓存第四步优化数据库第五步增加服务器第六步部署负载均衡而不是一开始就堆机器。总结很多企业部署了负载均衡服务器压力依然很大。原因并不是负载均衡没用。而是数据库成为瓶颈程序效率低没有缓存带宽不足监控缺失架构设计不合理记住一句话负载均衡解决的是“流量分发”问题而不是“性能优化”问题。真正成熟的架构优化不是简单增加服务器数量。而是找到真正的瓶颈然后针对性优化。