架构训练营 week7 课程总结

• 高可用架构设计理论

主要的 2 个定理是 FLP 和 CAP

FLP 是说在异步网络通信场景里，即便只有一个进程失败，也没有一个确定性的协议可以保证其他非失败的进程达到一致性。其 3 个特性是：Failure tolerance,safety,liveness。

CAP 则是说在分布式系统里，数据存储不可能同时满足一致性、可用性和分区容忍性三个特性。C 是指 Consistence, A 是指 available, P 是指 Partition tolerance。因为我们大型系统都是分布式的，所以 P 是必须要有的，那么就只有 2 个选择，就是 CP 和 AP。一般来说，CP 的系统对于用户体验影响较大，因为在一些情况下，会导致数据无法写入。而 AP 相对而言能较好保持用户体验的完整，只是在某些情况下数据会不一致，但是我们可以通过 BASE 达到最终一致性

BASE 也就是 basically available soft state eventual consistency。意味着数据并非每时每刻都是一致的，但是经过一个时间段后，可以最终达到一致。在中间的这段不一致的时间里，我们可以用各种手段，尽量不影响用户的体验。如果实在不能保证，就想办法安抚或者赔偿用户。

• FMEA

首先，FMEA 是一种分析和思考的方法，全称是 Failure mode and effects analysis。它是用于在我们初步是设计出一个架构之后，用这个方法进行分析，看看是否存在可用性的隐患用的。它并没有办法用来指导架构的设计。

FMEA 四个字母分别表示一个分析的维度。F 表示 Failure 意味着我们要首先假设某个 role 出了故障；M 表示 Mode，也就是说这个 role 是以什么方式出故障的；E 表示 effect：这个故障会带来什么影响，是否严重；A 表示 Analysis，我们有什么现有的办法，或者其他方法来预测，报警，或者解决，并非一定要是技术手段，也可以是业务的非技术手段。

• 业务级灾备架构设计常见模式

主要有 3 大模式：同城多中心，跨城多中心，跨国多中心。

同城多中心主要有 2 种模式：同城双中心，同城三中心。一般同城双中心较普遍；同城三中心成本较高，并且可用性并不会上升多少。 同城双中心的关键是：间隔 50km 以上，否则无法应对机房级别的灾难。用高速光纤互联，延时<2ms，否则无法作为同一个逻辑机房来对待。

跨城则一般有：跨城双中心和跨城多中心。跨城双中心主要可以应对城市级别的灾难，也可以用于用户分区，异地多活。关键是：不同的城市，并且用高速光纤互联。落地方案有 2 种：近邻城市和远端城市。近邻城市主要的关键是，机房延时<10ms，因为要作为同一个逻辑机房来看待；但是这样一来就无法应对区域级别灾难，也不能做用户分区。而远端城市则相反：两个城市离得较远，机房延时一般会 > 30ms，因此无法作为同一个逻辑机房，但是可以应对城市、区域级别灾难，可以做用户分区，也可以做异地多活。

而跨城多中心，成本很高，例如 OceanBase 的两近一远，一般是巨头专属。可以做用户分区、异地多活。

跨国多中心的主要目的其实不是异地多活，而是为了应对监管以及用户分区。因为延时太大，做异地多活的话，会造成数据延时很大，影响系统的性能和用户体验。

• 异地多活的三种模式

异地多活的三种模式是：业务定制型、业务通用型、存储通用型。

业务定制型主要是针对核心业务定制化搭建的异地多活。对基础设施无要求，可以支持城市、区域级别的故障，但是无法扩展，每次业务变化都要重新搭建。

业务通用型主要是用配套服务来支持异地多活，只要是可以支持 BASE 的业务其实都可以使用业务通用型的异地多活。对硬件设施无要求，可以支持城市、区域级别的故障；但是配套服务很复杂，有流量调度、配置中心、建站平台等。对于一些全局单点的业务，例如库存、卖家等，并不是很适用。

存储通用型异地多活是适用性最强的，因为他的架构天然支持异地多活，并且已经支持分布式一致性，只要切换了存储系统即可，业务不用改造。但是需要有分布式一致性的存储系统支持，目前这样的系统选择并不多，主要是 OceanBase。并且机房部署有要求：只能是近邻城市，否则延时太高，无法达到分布式一致性。

• 业务定制型异地多活架构设计

业务定制型的异地多活架构设计主要也是基于 CAP 来进行设计的。而 CAP 关注的不是整个系统，而是数据。也就是某些数据可以是 CP，某些数据则可以是 AP。并且我们说无法保证 CAP，并不表示不作为，在数据不一致的情况下，也得考虑如何让用户尽量少受影响。

有 3 个原则：保证核心业务；只能做最终一致性；只能保证绝大多数用户。

设计步骤主要有：

1. 业务分级，找出 TOP3 或者 TOP X

2. 数据分类，看看数据是否需要强一致性，或者是否需要唯一性，是否可丢失，是否可恢复。

3. 数据同步，数据同步最好是多管齐下，可以是数据库同步、消息队列、二次读取、回源读取、重新生成等。

4. 异常处理，当数据出现不一致，影响用户体验的时候，应该如何处理，是业务兼容？事后补偿？还是人工修正。

设计技巧有：

1. 消息队列同步比较适合幂等性的数据

2. 可以使用事务合并的方式，就是将数据的变化写入流水表，最后用一个 job 来定时扫描流水表，批量写入数据库。

3. 同步改异步，虽然会损失部分用户体验，但是可以比较好的达到最终一致性

4. 适当容忍，当技术手段无法解决一致性问题的时候，业务上适当容忍也是一个可选方案。