项目架构演变过程

1.单体架构

单体架构所有模块和功能都集中在一个项目中 ，部署时也是将项目所有功能部整体署到服务器中。不做详细介绍

2.垂直架构

根据业务把项目垂直切割成多个项目，因此这种架构称之为垂直架构。

优点：

• 系统拆分实现了流量分担，解决了并发问题
• 可以针对不同系统进行优化
• 方便水平扩展，负载均衡，容错率提高
• 系统间相互独立，互不影响，新的业务迭代时更加高效

缺点：

• 服务系统之间接口调用硬编码
• 搭建集群之后，实现负载均衡比较复杂
• 服务系统接口调用监控不到位调用方式不统一服务监控不到位
• 数据库资源浪费，充斥慢查询，主从同步延迟大

3.分布式架构SOA

SOA全称为ServiceOrientedArchitecture，即面向服务的架构。它是在垂直划分的基础上,将每个项目拆分出多个具备松耦合的服务,一个服务通常以独立的形式存在于操作系统进程中。各个服务之间通过网络调用，这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

我们在做了垂直划分以后，模块随之增多，系统之间的RPC逐渐增多，维护的成本也越来越高，一些通用的业务和模块重复的也越来越多，这个时候上面提到的接口协议不统一、服务无法监控、服务的负载均衡等问题更加突出，为了解决上面的这些问题，我们将通用的业务逻辑下沉到服务层，通过接口暴露，供其他业务场景调用。同时引入了阿里巴巴开源的Dubbo，一款高性能、轻量级的开源JavaRPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

优点：

• 服务以接口为粒度，为开发者屏蔽远程调用底层细节使用Dubbo面向接口远程方法调用屏蔽了底层调用细节
• 业务分层以后架构更加清晰并且每个业务模块职责单一扩展性更强
• 数据隔离，权限回收，数据访问都通过接口让系统更加稳定安全
• 服务应用本身无状态化这里的无状态化指的是应用本身不做内存级缓存而是把数据存入db
• 服务责任易确定每个服务可以确定责任人这样更容易保证服务质量和稳定

缺点：

• 粒度控制复杂如果没有控制好服务的粒度服务的模块就会越来越多就会引发超时分布式事务等问题
• 服务接口数量不宜控制容易引发接口爆炸所以服务接口建议以业务场景进行单位划分并对相近的业务做抽象防止接口爆炸
• 版本升级兼容困难尽量不要删除方法字段枚举类型的新增字段也可能不兼容
• 调用链路长服务质量不可监控调用链路变长下游抖动可能会影响到上游业务最终形成连锁反应服务质量不稳定同时链路的变成使得服务质量的监控变得困难

4.微服务架构

微服务架构是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在其自己的进程中独立运行，并使用轻量级机制(通常是HTTP资源的API)进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制进行独立部署。这些服务的集中化管理非常少，它们可以用不同的编程语言编写，并使用不同的数据存储技术。

微服务是在SOA上做的升华,粒度更加细致，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”。

关于微服务架构的知识,后面SpringCloud课程中会详细讲解。