项目架构演变过程

1. 单体架构

单体架构所有模块和功能都集中在一个项目中，部署时也是将项目的所有功能整体部署到服务器中，所有的业务都放在一个Tomcat里面。

  • 优点
  • 小项目开发快，成本低
  • 架构简单
  • 易于测试
  • 易于部署
  • 缺点
  • 大项目模块耦合严重，不易开发，沟通成本高
  • 新增业务难
  • 核心业务和边缘业务耦合在一起，出现问题相互影响

2. 垂直架构

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

做垂直划分的依据是业务的特性、核心目标。这样做一是为了业务之间互不影响，二是在研发团队壮大后提高效率，减少之间的依赖。

  • 优点
  • 系统拆分实现了流量分担，解决了并发问题
  • 可以针对不同系统进行优化
  • 方便水平扩展，负载均衡，容错率提高
  • 系统间相对独立，互不影响，新的业务迭代时更加高效
  • 缺点
  • 服务系统之间接口调用硬编码
  • 搭建集群之后，实现负载均衡较复杂
  • 服务系统接口调用监控不到位，调用方式不统一
  • 服务监控不到位
  • 数据库资源浪费

3. 分布式架构(SOA)

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

在对项目进行拆分时需要从一下几个方面考虑：

分层：按照业务性质分层，每一层要求简单和容易维护

分级：同一层的业务也要做好分级，依据业务的重要性进行分级，按照二八定律网站的80%的流量都在核心功能上面，要优先保证核心业务的稳定。

隔离：不同性质，不同重要性的业务要做好隔离，包括业务 缓存 DB 中间件 都要做好隔离

调用：总体上调用要单向，可以跨层调用，但是不能出现逆向调用

  • 优点
  • 服务已接口为粒度，为开发者屏蔽远程调用细节
  • 业务分层后架构更加清晰，并且每个业务模块职责单一，扩展性更强
  • 数据隔离，权限回收，数据访问都 通过接口，让系统更加稳定安全
  • 服务责任易确定，每个服务可以确定服务责任人，这样更容易保证服务质量和稳定。
  • 缺点
  • 粒度控制复杂，如果没有控制好服务粒度，服务的模块会越来越多，会引发超时，分布式事务等问题
  • 服务接口数量不易控制，容易引发接口爆炸，所以服务接口建议以业务场景进行单位划分，并对相近的业务做抽象，防止接口爆炸。
  • 版本升级兼容困难，
  • 调用链路长，服务质量不可监控，调用链路变长，下游抖动可能会影响到上游业务，最终形成连锁反应，服务质量不稳定，同时链路的变化使得服务质量的监控变得困难

4. 微服务架构

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

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