在互联网飞速发展的今天，软件开发已不再是简单的JSP/Servlet开发模式了，现在的软件项目一谈到架构，都是分布式/微服务等名词，那么分布式架构的本质是为了解决什么问题，为什么要有分布式架构，今天就来好好探讨一下。
分布式架构的演进
为了方便，这里以一个电商网站作为示例进行讲解，在一个电商项目中，会涉及到用户/订单/商品等等的一些业务，下面就来看整个项目在发展初期到现阶段的架构模式。
单体
在项目初期，可能更多考虑到是想法的落地，快速上线，所以，这个阶段的项目架构一定是单体架构，也就是，一个应用/一个db部署到同一台服务器对外提供服务，这个阶段的架构模式很简单，所有服务都被部署到同一台服务器，在项目初期流量不是很大的情况下，该种模式完全能胜任当前的业务需求。
随着流量的不断上升，可能就会出现单机负载过高等情况，这个时候不得不进行架构等升级，为了快速响应，这里将DB及应用分别部署，从同一台服务器中剥离开来，这样应用服务器所能享用的资源就更大了。
但好景不长，通过BD服务和应用服务的剥离并不能为系统提升较大的性能，所以这个时候需要考虑应用服务的横向扩展，所以就出现了集群架构。
集群
将原本单体的服务COPY多份分别部署到不同的服务器，加入一台服务器（一个应用）所能承载的并发是300，那么集群所能承载的并发是和节点数成倍增长的。所以这能解决以上问题。
但是，从单体架构直接升级为集群架构也有一些挑战的，比如说，如何让用户的请求分摊到集群中的每一个节点；session共享；这是升级所带来的问题，我们需要解决，针对流量分摊解决方式有DNS轮询/负载均衡（硬件负载/软件负载）；针对session共享，我们可以采用session复制/分布式session/无状态JWT等等一些方式来解决。
解决了应用服务的负载压力，DB压力日渐增大，需要缓解数据的读写压力，所以需要采用读写分离来解决当下的问题。
读写分离
我们都知道一个应用的数据一定是读多写少，就好比，咱们购物一定是先看，看多了才会下一个单一样的道理，可以根据应用实际情况考虑需要多个读库，应用将读取数据的请求分发到读数据库，将增删改的请求分发到写库上，写库和读库需要有数据同步。
当查询到数据较大或者查询条件较为复杂的时候，可能一些关系型数据库以及无法满足业务需求时，可以引入一些搜索引擎来提升读的性能，例如ES/Solr等等，事实上，搜索引擎也可以理解为是一个读库。
常规数据在此阶段暂时得到了缓解，但是，应用中的文件（图片/视频）也需要进行更好的存储及优化，在此之前，可能会将文件保存到DB或者应用服务器，但不管是从安全性及性能上的考虑，都是不合适的，所以，就有了分布式文件存储。
分布式文件系统
将原有业务中的文件（图片/视频等）抽离出来，放到独立的文件系统中，例如：Minio/OSS等。
看似完美的应用架构，但其实并不能支撑太久，随着业务量不断增大，以上优化都已经不能承载了，就需要考虑一些缓存啊等等。所以，一个应用架构永远都没有完美的。
缓存
将一些热点数据放到缓存中，减轻DB压力，提升请求响应时间，应用又能撑一段时间了。
在任何的软件架构中，任何一个优秀的解决方案都只适用于当下的应用需求，换了一个场景或者应用流量上升，任何方案都会过时。依然是DB上的压力，该怎么处理，分库分表吧。
分库分表
分库分表旨在将一个库或表分为多个库或表，那么应该怎么进行拆分，主要有两种：
- 垂直切分：将一张字段很多的大表拆分成多个小表
- 水平切分：将一张数据很多的大表拆分成多个小表
从拆分方式可以看出，两种拆分方式的维度不同，通常情况下，我们采用的是水平切分，这样带来的性能提升是最明显的，但也是代价最大的。
解决了DB的负载问题，改种架构应该能撑很长一段时间了，但是，应用的压力还是无法支撑现有业务，所以就有了微服务架构。
微服务
将一个单体的应用拆分成多个独立的微服务，比如，将用户/商品/订单分别拆分成一个单独的服务，用户下单通过远程RPC调用的方式进行服务间的通信，以此来达到更高的吞吐量。
小结
现阶段较为流量的架构也就是微服务架构，后面一定还会有，例如服务网格等，这里我想说的是，架构是为业务服务的，当应用不能很好的服务业务时，就一定会升级迭代。
CAP理论
什么是CAP理论，先说一下什么是CAP，CAP分别是一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），CAP理论讲述的是一个分布式系统最多同时满足两个条件。
一致性（Consistency）
一个事物操作在返回客户端后所有节点数据完全一致。强一致。
可用性（Availability）
服务一直可用，正常响应。
分区容错性（Partition tolerance）
分布式系统再遇到网络及节点故障等问题时，仍然能够保证服务的一致性或者可用性。
BASE理论
什么是BASE理论，BASE理论是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）。
基本可用（Basically Available）
分布式系统在出现故障时，允许损失部分可用性，核心业务可用。
软状态（ Soft State）
分布式系统允许出现中间状态，该状态不会影响系统的整体可用性。
最终一致性（ Eventual Consistency）
当数据在经过一段时间的通不过后，最终的结果是一致的。
BASE理论是CAP理论的延伸，主要将CAP中的强一致性改为弱一致性。
微服务架构所带来的问题及解决方案。
高可用
高可用的解决方案有很多种，从本身应用的可用性可以有如下解决方案：热备/集群；从应用自身预防宕机可以有如下解决方案：熔断/限流/缓存/降级
热备
很容易理解，当一台服务器宕机后，另外一台服务器自动顶替继续对外提供服务器。
集群（负载均衡）
当应用服务集群部署之后，就一定会涉及到请求的分发，达到这一功能及目的的方式有很多中，这里只展开讨论负载均衡，负载均衡，顾名思义将请求均衡的负载到各个节点，那么它怎么做到均衡负载到不同节点的呢，就需要讨论负载均衡算法。
负载均衡算法
- 随机：将请求随机分发到某一个节点
- 轮询：将请求轮流分发到后段节点
- 加权轮询：在轮询的基础上加上权重，可以根据服务器负载程度及能力来设置权重。
- ip_hash：将客户端IP进行hash，得到的值进行取模然后分发到指定节点。
- 最小连接数：根据后段节点的连接数量作为判断依据，将请求分发到连接数较少的节点上。
熔断
当一个应用服务器失败多次时，通过熔断直接返回失败，避免了频繁请求，最终导致整个系统崩溃。
限流
某一时刻流量突然猛增时，通过限流将一些超过系统负载能力以外的流量拒绝来避免系统突然收到冲击而导致崩溃。
缓存
缓存主要是为了保护缓存背后的一些服务，例如数据库，要知道，数据库一旦崩溃，整个系统甚至整个业务线都有可能停摆。
高并发
高并发解决方案上有一些与高可用解决方法重合，比如系统拆分/缓存等等，所以一个系统面临高并发的同时，一定也面临着可用性的问题。
高并发需要知道的几个指标有哪些？
吞吐量
系统在单位时间内能处理的请求数量。
QPS
每秒查询率是对服务器某一特定时间能处理的流量多少的衡量标准。
并发数
并发用户数表示系统可以同时承载正常使用的用户数量。
相应时间
系统对请求对处理及返回所耗的时间。
高并发常见解决方案
MQ消息队列
当系统出现并发写的问题时，可能后段服务（例如DB）一时间无法承载着么大的并发量，如果不做任何措施，可能撑不过几秒直接被干挂了，这在业务上一定是不允许的，所以，我们应该避免大量的请求直接达到后端核心服务或DB；但也不能直接丢弃用户请求呀，那怎么办，异步处理，将用户请求先堆积到队列中，后端服务慢慢处理，量不可能一直这么大，所以，这就叫削峰平谷。