一文读懂分布式架构知识制度（内含超全核心知识大图）

作者 | 晓土阿里巴巴高级工程师

姊妹篇阅读推荐：《[云原生时代，分布式平台设计必备常识图谱（内含22个知识点）]()》

导读：本文力求从分布式基础理论、架构设计理念、工程应用、部署运维、业界方案这几大方面，介绍基于 MSA（微服务架构）的分布式知识制度大纲，从而对 SOA 到 MSA 进化有着立体的了解；从概念上跟工具应用上最近一步了解微服务分布式的本质，身临其境的体会怎么构建全套微服务架构的过程。

关注“阿里巴巴云原生”公众号，回复“分布”，即可下载分布式平台以及知识体系清晰大图！

随着移动互联网的演进和智能终端的普及，计算机平台早就从单机独立工作过渡到多机器协作，集群按照分布式理论构建出庞大复杂的应用服务，在分布式的基础上正进行一场云原生的科技革命，彻底摆脱传统的研发方法，解放了新一代的生产力。

关注“阿里巴巴云原生”公众号，回复“**分布**”，即可下载分布式平台以及知识体系清晰大图！

由于业务发展至一定程度后，需要对服务进行耦合，进而把一个单一的大平台按逻辑拆分成不同的子系统，通过服务接口来通信。面向服务的设计理念，最终必须总线集成服务，而且大部分时候还共享，出现单点故障时会导致总线层面的故障，更进一步可能会把拖垮，所以才有了非常独立的设计方案的出现。

微服务是真正含义上的独立服务，从服务入口到数据持久层，逻辑上都是独立隔离的，无需服务总线来接入，但同时也降低了整个分布式平台的构建跟管理难度，需要对服务进行编排和管控，所以伴随着微服务的勃兴，微服务生态的整套技术栈也必须无缝接入，才能支撑起微服务的管控理念。

传统的节点也就是一台单体的物理机，所有的服务都揉进去包括服务跟；随着虚拟化的演进，单台物理机往往可以分成多台虚拟机，实现资源运用的最大化，节点的概念也成为单台虚拟机上面服务；近几年容器技术日渐成熟后，服务早已彻底容器化，也就是节点也是轻量级的容器服务。总体来说，节点就是能提供单位服务的逻辑计算资源的集合。

分布式架构的基石就是网络，不管是局域网还是公网，没有网络就能够把计算机联合在一起工作，但是网络也带给了一系列的难题。网络消息的传播有先后，消息丢失和推迟是一直出现的事情，我们定义了三种网络工作方式：

半同步网络异步网络

常用网络存储层有两大协议的特征简介：

UDP 协议

慢速物理时空中，时间独自在流淌着，对于串行的事务来说，很简单的就是跟着时间的脚步跑就可以，先来后到的出现。而后我们发明了时钟来刻画以往出现的时间点，时钟令这个世界井然有序。但是针对分布式世界来说，跟时间打交道着实是一件痛苦的事情。

分布式世界上面，我们应协调不同节点之间的先来后到关系，不同节点本身承认的时间既各执己见，于是我们创造了网络时间协议（NTP）试图来解决不同节点之间的标准时间，但是 NTP 本身体现并不尽如人意，所以我们既构造出了逻辑时钟，最后改进为向量时钟：

原子钟

有了考量时间的工具，解决顺序问题自然就是水到渠成了。因为整个分布式的理论基础就是如何协商不同节点的一致性问题，而排序则是一致性理论的基本概念，所以前文我们才必须花时间介绍衡量时间的刻度和工具。

说到一致性理论，我们需要看一张关于一致性强弱对平台建设影响的对比图：

该图对比了不同一致性算法下的事务、性能、错误、延迟的平衡。

单机环境下我们对传统关系型有严格的规定，由于存在网络的推迟和消息丢失，ACID 便是保证事务的方法，这四大原则并且我们都不需要解释起来就耳熟能详了：

分布式环境下，我们能够确保网络的正常连结和信息的传送分布式存储架构，于是发展出了 CAP/FLP/DLS 这三个重要的理论：

多数状况下，其实我们也只是一定要求强一致性，部分业务可以容忍一定程度的提早一致，所以为了突显效率，发展起来了最后一致性理论 BASE。BASE 是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）：

分布式架构的核心就在于一致性的谋求和让步，那么怎样设计一套算法来确保不同节点之间的通信和数据超过无限趋向一致性，就相当重要了。保证不同节点在增添不确定性网络环境下可达成同样副本的一致性是相当困难的，业界对该课题也做了长期的研究。

首先我们应知道一致性的大前提方法(CALM):

CALM 原则的全称是 Consistency and Logical Monotonicity ，主要表述的是分布式平台中单调逻辑与一致性的关系，它的内容如下，参考consistency as logical monotonicity。

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

我们了解到分布式一些规律原则以后，就要着手考虑怎样来推动解决方案，一致性算法的前提是数据结构，或者说一切算法的基石都是数据结构，设计良好的数据结构加上精妙的算法可以高效的缓解现实的难题。经过前人不断的探求，我们得知分布式系统被广泛运用的数据结构 CRDT。

参考《谈谈 CRDT》,A comprehensive study of Convergent and Commutative Replicated Data Types

了解数据结构后，我们必须来关注一下分布式平台的一些重要的协议HATs(Highly Available Transactions)，ZAB(Zookeeper Atomic Broadcast)：

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

最后要学习的是业界主流的一致性算法：

说实话具体的算法我也还没完全搞懂，一致性算法是分布式平台更核心本质的内容，这部分的演进也会妨碍架构的变革，不同场景的应用也造就不同的算法。

这一节我们说完分布式平台上面核心理论基础，如何达成不同节点之间的数据一致性，下面我们将要提到如今都有什么主流的分布式平台。

单台计算机的内存仍然有上限，随着网络的发生，多台计算机协同存储文件的细则也陆续被提起来。最早的分布式文件系统其实也称为网络文件系统，第一个文件服务器在 1970 年代被发展起来。在 1976 年迪吉多公司设计出 File Access Listener（FAL），而现代分布式文件系统则出自赫赫有名的 Google 的论文，《The Google File System》奠定了分布式文件系统的基础。现代主流分布式文件系统参考《分布式文件系统对比》,下面列出几个常用的文件系统：

当然也属于文件系统，主数据提高了事务、检索、擦除等高级特性，所以复杂度又提高了，既应考量数据一致性也得确保足够的性能。传统关系型为了突显事务跟性能的特点，在分布式方面的演进有限，非关系型摆脱了事务的强一致性束缚，达到了最后一致性的效果，从而有了飞跃的发展，NoSql(Not Only Sql) 也造成了多个架构的类型，包括 KV、列式存储、文档类型等。

分布式计算平台建立在分布式存储的基础上，充分发挥分布式平台的数据冗余灾备，多副本高效获取数据的特点，进而并行计算，把原来应该长时间计算的任务拆分成多个任务并行处理，从而提升了计算精度。分布式计算平台在场景上分为离线计算、实时计算和流式计算。

缓存作为提高功耗的神器无处不在，小到 CPU 缓存架构，大到分布式应用内存。分布式缓存系统提供了热点数据的随机访问模式，大大了提高了访问时间，但是带给的难题是怎样保证数据的一致性，引入分布式锁来缓解这个难题，主流的分布式内存系统基本就是 Redis 了。

分布式消息队列系统是减轻异步带来的一系列复杂流程的一大利器，在多线程高并发场景下，我们经常必须谨慎设计业务代码，来确保多线程并发情况下不发生资源竞争引起的宕机问题。而消息队列以一种延迟消费的方式将异步任务都存至队列，然后再逐个消化。

分布式系统从单机到集群的形态演进，复杂度也大大提高，所以对整个平台的监控也是必不可少。

分布式平台的核心组件就是在应用能否处理业务逻辑，应用直接的读取依赖于特定的协议来通信，有基于 RPC 协议的，也有基于通用的 HTTP 协议。

错误对应分布式系统是家常便饭，而且我们设计系统的之后，本身就必须把容错作为普遍存在的现象来考量。那么当发生故障的之后，快速修复和排查故障就变得更加重要了。分布式日志收集储存跟检索则可以帮我们提供有力的软件来定位请求链路中发生弊端的环节。

前文我们看到所谓分布式系统，是迫于单机的功耗有限，而堆硬件却既能够无休止的降低，单机堆软件最后也会遭遇性能增长曲线的窘境。于是我们才采取了多台计算机来干相同的活，但是这种的分布式平台仍然必须中心化的节点来监控以及调度平台的资源，即使该中心节点也或许是多节点构成。区块链则是真正的区中心化分布式平台，系统里面只有 P2P 网络协议各自通信，没有真正含义的中心结点，彼此按照区块链节点的算力、权益等措施来协调新区块的形成。

上节我们列举了不同场景下不同分布式平台架构扮演的角色跟实现的功能，本节我们更进一步归纳分布式平台设计的之后是怎样考虑架构设计的、不同设计方案直接的差别和侧重点、不同场景必须选用合作设计理念，来降低试错的费用，设计分布式平台必须考量以下的弊端。

可用性是平台运行和工作的时间比率，通常以正常运行时间的百分比来评判。它或许受平台错误、基础架构问题、恶意attack和平台负载的影响。分布式平台一般为客户提供服务级别合同（SLA），因此应用程序必须设计为最大化可用性。

数据管理是分布式平台的关键要素，并妨碍大多数质量的属性。由于功耗，可扩展性或可用性等因素，数据一般托管在不同位置跟多个服务器上，这或许带给一系列挑战。例如，必须维护数据一致性，并且一般必须跨不同位置同步数据。

良好的设计包含例如模块设计跟部署的一致性、简化管理跟开发的可维护性、以及允许模块和子系统用于其它应用程序和其他方案的可重用性等原因。在设计跟实施阶段作出的决策对分布式系统和服务品质跟总体拥有成本产生很大制约。

分布式平台必须一个连接部件和服务的消息传递中间件，理想状况是以松散耦合的方法，以便最大限度地减少能伸缩性。异步消息传递被广泛使用，并提供许多弊端，但也带来了例如消息排序，幂等性等挑战

分布式系统在远程数据中心运行，无法完全控制基础构架，这让管理跟监视比单机部署很困难。应用需要公开运行时信息，管理员可以使用这种信息来管控和监控平台，以及支持不断变化的业务需求跟自定义，而无需停止或再次推进应用。

性能表示平台在给定时间间隔内执行任何操作的响应性，而能伸缩性是平台处理负载降低而不妨碍性能或易于增加可用资源的能力。分布式平台一般会遭遇差异的负载和活动高峰，特别是在多租户场景中，几乎是不可能推测的。相反，应用需要才能在限制范围内扩充以满足需求高峰，并在意愿降低时进行扩充。可伸缩性不仅涉及计算例子，还涉及其它元素，如数据存储、消息队列等。

弹性是指系统无法优雅地处理故障并从故障中修复。分布式平台一般是多租户，使用共享系统服务、竞争资源跟带宽，通过 Internet 进行通信，以及在商用软件上运行，意味着出现瞬态和很永久性故障的可能性增加。为了维持弹性，必须迅速有效地测试故障并进行修复。

安全性是平台无法避免在设计使用之外的恶意或意外行为，并避免泄密或损坏信息。分布式平台在受认同的本地边界之外的 Internet 上运行，通常向公众开放，并且可以为不受信任的客户提供服务。必须以保护应用程序免受恶意attack，限制仅允许对未同意用户的访问，并保护敏感数据。

前文我们介绍了分布式平台的核心理论，面临的一些瓶颈和缓解问题的折中思路，罗列了现有主流分布式平台的分类，而且归纳了建设分布式系统的一些方法论，那么接下来我们将从项目角度来介绍搭建分布式平台包括的内容跟方法。

巧妇难为无米之炊，我们一切的工具系统都是构建在软件服务器的基础上。从更开始的物理机直接部署工具系统，到虚拟机的应用，最后到了资源上云容器化，硬件资源的使用也开始了集约化的管理。本节对比的是传统运维角色对应的职能范围，在 devops 环境下，开发运维一体化，我们要推动的只是资源的灵活高效使用。

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-135772-1.html