架构学习书摘总结（三）高可用架构模式（上）

2020-05-13 09:42:05 浏览数 (1)

最近阅读了一本架构方面的入门图书叫《从零开始学架构：照着做，你也能成为架构师》，部分内容比较不错，先做书摘总结，以便加深印象与未来回顾学习。

本文是该书第三部分上半部分，是书中第六至八章，主要介绍CAP、FMEA、存储高可用，涉及到CAP理论、FMEA理论、主备复制倒换等内容。

目录

▪第六章 CAP

▪第七章 FMEA

▪第八章 存储高可用

第六章 CAP

  1. CAP理论：在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的一个，另外一个必须被牺牲。
  2. 一致性（Consistence）：对某个指定的客户端来说，读操作保证能够返回最新的写操作结果。
  3. 可用性（Availability）：非故障的节点在合理的时间内返回合理的响应（不是错误和超时的响应）。
  4. 分区容错性（Partition Tolerance）：当出现网络分区后，系统能够继续“履行职责”。
  5. CAP应用：分布式系统理论上不可能选择CA架构，只能选择CP或者AP架构。
    1. CP：一致性/分区容错性
    2. AP：可用性/分区容错性
  6. CAP的细节
    1. CAP关注的粒度是数据，而不是整个系统；
      1. 实际设计过程中，每个系统不‍可能只处理一种数据，而是包含多种类型的数据，有的数据必须选择CP，有的数据必须选择AP。
      2. 在CAP理论落地实践时，我们需要将系统内的数据按照不同的应用场景和要求进行分类，每类数据选择‍不同的策略（CP还是AP），而不是直接限定整个系统所有数据都是同一策略。
    2. CAP是忽略网络延迟的；
      1. 布尔‍鲁在定义一致性时，并没有将延迟考虑进去。也就是说，当事务提交时，数据能够瞬间复制到所有节点。但实际情况下，从节点A复制数据到节点B，总是需要花费一定时间的。
      2. 而业务上必须要求一致性的业务场景例如和金钱相关的，技术上是无法做到分布式场景下完美的一致性的，因此单个用户的余额、单个商品的库存‍，理论上要求选择CP而实际上CP都做不到，只能选择CA。也就是说，只能单点写入，其他节点做备份，无法做到分布式情况下多点写入。
    3. 正常运行情况下，不存在CP和AP的选择，可以同时满足CA；
      1. CAP理论告诉我们分布式系统只能选择CP或AP，但其实这里的前提是系统发生了“分区”现象。如果系统没有发生分区现象，也就是说P不存在的时候（节点间的网络连接一切正常），我们没有必要放弃C或A，应该C和A都可以保证，这就要求架构设计的时候既要考虑分区发生时选择CP还是AP，也要考虑分区没有发生时如何保证CA。
    4. 放弃并不等于什么都不做，需要为分区恢复后做准备。
      1. CAP理论的“牺牲”只是说在分区过程中我们无法保证C或A，但并不意味着我们什么‍都不做。因为在系统整个运行周期中，大部分时间都是正常的，发生分区现象的时间并不长。
      2. 分区期间放弃C或‍A，并不意味着永远放弃C和A，我们可以在分区期间进行一些操作，从而让分区故障解决后，系统能够重新达到CA的状态。
  7. ACID
    1. Atomicity（原子性）
    2. Consistency（一致性）
    3. Isolation（隔离性）
    4. Durability（持久性）
    5. 区别：
      1. AC‍ID的A和CAP的A意义完全不同。
      2. ACID的C和CAP的C，前者指数据库的数据完整性，后者指分布式节点中的数据一致性。
      3. ACID‍的应用场景是数据库事务，CAP关注的是分布式系统数据读写。
  8. BASE：其是Basically Available（基本可用）、Soft State（软状态）和Eventually Consistency（最终一致性）三个短语的缩写，其核心思想是即使无法做到强一致性（CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventually Consistency）。
    2. Basically Available（基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
      1. 这里的关键词是“部分”和“核心”，具体选择哪些作为可以损失的业务，哪些是必须保证的业务，是一项有挑战的工作。
    3. Soft State（软状态）：允许系统存在中间状态，而该中间状态不会影响系统整体可用性。这里的中间状态就是CAP理论中的数据不一致。
    4. Eventually Consistency（最终一致性）：系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。
      1. 这里的关键词是“一定时间”和“最终”，“一定时间”和数据的特性是强关‍联的，不同的数据能够容忍的不一致时间是不同的。
      2. “最‍终”的含义就是不管多长时间，最终还是要达到一致性的状态。
    5. BASE理论本质上是对CAP的延伸和补充，更具体地说，是对CAP中AP方案的一个补充。
  9. ACID是数据库事务完整性的理论，CAP是分布式系统设计理论，BASE是CAP理论中AP方案的延伸。

第七章 FMEA

  1. FMEA (Failure mode and effects analysis, 故障模式与影响分析)， 是一种在各行各业广泛应用的可用性分析方法，通过对系统范围内潜在的故障模式加以分析，并按照严重程度进行分类，以确定失效对于系统的最终影响。
  2. FMEA是一套分析和思考的方法，而不是某个领域的技能或工具。FMEA并不是指导我们如何做架构设计，而是当我们设计出一个架构后，再使用FMEA对这个架构进行分析，看看架构是否还存在某些可用性的隐患。
  3. FMEA的具体分析方法如下：
    1. 给出初始的架构设计图。
    2. 假设架构中某个部件发生故障。
    3. 分析此故障对系统功能造成的影响。
    4. 根据分析结果，判断架构是否需要进行优化。

FMEA的分析方法就是一个FMEA分析表，常见分析表格包含如下部分：

  1. 功能点：当前的FMEA分析设计哪个功能点，注意这里的“功能点”指的是从用户的角度来看的，而不是从系统各个模块功能点划分来看的。
  2. 故障模式：故障模式指的是系统会出现什么样的故障，包括故障点和故障模式。这里的故障模式并不需要给出真正的故障原因，我们只需要假设出现某种故障现象即可。此外，故障模式的描述要尽量准确，多使用量化描述，避免使用泛化的描述。
  3. 故障影响：当发生故障模式中描述的故障时，功能点具体会受到什么影响。常见的影响有：功能点偶尔不可用、功能点完全不可用、部分用户功能点不可用、功能点响应缓慢，功能点出错等。故障影响也需要尽量准确描述。要注意这里的数字不需要完全精准，比如21.25%这样的数据其实是没有必要的，我们只需要预估影响是20%还是40%。
  4. 严重程度：严重程度指站在业务的角度，故障的影响程度，一般分为“致命/高/中/低/无”五个档次。对于某个故障的影响到底属于哪个档次，有时会出现一些争议。这个没有绝对标准，一般建议相关人员讨论确定即可。也不建议花费太多时间争论，争执不下时架构师裁定即可。
  5. 故障原因：“故障模式”中只描述了故障的现象，并没有单独列出故障原因。主要原因在于不管什么故障原因，故障现象相同，对功能点的影响就相同。而单独将故障原因列出主要因为：不同的故障原因发生概率不同、不同的故障原因检测手段不一样、不同的故障原因的处理措施不一样。
  6. 故障概率：这里的概率就是指某个具体故障原因发生的概率。具体评估的时候需要有以下几点需要重点关注：
    1. 硬件：硬‍件会随着使用时间推移，故障概率越来越高。
    2. 开源系统：成熟的开源系统bug率低，刚发布的开源系统bug率相比会高一些；自己已经有使用经验的开源系统bug率会低，刚开始尝试使用的开源系统bug率会高。
    3. 自研系统：和开源系统类似，成熟的自研系统故障概率会低，而新开发的系统故障‍率会高。 而高中低是相对的，只是为了确定优先级以决定后续的资源投入，没有必要绝对量化。
  7. 风险程度：是综合严重程度和故障概率来一起判断某个故障的最终等级，风险程度=严重程度×故障概率。
  8. 已有措施：针对具体故障原因系统现状是否提供某些措施应对，包括检测告警、容错、自恢复等。
  9. 规避措施：指为了降低故障发生概率而做的一些事情，可以是技术手段，也可以是管理手段。
  10. 解决措施：指为了能够解决问题而做的一些事，一般都是技术手段。一般来说，如果某个故障既可以采取规避措施，又可以采取解决措施，那么我们会优先选择解决措施，毕竟能解决问题当然是好的。系统能够自己解决的故障，大部分是和系统本身功能相关的。
  11. 后续规划：综合前面的分析，就可以看出哪些故障我们目前还缺乏对应的措施，哪些已有措施还不够，针对这些不足的地方，再结合风险程度进行排序，给出后续的改进规划。

第八章 存储高可用

  1. 存储高可用方案的本质都是通过将数据复制到多个存储设备，通过数据冗余的方式来实现高可用，其复杂性主要体现在如何应对复制延迟和中断导致的数据不一致问题。
  2. 常见的存储高可用架构有：主备、主从、主主、集群、分区，每一种又可以根据业务的需求进行一些特殊的定制化功能，由此衍生出更多的变种。一般的，不同业务的定制功能难以通用化。
  3. 主备复制：最常见也是最简单的一种存储高可用方案。主备架构中“备机”主要还是起到一个备份作用，并不承担合集的业务读写操作。 综合主备复制架构的优缺点，内部的后台管理系统使用主备复制架构的情况会比较多。因为这类系统的数据变更频率很低，即使在某些场景下丢失，也可以通过人工的方式补全。
  4. 主从复制：主机负责读写操作，从机只负责读操作，不负责写操作。 综合主从复制架构的优缺点，一般情况下，写少读多的业务使用主从复制的存储架构比较多。例如：BBS、新闻网站这类业务，此类业务的读操作数量是写操作数量的10倍甚至100倍以上。
    1. 如果主从间延迟较多，恰好此时主机又宕机了，则可能丢失较多数据，因此对于复制延迟也不能掉以轻心。一般的做法是做复制延迟的监控措施，当延迟的数据量较大时及时报警，由人工干预处理。
    2. 主从复制同样有故障时需要人工干预的缺点，人工在执行回复操作的过程中也容易出错，因为这类操作并不常见，可能一年也就一两次。
  5. 主备倒换与主从倒换：此为了解决“主机故障后无法进行写操作”、“主机无法恢复时需要人工指定新主机角色”两个问题而产生。简单来说，就是基于主备复制和主从复制方案基础上增加“倒换”功能，即系统自动决定主机角色，并完成角色切换。常见主备倒换架构有：互联式、中介式、模拟式。
    1. 关键设计点：主备间状态判断（状态传递的渠道、状态检测的内容）、倒换决策（倒换时机、倒换策略、自动程度）、数据冲突解决。
    2. 倒换方案比主备、主从的复制方案不止是多了一个倒换功能那么简单，而是复杂度上升一个数量级。
    3. 互联式：主备机直接建立状态传递的渠道。其如果状态传递的通道本身有故障（例如网线被踢掉），那么备机也会认为主机故障了从而将自己升级为主机，而此时主机并没有故障，最终可能就出现两个主机。
    4. 中介式：在主备两者之外引入第三方中介，但其比互联式连接管理与状态决策上更简单。但其关键代价就在于如何实现中介本身的高可用。这就陷入了一个设计递归陷阱。 当下MongoDB的Replica Set采取的就是这种方式。其有个仲裁节点（MongoDB(A)），仲裁节点是一种特殊的节点，它本身并不存储数据，主要的作用是决定哪一个备节点在主节点挂掉之后提升为主节点，所以客户端不需要连接此节点。即使只有一个备节点，但是仍然需要一个仲裁节点来提升备节点级别。 另外，幸运的是，开源的ZooKeeper是一个很成熟的解决方案。其本身就是一个高可用的系统，在高可用架构中有很多用途，主备倒换的中介就可以用ZooKeeper来做状态同步。
    5. 模拟式：指主备机之间并不传递任何状态数据，而是备机模拟成一个客户端向主机发起模拟的读写操作，根据读写操作的响应情况来判断主机的状态。
  6. 主主复制：其实两台机器都是主机，互相将数据复制给对方，客户端可以任意挑选其中一台机器进行读写操作。如果采用本架构，必须保证数据能够双向复制，而很多数据是不能双向复制的，比如用户注册后生成的用户ID以及库存。 综上，本架构对数据的设计有严格的要求，一般适合于那些临时性、可丢失、可覆盖的数据场景。例如用户登录产生的session数据，用户行为的日志数据，论坛的草稿数据等。
  7. 数据集群：集群就是多台机器组合在一起形成一个统一的系统，这里的多肽数量上至少是3台，相比而言，主备、主从都是2台机器。根据集群中机器承担的不同角色来划分，集群可以分为两类：数据集中集群、数据分散集群。
    1. 数据集中集群：与主备、主从架构类似，可称为数据集中集群为一主多备、一主多从。其整体复杂度更高体现在主机如何将数据复制给备机、备机如何检测主机状态、主机故障后如何决定新主机。其例为开源的ZooKeeper，ZooKeeper通过ZAB协议来解决上面的几个问题，但ZAB协议比较复杂（类似Paxos算法），如果我们自己去实现ZAB协议的话那么复杂度同样非常高。
    2. 数据分散集群：多个服务器组成一个集群，每台服务器都会负责存储一部分数据。同时，未来提升硬件利用率，每台服务器又会备份一部分数据。例子如Hadoop的实现就是独立的服务器负责数据分区的分配，这台服务器叫做Namenode。而Elasticsearch集群通过选举一台服务器来做数据分区的分配，叫做master node。
    3. 上面两种集群的不同点在于，数据分散集群中的每台服务器都可以处理读写请求，因此不存在数据集中集群中负责写的主机那样的角色。但在数据分区集群中，必须有一个角色来负责执行数据分配算法，这个角色可以是独立的一台服务器，也可以是集群自己选举出的一台服务器。
    4. 数据集中集群架构中，客户端只能将数据写到主机；数据分散机群架构中，客户端可以向任意服务器中读写数据。正是因为这个关键的差异，决定了两种集群的应用场景不同。一般来说，数据集中式集群适合数据量不大，集群机器数量不多的场景。例如ZooKeeper集群一般推荐5台及其左右，数据量是单台服务器就能够支撑。而数据分散式集群，由于其良好的可伸缩性，适合业务数据量巨大，集群机器数量庞大的业务场景。例如Hadoop集群、HBase集群，大规模的集群可以达到上百台甚至上千台服务器。
  8. 数据分区：对于一些影响非常大的灾难或事故，例如天灾人祸，基于硬件故障而设计的高可用架构不再适用，我们需要基于地理级别的故障来设计高可用架构，这就是数据分区架构产生的背景。 数据分区指将数据按照一定的规则进行分区，不同分区分布在不同的地理位置上，每个分区存储一部分数据，通过这种方式来规避地理级别的故障所造成的巨大影响。 设计一个良好的数据分区架构，需要从数据量（数据量越大分区规则越复杂）、分区规则（洲际分区、国家分区、城市分区）、复制规则（集中式、互备式、独立式）、等方面进行考虑。
数据分析 数据库 sql 架构设计 开源

0 人点赞