分布式系统真的离不开负载均衡吗？
很多人一听到“分布式系统”，脑子里马上蹦出几个词：高并发、微服务、集群，还有就是——负载均衡。好像不用负载均衡，整个系统就不够“分布式”似的。但实际情况真是这样吗？
其实，负载均衡并不是分布式系统的强制标配。它更像是一个“优化工具”，而不是“入场门票”。
没有负载均衡的分布式系统长什么样？
想象一下你开了家连锁奶茶店，每家店都独立运营，有自己的原料、员工和收银系统。顾客去哪家店，完全凭自己喜好，比如离得近或者排队少。这种模式下，并没有一个中央调度员来分配客流，但各门店之间依然构成了“分布”的结构。
在技术上也类似。早期的一些分布式应用，比如某些P2P网络或简单的服务集群，节点之间直接通信，靠客户端自己选择连接哪个节点。这时候根本没有负载均衡器的存在，系统照样跑得起来。
比如，一个简单的Redis主从架构，客户端可以直接配置连接主节点写数据，从节点读数据。只要客户端自己处理好节点选择逻辑，中间不需要Nginx或HAProxy这类负载均衡设备。
那什么时候非用不可？
当你的服务节点多了，用户请求量上来了，问题就开始冒头了。比如某个节点CPU飙到90%，另一个却闲着喝茶；或者某台机器挂了，用户还在不停地往它发请求，导致大量超时。
这时候，负载均衡的作用就显现出来了。它像个交通指挥员，把请求合理地分到各个后端节点，避免“旱的旱死，涝的涝死”。
常见的做法是加一层Nginx：
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
server {
location / {
proxy_pass http://backend;
}
}这样一来，外部请求先打到Nginx，再由它转发到后端三台服务器中的某一台。即使其中一台挂了，Nginx也能自动剔除，保证服务不中断。
不用会怎样？
可以不用，但代价不小。比如客户端得自己实现重试、熔断、节点健康检查这些逻辑。原本简单的一个HTTP调用，可能要写一堆判断代码。时间一长，维护成本反而更高。
更麻烦的是故障排查。当用户反馈“有时候能访问，有时候不行”，你得一个个节点去查日志、看资源使用情况。而如果有负载均衡，一眼就能看出流量分布是否均匀，哪个节点响应慢，问题定位快得多。
所以，虽然技术上“可以不用”，但实际生产中，几乎没人会主动放弃负载均衡。就像你不会让顾客自己记住所有奶茶店地址再去选一家排队最少的，那样体验太差。
替代方案也不是没有
现在有些服务网格（Service Mesh）架构，比如Istio，把负载均衡的能力下沉到了Sidecar里。每个服务实例旁边跑一个Envoy代理，自动完成流量调度。这时候你看不到独立的负载均衡服务器，但功能其实还在。
还有的系统用DNS轮询做简单的负载分发。每次解析域名时返回不同的IP地址。虽然不够智能，但在小规模场景下也能凑合用。
说到底，负载均衡的核心目标是让系统更稳定、更好维护。形式不重要，关键是能不能应对真实场景里的流量波动和节点故障。