公司刚上线的新系统，突然某个机房断电了，用户访问直接卡住。这种时候，有没有提前设计好网络分区和容灾策略，差别可就大了。有人手忙脚乱重启服务，有人却能无缝切换流量，用户体验几乎不受影响。
什么是网络分区
网络分区指的是由于网络故障、设备宕机或配置错误，导致原本连通的服务器之间无法通信。比如北京和上海两个数据中心之间的专线中断，两边的服务各自为政，数据不同步，用户请求可能被发到“失联”的那一边。
这种情况在分布式系统里特别常见。像电商平台搞大促时，如果没做好分区处理，订单服务和库存服务一旦分处两个不可通信的区域，就可能出现超卖或者下单失败。
容灾不是备份那么简单
很多人以为做了数据备份就万事大吉，其实不然。备份解决的是数据丢失问题，但恢复需要时间。而容灾关注的是服务能不能继续对外提供功能，哪怕是在降级状态下。
举个例子：银行系统遇到网络分区，ATM还能取现，但不能查明细。这叫“降级运行”，核心功能还在，这就是容灾做得到位。
常见的分区策略有哪些
面对分区，系统得有明确的行为规范。CAP理论告诉我们，在一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）中只能三选二。既然网络分区不可避免，那就必须在设计时就做取舍。
一种做法是优先保证可用性。比如电商的购物车服务，在分区发生时允许用户继续加购，即使暂时无法同步到另一侧，等网络恢复后再合并数据。这种方式牺牲了一定的一致性，换来用户体验的连续。
另一种是优先保一致。金融类系统通常走这条路。一旦检测到分区，直接拒绝部分写操作，确保两边不会产生冲突数据。虽然服务可能暂时不可用，但数据不会出错。
实际部署中的容灾方案
真正落地的时候，光有理论不够，还得靠架构支撑。常见的手段包括多活数据中心、DNS智能调度、服务熔断与降级。
比如通过 DNS 根据用户的地理位置和机房健康状态，把请求导向正常的服务节点。当某地机房失联，DNS 可以快速切换解析，把流量引到备用站点。
再比如使用 ZooKeeper 或 etcd 这类协调服务来判断集群状态。当主节点失联超过阈值，自动触发选举，让备用节点接管服务。
health_check {
interval 5s;
timeout 3s;
fall 3;
rise 2;
server 192.168.10.11:8080;
server 192.168.10.12:8080;
}上面这段配置就是一个简单的健康检查规则，用于反向代理判断后端服务是否存活。一旦发现异常，立即停止转发请求，避免把用户带到“死”节点上。
别等到出事才想起预案
很多团队平时不演练故障切换，真出了问题才发现证书过期、权限不对、脚本跑不起来。定期进行“故障模拟”很有必要，比如主动断开某个服务的网络，看系统能否自动恢复。
Netflix 的 Chaos Monkey 就是干这个的——每天随机杀掉生产环境里的几个实例，逼着工程师写出更健壮的系统。听起来吓人，但正是这种日常“找茬”，才能在真正灾难来临时稳住阵脚。