我们一直在谈论各式各样的架构，如高并发架构、异地多活架构、容器化架构、微服务架构、高可用架构、弹性化架构等。还有和这些架构相关的管理型的技术方法，如 DevOps、应用监控、自动化运维、SOA 服务治理、去 IOE 等。面对这么多纷乱的技术，很多团队或是公司都是一个一个地去做这些技术，非常辛苦，也非常累。

接下来我们来谈一谈分布式架构。

一、概述

1. 分布式的优缺点

首先，为什么需要分布式系统，而不是传统的单体架构。

• 增大系统容量。我们的业务量越来越大，而要能应对越来越大的业务量，一台机器的性能已经无法满足了，我们需要多台机器才能应对大规模的应用场景。所以，我们需要垂直或是水平拆分业务系统，让其变成一个分布式的架构。
• 加强系统可用。我们的业务越来越关键，需要提高整个系统架构的可用性，这就意味着架构中不能存在单点故障。这样，整个系统不会因为一台机器出故障而导致整体不可用。所以，需要通过分布式架构来冗余系统以消除单点故障，从而提高系统的可用性。

当然，分布式系统还有一些优势，比如：

• 因为模块化，所以系统模块重用度更高；
• 因为软件服务模块被拆分，开发和发布速度可以并行而变得更快；
• 系统扩展性更高；团队协作流程也会得到改善；
• ……

不过，这个世界上不存在完美的技术方案，采用任何技术方案都是“按下葫芦浮起瓢”，都是有得有失，都是一种 trade-off。也就是说，分布式系统在解决上述问题的同时，也给我们带来了其他的问题。因此，我们需要清楚地知道分布式系统所带来的问题。

从上面的表格我们可以看到，分布式系统虽然有一些优势，但也存在一些问题。

• 架构设计变得复杂（尤其是其中的分布式事务）。
• 部署单个服务会比较快，但是如果一次部署需要多个服务，流程会变得复杂。
• 系统的吞吐量会变大，但是响应时间会变长。
• 运维复杂度会因为服务变多而变得很复杂。
• 架构复杂导致学习曲线变大。
• 测试和查错的复杂度增大。
• 技术多元化，这会带来维护和运维的复杂度。
• 管理分布式系统中的服务和调度变得困难和复杂。

2. 面向服务的架构有以下三个阶段

下面是一个 SOA 架构的演化图。

我们可以看到，面向服务的架构有以下三个阶段。

1. 20 世纪 90 年代前，是单体架构，软件模块高度耦合。当然，这张图同样也说明了有的 SOA 架构其实和单体架构没什么两样，因为都是高度耦合在一起的。就像图中的齿轮一样，当你调用一个服务时，这个服务会调用另一个服务，然后又调用另外的服务……于是整个系统就转起来了。但是这本质是比较耦合的做法。
2. 2000 年左右出现了比较松耦合的 SOA 架构，这个架构需要一个标准的协议或是中间件来联动其它相关联的服务（如 ESB）。这样一来，服务间并不直接依赖，而是通过中间件的标准协议或是通讯框架相互依赖。这其实就是 IoC（控制反转）和 DIP（依赖倒置原则）设计思想在架构中的实践。它们都依赖于一个标准的协议或是一个标准统一的交互方式，而不是直接调用。
3. 2010 年后，出现了微服务架构，这个架构更为松耦合。每一个微服务都能独立完整地运行（所谓的自包含），后端单体的数据库也被微服务这样的架构分散到不同的服务中。而它和传统 SOA 的差别在于，服务间的整合需要一个服务编排或是服务整合的引擎。就好像交响乐中需要有一个指挥来把所有乐器编排和组织在一起。

3. 最早的分布式服务化架构思想

从目前已经公开的资料来看，分布式服务化架构思想实践最早的公司应该是亚马逊。因为早在 2002 年的时候，亚马逊 CEO 杰夫·贝索斯（Jeff Bezos）就向全公司颁布了下面的这几条架构规定（来自《Steve Yegge 对 Google 平台吐槽》一文）。

• 所有团队的程序模块都要通过 Service Interface 方式将其数据与功能开放出来。
• 团队间程序模块的信息通信，都要通过这些接口。
• 除此之外没有其它的通信方式。其他形式一概不允许：不能直接链结别的程序（把其他团队的程序当作动态链接库来链接），不能直接读取其他团队的数据库，不能使用共享内存模式，不能使用别人模块的后门，等等。唯一允许的通信方式是调用 Service Interface。
• 任何技术都可以使用。比如：HTTP、CORBA、Pub/Sub、自定义的网络协议等。
• 所有的 Service Interface，毫无例外，都必须从骨子里到表面上设计成能对外界开放的。也就是说，团队必须做好规划与设计，以便未来把接口开放给全世界的程序员，没有任何例外。
• 不这样做的人会被炒鱿鱼。

这应该就是 AWS（Amazon Web Service）出现的基因吧。

4. 分布式系统中需要注意的问题

• 分布式系统之所以复杂，就是因为它太容易出错了。这意味着，要把处理错误的代码当成正常功能的代码来处理。

• 开发一个健壮的分布式系统的成本是单体系统的几百倍甚至几万倍。这意味着，要自己开发一个，需要能力很强的开发人员。

• 非常健壮的开源的分布式系统并不多，或者说基本没有。这意味着，如果要用开源的，那么你需要 hold 得住其源码。

• 管理或是协调多个服务或机器是非常难的。这意味着，要去读很多很多的分布式系统的论文。

• 在分布式环境下，出了问题是很难 debug 的。这意味着，需要非常好的监控和跟踪系统，还需要经常做演练和测试。

• 在分布式环境下，需要更科学地分析和统计。这意味着，要用 P90 这样的统计指标，而不是平均值，还需要做容量计划和评估。

• 在分布式环境下，需要应用服务化。这意味着，需要一个服务开发框架，比如 SOA 或微服务。

• 在分布式环境下，故障不可怕，可怕的是影响面过大，时间过长。这意味着，需要花时间来开发我们的自动化运维平台。

总之，在分布式环境下，一切都变得非常复杂。要进入这个领域，需要有足够多的耐性和足够强的心态来接受各式各样的失败。当拥有丰富的实践和经验后，才会有所建树。这并不是一日之功，可能要在这个领域花费数年甚至数十年的时间。

二、分布式系统的技术栈

构建分布式系统的目的是增加系统容量，提高系统的可用性，转换成技术方面，也就是完成下面两件事。

• 大流量处理。通过集群技术把大规模并发请求的负载分散到不同的机器上。
• 关键业务保护。提高后台服务的可用性，把故障隔离起来阻止多米诺骨牌效应（雪崩效应）。

如果流量过大，需要对业务降级，以保护关键业务流转。说白了就是干两件事。一是提高整体架构的吞吐量，服务更多的并发和流量，二是为了提高系统的稳定性，让系统的可用性更高。

1. 提高架构的性能

提高系统性能的常用技术

• 缓存系统。加入缓存系统，可以有效地提高系统的访问能力。从前端的浏览器，到网络，再到后端的服务，底层的数据库、文件系统、硬盘和 CPU，全都有缓存，这是提高快速访问能力最有效的手段。对于分布式系统下的缓存系统，需要的是一个缓存集群。这其中需要一个 Proxy 来做缓存的分片和路由。

• 负载均衡系统。负载均衡系统是水平扩展的关键技术，它可以使用多台机器来共同分担一部分流量请求。

• 异步调用。异步系统主要通过消息队列来对请求做排队处理，这样可以把前端的请求的峰值给“削平”了，而后端通过自己能够处理的速度来处理请求。这样可以增加系统的吞吐量，但是实时性就差很多了。同时，还会引入消息丢失的问题，所以要对消息做持久化，这会造成“有状态”的结点，从而增加了服务调度的难度。数据分区和数据镜像。

• 数据分区是把数据按一定的方式分成多个区（比如通过地理位置），不同的数据区来分担不同区的流量。这需要一个数据路由的中间件，会导致跨库的 Join 和跨库的事务非常复杂。而数据镜像是把一个数据库镜像成多份一样的数据，这样就不需要数据路由的中间件了。可以在任意结点上进行读写，内部会自行同步数据。然而，数据镜像中最大的问题就是数据的一致性问题。

  一般来说，初期使用读写分离的数据镜像方式，后期会采用分库分表的方式。

2. 提高架构的稳定性

提高系统系统稳定性的一些常用技术。

• 服务拆分。服务拆分主要有两个目的：一是为了隔离故障，二是为了重用服务模块。但服务拆分完之后，会引入服务调用间的依赖问题。
• 服务冗余。服务冗余是为了去除单点故障，并可以支持服务的弹性伸缩，以及故障迁移。然而，对于一些有状态的服务来说，冗余这些有状态的服务带来了更高的复杂性。其中一个是弹性伸缩时，需要考虑数据的复制或是重新分片，迁移的时候还要迁移数据到其它机器上。
• 限流降级。当系统实在扛不住压力时，只能通过限流或者功能降级的方式来停掉一部分服务，或是拒绝一部分用户，以确保整个架构不会挂掉。这些技术属于保护措施。
• 高可用架构。通常来说高可用架构是从冗余架构的角度来保障可用性。比如，多租户隔离，灾备多活，或是数据可以在其中复制保持一致性的集群。总之，就是为了不出单点故障。
• 高可用运维。高可用运维指的是 DevOps 中的 CI/CD（持续集成 / 持续部署）。一个良好的运维应该是一条很流畅的软件发布管线，其中做了足够的自动化测试，还可以做相应的灰度发布，以及对线上系统的自动化控制。这样，可以做到“计划内”或是“非计划内”的宕机事件的时长最短。

3. 分布式系统的关键技术

引入分布式系统，会引入一堆技术问题，需要从以下几个方面来解决。

• 服务治理。服务拆分、服务调用、服务发现、服务依赖、服务的关键度定义……服务治理的最大意义是需要把服务间的依赖关系、服务调用链，以及关键的服务给梳理出来，并对这些服务进行性能和可用性方面的管理。
• 架构软件管理。服务之间有依赖，而且有兼容性问题，所以，整体服务所形成的架构需要有架构版本管理、整体架构的生命周期管理，以及对服务的编排、聚合、事务处理等服务调度功能。
• DevOps。分布式系统可以更为快速地更新服务，但是对于服务的测试和部署都会是挑战。所以，还需要 DevOps 的全流程，其中包括环境构建、持续集成、持续部署等。
• 自动化运维。有了 DevOps 后，我们就可以对服务进行自动伸缩、故障迁移、配置管理、状态管理等一系列的自动化运维技术了。
• 资源调度管理。应用层的自动化运维需要基础层的调度支持，也就是云计算 IaaS 层的计算、存储、网络等资源调度、隔离和管理。
• 整体架构监控。如果没有一个好的监控系统，那么自动化运维和资源调度管理只可能成为一个泡影，因为监控系统是你的眼睛。没有眼睛，没有数据，就无法进行高效运维。所以说，监控是非常重要的部分。这里的监控需要对三层系统（应用层、中间件层、基础层）进行监控。
• 流量控制。最后是我们的流量控制，负载均衡、服务路由、熔断、降级、限流等和流量相关的调度都会在这里，包括灰度发布之类的功能也在这里。

4. 分布式系统的“纲”

总结一下上面讲述的内容，分布式系统有五个关键技术，它们是：

• 全栈系统监控；
• 服务 / 资源调度；
• 流量调度；
• 状态 / 数据调度；
• 开发和运维的自动化。

最后一项——开发和运维的自动化，是需要把前四项都做到了，才有可能实现的。所以，最为关键是下面这四项技术，即应用整体监控、资源和服务调度、状态和数据调度及流量调度，它们是构建分布式系统最最核心的东西。

三、关键技术：全栈监控

全栈系统监控，它就像是我们的眼睛，没有它，我们就不知道系统到底发生了什么，我们将无法管理或是运维整个分布式系统。所以，这个系统是非常非常关键的。

这个监控系统需要完成的功能为：

• 全栈监控；
• 关联分析；
• 跨系统调用的串联；
• 实时报警和自动处置；
• 系统性能分析。

1. 多层体系的监控

所谓全栈监控，其实就是三层监控。

• 基础层：监控主机和底层资源。比如：CPU、内存、网络吞吐、硬盘 I/O、硬盘使用等。
• 中间层：就是中间件层的监控。比如：Nginx、Redis、RabbitMQ、Kafka、MySQL 等。
• 应用层：监控应用层的使用。比如：HTTP 访问的吞吐量、响应时间、返回码、调用链路分析、性能瓶颈，还包括用户端的监控。

还需要一些监控的标准化。

• 日志数据结构化；
• 监控数据格式标准化；
• 统一的监控平台；
• 统一的日志分析。

2. 什么才是好的监控系统

一个好的监控系统应该有以下几个特征。

• 关注于整体应用的 SLA。主要从为用户服务的 API 来监控整个系统。

  SLA（服务等级协议）是系统服务提供者对客户的承诺，包括可用性、准确性、系统容量和延迟等关键指标。

• 关联指标聚合。把有关联的系统及其指标聚合展示。主要是三层系统数据：基础层、平台中间件层和应用层。其中，最重要的是把服务和相关的中间件以及主机关联在一起。总之，无论运行在哪里，我们都需要把服务的具体实例和主机关联在一起，否则，对于一个分布式系统来说，定位问题犹如大海捞针。

• 快速故障定位。对于现有的系统来说，故障总是会发生的，而且还会频繁发生。故障发生不可怕，可怕的是故障的恢复时间过长。所以，快速地定位故障就相当关键。快速定位问题需要对整个分布式系统做一个用户请求跟踪的 trace 监控，需要监控到所有的请求在分布式系统中的调用链，这个事最好是做成没有侵入性的。

换句话说，一个好的监控系统主要是为以下两个场景所设计的。

• “体检”容量管理。
  • 提供一个全局的系统运行时数据的展示，可以让团队知道是否需要增加机器或者其它资源。
  • 性能管理。可以通过查看大盘，找到系统瓶颈，并有针对性地优化系统和相应代码。
• “急诊”定位问题。
  • 可以快速地暴露并找到问题的发生点，帮助技术人员诊断问题。
  • 性能分析。当出现非预期的流量提升时，可以快速地找到系统的瓶颈，并帮助开发人员深入代码。

3. 如何做出一个好的监控系统

• 服务调用链跟踪
• 服务调用时长分布
• 服务的 TOP N 视图。所谓 TOP N 视图就是一个系统请求的排名情况。一般来说，这个排名会有三种排名的方法：
  • 按调用量排名，
  • 按请求最耗时排名，
  • 按热点排名（一个时间段内的请求次数的响应时间和）
• 数据库操作关联。可以使用数据库工具监控慢查询
• 服务资源跟踪：我们需要把服务运行的机器节点上的数据（如 CPU、MEM、I/O、DISK、NETWORK）关联起来。

4. 需要达到的目标

• 当一台机器挂掉是因为 CPU 或 I/O 过高的时候，马上可以知道其会影响到哪些对外服务的 API。
• 当一个服务响应过慢的时候，马上能关联出来是否在做 GC，或是其所在的计算结点上是否有资源不足的情况，或是依赖的服务是否出现了问题。
• 当发现一个 SQL 操作过慢的时候，马上知道其会影响哪个对外服务的 API
• 当发现一个消息队列拥塞的时候，马上知道其会影响哪些对外服务的 API。

一旦了解了这些信息，我们就可以做出调度。比如：

• 一旦发现某个服务过慢是因为 CPU 使用过多，我们就可以做弹性伸缩。
• 一旦发现某个服务过慢是因为 MySQL 出现了一个慢查询，我们就无法在应用层上做弹性伸缩，只能做流量限制，或是降级操作了。

四、关键技术：服务治理

1. 服务关键程度和服务的依赖关系

服务关键程度，主要是梳理和定义服务的重要程度。这不是使用技术可以完成的，它需要细致地管理对业务的理解，才能定义出架构中各个服务的重要程度。

梳理服务间的依赖关系，这点也非常重要。我们常说，“没有依赖，就没有伤害”。这句话的意思就是说，服务间的依赖是一件很易碎的事。依赖越多，依赖越复杂，我们的系统就越易碎。

微服务是服务依赖最优解的上限，而服务依赖的下限是千万不要有依赖环。

如果系统架构中有服务依赖环，那么表明架构设计是错误的。循环依赖有很多的副作用，最大的问题是这是一种极强的耦合，会导致服务部署相当复杂和难解，而且会导致无穷尽的递归故障和一些意想不到的问题。

解决服务依赖环的方案一般是，依赖倒置的设计模式。

在分布式架构上，你可以使用一个第三方的服务来解决这个事。比如，通过订阅或发布消息到一个消息中间件，或是把其中的依赖关系抽到一个第三方的服务中，然后由这个第三方的服务来调用这些原本循环依赖的服务。

2. 服务状态和生命周期的管理

我们需要一个服务发现的中间件，这个中间件是非常非常关键的。因为这个分布式架构中的服务是动态的，有的服务会新加进来，有的会离开，有的会增加更多的实例，有的会减少，有的服务在维护过程中（发布、伸缩等），所以我们需要有一个服务注册中心，来知道这么几个事。

• 整个架构中有多少种服务？
• 这些服务的版本是什么样的？
• 每个服务的实例数有多少个，它们的状态是什么样的?
• 每个服务的状态是什么样的？是在部署中，运行中，故障中，升级中，还是在回滚中，伸缩中，或者是在下线中……

有了这些服务的状态和运行情况之后，就需要对这些服务的生命周期进行管理了。服务的生命周期通常会有以下几个状态：

• Provision，代表在供应一个新的服务；
• Ready，表示启动成功了；
• Run，表示通过了服务健康检查；
• Update，表示在升级中；
• Rollback，表示在回滚中；
• Scale，表示正在伸缩中（可以有 Scale-in 和 Scale-out 两种）；
• Destroy，表示在销毁中；
• Failed，表示失败状态。

3. 整个架构的版本管理

在分布式架构中，我们需要一个架构的版本，用来控制其中各个服务的版本兼容。

比如，A 服务的 1.2 版本只能和 B 服务的 2.2 版本一起工作，A 服务的上个版本 1.1 只能和 B 服务的 2.0 一起工作。这就是版本兼容性。

当然，一般来说，在设计过程中，我们希望没有版本的依赖性问题。但可能有些时候，不可避免的会有这样的问题，那么就需要在架构版本中记录下这个事，以便可以回滚到上一次相互兼容的版本。

要做到这个事，就需要一个架构的 manifest，一个服务清单，这个服务清单定义了所有服务的版本运行环境，其中包括但不限于：

• 服务的软件版本；
• 服务的运行环境——环境变量、CPU、内存、可以运行的节点、文件系统等；
• 服务运行的最大最小实例数。

每一次对这个清单的变更都需要被记录下来，算是一个架构的版本管理。

4. 资源 / 服务调度

服务运行时的状态是非常关键的。服务运行过程中，状态是会有变化的，这样的变化有两种。

• 一种是没有预期的变化。比如，服务运行因为故障导致一些服务挂掉，或是别的什么原因出现了服务不健康的状态。而一个好的集群管理控制器应该能够强行维护服务的状态。在健康的实例数变少时，控制器会把不健康的服务给摘除，而又启动几个新的，强行维护健康的服务实例数。
• 另外一种是预期的变化。比如，我们需要发布新版本，需要伸缩，需要回滚。这时，集群管理控制器就应该把集群从现有状态迁移到另一个新的状态。这个过程并不是一蹴而就的，集群控制器需要一步一步地向集群发送若干控制命令。这个过程叫“拟合”——从一个状态拟合到另一个状态，而且要穷尽所有的可能，玩命地不断地拟合，直到达到目的。

详细说明一下，对于分布式系统的服务管理来说，当需要把一个状态变成另一个状态时，需要对集群进行一系列的操作。比如，当需要对集群进行 Scale 的时候，我们需要：

• 先扩展出几个结点；
• 再往上部署服务；
• 然后启动服务；
• 再检查服务的健康情况；
• 最后把新扩展出来的服务实例加入服务发现中提供服务。

如果研究过 Kubernetes 这个调度控制系统，会看到它的思路就是这个样子的。

对于弹性伸缩，上面已经给出了一个服务伸缩所需要的操作步骤。还是比较复杂的，其中涉及到了：

• 底层资源的伸缩；
• 服务的自动化部署；
• 服务的健康检查；
• 服务发现的注册；
• 服务流量的调度。

而对于故障迁移，也就是服务的某个实例出现问题时，我们需要自动地恢复它。对于服务来说，有两种模式，一种是宠物模式，一种是奶牛模式。

• 所谓宠物模式，就是一定要救活，主要是对于 stateful 的服务。
• 而奶牛模式，就是不用救活了，重新生成一个实例。

对于这两种模式，在运行中也是比较复杂的，其中涉及到了：服务的健康监控（这可能需要一个 APM 的监控）。

• 如果是宠物模式，需要：服务的重新启动和服务的监控报警（如果重试恢复不成功，需要人工介入）。
• 如果是奶牛模式，需要：服务的资源申请，服务的自动化部署，服务发现的注册，以及服务的流量调度。

要完成这些事情并不容易，需要做很多工作，而且有很多细节上的问题会让感到焦头烂额。幸运地是我们生活在了一个比较不错的时代，因为有 Docker 和 Kubernetes 这样的技术，可以非常容易地让我们做这个工作。

5. 服务工作流和编排

在前面提到的SOA 架构演化图来看，要完成这个编排工作，传统的 SOA 是通过 ESB——企业服务总线来完成的。ESB 的主要功能是服务通信路由、协议转换、服务编制和业务规则应用等。

而在微服务中，我们希望使用更为轻量的中间件来取代 ESB 的服务编排功能。

简单来说，这需要一个 API Gateway 或一个简单的消息队列来做相应的编排工作。所有的请求都统一通过 API Gateway来访问内部的服务。这个和 Kubernetes 中的 Ingress 相似。

五、关键技术：流量与数据调度

关于流量调度，很多都把这个事和服务治理混为一谈了。我觉得还是应该分开的。一方面，服务治理是内部系统的事，而流量调度可以是内部的，更是外部接入层的事。另一方面，服务治理是数据中心的事，而流量调度要做得好，应该是数据中心之外的事，也就是我们常说的边缘计算，是应该在类似于 CDN 上完成的事。

1. 流量调度的主要功能

• 依据系统运行的情况，自动地进行流量调度，在无需人工干预的情况下，提升整个系统的稳定性；
• 让系统应对爆品等突发事件时，在弹性计算扩缩容的较长时间窗口内或底层资源消耗殆尽的情况下，保护系统平稳运行。

这还是为了提高系统架构的稳定性和高可用性。此外，这个流量调度系统还可以完成以下几方面的事情。

• 服务流控。服务发现、服务路由、服务降级、服务熔断、服务保护等。
• 流量控制。负载均衡、流量分配、流量控制、异地灾备（多活）等。
• 流量管理。协议转换、请求校验、数据缓存、数据计算等。

所有的这些都应该是一个 API Gateway 应该做的事。

2. 流量调度的关键技术

作为一个 API Gateway 来说，因为要调度流量，首先需要扛住流量，而且还需要有一些比较轻量的业务逻辑，所以一个好的 API Gateway 需要具备以下的关键技术。

• 高性能。API Gateway 必须使用高性能的技术，所以，也就需要使用高性能的语言。
• 扛流量。要能扛流量，就需要使用集群技术。集群技术的关键点是在集群内的各个结点中共享数据。这就需要使用像 Paxos、Raft、Gossip 这样的通讯协议。因为 Gateway 需要部署在广域网上，所以还需要集群的分组技术。
• 业务逻辑。API Gateway 需要有简单的业务逻辑，所以，最好是可以让人注入不同语言的简单业务逻辑。
• 服务化。一个好的 API Gateway 需要能够通过 Admin API 来不停机地管理配置变更，而不是通过一个.conf 文件来人肉地修改配置。

3. 状态数据调度

对于服务调度来说，最难办的就是有状态的服务了。这里的状态是 State，也就是说，有些服务会保存一些数据，而这些数据是不能丢失的，所以，这些数据是需要随服务一起调度的。

一般来说，我们会通过“转移问题”的方法来让服务变成“无状态的服务”。也就是说，会把这些有状态的东西存储到第三方服务上，比如 Redis、MySQL，或是 NFS、Ceph 的文件系统中。

这些“转移问题”的方式把问题转移到了第三方服务上，于是自己的 .net 或 PHP 服务中没有状态，但是 Redis 和 MySQL 上则有了状态。

所以，我们可以看到，现在的分布式系统架构中出问题的基本都是这些存储状态的服务。因为数据存储结点在 Scale 上比较困难，所以成了一个单点的瓶颈。

4. 分布式事务一致性的问题

让数据服务可以像无状态的服务一样在不同的机器上进行调度，这就会涉及数据的 replication 问题。而数据 replication 会带来数据一致性的问题，进而对性能带来严重的影响。

要解决数据不丢失的问题，只能通过数据冗余的方法，就算是数据分区，每个区也需要进行数据冗余处理。这就是数据副本。当出现某个节点的数据丢失时，可以从副本读到。数据副本是分布式系统解决数据丢失异常的唯一手段。简单来说：

• 要想让数据有高可用性，就得写多份数据。
• 写多份会引起数据一致性的问题。
• 数据一致性的问题又会引发性能问题。

在解决数据副本间的一致性问题时，我们有一些技术方案。

• Master-Slave 方案。
• Master-Master 方案。
• 两阶段和三阶段提交方案。
• Paxos 方案。

当然现在还有一些成熟的CAP框架和Saga框架供我们使用，最核心的还是我们需要理解框架背后的逻辑。

六、分布式相关的几个知识点

1. CAP定理

CAP 定理是分布式系统设计中最基础，也是最为关键的理论。它指出，分布式数据存储不可能同时满足以下三个条件。

• 一致性（Consistency）：每次读取要么获得最近写入的数据，要么获得一个错误。
• 可用性（Availability）：每次请求都能获得一个（非错误）响应，但不保证返回的是最新写入的数据。
• 分区容忍（Partition tolerance）：尽管任意数量的消息被节点间的网络丢失（或延迟），系统仍继续运行。

CAP 定理表明，在存在网络分区的情况下，一致性和可用性必须二选一。而在没有发生网络故障时，即分布式系统正常运行时，一致性和可用性是可以同时被满足的。这里需要注意的是，CAP 定理中的一致性与 ACID 数据库事务中的一致性截然不同。

掌握 CAP 定理，尤其是能够正确理解 C、A、P 的含义，对于系统架构来说非常重要。因为对于分布式系统来说，网络故障在所难免，如何在出现网络故障的时候，维持系统按照正常的行为逻辑运行就显得尤为重要。可以结合实际的业务场景和具体需求，来进行权衡。

例如，对于大多数互联网应用来说（如门户网站），因为机器数量庞大，部署节点分散，网络故障是常态，可用性是必须要保证的，所以只有舍弃一致性来保证服务的 AP。而对于银行等，需要确保一致性的场景，通常会权衡 CA 和 CP 模型，CA 模型网络故障时完全不可用，CP 模型具备部分可用性。

• CA ，这样的系统关注一致性和可用性，它需要非常严格的全体一致的协议，比如“两阶段提交”（2PC）。CA 系统不能容忍网络错误或节点错误，一旦出现这样的问题，整个系统就会拒绝写请求，因为它并不知道对面的那个结点是否挂掉了，还是只是网络问题。唯一安全的做法就是把自己变成只读的。
• CP，这样的系统关注一致性和分区容忍性。它关注的是系统里大多数人的一致性协议，比如：Paxos 算法。这样的系统只需要保证大多数结点数据一致，而少数的结点会在没有同步到最新版本的数据时变成不可用的状态。这样能够提供一部分的可用性。
• AP，这样的系统关心可用性和分区容忍性。因此，这样的系统不能达成一致性，需要给出数据冲突，给出数据冲突就需要维护数据版本。

基本上，每个人刚开始建立一个分布式系统时，都做了以下 8 条假定。随着时间的推移，每一条都会被证明是错误的，也都会导致严重的问题，以及痛苦的学习体验。

• 网络是稳定的。
• 网络传输的延迟是零。
• 网络的带宽是无穷大。
• 网络是安全的。
• 网络的拓扑不会改变。
• 只有一个系统管理员。
• 传输数据的成本为零。
• 整个网络是同构的。

为什么我们要深刻地认识这 8 个错误？是因为，这要我们清楚地认识到——在分布式系统中错误是不可能避免的，我们能做的不是避免错误，而是要把错误的处理当成功能写在代码中。

2. Paxos 算法

Paxos 算法，是莱斯利·兰伯特（Lesile Lamport）于 1990 年提出来的一种基于消息传递且具有高度容错特性的一致性算法。但是这个算法太过于晦涩，所以，一直以来都属于理论上的论文性质的东西。

3. Raft 算法

Raft 算法和 Paxos 的性能和功能是一样的，但是它和 Paxos 算法的结构不一样，这使 Raft 算法更容易理解并且更容易实现。

Raft 把这个一致性的算法分解成了几个部分，一个是领导选举（Leader Selection），一个是日志复制（Log Replication），一个是安全性（Safety），还有一个是成员变化（Membership Changes）。对于一般人来说，Raft 协议比 Paxos 的学习曲线更低，也更平滑。

Raft 协议中有一个状态机，每个结点会有三个状态，分别是 Leader、Candidate 和 Follower。Follower 只响应其他服务器的请求，如果没有收到任何信息，它就会成为一个 Candidate，并开始进行选举。收到大多数人同意选票的人会成为新的 Leader。

一旦选举出了一个 Leader，它就开始负责服务客户端的请求。每个客户端的请求都包含一个要被复制状态机执行的指令。Leader 首先要把这个指令追加到 log 中形成一个新的 entry，然后通过 AppendEntries RPC 并行地把该 entry 发给其他服务器（server）。如果其他服务器没发现问题，复制成功后会给 Leader 一个表示成功的 ACK。

Leader 收到大多数 ACK 后应用该日志，返回客户端执行结果。如果 Follower 崩溃 （crash）或者丢包，Leader 会不断重试 AppendEntries RPC。

4. Gossip 协议

节点之间存在三种通信方式：

• push 方式。A 节点将数据 (key,value,version) 及对应的版本号推送给 B 节点，B 节点更新 A 中比自己新的数据。
• pull 方式。A 仅将数据 key,version 推送给 B，B 将本地比 A 新的数据 (key,value,version) 推送给 A，A 更新本地。
• push/pull 方式。与 pull 类似，只是多了一步，A 再将本地比 B 新的数据推送给 B，B 更新本地。

如果把两个节点数据同步一次定义为一个周期，那么在一个周期内，push 需通信 1 次，pull 需 2 次，push/pull 则需 3 次。从效果上来讲，push/pull 最好，理论上一个周期内可以使两个节点完全一致。直观感觉上，也是 push/pull 的收敛速度最快。

另外，每个节点上又需要一个协调机制，也就是如何交换数据能达到最快的一致性——消除节点的不一致性。上面所讲的 push、pull 等是通信方式，协调是在通信方式下的数据交换机制。

协调所面临的最大问题是，一方面需要找到一个经济的方式，因为不可能每次都把一个节点上的数据发送给另一个节点；另一方面，还需要考虑到相关的容错方式，也就是当因为网络问题不可达的时候，怎么办？

一般来说，有两种机制：一种是以固定概率传播的 Anti-Entropy 机制，另一种是仅传播新到达数据的 Rumor-Mongering 机制。前者有完备的容错性，但是需要更多的网络和 CPU 资源，后者则反过来，不耗资源，但在容错性上难以保证。

Anti-Entropy 的机制又分为 Precise Reconciliation（精确协调）和 Scuttlebutt Reconciliation（整体协调）这两种。前者希望在每次通信周期内都非常精确地消除双方的不一致性，具体表现就是互发对方需要更新的数据。因为每个结点都可以读写，所以这需要每个数据都要独立维护自己的版本号。

而整体协调与精确协调不同的是，整体协调不是为每个数据都维护单独的版本号，而是每个节点上的数据统一维护一个版本号，也就是一个一致的全局版本。这样与其他结果交换数据的时候，就只需要比较节点版本，而不是数据个体的版本，这样会比较经济一些。如果版本不一样，则需要做精确协调。