分布式基础

1、分布式简介

1.1、分布式定义

分布式系统由一组为了完成共同任务而协调工作的计算机节点组成，它们通过网络进行通信。分布式系统能满足互联网对大数据存储、高并发和快响应的要求，采用了分而治之的思想。

1.2、分布式系统的优点

• 高性能：因为大量请求被合理地分摊到各个节点，使每一台服务器的压力减小，并且多个请求可以使用多台机器处理，所以能处理更多的请求和数据，性能更高。如此，便解决了互联网系统的3个关键问题——大数据、高并发和快响应。
• 高可用：在单机系统中，机械故障会造成网站不可用。但在分布式系统中，如果某个节点出现故障，系统会自动发现这个故障，不再向这个节点转发请求，系统仍旧可以工作。自动避开存在故障的节点，继续对外提供服务，这就是分布式的高可用性。
• 可伸缩性：当现有机器的性能不能满足业务的发展时，我们需要更多的机器提供服务。只要改造路由算法，就能够路由到新的机器，从而将更多的机器容纳到系统中，继续满足大数据、高并发和快响应的要求。从另一个方面来说，如果现有的机器已经大大超出所需，则可以减少机器，从而节省成本。
• 可维护性：如果设备当中有一台机器因某种原因不能对外提供服务，如机器出现故障，此时只需要停止那些出现故障的节点，对其进行处理，然后重新上线即可。
• 灵活性：例如，当需要更新系统时，只需要在非高峰期，停用部分节点，将这些节点更新为最新版本，然后再通过路由算法将请求路由到这些更新后的节点，最后更新那些旧版本的节点，就可以让网站在更新系统时不间断地对外提供服务了。

２、分布式系统的切分方法

使用分布式系统，就意味着需要将系统按照不同的维度（如业务、数据等）切分给各个不同节点的机器。因此，需要对业务或者数据进行合理切分，让多个机器节点能够相互协作，以满足业务功能的需要。

2.1、水平拆分

将同一个系统部署到多台机器上（集群）。

单体的Web服务器变成了多个Web服务器节点，每台服务器都有相同的应用，都能独立完成计算，互不相干。这样的切分有以下几个好处：

• 简单：只需要实现一个路由算法，将请求合理地分配到各个节点即可。目前能够快速方便地实现这个功能的网关包括Nginx、Netflix Zuul和Spring Cloud Gateway等。
• 独立：每个节点都有完整的运算功能，不需要依赖其他节点，因此系统之间不需要太多的交互。
• 高可用：当出现不能工作的节点时，系统仍然可以继续运行，无须停机，因为路由算法不会给不能工作的节点分配请求。
• 可伸缩：可以随着业务的增长，增加服务节点，也可以随着业务的缩减，减少服务节点，二者都十分容易。
• 高性能：因为都是在单机内完成，不需要做外部调用，因此可以得到很高的性能。

以上就是水平切分的优势，但是这样的分法，也有很大的弊端。随着业务的发展，业务会从简单变复杂。例如，一个电商的网站，用户和业务不断膨胀，所需的产品、卖家、交易和评论业务也会日趋复杂。如果此时还将所有的业务全部集中在一套系统里开发，那么显然所有业务都会耦合到一套系统里，日后的扩展和维护会越来越困难。一方面，我们会不断地通过打包来升级系统，使得系统的稳定性和可靠性不断下降；另一方面，维护起来也不方便，例如，要升级产品业务，就需要对全部节点进行升级，而这样的升级会比较麻烦。

2.2、垂直拆分

随着业务的增加和深入，以及用户数的膨胀，有时候，单一业务也会随之变得异常复杂，有必要按照业务的维度进行拆分，将各个业务独立出来，单独开发和维护。假设，我们将用户、交易和产品系统拆分出来，独立开发，就可以得到如下如所示的架构：

可以看出，我们把系统按照业务维度进行了切分，这样每一个系统就都能独立开发和维护了。垂直切分有以下好处：

• 提高业务独立性：只要根据业务把系统划分成高内聚、低耦合的模块，就能极大地降低开发难度。
• 提高灵活性：任何一个业务发生改变，都只需要维护相关的系统，而无须将全部系统打包上线。
• 提高可维护性：独立的系统更容易发现问题。因为将业务分离出去后，发生的异常情况更容易被定位了，所以开发者和业务人员维护起来更方便了。

虽然这样的划分带来了以上诸多好处，但其存在的弊端也是值得我们重视的，主要有以下几点：

• 增加了系统之间的协作：系统之间往往需要协作完成任务，也就是说，系统之间是相互依赖的。例如，购买一件商品，需要买家系统提供买家信息，产品系统扣减产品库存，交易系统记录商品交易，这需要3个系统共同协作来完成。从这个角度来说，系统之间必须进行协作。现今流行的系统交互有远程过程调用（RPC）、面向服务的架构（SOA）、REST风格请求和消息机制等。
• 降低了可用性：因为系统之间存在依赖，所以任何一个系统出现问题，都会影响其他系统。例如，产品系统不可用，就无法扣减库存，也就无法进行购买产品的交易了。由此可见，可用性大大降低。
• 数据一致性难以保证：因为节点之间需要通信，而网络通信往往并不可靠，所以节点之间数据的一致性难以保证。只能通过某些方法尽量减少不一致性。

2.3、混合切分

混合切分是将水平切分和垂直切分结合起来的一种切分方法。现今微服务架构大部分采用了这种分法。

可以看到，先是把系统按照业务维度切分到不同的服务器群里。然后，又对其中一种业务系统进行了水平切分，使得这种业务系统可以在多个节点中运行。最后，系统之间采用了交互机制进行协作。

通过其中的垂直切分，我们能够将业务分隔为独立的系统。这样就不会形成大耦合，有利于灵活的管理和简化后续的开发。而对每一个独立的业务系统又采用了水平切分，即使某个节点因为某种原因不可用，也有其他业务系统节点可以代替它。这样系统就可以变为高可用的了。这样的划分依旧不能克服系统之间大量交互和难以维护的数据一致性的问题，同时，切分节点比较多也会使实施分布式系统的硬件成本提高。实际上，无论何种划分，都不可能使得分布式系统只有优点，没有缺点。相对于耦合性和缺乏灵活性来说，大量交互和数据一致性的问题则更容易处理，因此混合划分渐渐成为主流划分方式。

3、分布式系统面临的问题

1.2、分布式系统所面临的问题及特点

1. 分布性：分布式系统中的多台计算机都会在空间上随意分布，同时，机器的分布情况也会随时变动。
2. 对等性：分布式系统中的计算机没有主/从之分，既没有控制整个系统的主机，也没有被控制的从机，组成分布式系统的所有计算机节点都是对等的。副本(Replica)是分布式系统最常见的概念之一，指的是分布式系统对数据和服务提供的一种冗余方式。在常见的分布式系统中，为了对外提供高可用的服务，我们往往会对数据和服务进行副本处理。数据副本是指在不同的节点上持久化同一份数据，当某一个节点上存储的数据丢失时，可以从副本上读取到该数据，这是解决分布式系统数据丢失问题最为有效的手段。另一类副本是服务副本，指多个节点提供同样的服务，每个节点都有能力接收来自外部的请求并进行相应的处理。
3. 并发性:在“问题的提出”部分，我们已经提到过与“更新的并发性”相关的内容。在一个计算机网络中，程序运行过程中的并发性操作是非常常见的行为，例如同一个分布式系统中的多个节点，可能会并发地操作一些共享的资源，诸如数据库或分布式存储等，如何准确并高效地协调分布式并发操作也成为了分布式系统架构与设计中最大的挑战之一。
4. 缺乏全局时钟:一个典型的分布式系统是由一系列在空间上随意分布的多个进程组成的，具有明显的分布性，这些进程之间通过交换消息来进行相互通信。因此，在分布式系统中，很难定义两个事件究竟谁先谁后，原因就是因为分布式系统缺乏一个全局的时钟序列控制。
5. 故障总是会发生:组成分布式系统的所有计算机，都有可能发生任何形式的故障。一个被大量工程实践所检验过的黄金定理是：**任何在设计阶段考虑到的异常情况，一定会在系统实际运行中发生，并且，在系统实际运行过程中还会遇到很多在设计时未能考虑到的异常故障。**所以，除非需求指标允许，在系统设计时不能放过任何异常情况。

1.3、分布式环境的典型问题

1. 通信异常：从集中式向分布式演变的过程中，必然引入了网络因素，而由于网络本身的不可靠性，因此也引入了额外的问题。分布式系统需要在各个节点之间进行网络通信，因此每次网络通信都会伴随着网络不可用的风险，网络光纤、路由器或是DNS等硬件设备或是系统不可用都会导致最终分布式系统无法顺利完成一次网络通信。另外，即使分布式系统各节点之间的网络通信能够正常进行，其延时也会远大于单机操作。通常我们认为在现代计算机体系结构中，单机内存访问的延时在纳秒数量级（通常是10ns左右），而正常的一次网络通信的延迟在0.1～1ms左右（相当于内存访问延时的105～106倍），如此巨大的延时差别，也会影响消息的收发的过程，因此消息丢失和消息延迟变得非常普遍。
2. 网络分区:当网络由于发生异常情况，导致分布式系统中部分节点之间的网络延时不断增大，最终导致组成分布式系统的所有节点中，只有部分节点之间能够进行正常通信，而另一些节点则不能——我们将这个现象称为网络分区，就是俗称的“脑裂”。当网络分区出现时，分布式系统会出现局部小集群，在极端情况下，这些局部小集群会独立完成原本需要整个分布式系统才能完成的功能，包括对数据的事务处理，这就对分布式一致性提出了非常大的挑战。
3. 三态：在分布式环境下，网络可能会出现各式各样的问题，因此分布式系统的每一次请求与响应，存在特有的“三态”概念，即成功、失败与超时。在传统的单机系统中，应用程序在调用一个函数之后，能够得到一个非常明确的响应：成功或失败。而在分布式系统中，由于网络是不可靠的，虽然在绝大部分情况下，网络通信也能够接收到成功或失败的响应，但是当网络出现异常的情况下，就可能会出现超时现象，通常有以下两种情况：（1）由于网络原因，该请求（消息）并没有被成功地发送到接收方，而是在发送过程就发生了消息丢失现象。（2）该请求（消息）成功的被接收方接收后，并进行了处理，但是在将响应反馈给发送方的过程中，发生了消息丢失现象。当出现这样的超时现象时，网络通信的发起方是无法确定当前请求是否被成功处理的。
4. 节点故障：节点故障则是分布式环境下另一个比较常见的问题，指的是组成分布式系统的服务器节点出现的宕机或“僵死”现象。通常根据经验来说，每个节点都有可能会出现故障，并且每天都在发生。

4、分布式重点概念

4.1、分布式事务

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于分布式系统的不同节点之上。通常一个分布式事务中会涉及对多个数据源或业务系统的操作。

设想一个最典型的分布式事务场景：一个跨银行的转账操作涉及调用两个异地的银行服务，其中一个是本地银行提供的取款服务，另一个则是目标银行提供的存款服务，这两个服务本身是无状态并且是互相独立的，共同构成了一个完整的分布式事务。假设客户小明在北京分行账户有100万存款，今天早上小明从北京银分行账户取款20万转账到上海分行，但是因为某种原因上海分行的存款服务失败了，那么北京分行的存款服务就必须回滚到取款前的状态，否则小明可能会发现自己的20万不翼而飞了。

从上面这个例子中，我们可以看到，一个分布式事务可以看作是由多个分布式的操作序列组成的，例如上面例子中的取款服务和存款服务，通常可以把这一系列分布式的操作序列称为子事务。因此，分布式事务也可以被定义为一种嵌套型的事务，同时也就具有了ACID事务特性。但由于在分布式事务中，各个子事务的执行是分布式的，因此要实现一种能够保证ACID特性的分布式事务处理系统就显得格外复杂。

4.2、分布式的衡量标准

在Andrew S. Tanenbaum创作的《分布式系统：原理与范例》中，指出了以下几点：

• 透明性：所谓透明性，就是指一个分布式系统对外来说如同一个单机系统，使用者不需要知道其内部的实现，只需要知道其参数、功能和返回结果即可。
• 可伸缩性：当分布式系统的全部现有节点都无法满足业务膨胀的需求时，可以根据需要加入新的节点来应对业务数据的增加。当业务缩减时，又可以根据需要减少节点来达到节省资源的效果。
• 可用性：一般来说，分布式系统可全天候不间断地提供服务，即使在出现故障的情况下，也尽可能对外提供服务。因而，可以通过正常服务时间和不可用时间的比值来衡量其可用性。
• 可靠性：可靠性，主要是针对数据来说的，数据要计算正确且不丢失地存储。
• 高性能：因为有多个节点分摊请求，所以能更快地处理请求。再加上每一个节点都可以高性能地处理请求，所以分布式系统的性能比单机性能高得多。
• 一致性：因为分布式系统采用了多个节点，所以在一个业务处理中，需要多台机器协作处理数据。然而，网络延迟、丢包、不稳定性或者协作时序错乱，会造成数据的不一致或者丢失。对于一些重要的数据，如账户金额和产品库存等参数，是不允许发生错误和丢失的，所以如何保证数据的一致性和防止丢失是分布式系统的一个重要的衡量标准。

4.3、微服务和分布式系统的关系

因为分布式非常复杂，所以一直以来都没有权威的架构和设计，更多的只是前人的积累和实践。前人总结出了许多有用的理念，积累了许多经验，开发了很多实施分布式的软件。近几年来，最热门的分布式架构非微服务架构莫属。它是由美国科学家Eric Brewer在其博客上发表的概念。微服务是当前分布式开发的热点内容。可以说微服务是分布式系统设计和架构的理念之一。

4.4、Spring Cloud的各个组件的简介

为了构建微服务，Spring Cloud 容纳了很多分布式开发的组件。

• Spring Cloud Config：配置管理，允许被集中化放到远程服务器中。目前支持本地存储、Git和SVN等。
• Spring Cloud Bus：分布式事件、消息总线、用于集群（如配置发生变化）中传播事件状态，可以与Spring Cloud Config联合实现热部署。
• Netflix Eureka：服务治理中心，它提供微服务的治理，包括微服务的注册和发现，是Spring Cloud的核心组件。
• Netflix Hystrix：断路器，在某个组件因为某些原因无法响应或者响应超时之际进行熔断，以避免其他微服务调用该组件造成大量线程积压。它提供了更为强大的容错能力。
• Netflix Zuul：API网关，它可以拦截Spring Cloud的请求，提供动态路由功能。它还可以限流，保护微服务持续可用，还可以通过过滤器提供验证安全。
• Spring Cloud Security：它是基于Spring Security的，可以给微服务提供安全控制。
• Spring Cloud Sleuth：它是一个日志收集工具包，可以提供分布式追踪的功能。它封装了Dapper和log-based追踪以及Zipkin和HTrace操作。
• Spring Cloud Stream：分布式数据流操作，它封装了关于Redis、RabbitMQ、Kafka等数据流的开发工具。
• Netflix Ribbon：提供客户端的负载均衡。它提供了多种负载均衡的方案，我们可以根据自己的需要选择某种方案。它还可以配合服务发现和断路器使用。
• Netflix Turbine：Turbine是聚合服务器发送事件流数据的工具，用来监控集群下Hystrix的metrics情况。
• OpenFeign：它是一个声明式的调用方案，可以屏蔽REST风格的代码调用，而采用接口声明方式调用，这样就可以有效减少不必要的代码，进而提高代码的可读性。
• Spring Cloud Task：微服务的任务计划管理和任务调度方案。

…

4.5、REST风格

REST的全称为Representational State Transfer，中文可翻译为表现层状态转换。理解它的关键在于名称的解释，这里有3个关键的名词。

• 资源：REST的中文翻译谈到了状态，但是没有谈到状态是描述什么的。在REST风格中，状态是用来描述资源的，所以要有对应的资源才能谈状态。状态可以表现为新增、修改和删除等。资源可以是一个用户、账户等，即具体存在的某个事物。
• 表现层：表现层是指资源的表现形式。一个资源可以通过JSP页面展示，也可以展示为XML或者JSON。当然，在现今最流行的表现形式是JSON，所以本书也以JSON为主。
• 状态转换：一个资源不是一成不变的，它可以被创建、访问、修改和删除。它的状态是不断变化的，所以状态转换是描述资源状况的。

根据以上3个名词，REST风格做了如下约定：

• 任何一个资源都会有一个URL，因为资源是一种名称的概念，所以在URL中不应该存在动词，只应该存在名词。
• 客户端和服务端可以互相传递资源，资源会以某种表现层的形式展示（现今最流行的是JSON数据集）。
• 客户端可以通过HTTP动作来实现资源状态的转换。

这里，每一个访问资源的URI也可以称为REST风格的一个端点（EndPoint）。关于这里的HTTP动作这个概念，还需要进一步的解释。在HTTP协议中，常见的动作（请求）主要有7种：GET、POST、PUT、PATCH、DELETE、HEAD和OPTIONS。但在实际开发中，主要有4种：GET、POST、PUT和DELETE。

• GET：获取服务端资源。
• POST：提交资源信息，让服务器创建资源。
• PUT：提交服务端现有资源的全部属性，让服务器修改资源。
• DELETE：删除服务端资源。