这一章节作者从“异地多活”和“接口级别故障”两个业务场景中，考虑如何设计高可用系统。

一、异地多活

异地多活是指，正常情况下用户无论访问哪一个地点的业务系统，都能够得到正确的业务服务；若某个地方业务异常的时候，用户访问其他不同地理位置正常的业务系统，也能够得到正确的业务服务。

异地多活架构设计是为了应对在一些极端场景下，服务器出现故障如机房断电、地震等等。但是，要实现异地多活的代价比较高，一方面系统的复杂度会变变高；另一方面，系统实现的成本也会变高。

作者从异地多活的架构模式、设计技巧、设计步骤几个方面简单介绍了异地多活。

1.异地多活的架构模式

从地理位置上的距离来划分，可以分为同城异区、跨城异地、跨国异地。

同城异区指将业务部署在同一个城市不同区的多个机房。若某个区机房的电缆被挖断，同城异区架构可以很好地解决。同城异区是应对机房级别故障的最优架构。

跨城异地指业务部署在不同城市的多个机房，而且距离要远一些。如将业务部署在上海和北京两个机房。部署在不同的城市，可以解决某个城市遇到水灾等地理灾难的问题，但是由于距离远的因素，可能会导致数据在同步时，出现延迟问题。所以，对数据一致性要求很高的业务，如金融相关系统，一般不会做跨城异地多活。

跨国异地指业务部署在不同国家的多个机房。由于距离比较远，所以延时比较明显，因而跨国异地一般用来为不同地区用户提供服务或者是对只读业务做多活。

2.异地多活设计技巧

作者主要提供了4个技巧：保证核心业务的异地多活、保证核心数据最终一致性、采用多种手段同步数据、只保证绝大部分用户的异地多活。

异地多活是为了保证业务的高可用，但是很多人就误以为要保证所有业务都能够异地多活。一方面由于延迟的原因，可能所有的业务无法都实现异地多活，或者难实现异地多活；另一方面，有些非核心业务，暂时的不可用可能不会对系统造成太大的影响。所以，设计的第一个技巧就是优先实现核心业务的异地多活架构。

异地多活的本质是通过异地的数据冗余，来保证在极端异常的情况下业务也能够正常提供给用户使用。所以，数据同步是异地多活架构设计的核心。尽管业务上要求数据快速同步，但是物理上做不到数据快速同步。所以，设计的第二个技巧就是保证核心数据最终一致性，而非实时一致性。

由于数据同步是异步多活架构设计的核心，所以在实现数据同步时，不应只使用存储系统的同步功能，可以将多种手段配合存储系统的同步使用，如采用消息队列方式、二次读取方式、存储系统同步方式、回源读取方式、重新生成数据方式等。即采用多种手段同步数据。

尽管异地多活设计是为了应对极端情况下业务的可用，但是在某些场景下，这种架构仍然无法保证100%的业务可用性，所以，设计的最后一个技巧就是，只保证绝大部分用户的异地多活

3.异地多活设计步骤

主要分为四步骤：业务分级、数据分类、数据同步和异常处理。

业务分级即按照一定的标准将业务进行分级，挑选出核心的业务，只为核心业务设计异地多活，以便降低方案整体复杂度和实现成本。

数据分类即挑选出核心业务后，对核心业务相关数据进行分析，识别所有的数据及数据特征。如数据量、唯一性、实时性、可丢失性、可恢复性等。

数据同步即在确定数据特征后，根据不同的数据设计不同的同步方案。常见的数据同步方案有：存储系统同步、消息队列同步、重复生成。

异常处理即在数据出现异常问题时，系统采取的应对措施。避免问题发生时，导致整体业务不可用；问题恢复后，对异常数据的修复等。常见的异常处理措施有：多通道同步、同步和访问结合、记录日志、用户补偿等。

二、接口级别故障

异地多活方案主要针对系统级别的故障，而接口级别故障，顾名思义就是针对接口级别的故障。其典型表现就是，系统没有宕机、网络没有中断，但是业务出现问题。内部可能是程序bug问题，外部可能是黑客攻击、大量请求访问等等。

解决办法一般分为三种：降级、熔断、限流、排队。降级就是系统将某些业务或者接口的功能降级，只提供部分功能，关闭其余功能。如双十一开始时，关闭修改地址的功能。熔断指暂停调用出现问题的外部系统，主要通过统一的API调用层和阈值来实现的。限流指只允许系统能够承受的访问量进来，超出系统访问能力的请求将被丢弃。排队指只处理系统能够承受的访问量进来，超出系统访问能力的请求需要排队等待处理。