分布式架构知识体系必读

1.问题 2.关键词

节点、时间、一致性、CAP、ACID、BASE、P2P、机器伸缩、网络变更、负载均衡、限流、鉴权、服务发现、服务编排、降级、断路器、幂等、分库分表、分片Partitioning 、自动化运维、容错处理、全栈监控、故障恢复、性能调优

三、全文概要

随着移动互联网的发展和智能终端的普及，计算机系统早已从单机独立工作过渡到多机协同工作。 计算机以集群的形式存在，按照分布式理论指导构建庞大复杂的应用服务也已经深入人心。 本文力图从分布式基础理论、架构设计模式、工程应用、部署运维、行业解决方案等方面介绍一个基于MSA（微服务架构）的分布式知识体系概述。 这样，我们就对从SOA到MSA的演进有了一个立体的认识，可以从概念和工具应用的角度进一步理解微服务分发的本质，体验如何构建一套完整的服务架构的过程。微服务架构。

4. 基础理论 4.1 从SOA到MSA的演化 SOA面向服务架构

业务发展到一定程度后，需要对服务进行解耦，然后在逻辑上将单个大系统拆分成不同的子系统，通过服务接口进行通信。 面向服务的设计模式最终需要总线集成服务。 ，而且大多数时候比特币系统架构，数据库也是共享的。 当出现单点故障时，会造成总线层面的故障，进一步的，可能会拖累数据库，所以有更独立的设计方案。

MSA 微服务架构

微服务是真正意义上的独立服务。 从服务入口到数据持久层，它们在逻辑上是隔离的，不需要服务总线来访问，但同时也增加了整个分布式系统的搭建和管理难度。 编排和管理，所以随着微服务的兴起，微服务生态的整个技术栈也需要无缝衔接，以支撑微服务的治理理念。

4.2 节点和网络节点

传统节点只是一台物理机，所有的服务都包括在内，包括服务和数据库； 随着虚拟化的发展，往往可以将一台物理机划分为多个虚拟机，以实现资源利用率的最大化。 节点的概念也变成了单个虚拟机上的服务； 近年来，容器技术逐渐成熟后，服务已经完全容器化，即节点只是一个轻量级的容器服务。 一般来说，节点是可以提供单元服务的逻辑计算资源的集合。

互联网

分布式架构的基础是网络。 无论是局域网还是公网，没有网络计算机是无法协同工作的，但是网络也带来了一系列的问题。 网络消息的传输是有先后顺序的，消息丢失和延迟是常有的事。 我们定义了三种网络工作模式：

同步网络

半同步网络

异步网络

协议

UDP协议

4.3 时间和顺序时间

在缓慢的物理时间和空间中，时间独自流动。 对于串行交易来说，跟随时间的步伐很简单，事情先发生。 然后我们发明了时钟来描述过去发生的时间点，时钟让世界保持秩序。 但是对于分布式世界来说，处理时间确实是一件痛苦的事情。 在分布式世界中，我们需要协调不同节点之间的先到先得的关系，但是不同节点所认可的时间有不同的看法，因此我们创建了网络时间协议（NTP）来尝试解决标准时间不同节点之间，但是NTP本身的性能并不理想，所以我们构造一个逻辑时钟，最后改进为向量时钟：

NTP的一些缺点不能完全满足分布式下并发任务的协调问题

逻辑时钟

矢量时钟

原子钟

命令

有了计量时间的工具，解决时序问题自然水到渠成。 因为整个分布的理论基础是如何协商不同节点的一致性，而顺序是一致性理论的基本概念，所以我们需要在上一篇文章中花时间介绍衡量时间的尺度和工具。

4.4 一致性理论

说到一致性理论，必须看一张一致性对系统建设影响的对比图：

这张图比较了不同共识算法下的交易平衡、性能、错误和延迟。

强稠度酸

在单机环境下，我们对传统的关系型数据库有着严格的要求。 由于网络延迟和消息丢失，ACID 是保证交易的原则。 这四个原则我们不用解释也很熟悉：

分布式一致性 CAP

在分布式环境中，我们无法保证网络的正常连接和信息的传递，所以我们发展了CAP/FLP/DLS的三个重要理论：

弱一致性 BASE

大多数情况下，其实我们并不一定需要强一致性。 一些业务可以容忍一定程度的延迟一致性。 因此，为了兼顾效率，最终一致性理论BASE应运而生。 BASE指的是基本可用（Basically Available）、软状态（Soft State）、最终一致性（Eventual Consistency）

共识算法

分布式架构的核心在于一致性的实现和妥协，因此如何设计一套算法来保证不同节点之间的通信和数据达到无限一致性就显得非常重要。 在不确定的网络环境下，保证不同节点能够实现同一份副本的一致性是非常困难的，业界对此也做了大量的研究。

首先，我们需要了解一致性的大前提原则（CALM）：

CALM原则的全称是Consistency and Logical Monotonicity，主要描述分布式系统中单调逻辑与一致性的关系。 其内容如下。 将一致性称为逻辑单调性

然后关注分布式系统的数据结构CRDT（Conflict-Free Replicated Data Types）：

在我们了解了一些分配的规律和原则之后，我们就要开始考虑如何实施解决方案了。 共识算法的前提是数据结构，或者说所有算法的基础都是数据结构。 一个设计良好的数据结构加上一个精巧的算法可以高效的解决实际问题。 经过前人的不断探索，我们了解到CRDT这种数据结构在分布式系统中的应用非常广泛。

参考《浅谈CRDT》，综合研究Convergent and Commutative Replicated Data Types

了解了数据结构后，我们需要关注分布式系统的一些重要协议HATs（Highly Available Transactions）、ZAB（Zookeeper Atomic Broadcast）：

参考《高可用事务》、《ZAB协议分析》

最后要学习的是业界主流的共识算法：

说实话，具体的算法我还没有完全理解。 共识算法是分布式系统的核心和必备内容。 这部分的发展也会影响架构的创新。 不同场景的应用也导致了不同的算法。

在本节中，我们介绍了分布式系统的核心理论基础以及如何实现不同节点之间的数据一致性。 接下来，我们就来说说目前主流的分布式系统。

5. 场景分类 5.1 文件系统

单台电脑的存储总是有上限的。 随着网络的出现，多台计算机协同存储文件的方案也相继被提出。 最早的分布式文件系统其实也叫网络文件系统，第一个文件服务器是在1970年代开发的。 1976年，Digito公司设计了File Access Listener（FAL），现代分布式文件系统出自谷歌著名论文“The Google File System”，奠定了分布式文件系统的基础。参见《Comparison of Distributed File Systems》 " 用于现代主流分布式文件系统。 下面介绍几个常用的文件系统

5.2 数据库

当然，数据库也属于文件系统。 主数据增加了交易、检索、擦除等高级特性，因此复杂度增加了。 需要考虑数据的一致性，保证足够的性能。 传统关系型数据库为了兼顾事务和性能的特点，在分布式方面发展有限。 非关系型数据库摆脱了事务强一致性的约束，达到了最终一致性的效果，从而实现了快速发展。 NoSql(Not Only Sql)还生成多种架构的数据库类型，包括KV、列式存储、文档类型等。

5.3 计算

分布式计算系统建立在分布式存储的基础上，充分发挥分布式系统的数据冗余和容灾能力，以及多副本高效获取数据的特点，然后进行并行计算比特币系统架构，将原本需要的任务拆分开来长期计算分成多个任务并行处理，从而提高计算效率。 分布式计算系统在场景上分为离线计算、实时计算和流式计算。

5.4 缓存

缓存作为提升性能的利器，无处不在，从CPU缓存架构到分布式应用存储。分布式缓存系统为热点数据提供了随机访问机制，大大提高了访问时间，但问题是如何保证数据一致性。 引入分布式锁就是为了解决这个问题。 主流的分布式存储系统基本都是Redis up

5.5 消息

分布式消息队列系统是消除异步带来的一系列复杂步骤的有力工具。 在多线程高并发场景下，我们往往需要精心设计业务代码，保证在多线程并发的情况下不会出现资源竞争。 锁问题。 消息队列将所有异步任务以延迟消费的方式存储在队列中，然后一个一个的消化。

5.6 监控

随着分布式系统从单机向集群发展，复杂度也大大增加，因此对整个系统的监控也是必不可少的。

5.7 应用

分布式系统的核心模块是应用程序如何处理业务逻辑。 应用程序的直接调用依赖于特定的协议进行通信，有的基于RPC协议，有的基于通用的HTTP协议。

5.8 日志

错误对应分布式系统是家常便饭，我们在设计系统的时候，需要把容错这个普遍存在的现象考虑进去。 那么当出现故障时，快速恢复和排除故障就显得非常重要了。 分布式的日志收集、存储和检索可以为我提供强大的工具来定位请求链接中的问题链接。

5.9 账本

上面我们提到，所谓的分布式系统是由于单机性能有限，但是堆硬件不可能无止境地增加，单机堆硬件最终会遇到性能增长曲线的瓶颈。 这就是为什么我们使用多台计算机来完成同一个工作，但是这样的分布式系统总是需要一个中心节点来监控或调度系统资源，即使中心节点也可能由多个节点组成。 区块链是一个真正的中心化分布式系统。 系统中只有P2P网络协议相互通信。 没有真正的中心节点。 他们根据区块链节点的计算能力和权利来协调新区块的开发。 生产。

6. 设计模式

在上一节中，我们列举了不同分布式系统架构在不同场景下的作用和作用。 在本节中，我们进一步总结了在设计分布式系统时如何考虑架构设计，以及不同设计方案的直接区别和侧重点。 不同场景需要选择协同设计模式，降低试错成本。 在设计分布式系统时，需要考虑以下问题。

6.1 可用性

可用性是系统运行和工作的时间比例，通常以正常运行时间的百分比来衡量。 它可能会受到系统错误、基础设施问题、恶意攻击和系统负载的影响。 分布式系统通常为用户提供服务级别协议 (SLA)，因此应用程序的设计必须最大限度地提高可用性。

6.2 数据管理

数据管理是分布式系统的关键要素，影响着大多数质量属性。 由于性能、可扩展性或可用性等原因，数据通常托管在不同位置和多台服务器上，这可能会带来一系列挑战。 例如，必须保持数据的一致性，并且经常需要跨不同位置同步数据。

6.3 设计与实现

良好的设计包括组件设计和部署的一致性、简化管理和开发的可维护性以及允许组件和子系统用于其他应用程序和其他场景的可重用性等因素。 在设计和实施阶段做出的决策对分布式系统和服务质量以及总拥有成本有着巨大的影响。

6.4 消息

分布式系统需要一个消息中间件来连接组件和服务，理想情况下是以松散耦合的方式，以最大限度地提高可扩展性。异步消息被广泛使用并提供了许多好处，但也带来了消息排序、幂等等挑战。

6.5 管理和监控

分布式系统运行在远程数据中心，无法完全控制基础设施，这使得管理和监控比单机部署更加困难。 应用程序必须公开运行时信息，管理员可以使用这些信息来管理和监控系统，以及支持不断变化的业务需求和定制，而无需停止或重新部署应用程序。

6.6 性能和扩展

性能表示系统在给定时间间隔内执行任何操作的响应能力，而可伸缩性是系统在不影响性能或轻松增加可用资源的情况下处理负载增加的能力。 分布式系统经常会经历变化的负载和活动峰值，尤其是在多租户场景中，这几乎是无法预测的。 相反，应用程序应该能够在限制范围内扩展以满足需求高峰，并在需求下降时扩大规模。 可扩展性不仅涉及计算实例，还涉及其他元素，例如数据存储、消息队列等。

6.7 弹性

弹性是指系统优雅地处理故障和从故障中恢复的能力。 分布式系统通常是多租户的，使用共享平台服务，竞争资源和带宽，通过 Internet 通信，并在商用硬件上运行，这意味着出现瞬时和更永久故障的可能性增加。 为了保持弹性，必须快速有效地检测和恢复故障。

6.8 安全

安全性是系统防止其设计用途之外的恶意或意外行为，并防止信息泄露或丢失的能力。 分布式系统在受信任的本地边界之外的 Internet 上运行，通常对公众开放，并且可以为不受信任的用户提供服务。 必须保护应用程序免受恶意攻击，仅允许经过批准的用户访问，并保护敏感数据。

七、工程应用

在上一篇文章中，我们介绍了分布式系统的核心理论、面临的一些困难和解决问题的折衷思路，列出了现有主流分布式系统的分类，总结了一些构建分布式系统的方法论。 接下来，我们将从工程的角度，以真刀真枪的方式介绍搭建分布式系统所涉及的内容和步骤。

7.1 资源调度

我们所有的软件系统都是建立在硬件服务器的基础上。 从最初的软件系统直接部署在物理机上，到虚拟机的应用，再到资源的云容器化，硬件资源的利用也很重要。 集约化管理开始。 本节对比传统运维角色对应的职责范围。 在devops环境下，开发运维是一体化的，我们要实现的是资源的灵活高效的利用。

弹性膨胀

过去，如果软件系统随着用户数量的增加需要增加机器资源，传统的做法是找一台运维应用机器，然后部署软件服务连接集群。 整个过程依赖于运维人员的人为经验，效率低下且容易出错。 微服务分发不需要人肉加物理机。 在容器化技术的支持下，我们只需要申请云资源，然后执行容器脚本即可。

网络管理

有了计算资源，最重要的就是网络资源。 在当前的云化背景下，我们几乎无法直接访问物理带宽资源，而是由云平台直接统一管理。 我们需要的是对网络资源的最大应用和有效管理。

故障快照

当系统出现故障时，我们的首要任务是恢复系统。 同时，保存案发现场也很重要。 资源调度平台需要有统一的机制来保存故障现场。

7.2 流量调度

我们搭建好分布式系统后，首先要测试的网关就是网关。 然后我们需要关注系统的流量情况，即如何管理流量。 我们追求的是在系统能够容纳的流量上限之内。 为最优质的流量预留资源，将非法和恶意流量拒之门外，以节省成本，确保系统不被冲击和崩溃。

负载均衡

负载均衡是我们对服务如何消化流量的总体设计。 通常分为物理层底层协议分布的硬负载均衡和软件层的软负载。负载均衡方案在业界已经是比较成熟的方案。 我们通常会在不同的环境中优化特定的业务。 常用的负载均衡方案如下

网关设计

网关是负载均衡首当其冲的，因为网关是集中式集群流量最先冲击的地方。 如果网关无法承受压力，整个系统将不可用。

流量管理 流量控制

对于剩下的真实流量，我们使用不同的算法进行请求导流

交通限制

当流量激增时，通常我们需要限流措施来防止系统雪崩，这时我们需要预估系统流量的上限，然后设置上限，但是当流量增加到一定阈值后，额外的流量不会进入系统，通过牺牲部分流量来保持系统的可用性。

7.3 服务调度

所谓锻造，就是要靠自己的努力。 在流量被调度和管理之后，剩下的就是服务本身的健壮性。 分布式系统服务失败是常有的事，我们甚至需要将失败本身视为分布式服务的一部分。

注册中心

我们在网络管理部分介绍了网关。 网关是流量的集散地，注册中心是服务的基地。

版本管理服务编排

服务编排的定义是通过消息的交互顺序来控制各个部分资源的交互。 参与交互的资源都是对等的，没有集中控制。 微服务环境中有很多服务。 我们需要一个总协调器来协商服务之间的依赖关系和调用关系。 K8S是我们最好的选择。

服务控制

前面我们已经解决了网络的健壮性和高效性，本节介绍如何让我们的服务更加健壮。

降级

当用户量激增时，我们首先在流量端做一些小动作，就是限制流量。 当我们发现节流后系统响应变慢，可能会导致更多的问题，我们也需要对服​​务本身做一些操作。 服务降级就是把目前不是很核心的功能关掉，或者放宽不是很重要的精度范围，之后再做一些人工补救。

保险丝

当我们做了以上操作，还是觉得心神不宁时，那我们就需要进一步担心了。 熔断是一种对过载的自我保护，就像我们的开关跳闸一样。 比如我们的服务不断查询数据库的时候，如果业务问题导致查询出现问题，那是因为数据库本身需要进行融合，保证不会被应用拖累，访问友好的信息告诉服务不盲目地打电话。

幂等的

我们知道，幂等操作的特点是任意多次执行的影响和一次执行的影响是一样的。 这么长的时间，需要给单个操作分配一个全局id进行标识，这样在多次请求之后，我们才能判断是来自同一个客户端，避免脏数据。

7.4 数据调度

数据存储的最大挑战是数据冗余的管理。 冗余太多，效率低下，占用资源。 如果副本少，就起不到容灾的作用。 我们通常的做法是通过transitions将requests与transitions分开。 , 转换为无状态请求。

状态转移

将状态分离到全局存储，并将请求转换为无状态流量。 比如我们在多个应用中，通常会把登录信息缓存到全局的redis中间件中，而不会出现冗余的用户登录数据。

分库分表

数据横向扩展

分片分区

多副本冗余

7.5 自动化运维

我们从资源应用管理的时候就引入了devops的趋势，真正的开发运维一体化需要不同中间件的配合。

配置中心

全局配置中心以环境区分，统一管理，减少多种配置的混淆

部署策略

微服务的分布式部署很常见。 如何让我们的服务更好的支持业务发展，健壮的部署策略是我们首先要考虑的。 以下部署策略适用于不同的业务和不同的阶段。

作业调度

任务调度是系统的重要组成部分。 传统的方式是在linux机器上配置crond定时任务或者直接在业务代码中完成调度业务。 现在已经被成熟的中间件所取代。

应用管理

很大一部分运维工作需要重启应用，登录退出，清理日志。

7.6 容错处理

既然知道分布式系统故障是家常便饭，那么故障的解决方案也是必不可少的一环。 通常我们有主动和被动的方式来应对。 主动地，当错误发生时，我们尝试多尝试几次，也许我们会成功。 如果我们成功了，我们就可以避免错误。 被动的方式是错误的事情已经发生了。 为了挽回，我们只是及时处理，将负面影响降到最低。

重试设计

重试设计的关键是设计重试的时间和次数。 如果重试的次数超过或者一段时间，那么重试就没有意义了。 开源项目spring-retry可以很好的实现我们的重试计划。

商业补偿

交易补偿符合我们最终一致性的理念。 补偿事务不一定将系统中的数据返回到原始操作开始时的状态。 相反，它补偿在操作失败之前成功完成的步骤所执行的工作。 补偿事务中的步骤顺序不一定与原始操作中的步骤顺序完全相反。 例如，一个数据存储可能比另一个数据存储对不一致更敏感，因此在补偿事务中撤消对该存储的更改的步骤应该首先发生。 对完成操作所需的每个资源进行短暂的基于超时的锁定并预先获取这些资源有助于提高活动成功的总体可能性。 只有在获得所有资源后才能执行工作。 所有操作都必须在锁过期之前完成。

7.7 全栈监控

由于分布式系统是一个多台机器协作的系统，网络不能保证完全可用，所以我们需要搭建一个可以全方位监控的系统，这样我们就可以从底层到各个层面进行监控商业。 及时修复故障，避免出现更多问题。

基层

基础层是容器资源的监控，包括各种硬件指标的负载状态

中间件

分布式系统接入大量的中间件平台，中间件本身的健康状况也需要监控

应用层监控链路7.8故障恢复

当故障发生时，我们要做的第一件事就是立即排除故障，保证系统服务的正常可用。 这个时候我们一般会做一个回滚操作。

应用程序回滚

在回滚应用程序之前，您需要保存故障站点，以便您排查原因。

基线回滚

应用服务回滚后，代码基线也需要回滚到之前的版本。

版本回滚

整体回滚需要服务编排，通过大版本号回滚集群。

7.9 性能调优

性能优化是分布式系统的一个大课题，涉及面很广。 这篇可以单独作为一个系列拿出来，本节就不展开了。 我们服务治理的过程本身也处于性能优化的过程中。

分布式锁

缓存是解决性能问题的好工具。 理想情况下，每个请求都可以在不需要额外计算的情况下立即得到最快的结果。 小到CPU的三级缓存，大到分布式缓存，缓存无处不在。 分布式缓存要解决的是数据的一致性。 这个时候我们引入了分布式锁的概念。 如何处理分布式锁的问题将决定我们访问缓存数据的效率。

高并发

多线程编程模型提高了系统的吞吐量，但同时带来了业务的复杂性。

异步

事件驱动异步编程是一种新的编程模型，它摒弃了多线程复杂的业务处理问题，同时可以提高系统的响应效率。

8.总结

总而言之，如果可能的话，请尝试使用单节点方法而不是分布式系统。 分布式系统伴随着一些失败的操作，为了处理灾难性的失败，我们使用备份。 为了提高可靠性，我们引入了冗余。 分布式系统的本质是一堆机器的协作。 而我们要做的就是想出各种办法，让机器的运行达到预期。 对于这样一个复杂的系统，了解所有环节，接入各种中间件，是一项非常庞大的工程。 幸运的是，在微服务的背景下，大部分基础工作已经为我们实现了。 上面介绍的分布式架构，在项目实现后，基本可以使用分布式三件套（Docker+K8S+Srping Cloud）来搭建。

分布式架构的核心技术分布图如下：

分布式技术栈使用中间件：

最后用一张图总结一下分布式系统的知识体系。

Friends who like this article, welcome to follow the subscription account programmer Xiaohui by pressing the picture for a long time, and watch more exciting content