异地多活的判断标准，及并非所有业务都值得做的代价权衡

高可用计算架构和高可用存储架构解决的都是”部分服务器故障”这个场景，但机房断电、机房火灾、地震、水灾这类极端情况可能导致整个系统的所有服务器一起瘫痪——即使有异地备份，把备份系统真正恢复到能对外服务，往往也要花半小时到十几小时（因为备份系统平时不对外提供服务，很多隐藏问题只有真正切过去才会暴露），如果业务要求在这类灾难性故障下依然不受影响、或者能在几分钟内恢复，就需要异地多活架构。判断一个系统是否真正做到了异地多活，要满足两条标准：正常情况下用户访问任意一个地点的业务系统，都能得到正确的业务服务；某个地方业务异常时，用户访问其他正常地点的业务系统，同样能得到正确的服务。这里的”活”（活动、活跃）和”备”（备份）是本质不同的两个概念——”备”平时不对外提供服务，真要用起来需要大量人工干预和时间才能切成”活”。虽然异地多活听起来很强大，但实现它的代价并不低：系统复杂度会发生质的变化，需要设计专门的异地多活架构；成本也会明显上升，因为要在一个或多个额外的机房搭建独立的一整套业务系统。因此异地多活不是所有业务都值得上的——新闻网站、企业内部IT系统、游戏、博客站点这类业务，即使中断对用户的实际影响也不大（比如新闻网站看不了，用户换一个就是），承受不起异地多活的复杂度和成本的话，做异地备份就够了；但共享单车、滴滴出行、支付宝、微信这类业务一旦中断，对用户的影响非常直接（支付宝用不了就没法买东西，滴滴用不了就打不到车），就必须做异地多活。而且如果业务规模足够大，即使表面看起来”中断影响不大”，也值得尽量做异地多活——一是能在异常场景下给用户更好的体验，二是大规模业务背后往往伴随着可观的收入（比如广告收入），异地多活能实实在在减少故障期间的收入损失，即便是新闻网站，几个小时不可访问对口碑和广告收入的影响也不能忽视。