异地多活
前面讲到的高可用计算架构，以及高可用存储架构，其本质的设计目的都是为了解决部分服务器故障的场景下，如何保证系统能够继续提供服务。
但在一些极端场景下，有可能所有服务器都出现故障。例如，典型的有机房断电、机房火灾、地震、水灾……这些极端情况会导致某个系统所有服务器都故障，或者业务整体瘫痪，而且即使有其他地区的备份，把备份业务系统全部恢复到能够正常提供业务，花费的时间也比较长，可能是半小时，也可能是 12 小时。因为备份系统平时不对外提供服务，可能会存在很多隐藏的问题没有发现。如果业务期望达到即使在此类灾难性故障的情况下，业务也不受影响，或者在几分钟内就能够很快恢复，那么就需要设计异地多活架构
应用场景
- 异地多活架构的关键点就是异地、多活
- 其中异地就是指地理位置上不同的地方，类似于“不要把鸡蛋都放在同一篮子里”
- 多活就是指不同地理位置上的系统都能够提供业务服务，这里的“活”是活动、活跃的意思
- 判断一个系统是否符合异地多活，需要满足两个标准：
- 正常情况下，用户无论访问哪一个地点的业务系统，都能够得到正确的业务服务
- 某个地方业务异常的时候，用户访问其他地方正常的业务系统，能够得到正确的业务服务
- 与“活”对应的是字是“备”，备是备份，正常情况下对外是不提供服务的，如果需要提供服务，则需要大量的人工干预和操作，花费大量的时间才能让“备”变成“活”
- 实现异地多活架构不是没有代价的，相反其代价很高，具体表现为：
- 系统复杂度会发生质的变化，需要设计复杂的异地多活架构
- 成本会上升，毕竟要多在一个或者多个机房搭建独立的一套业务系统
- 异地多活虽然功能很强大，但也不是每个业务都要上异地多活。例如，常见的新闻网站、企业内部的 IT 系统、游戏、博客站点等，如果无法承受异地多活带来的复杂度和成本，是可以不做异地多活的，只需要做异地备份即可
- 而共享单车、滴滴出行、支付宝、微信这类业务，就需要做异地多活了，这类业务系统中断后，对用户的影响很大
- 如果业务规模很大，能够做异地多活的情况下还是尽量。首先，这样能够在异常的场景下给用户提供更好的体验；其次，业务规模很大肯定会伴随衍生的收入，例如广告收入，异地多活能够减少异常场景带来的收入损失
架构模式
- 根据地理位置上的距离来划分，异地多活架构可以分为同城异区、跨城异地、跨国异地
- 同城异区
- 同城异区指的是将业务部署在同一个城市不同区的多个机房。例如，在北京部署两个机房，一个机房在海淀区，一个在通州区，然后将两个机房用专用的高速网络连接在一起
- 同城的两个机房，距离上一般大约就是几十千米，通过搭建高速的网络，同城异区的两个机房能够实现和同一个机房内几乎一样的网络传输速度
- 虽然是两个不同地理位置上的机房，但逻辑上我们可以将它们看作同一个机房，这样的设计大大降低了复杂度，减少了异地多活的设计和实现复杂度及成本
- 如果采用了同城异区架构，如果发生水灾、地震等自然灾害，就无能为力了
- 这种极端灾难发生概率是比较低的，可能几年或者十几年才发生一次
- 除了这类灾难，机房火灾、机房停电、机房空调故障这类问题发生的概率更高，而且破坏力一样很大
- 而这些故障场景，同城异区架构都可以很好地解决
- 因此，结合复杂度、成本、故障发生概率来综合考虑，同城异区是应对机房级别故障的最优架构
- 跨城异地
- 跨城异地指的是业务部署在不同城市的多个机房，而且距离最好要远一些
- 例如，将业务部署在北京和广州两个机房，而不是将业务部署在广州和深圳的两个机房
- 跨城异地就是为了解决同城异区不能解决水灾、两个城市离得太近又无法大停电这两类问题的，因此需要在距离上比较远，才能有效应对这类极端灾难事件
- 跨城异地虽然能够有效应对极端灾难事件，但“距离较远”这点并不只是一个距离数字上的变化，而是量变引起了质变，导致了跨城异地的架构复杂度大大上升
- 距离增加带来的最主要问题是两个机房的网络传输速度会降低，光速真空传播大约是每秒 30 万千米，在光纤中传输的速度大约是每秒 20 万千米，再加上传输中的各种网络设备的处理，实际还远远达不到理论上的速度
- 除了距离上的限制，中间传输各种不可控的因素也非常多。例如，挖掘机把光纤挖断、中美海底电缆被拖船扯断、骨干网故障等，这些线路很多是第三方维护，针对故障我们根本无能为力也无法预知
- 虽然同城异区理论上也会遇到，但由于同城异区距离较短，中间经过的线路和设备较少，问题发生的概率会低很多。而且同城异区距离短，即使是搭建多条互联通道，成本也不会太高，而跨城异区距离太远，搭建或者使用多通道的成本会高不少
- 跨城异地距离较远带来的网络传输延迟问题，给异地多活架构设计带来了复杂性，如果要做到真正意义上的多活，业务系统需要考虑部署在不同地点的两个机房，在数据短时间不一致的情况下，还能够正常提供业务
- 数据不一致业务肯定不会正常，但跨城异地肯定会导致数据不一致
- 如何解决这个问题呢？重点还是在“数据”上，即根据数据的特性来做不同的架构。如果是强一致性要求的数据，例如银行存款余额、支付宝余额等，这类数据实际上是无法做到跨城异地多活的
- 支付宝等金融相关的系统，对余额这类数据，一般不会做跨城异地的多活架构，而只能采用同城异区这种架构
- 而对数据一致性要求不那么高，或者数据不怎么改变，或者即使数据丢失影响也不大的业务，跨城异地多活就能够派上用场了
- 例如，用户登录（数据不一致时用户重新登录即可）
- 新闻类网站（一天内的新闻数据变化较少）
- 微博类网站（丢失用户发布的微博或者评论影响不大）
- 这些业务采用跨城异地多活，能够很好地应对极端灾难的场景
- 跨国异地
- 跨国异地指的是业务部署在不同国家的多个机房。相比跨城异地，跨国异地的距离就更远了，因此数据同步的延时会更长，正常情况下可能就有几秒钟了
- 这种程度的延迟已经无法满足异地多活标准的第一条：“正常情况下，用户无论访问哪一个地点的业务系统，都能够得到正确的业务服务”
- 因此，跨国异地的“多活”，和跨城异地的“多活”，实际的含义并不完全一致。跨国异地多活的主要应用场景一般有这几种情况：
- 为不同地区用户提供服务
- 例如，亚马逊中国是为中国用户服务的，而亚马逊美国是为美国用户服务的
- 亚马逊中国的用户如果访问美国亚马逊，是无法用亚马逊中国的账号登录美国亚马逊的
- 只读类业务做多活
- 例如，谷歌的搜索业务，由于用户搜索资料时，这些资料都已经存在于谷歌的搜索引擎上面，无论是访问英国谷歌，还是访问美国谷歌，搜索结果基本相同
- 并且对用户来说，也不需要搜索到最新的实时资料，跨国异地的几秒钟网络延迟，对搜索结果是没有什么影响的
- 为不同地区用户提供服务
小结
- 本文讲了异地多活架构的应用场景和常见架构模式，希望对你有所帮助，后续还会有异地多活的详细设计介绍
