负载均衡就是把流量、服务请求、计算任务或者通信负载分摊到多个资源上，避免单独一台服务器、一个应用、一个网关或者某条网络链路被压垮的过程。
理解这个概念
在今天这个数字化系统里，用户希望网站、应用、通信平台、数据库还有云服务都能快速响应，就算碰到高峰期也能保持在线。要是把所有请求都发给一台机器或者同一个系统组件，那个资源就会变慢、不稳甚至彻底挂掉。负载均衡干的事情，就是把活儿分散到多台可用的资源上。负载均衡器就像一个交通调度员，接到进来的请求，先看看后面有哪些资源可以用，然后按照预先定好的规则或算法，把请求转给最合适的目标。后端这些资源可以是 Web 服务器、应用服务器、数据库节点、流媒体服务器、SIP 服务器、云主机、容器、网关，甚至网络链路。
负载均衡不光是为了快，更是为了让服务在需求变化的时候，仍然能保持可用、可预期，也更容易扩展。
这个过程是怎么跑的
流量从一个共享的入口进来
用户或设备通常连到同一个服务地址、域名、虚拟 IP、网关地址或者应用接口。在这个入口背后，有好多后端系统随时等着接请求，用户根本不需要知道到底是哪台机器在处理。
这种设计既简单了访问方式，又给了管理员很大的灵活性。后端服务器可以随时加、随时摘、随时更新或者隔离，顾客、员工、应用和联网设备用的那个地址完全不用变。
负载均衡器先看看后端能不能扛
好的负载均衡系统不会闭着眼睛瞎转发流量。它会先检查后端资源是不是健康、能不能响应、通不通、还能不能接收新流量。健康检查可能是简单的 ping 测试、端口检查、HTTP 状态码检测、应用层的探测，甚至是自己写的监控脚本。
如果某台后端服务器检查没通过，负载均衡器可以暂时不给它发流量，这样用户就不会被引导到一台坏的或者已经扛不住的机器上。
按照策略来分发请求
看完后端状态之后，负载均衡器再决定每个请求应该往哪儿走。决策可能基于轮询顺序、服务器权重、当前连接数、响应快慢、地理位置、会话保持、请求内容或者自定义规则。
对简单系统来说，一条基本的分发规则就够了。但如果是大流量或者关键业务的系统，策略可能还得把应用自身健康状况、用户会话、服务优先级、安全检测和故障转移这些因素都考虑进去。
典型的负载均衡流程
一个最基本的负载均衡过程可以理解成一个四步走的工作流，这样既能管住流量，也能保护好后端资源。
常见分发方式
轮询
轮询就是按顺序把请求一个一个地轮流发给后端资源。这种方法简单、好理解，在后端服务器性能差不多、请求复杂程度也比较均衡的时候很适用。
不过，要是有的机器性能强、有的比较弱，或者有些请求特别吃资源，轮询就未必合适了。这时候可能得换成更灵活的调度算法。
最小连接数
最小连接数这种方法是把新请求发给当前活动连接最少的那台后端资源。当连接持续的时间长短不一的时候，比如数据库连接、长 HTTP 会话、媒体流或者实时通信服务，这种方式就很有用。
它能避免一台服务器扛着一大堆长连接，而另一台却闲得发慌的情况。
加权均衡
加权负载均衡就是给不同的后端资源分配不同的流量比例。性能更强的机器可以多接一些请求，配置低或者老一些的机器就少接一点。在硬件、云主机或者虚拟机性能参差不齐的时候，这招很实在。
做迁移的时候也能用到权重。管理员可以先放一小部分流量到新版本上，等确认稳定了，再慢慢地把流量比例加上去。
基于内容和应用的路由
更强一点的负载均衡器还会去检查请求里的信息，然后根据 URL 路径、请求头、Cookie、协议、租户标识、应用类型或者服务类别来转发流量。这在 Web 平台、微服务、API 和云原生系统里经常能见到。
比方说，静态内容走一组服务器，API 请求走另一组，实时通信流量则交给专门的流媒体服务去处理。这样一来，整个架构就更灵活、也更高效。
核心功能
健康检查和故障转移
健康检查能让负载均衡器知道后端资源还能不能正常处理请求。只要有一台机器挂了，流量就会自动切到其他资源上去。这样可用性就提高了，因为一台机器出问题不会拖垮整个服务。
故障转移的行为一定要仔细测试。管理员得清楚系统多久能感知到故障、已有的会话会受什么影响，以及故障机器恢复以后流量又是怎么回来的。
会话保持
有些应用需要用户在一个会话期间始终连着同一台后端服务器，这就叫会话保持、粘性会话或者会话亲和性。这种机制可以基于 Cookie、源 IP、令牌或者应用标识来实现。
会话保持对那些把临时会话状态存在本地的应用很有用。但用的时候得小心，因为如果太多用户都黏在同一台后端资源上，流量分发的效果就会打折扣。
SSL 卸载
很多负载均衡器可以在前端处理 SSL 或 TLS 加密。也就是说，加密的客户端流量到了负载均衡器先解密，然后再转发给后端服务器。SSL 卸载能简化证书管理，还能减轻后端系统的加密运算负担。
在安全要求比较高的环境里，负载均衡器和后端服务器之间的流量也可以继续保持加密。具体怎么设计，得看安全需求、网络信任边界、合规要求以及性能指标。
流量可以从故障或者亚健康的资源上自动引开，在出现局部问题时仍能保持服务在线。
请求被分散到多台资源上，单台服务器的压力小了，响应也更平稳。
需求涨了，只要在负载均衡器后面加新的服务器、节点或者服务实例就行。
主要收益
服务可靠性更高
负载均衡能避免单独一个资源成为唯一服务点，从而提高可靠性。就算有一台后端服务器挂了，健康的机器照样能接着扛流量。
这并不能替代完整的高可用设计，但却是其中非常关键的一环。一个真正可靠的服务可能还需要冗余的负载均衡器、多条网络路径、复制好的数据库、备用电源、监控系统以及灾难恢复计划。
用户体验更好
流量有效分摊之后，用户碰到页面半天打不开、请求失败、掉线或者服务卡死的概率就低多了。这对网站、在线平台、客户门户、云应用、通信服务还有内部业务系统都特别重要。
高峰期的时候，用户体验尤其敏感。一个平时跑得挺顺的系统，可能在促销活动、新品发布、季节性高峰、公共事件或者突发状况面前直接崩掉。
维护更加灵活
负载均衡能让维护工作轻松不少，因为后端资源可以随时摘下来，升级、测试完了再放回去，完全不用停掉整个平台。管理员可以从一台服务器上把流量排干，让其他机器继续服务用户。
这对软件升级、打安全补丁、换硬件、改配置以及新版本的灰度发布都很有用。
典型应用场景
网站和 Web 应用
Web 平台普遍用负载均衡把 HTTP 和 HTTPS 流量分摊到多台 Web 服务器或应用服务器上。这样网站就能承载更多访客，保持快速响应，并且不会因为一台机器宕机就整体瘫痪。
对于现在的 Web 应用来说，负载均衡还可以根据应用规则，把 API 调用、静态资源、用户会话以及微服务请求分别路由到不同的后端集群。
云与容器环境
云平台和容器系统严重依赖负载均衡，因为服务实例会被动态创建、替换、伸缩或者迁移。即使后端资源一直在变，负载均衡器也能提供一个稳定的入口。
在容器编排环境里，负载均衡可能在多个层面同时运行，包括入口控制器、服务网格路由、节点级负载均衡以及外部的云负载均衡器。
通信与流媒体服务
通信平台可能把负载均衡用在 SIP 信令、媒体服务、会议系统、消息网关、录制服务和 API 访问上。设计方案时必须考虑协议行为、会话保持、NAT 穿透、延迟以及实时媒体的质量。
语音或视频这类服务，光靠普通 Web 风格的均衡往往不够。管理员要确认负载均衡器是否理解相关的协议，媒体流的路径是否需要特殊处理。
数据库与内部平台
数据库负载均衡可以分担读流量，把应用引导到可用的数据库副本上，或者在节点之间支持故障转移。企业内部平台也可能把负载均衡用于认证系统、文件服务、监控平台和业务应用。
数据库层面的负载均衡得好好规划，因为数据一致性、写请求路由、复制延迟以及事务行为都可能影响业务逻辑的正确性。
规划时的考虑点
选对工作层
负载均衡可以在不同层上工作。四层负载均衡主要处理 IP 地址和端口，而七层负载均衡能看懂应用层的信息，比如 HTTP 头、URL、Cookie 和请求内容。
四层通常处理普通流量比较快、效率也高。七层则能为 Web 应用、API 和基于应用内容的路由策略提供更智能的调度。具体怎么选，得看协议类型、性能要求、安全检测和路由复杂度。
别留下隐藏的单点故障
把一台负载均衡器挂在很多服务器前面，的确能改善后端分发，但如果这台负载均衡器自己没有做冗余，它自己就成了单点故障。关键系统通常会采用主备或者双活的负载均衡器对。
同时，网络路径、DNS、证书、防火墙策略、监控系统和管理入口也都要复查一遍。光有一个高可用的后端池子还不够，要是入口那条路本身很脆弱，一切都是白搭。
关注真实性能表现
负载均衡需要持续监控。重要的指标有请求数量、响应时间、错误率、活动连接数、后端健康状态、带宽占用、CPU 负载、内存使用、队列长度以及失败的健康检查次数。
报表能帮管理员调优算法、调整后端容量、找出瓶颈，并决定什么时候该横向扩展。没有监控的话，负载均衡可能会把问题藏得很深，直到用户开始投诉才发现。
设计上的实用提醒
别把负载均衡器当成什么性能魔法棒。只有当后端系统本身健康、监控到位、容量规划切合实际，而且故障转移行为在真正出故障之前就做过充分测试，它才能发挥出最好的效果。
维护小贴士
复查健康检查设置
健康检查应该反映服务的真实可用情况。一台服务器可能 ping 得通，但上面的应用其实已经挂了。应用层级的检查通常更有价值，因为它们能确认服务是否真的能干正事。
健康检查的时间间隔和判定失败的阈值也要调好。太激进的检查可能会在短暂抖动时就把正常机器踢出去，而太慢的检查又可能一直往坏了的资源上发流量。
测试故障转移和恢复
故障转移行为应该在计划性维护时测好，别等到线上出事了才去“发现”。团队需要验证：当一台后端服务器挂了、负载均衡器自己挂了、某条网络路径断了，以及恢复后的服务器重新加回池子的时候，分别会发生什么。
测试既要看技术指标，也要看对用户的实际影响。有时候在日志里看着是成功切过去了，但如果状态处理没设计对，还是可能引起掉线或者业务报错。
保持证书和策略是最新的
如果负载均衡器做了 SSL 卸载，那就得管好证书过期的问题。证书一旦过期，一个明明好好的服务在用户看来也会像是挂了。安全策略、加密套件、访问规则和日志配置也应该定期检查。
在受监管的环境里，管理员还应该把证书变更、访问策略更新和流量处理规则都记录下来，方便审计和排查问题。
常见问题
负载均衡能提升安全性吗？
当它和 SSL 卸载、访问控制、流量过滤、Web 应用防火墙集成、速率限制以及日志记录这些功能配合在一起时，确实能帮助加强安全。但单靠它本身，还算不上一个完整的安全方案。
负载均衡和故障转移有啥区别？
负载均衡负责把正常流量分摊到多个资源上；故障转移则是在某个资源出问题后，把流量挪到另一个还能用的资源上。很多系统两者都用，但它们解决的是服务可靠性当中不同层面的问题。
小网站都需要负载均衡器吗？
不一定。流量很小的小网站，单台服务器就能跑得挺好。当服务的在线时长、流量增长、维护灵活性或者性能稳定性变得重要起来的时候，负载均衡的价值才会明显体现出来。
如果配错了，负载均衡会惹出麻烦吗？
会的。会话保持设得不对、健康检查太弱、路由规则写错、证书过期或者后端权重失衡，都可能导致登录失败、交易中断、服务死循环，或者流量集中到错误的服务器上。
负载均衡规则多久检查一次比较好？
应用有大改动、流量明显增长、换过服务器、迁到云上、更新过证书，或者反复收到性能方面的投诉之后，都应该重新检查规则。对于关键业务，定期检查应该是常规运维的一部分。
