无论是高可用计算架构还是高可用存储架构，它们的核心设计目标均是在部分服务器出现故障时确保系统能继续运行。然而，在极端情况下，如机房断电、火灾、地震或洪水等，可能导致一个地点的所有服务器同时出现故障，使得整个业务系统瘫痪。即便依靠其他地区的备份系统，全面恢复业务的时间也可能较长，从半小时到12小时不等。备份系统由于平时不提供服务，可能存在许多未被发现的潜在问题。如果业务需求是在这种灾难性故障发生后也能保持业务连续性，或者希望在几分钟内快速恢复服务，那么就需要采用异地多活架构。
接下来，我将继续探讨异地多活架构的设计技巧和实施流程。
图片
应用场景
异地多活架构的核心概念包括“异地”和“多活”，其中“异地”指的是将系统部署在地理位置分散的不同地点，类似于常说的“不把所有鸡蛋放在一个篮子里”的策略；而“多活”意味着这些地理上分散的系统都处于活跃状态，随时能够提供业务服务。要判断一个系统是否实现了异地多活，主要看以下两点：
在正常情况下，无论用户连接到哪个地点的系统，都能够接收到一致且正确的服务。
当某地的系统出现异常时，用户可以无缝连接到其他地点的系统，继续获得所需服务。
相对于“多活”的“备”更多指的是备份系统，这类系统通常不对外提供服务，只在主系统出现问题时，经过一系列人工操作后才能变“活”，这个过程通常耗时较长。
虽然从理论上讲，异地多活架构能够提供极高的业务连续性，即使在面临灾难时也能保证业务不中断，但这并不意味着所有业务都必须实现异地多活。实际上，异地多活架构的成本和系统复杂度都非常高。具体体现在：
- 系统设计复杂度显著增加，需要构建一个在多个地点同时活跃的复杂系统架构。
- 运行成本提高，因为需要在多个数据中心部署并维护相同的业务系统。
因此，并非所有业务都适合采用异地多活架构。对于一些新闻网站、内部IT系统、游戏和博客等，如果不能承担高昂的成本和复杂度，可以选择仅进行异地备份。这类业务即便暂时中断，也不会对用户造成重大影响。例如，如果一个新闻网站暂时无法访问，用户可以选择其他新闻源。
然而，对于像共享单车、网约车、支付宝、微信等关键业务系统，它们的中断会直接影响到用户的日常生活，因此必须实现异地多活架构。此外，对于规模较大的业务，异地多活不仅可以在突发事件中保证服务的连续性，还有助于维护品牌声誉和最小化收入损失。例如，对于新闻网站来说，虽然短时间的服务中断看似影响有限，但从长远来看，频繁的服务中断会损害用户信任，同时也会导致广告收入的直接损失。
架构模式
异地多活架构根据地理位置的分布，可以分为同城异区、跨城异地和跨国异地。这里，我将详细说明每种架构的细节及其优缺点。
同城异区
这种架构涉及在同一城市的不同区域部署多个数据中心。例如，在北京的海淀区和通州区各设有一个数据中心，它们通过高速网络连接。
虽然在极端灾难如全城大停电或洪水时，同城异区可能无法提供保护，但这种设计的优点在于网络延迟极低，可以视为一个逻辑上的单一数据中心，这简化了系统设计，降低了成本和复杂度。
尽管面对如新奥尔良洪水这样的灾难无力回天，但需要注意的是这类极端灾难发生的频率相对较低。相比之下，如数据中心火灾、停电或空调故障这样的常见问题更为频繁，同城异区架构能有效应对这些情况。综合考虑成本、复杂度和故障概率，同城异区为解决数据中心级别的故障提供了最优解决方案。
图片
跨城异地
跨城异地指将业务系统部署在相距较远的不同城市，比如北京和广州，而不是相近的城市如广州和深圳。
图片
跨城部署的主要优点是能有效抵御区域性灾难，如大规模停电或地区性自然灾害。然而，增加的地理距离导致网络延迟增加，这不仅是因为物理距离，还包括中间网络设备处理等因素，这使得设计异地多活架构的复杂度大幅上升。
跨城异地的网络传输速度会受到限制，这是由光速在光纤中的传播速度决定的。此外，网络中断、光缆损坏等不可预测的因素也可能导致连接问题。例如，从广州到北京的机房网络延迟在正常情况下可能为50毫秒，但在网络不稳定时，延迟可能急剧增加。
针对这种架构，必须考虑数据一致性与业务需求。对于要求高数据一致性的服务（如金融服务），跨城异地多活可能不适合，因为数据不一致性可能导致重大错误。而对于数据一致性要求较低的应用，如新闻发布或社交媒体，跨城异地多活则可以提供有效的灾难恢复解决方案。
跨国异地指的是业务部署在不同国家的多个机房。相比跨城异地，跨国异地的距离就更远了，因此数据同步的延时会更长，正常情况下可能就有几秒钟了。这种程度的延迟已经无法满足异地多活标准的第一条：“正常情况下，用户无论访问哪一个地点的业务系统，都能够得到正确的业务服务”。例如，假设有一个微博类网站，分别在中国的上海和美国的纽约都建了机房，用户 A 在上海机房发表了一篇微博，此时如果他的一个关注者 B 用户访问到美国的机房，很可能无法看到用户 A 刚刚发表的微博。虽然跨城异地也会有此类同步延时问题，但正常情况下几十毫秒的延时对用户来说基本无感知的；而延时达到几秒钟就感觉比较明显了。
因此，跨国异地的“多活”，和跨城异地的“多活”，实际的含义并不完全一致。跨国异地多活的主要应用场景一般有这几种情况：
为不同地区用户提供服务
例如，亚马逊中国是为中国用户服务的，而亚马逊美国是为美国用户服务的，亚马逊中国的用户如果访问美国亚马逊，是无法用亚马逊中国的账号登录美国亚马逊的。
只读类业务做多活
例如，谷歌的搜索业务，由于用户搜索资料时，这些资料都已经存在于谷歌的搜索引擎上面，无论是访问英国谷歌，还是访问美国谷歌，搜索结果基本相同，并且对用户来说，也不需要搜索到最新的实时资料，跨国异地的几秒钟网络延迟，对搜索结果是没有什么影响的。
假设我们做了前面提到的高可用存储架构中的数据分区备份，又通过自动化运维能够保证 1 分钟就能将全部系统正常启动，那是否意味着没有必要做异地多活了？
