分布式系统概论

一、集群

最原始最简单的项目架构就是单体单节点架构，一个应用程序，一个数据库就完成了整个项目的部署。随着软件行业的发展和完善，发现单节点部署的弊端越来越大。主要体现在节点挂掉之后，整个项目都无法访问。在几十年前，软件应用尚少的情况下，单节点挂掉之后，重启节点，再对外提供服务没什么问题。但是随着软件用户的越来越多，单节点挂掉之后用户需要等待重启才能使用服务这种方式广为诟病。为了解决这个问题，于是出现了集群的概念。

集群就是将相同的节点部署多个，当一个节点挂掉后，还可以通过其他节点提供服务，用户可以不间断使用系统。因此，出现了数据库集群，应用程序集群等等诸多程序或服务的集群。

引入集群后，首先面对的两个问题是:
第一，之前的单节点结构，只有一个节点可以使用，所以无论是请求，还是数据的流程和业务的处理，都是一个节点来完成。当引入集群后，相同功能的节点会有多个，那么选谁来进行请求，数据，或业务的处理呢？总不能每个节点都处理一次吧，这样幂等性就出问题了。因此，必须通过一定的选举机制，来决定哪个节点进行处理，其他节点用于备份。诸如负载均衡、领导者leader的选举、注册中心等等技术和策略，都是为了解决这个问题而出现的。不同的服务集群有其自己的选举机制。

第二，出现集群，且有了选举机制后，那么另一个问题就出现了，那就是数据同步问题。只会有一个节点处理或存储数据，那么这个节点挂掉之后，其他备胎节点顶上来时，数据必须和之前挂掉的节点保持一致，否则就会出问题。因此，引入集群后，必须考虑的是各个节点之间的通信和数据的同步性。因此，各服务的集群之间，都会有自己的节点通信机制和数据同步机制。

从上面描述可以看出，集群解决了单节点故障的问题，同时，为了解决集群带来的问题，而引入了负载均衡、注册中心、数据同步、节点通信等等诸多方面的考虑和优化，集群项目的复杂度远远超过了单节点项目。

二、分布式

随着软件行业的快速发展，越来越多的线下业务，转到了线上进行。所以，项目的业务越来越复杂，功能也越来越多，因此，项目的代码也成倍增加。造成的后果就是项目庞大，代码不好维护，开发效率降低。同时，随着业务量的增多，单体项目为用户提供服务承受的压力也越来越大，项目越跑越慢。为了解决这个问题，于是，人们将项目进行了拆分。将之前的单体项目，按照业务类型、开发技术等维度，进行了项目的拆分。一个项目，拆分成了多个项目。但是对于用户而言，并不关心项目内部的实现方式，总之可以正常使用服务即可。所以，拆分后的项目，对外还要是一个项目整体，为用户提供整体的服务。这种内部多个系统协调工作，对外提供一个服务的架构，就是分布式架构。

由上可知，分布式架构就是内部"分"，对外"合"。这样改造项目结构，也带来了以下几个问题需要考虑和解决:
第一、之前的单体项目，都在一个项目里，很容易进行内部接口的调用。现在拆分成多个项目后，不同项目之前的接口调用，如何调？这就需要考虑多个项目之前的通信问题。

第二、安全性:包括数据的一致性和幂等性。

第三、高可用性考虑。针对拆分后的单个项目而言，其本质也是一个单体项目，也要考虑高可用，所以，也需要部署多个节点的集群。每个拆分的项目都部署集群，可想而知，分布式集群的复杂度更大。

第四、可扩展性:通过服务、存储的扩展，提高系统处理能力。应对不断增加的大数据量和大请求量场景。

第五、可管理性：分布式内部项目直接如何调用，以及哪个节点有问题，都要可管理。

第六、采用分布式架构，说明业务量庞大。从而代表访问量也庞大。因此，需要考虑限流技术和服务的熔断降级技术。

。。。。。。

分布式系统需要考虑的问题还有很多。目前市面上使用的流行技术，也都是为了解决分布式系统带来的问题。诸如注册中心、dubbo、以及微服务技术栈中的网关、限流熔断、链路追踪等框架，都是为了解决分布式带来的问题。此外，分布式还涉及到了分布式ID,分布式锁、分布式事务、分布式缓存，分布式共享session，分布式 存储等等诸多问题，这都是根据具体的业务场景产生的问题而生成的解决方案。在下面博客详细记录。

参考文章:分布式系统全面解析