说明：

（1）对分布式的基本内容，进行一个入门级介绍；

（2）该篇博客参考的文章有：

         ● 【分布式与集群的区别是什么？】专栏中的一条回答，答主是【大闲人柴毛毛】；

目录

1.什么是分布式；

2.分布式的作用；

3.分布式和单体结构的对比；

4.CAP定理；

5.集群、分布式、微服务的差别；

---

1.什么是分布式；

（1）分布式这个概念是比较新的，发展时间也不长，而且分布式还正在发展，比如很多新的概念、新的技术也还在不断诞生；

（2）分布式目前为止并没有有个官方的、定型的定义；Leslie Lamport给出了这个定义：利用物理架构形成多个自治的处理元素，不共享主内存，但是通过发送信息合作；

Leslie Lamport给出的这个定义，可以这样 【利用物理架构形成多个自治的处理元素】可以理解为多台相互独立的服务器；【不共享主内存】可以理解为服务器与服务器之间是独立的，一个服务器不会访问到另一个服务器的内存；【但是通过发送信息合作】可以理解为：既然服务器之间不能互相访问内容，那么服务器要想合作就需要通过发送消息来合作了；

以下内容，完全摘抄自【分布式与集群的区别是什么？】专栏中的一条回答，答主是【大闲人柴毛毛】；

画了一上午，麻烦点个赞～

下面就正经解释下三种结构的区别吧～

单机结构

我想大家最最最熟悉的就是单机结构，一个系统业务量很小的时候所有的代码都放在一个项目中就好了，然后这个项目部署在一台服务器上就好了。整个项目所有的服务都由这台服务器提供。这就是单机结构。

那么，单机结构有啥缺点呢？我想缺点是显而易见的，单机的处理能力毕竟是有限的，当你的业务增长到一定程度的时候，单机的硬件资源将无法满足你的业务需求。此时便出现了集群模式，往下接着看。

集群结构

集群模式在程序猿界有各种装逼解释，有的让你根本无法理解，其实就是一个很简单的玩意儿，且听我一一道来。

单机处理到达瓶颈的时候，你就把单机复制几份，这样就构成了一个“集群”。集群中每台服务器就叫做这个集群的一个“节点”，所有节点构成了一个集群。每个节点都提供相同的服务，那么这样系统的处理能力就相当于提升了好几倍（有几个节点就相当于提升了这么多倍）。

但问题是用户的请求究竟由哪个节点来处理呢？最好能够让此时此刻负载较小的节点来处理，这样使得每个节点的压力都比较平均。要实现这个功能，就需要在所有节点之前增加一个“调度者”的角色，用户的所有请求都先交给它，然后它根据当前所有节点的负载情况，决定将这个请求交给哪个节点处理。这个“调度者”有个牛逼了名字——负载均衡服务器。

集群结构的好处就是系统扩展非常容易。如果随着你们系统业务的发展，当前的系统又支撑不住了，那么给这个集群再增加节点就行了。但是，当你的业务发展到一定程度的时候，你会发现一个问题——无论怎么增加节点，貌似整个集群性能的提升效果并不明显了。这时候，你就需要使用微服务结构了。

分布式结构

先来对前面的知识点做个总结。

从单机结构到集群结构，你的代码基本无需要作任何修改，你要做的仅仅是多部署几台服务器，每台服务器上运行相同的代码就行了。但是，当你要从集群结构演进到微服务结构的时候，之前的那套代码就需要发生较大的改动了。所以对于新系统我们建议，系统设计之初就采用微服务架构，这样后期运维的成本更低。但如果一套老系统需要升级成微服务结构的话，那就得对代码大动干戈了。所以，对于老系统而言，究竟是继续保持集群模式，还是升级成微服务架构，这需要你们的架构师深思熟虑、权衡投入产出比。

OK，下面开始介绍所谓的分布式结构。

分布式结构就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中，它们之间通过RPC方式通信。

举个例子，假设需要开发一个在线商城。按照微服务的思想，我们需要按照功能模块拆分成多个独立的服务，如：用户服务、产品服务、订单服务、后台管理服务、数据分析服务等等。这一个个服务都是一个个独立的项目，可以独立运行。如果服务之间有依赖关系，那么通过RPC方式调用。

这样的好处有很多：

1. 系统之间的耦合度大大降低，可以独立开发、独立部署、独立测试，系统与系统之间的边界非常明确，排错也变得相当容易，开发效率大大提升。
2. 系统之间的耦合度降低，从而系统更易于扩展。我们可以针对性地扩展某些服务。假设这个商城要搞一次大促，下单量可能会大大提升，因此我们可以针对性地提升订单系统、产品系统的节点数量，而对于后台管理系统、数据分析系统而言，节点数量维持原有水平即可。
3. 服务的复用性更高。比如，当我们将用户系统作为单独的服务后，该公司所有的产品都可以使用该系统作为用户系统，无需重复开发。

PS：该作者的微信公众号【dxrcmm】；

总结归纳：

（1）最初时候：我们开发的系统，访问量很小，完全可以把系统部署在一台服务器上；

（2）需要集群的时候：如果我们系统的访问量增加了，只用一台服务器不够用了；那么，我们就可以部署10台服务器；这10台服务器上互相独立，每台服务器上都部署完整的系统；

但是，后来访问的数量继续增大了；但是，如果我们继续增加集群数量，比如我们再增加10台服务器，效果不明显了；其实，这儿的原因和计算机网络中网络阻塞的原理有点相通的（即，盲目的增加带宽并不能缓解网络的阻塞，网络的阻塞往往是由最狭窄的那部分决定的）；

之所以继续增加集群规模，并不能有效解决问题的原因是：比如我们的系统是商城系统，其有【订单系统】、【产品系统】、【后台管理系统】、【数据分析系统】；那么，如果在双十一促销的时候，下单量会大大提升，那么【订单系统】和【产品系统】承受的压力就会比【后台管理系统】和【数据分析系统】要高的多；所以，为了更好的提升系统应对并发请求的能力；分布式架构就可以选用了；

（3）分布式架构的时候：分布式结构就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中，它们之间通过RPC方式通信。那么在商城要搞大促，下单量大大提升时，因此我们可以针对性地提升【订单系统】、【产品系统】的节点数量，而对于【后台管理系统】、【数据分析系统】而言，节点数量维持原有水平即可。

---

2.分布式的作用；

（1）单体应用的问题；

         ● 问题1：速度越来越慢：随着项目发展，项目的代码量会越来越大；那么，项目的下载、启动、打包、部署、测试都会越来越慢；

         ● 问题2：熟悉项目的工作量太大：该项目的所有模块都在一起，一个新人想要熟悉项目，需要花费很大的精力；

         ● 问题3：耦合严重：各个模块之间耦合严重；那么，高耦合就会导致程序扩展困难，同时我们想升级某个模块时候也会比较困困难；

         ● 问题4：合并代码的时，冲突会很多，同时依赖也可能有冲突：因为不同的模块都在一个项目中，很自然就会出现开发不同模块的人修改了同一处公用代码，导致合并冲突；

鉴于这些问题，分布式就逐渐发展起来了；

（2）分布式的好处；

         ● 好处1：开发、部署速度快：因为，分布式后，我们会把应用拆分成不同的、相对独立的模块；每个模块的规模相对小；

         ● 好处2：技术升级空间大：由于每个模块相对独立，耦合不严重，那么每个模块想要升级本模块的时候，就比较容易；

         ● 好处3：可用性增强：系统能够对外一直提供服务的能力更强了；因为分布式后，我们会把每个模块进行独立部署，于是就算部分模块不可用后，其实影响也不会扩大；比如下单的时候，比如有【优惠券模块】和【下单二次确认模块】，那么这两个模块并不是必须要有的，如果这两个模块不能提供服务了，并不会太影响下单；

         ● 好处4：成本低：因为每个模块都比较小，所以我们并不用买一台配置很好的服务器，而是只需要买多个普通配置的服务器就可以了；

         ● 好处5：资源利用率高：对于那些流量小的模块，比如很少会用的【注销模块】只需要部署一两个实例就够了；

---

3.分布式和单体结构的对比；

并不是说单体结构就不好，需要根据我们的实际情况，选择更合适的； 

         ● 对比1：项目启动速度：分布式的单个模块启动很快，但要想把拆分的很多模块给协调起来，也还是需要一些时间的；

         ● 对比2：团队规模：单体架构一般最多只需要3-5个人维护一个单体应用就够了；分布式架构能够支持的团队规模则没有上限了，因为只要人一多，完全就可以再拆分出一个模块给这些人就可以了；

         ● 对比3：功能维护成本：单体架构可能经常有冲突，而且对于一些旧的功能也不敢轻易修改和下限；

         ● 对比4：代码清晰度：在单体架构中，不同的模块是在一个项目中的，不同的模块共享内存，那么某个模块就可以容易去操作其他模块，这就导致我们在单体架构中一不小心就会违反“低耦合的规范”；

         ● 对比5：可用性：分布式架构有故障时，其可以很好的把故障限定在这一个模块中；

         ● 对比6：架构设计难度：分布式架构设计难度较高，要想使用分布式架构，需要团队有技术储备；

……………………………………………………

如果人员规模或公司规模比较小，那么我们在一开始开发一个项目时候，可以选择先做成单体架构的；因为我们不能保证这个项目一定能发展的很好；如果后面项目发展的很好，流量大了后，完全再可以拆分成分布式架构；（但也要考虑到，把单体架构拆分成分布式架构，也是需要成本的）

---

4.CAP定理；

（1）CAP理论是什么；

在分布式系统中，节点比较多，节点与节点间是需要通信的；因此就需要考虑到C（Consistency，一致性）；

         ● C（Consistency，一致性）：总能读到最新的写操作的结果；比如A节点进行了写操作，那么B节点读取的时候，能够读取到最新的；

         ● A（Availability，可用性）：每个请求都要在合理的时间内给出响应；即我们的系统必须可用；可用的意思是，系统要在合理的时间内给出响应，而且响应内容也是需要合理的（比如，如果响应是“请等待”、“无法给出结果”这种，就是不合理的）；

         ● P（Partition tolerance，分区容错性）：当节点之间网络不通，系统能够继续运行；比如，多个节点之间网络不通的时候，系统还能继续运行；

（2）CAP三个不可兼得；

         ● CAP我们最多只能同时兼顾两个；不能同时满足全部三个；（这个定理背后是有严格的数学证明的，我们不必深究，只需要知道有这个定理即可）

（3）CAP分析； 

         ● P（Partition tolerance，分区容错性）：在目前的情况下，这个条件必须总是成立；

那么又因为CAP三个不可兼得；所以，我们只能选择CP或者AP；

         ● C（Consistency，一致性）：例子；

         ● A（Availability，可用性）：例子；

可用性就是每个请求都要在合理的时间内给出响应；即我们的系统必须可用；可用的意思是，系统要在合理的时间内给出响应，而且响应内容也是需要合理的；

但是，如果我们返回的不是最新的数据，只要能够返回一个合理的响应，都认为是可用的；

（4）CAP如何选择；  

已知，CAP我们最多只能同时兼顾两个；不能同时满足全部三个；同时P（Partition tolerance，分区容错性）是必须要选择的；那么究竟是选择CP还是选择AP是不一定的，需要根据具体的需求选择；

         ● CDN例子：比如我们有个图片放在网上，为了让这个图片加载速度更快，我们会部署很多个节点（比如西安、北京、上海都有一个节点；那么就相当于同一份数据，有多个副本；），那么假如我们在北京访问这个系统，修改了图片，那么所有的节点不会立刻同步成北京节点上最新的那个图片的；同步更新的时间延迟，我们可以配置成几个小时或者一天；那么，在延迟到达前，通过西安和上海节点访问的用户，看到的还是老图片；；；；那么在这种场景下，我们选择就是A（Availability，可用性），即AP；（PS：选择A的情况，适用于那些对实时性要求不太高的系统）；

         ● 转账的例子：对于这种场景，对于C（Consistency，一致性）要求很高很高；那么对于这种与金融相关的场景，我们允许不可用，但不允许不一致；那么在这种场景下，我们选择就是C（Consistency，一致性），即CP；

---

5.集群、分布式、微服务的差别；

（1）集群和分布式的区别；

         ● 分布式：不同的项目（更多的是同一个项目，拆分成的不同的模块），部署在不同的服务器上；而且，分布式的不同部分之间，需要协调合作；

         ● 集群：同一个项目，部署在多台服务器上；对外，我们可以通过负载均衡的方式，来把集群的多个节点进行平衡；集群的不同服务器之间，可以任务不需要协调合作；

（2） 集群和微服务的区别；

         ● 集群：集群的主要目的是，分散压力；

         ● 微服务：微服务主要是按照功能，对系统进行拆分，即微服务主要目的是，分散能力；

（3）微服务和分布式的区别；

         ● 微服务一种结构设计的方式；其在结构设计时，是把系统按业务垂直拆分；按业务垂直拆分的意思就是按功能模块进行拆分，比如【商品模块】拆出来，【订单模块】拆出来……

         ● 分布式强调的是系统部署的方式；我们利用微服务把业务拆分成不同模块后，分开部署，并且不同节点之间还需要通信的话，那么就是分布式了；

         ● 分布式不一定是微服务：比如，我们把系统的表示层（对外提供页面的能力，可以理解为前端）给拆出来单独部署；然后，服务和数据层（可以理解为后端）也单独部署；因为我们分开部署了，而且两部分之间需要通信，这自然是分布式；；；；但是，这并不是微服务，因为我们并没有按照业务对其进行垂直拆分；

         ● 上面有点抠字眼了；更多的情况是：在开发的时候，我们按照微服务进行拆分；然后，在部署的时候，按照分布式的方式去部署；