Load Balancer 将传入的请求分发到应用服务器和数据库等计算资源。无论哪种情况，负载均衡器将来自计算资源的响应，返回给恰当的客户端。负载均衡器的效用在于:
- 防止请求进入不好的服务器
- 防止资源过载
- 帮助消除单一的故障点
负载均衡器可以通过硬件（昂贵）或 HAProxy 等软件来实现。 增加的好处包括：
- SSL 终结：解密传入的请求并加密服务器响应，这样的话后端服务器就不必再执行这些潜在高消耗运算了（不需要再每台服务器上安装
X.509）； - Session 留存：当 Web 应用程序不追踪 session 时，发出
cookie并将特定客户端的请求，路由到同一实例。
通常会设置采用 active-passive 或 active-active 模式的多个负载均衡器，以免发生故障。
负载均衡器能基于多种方式来路由流量：
- 随机
- 最少负载
- session/cookie
- （加权）轮询调度算法
- 四层负载均衡
- 七层负载均衡
四层负载均衡
四层负载均衡，通过监控传输层的信息来决定如何分发请求。通常，这会涉及来源，目标 IP 地址和请求头中的端口，但不包括数据包（报文）内容。四层负载均衡器，执行NAT来向上游服务器转发网络数据包。
七层负载均衡
七层负载均衡，通过监控应用层的信息来决定怎样分发请求。这会涉及请求头的内容，消息和 cookie。七层负载均衡器，终结网络流量，读取消息，做出负载均衡判定，然后传送给特定服务器。
比如，一个七层负载均衡器能直接将视频流量连接到托管视频的服务器，同时，将更敏感的用户账单流量引导到安全性更强的服务器。
以损失灵活性为代价，四层负载均衡比七层负载均衡花费更少的时间和计算资源（这对现代商用硬件的性能影响甚微）。
水平扩展
负载均衡器还能帮助水平扩展，提高性能和可用性。使用商业硬件的性价比更高，并且比在单台硬件上垂直扩展更贵的硬件具有更高的可用性。相比招聘特定企业系统人才，招聘商业硬件方面的人才更加容易。
缺陷：水平扩展
- 水平扩展引入了复杂度并涉及服务器复制：
- 服务器是无状态的：它们不应该包含 session 或资料图片等与用户关联的数据；
- session 可以集中存储在持久化缓存（Redis、Memcached）或数据库（SQL、NoSQL）的数据存储区中。
- 缓存和数据库等下游服务器，需要随着上游服务器进行扩展，以处理更多的并发连接。
缺陷：负载均衡器
- 如果没有足够的资源配置或配置错误，负载均衡器会变成一个性能瓶颈；
- 引入负载均衡器以帮助消除单点故障，但导致了额外的复杂性；
- 单个负载均衡器会导致单点故障，但配置多个负载均衡器会进一步增加复杂性。