软件架构演变

单体架构

也可以叫做传统架构

网站流量很小时，只需要一个应用，将所有功能部署在一起，减少部署节点和成本。
此时 用于简化增删改查工作量的数据库访问框架orm 是影响开发的关键。

所谓的单体项目，就是将所有程序打包为一个一个应用程序，如 war 包、jar 包直接运行，里面包含了我们常规的表现层、控制层、数据库访问层都在同一个项目内。 当然在项目体积不是很大的时候是完全够用的，但是项目体积太大，单体的缺陷就很明显了。

在这里插入图片描述

传统单体架构存在的问题：

• 代码耦合度高，，牵一发而动全身

随着功能的增多，迭代次数增加，一个项目里面包含的代码模块就会越来越多，而且功能之间相互调用会很复杂。说的直白就是很乱。这样对于代码的修改 维护就会困难，很有可能只是一个小的改动就导致整个项目直接挂掉，。

• 不移维护，维护性能差

随着项目模块和新需求的增加，就会出现很多的沉郁代码，功能模块，使得维护又变的很困难，代码质量降低，部熟悉代码的人异常难维护

• 技术难度大

单体项目使用同一种语言，框架来进行开发，整合新的技术，语言，框架很困难。

• 单点容错率低，并发能力差

单个项目挂了整个服务就挂掉了，除去日常断电，还会出现tomcat挂掉，数据库挂掉，稍微并发量大点导致机器宕机，整个系统也就无法访问。

单体项目解决容错可以办法之一就是后台使用集群，增加多个节点，但是无形中又增加维护困难。

后端集群 反向代理

单体架构

在这里插入图片描述

集群架构

在这里插入图片描述
图片来自网络

针对这种项目，我们可以使用Nginx进行后端集群操作，增加机器节点 从而横向扩展
使得并发能力增强。

• 但是还是存在代码耦合度高
• 牵一发而动全身，修改一个地方，整个集群项目都要进行重新部署
• 维护更加困难，更改需求或者维护，多个节点需要同时重新部署

1.2 垂直拆分

当访问量增大时，单一应用无法满足需求，此时为了更高的并发和需求，我们需要将业务功能进行垂直拆分，按照功能节点进行拆分，拆分成每个独立的系统服务。
订单模块，订单管理模块，用户管理模块，后台管理模块，购物车模块等等

在这里插入图片描述

1.3 分布式微服务项目

垂直应用越来越多，应用之间交互不可避免，可以将核心的业务提取出来，作为一个个独立的服务，服务之间互相调用，还可以进行横向扩展并发量高的服务。

将项目按照表现层，服务层进行纵向拆分，然后再按照模块横向拆分，如登录服务，订单服务，购物车服务等等。

分布式服务优势：

单一职责：每个服务都对应唯一的业务需求能力，单一职责。

• 微：微服务的服务拆分粒度很小，如 用户管理，订单。
• 面向服务：面向服务是每个服务都要对外暴露Rest ful风格的API接口。并不关心技术的实现与平台和语言无关。
• 自治：服务间互相独立，互不干扰。
• 团队独立：每个服务都是一个独立开发团队，人数不能过多。
• 技术独立：面向服务，只提供Rest 接口，与技术语言无关
• 前后端分离：采用券后端分离开发，提供统一的Rest接口，后端不用为PC，移动端开发不同的接口
• 数据库分离：每个服务都可以使用自己的数据源
• 部署独立：服务间虽然有调用，但是要做到服务重启不影响其他服务。有利于持续交付和集成。
  每个服务都是独立的组件，可以服用，可以替换，降低耦合，易维护。
• 服务之间互相调用，提高代码复用，开发效率
• 耦合度变高，调用关系错综负载，难以维护

图片来自网络