文章目录

• 架构的演变
• • 一、开天辟地，单体架构
  • 二、垂直架构（分布式架构）
  • 三、SOA 架构
  • 四、微服务架构

架构的演变

随着互联网的兴起，后端承受的流量负担越来越大，早期的架构已经不能适应新兴的需求，于是，一代代互联网人苦心钻研，探索出一个个新的解决方案

一、开天辟地，单体架构

我们学生时代做的大部分项目，都是单体架构，全部功能都集中在一个模块里

这种架构的好处在于，开发迅速，成本低，适合小型项目

但是一旦遇到大型项目，就歇菜了，单体架构难以维护和扩展

系统性能扩展，只能通过扩展集群节点，成本太高

下面，就是个经典的单体项目结构：

二、垂直架构（分布式架构）

其实，就是把原来的大单体，拆分成一个个小单体，然后分开部署。

这玩意儿尴尬就尴尬在学生时代碰不着，企业里现在也淘汰了，所以没有具体的例子给各位看

优点：

1、通过垂直拆分，每个子系统变成小型系统，功能简单，前期开发成本低，周期短。

2、每个子系统可按需伸缩。

3、每个子系统可采用不同的技术。

缺点：

1、子系统之间存在数据冗余、功能冗余，耦合性高。

2、按需伸缩粒度不够，对同一个子系统中的不同的业务无法实现，比如订单管理和用户管理。

三、SOA 架构

SOA是一种面向服务的架构，基于分布式架构，它将不同业务功能按服务进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。

SOA ，其实就像一个只有 网关，没有配置 Feign 的 SpringCloud 项目。一个服务，如果要调用另一个服务的接口，是没有办法的，只能再在自己的服务模块中，实现该功能

我从网上扒个图解释一下：

用标准一点的说法，就是划分的粒度太粗，造成了代码冗余

四、微服务架构

为了解决上述 SOA 的问题，微服务架构应运而生

客户端访问数据接口，可以走网关，服务之间如果有相互调用的话，在SpringCloud 中可以使用 Feign

这样粒度更细的划分，能够做到尽力减少冗余代码的产生

项目结构如下：