《从0开始学架构》——高可用：异地多活和接口级故障

本系列是极客时间《从0开始学架构》的读书笔记。

一、异地多活

对应《28 | 业务高可用的保障：异地多活架构》《29 | 异地多活设计4大技巧》《30 | 异地多活设计4步走》

在上一篇提到过，如果部分节点的故障是地理级别的话，最好做数据分区备份架构。但是，由于备份系统正常情况下是不对外提供服务的，所以把备份数据恢复到正常情况，需要很长时间。
这个很长时间，并不是指的系统启动的时间，而是由于备份系统平时没有流量，如果直接上线可能会触发平常测不到的问题；备份系统也没有中间数据、缓存数据，如果不经过预热直接切换，大流量会直接拖垮系统；即使是再实时的系统也会有数据延迟，如果是金融类系统需要确保数据一致。许多方面的考虑，都不能保证备份系统能够实时切换上线。

如果业务需要在此种故障背景下，依然要能够不受影响或只影响几分钟，那么就需要考虑异地多活架构。

应用场景

异地，指的是地理上位于不同位置，多活指的是都能对外提供服务。一个系统符合异地多活，需要满足：正常情况下，用户无论访问哪个地点的业务系统，都能得到正确的服务；当某个地点的服务异常时，用户访问其他地方的系统，可以得到正确的服务。

这种架构的代价很高：系统的复杂度会发生本质变化，成本大幅上升。
所以，是否选择异地多活，要看业务的具体情况。一般而言，核心的、关键的业务才会去考虑。

架构模式

依据地理位置划分。

1.同城异区。
这种架构不能应对极端故障（如城市停电、地震、洪水……），但是由于处于同一个城市，可通过搭建专用网络实现和在同一个机房内几乎一样的速度。这样就减少了设计的复杂度以及相应的成本。
这种架构可以很好地应对机房故障、火灾等场景。由于此类故障场景发生概率更大，所以综合考虑，同城异区架构是应对机房级别故障的最优选择。

2.跨城异地。
选址时距离要尽量远，这样才能应对城市级别的极端故障。
由于距离非常远，量变引起质变，机房之间的传输速度急剧下降，并且传输线路的可用性难以可控（如挖掘机把光缆挖断导致支付宝故障、中美海底光缆被拖船扯断导致一系列故障）。这些由于距离导致的网络延迟，一定会造成数据的不一致。
如果数据要求强一致性，如银行存款、支付宝