软件架构演变
单体架构
也可以叫做传统架构
网站流量很小时，只需要一个应用，将所有功能部署在一起，减少部署节点和成本。
此时 用于简化增删改查工作量的数据库访问框架orm 是影响开发的关键。
所谓的单体项目，就是将所有程序打包为一个一个应用程序，如 war 包、jar 包直接运行，里面包含了我们常规的表现层、控制层、数据库访问层都在同一个项目内。 当然在项目体积不是很大的时候是完全够用的，但是项目体积太大，单体的缺陷就很明显了。
传统单体架构存在的问题：
- 代码耦合度高，，牵一发而动全身
随着功能的增多，迭代次数增加，一个项目里面包含的代码模块就会越来越多，而且功能之间相互调用会很复杂。说的直白就是很乱。这样对于代码的修改 维护就会困难，很有可能只是一个小的改动就导致整个项目直接挂掉，。
- 不移维护，维护性能差
随着项目模块和新需求的增加，就会出现很多的沉郁代码，功能模块，使得维护又变的很困难，代码质量降低，部熟悉代码的人异常难维护
- 技术难度大
单体项目使用同一种语言，框架来进行开发，整合新的技术，语言，框架很困难。
- 单点容错率低，并发能力差
单个项目挂了整个服务就挂掉了，除去日常断电，还会出现tomcat挂掉，数据库挂掉，稍微并发量大点导致机器宕机，整个系统也就无法访问。
单体项目解决容错可以办法之一就是后台使用集群，增加多个节点，但是无形中又增加维护困难。
后端集群 反向代理
单体架构
集群架构
针对这种项目，我们可以使用Nginx进行后端集群操作，增加机器节点 从而横向扩展
使得并发能力增强。
- 但是还是存在代码耦合度高
- 牵一发而动全身，修改一个地方，整个集群项目都要进行重新部署
- 维护更加困难，更改需求或者维护，多个节点需要同时重新部署
1.2 垂直拆分
当访问量增大时，单一应用无法满足需求，此时为了更高的并发和需求，我们需要将业务功能进行垂直拆分，按照功能节点进行拆分，拆分成每个独立的系统服务。
订单模块，订单管理模块，用户管理模块，后台管理模块，购物车模块等等
1.3 分布式微服务项目
垂直应用越来越多，应用之间交互不可避免，可以将核心的业务提取出来，作为一个个独立的服务，服务之间互相调用，还可以进行横向扩展并发量高的服务。
将项目按照表现层，服务层进行纵向拆分，然后再按照模块横向拆分，如登录服务，订单服务，购物车服务等等。
分布式服务优势：
单一职责：每个服务都对应唯一的业务需求能力，单一职责。
- 微：微服务的服务拆分粒度很小，如 用户管理，订单。
- 面向服务：面向服务是每个服务都要对外暴露Rest ful风格的API接口。并不关心技术的实现与平台和语言无关。
- 自治：服务间互相独立，互不干扰。
- 团队独立：每个服务都是一个独立开发团队，人数不能过多。
- 技术独立：面向服务，只提供Rest 接口，与技术语言无关
- 前后端分离：采用券后端分离开发，提供统一的Rest接口，后端不用为PC，移动端开发不同的接口
- 数据库分离：每个服务都可以使用自己的数据源
- 部署独立：服务间虽然有调用，但是要做到服务重启不影响其他服务。有利于持续交付和集成。
每个服务都是独立的组件，可以服用，可以替换，降低耦合，易维护。 - 服务之间互相调用，提高代码复用，开发效率
- 耦合度变高，调用关系错综负载，难以维护
图片来自网络，侵删
分布式系统面临的问题
通信异常
网络本身的不可靠性，因此每次网络通信都会伴随着网络不可用的风险（光纤、路由、DNS等硬件设备或系统的不
可用），都会导致最终分布式系统无法顺利进行一次网络通信，另外，即使分布式系统各节点之间的网络通信能够
正常执行，其延时也会大于单机操作，存在巨大的延时差别，也会影响消息的收发过程，因此消息丢失和消息延迟
变的非常普遍。
网络分区
网络之间出现了网络不连通，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个
孤立的区域，分布式系统就会出现局部小集群，在极端情况下，这些小集群会独立完成原本需要整个分布式系统才
能完成的功能，包括数据的事务处理，这就对分布式一致性提出非常大的挑战。
节点故障
节点故障是分布式系统下另一个比较常见的问题，指的是组成分布式系统的服务器节点出现的宕机或"僵死"现象，
根据经验来说，每个节点都有可能出现故障，并且经常发生.
三态
分布式系统每一次请求与响应存在特有的“三态”概念，即成功、失败和超时。
分布式系统中，由于网络是不可靠的，虽然绝大部分情况下，网络通信能够接收到成功或失败的响应，但当网络出
现异常的情况下，就会出现超时现象，通常有以下两种情况：
-
- 由于网络原因，该请求并没有被成功的发送到接收方，而是在发送过程就发生了丢失现象。
-
- 该请求成功的被接收方接收后，并进行了处理，但在响应反馈给发送方过程中，发生了消息丢失现象。
