一、单体架构

1、核心定义

• 单体架构是最基础、最传统的软件架构模式，指将项目中所有的业务功能、代码逻辑、数据库操作全部集中在一个项目中，整体编码、整体打包、整体部署，不存在项目拆分。
• 例如：

2、核心优缺点

• 优点
• • 架构简单，上手门槛低：项目结构清晰，没有复杂的服务拆分、远程调用等逻辑，新手开发、调试都很方便。
• • 部署成本低：只需打包一个项目包，单次部署即可完成整个系统上线，无需维护多个服务节点。
• • 开发效率快：无需考虑服务通信、数据同步、集群配置等问题，专注业务开发即可。。
• 缺点
• • 代码耦合度高：所有业务代码交织在一起，修改一个小功能，可能影响整个系统的逻辑。
• • 拓展性差：无法针对高并发模块单独扩容。比如商城的商品模块访问量极大，但因为是单体项目，只能整体扩容，资源浪费严重。

二、分布式架构

1、核心定义

• 分布式架构的核心是业务拆分：根据系统的不同业务功能，将一个完整的单体项目拆分成多个独立的子项目，每个子项目负责一类专属业务，单独开发、单独部署，每一个独立的子项目就是一个服务。

2、核心优点

• 解耦业务，降低代码依赖：各业务服务相互独立，修改、迭代某一个服务，不会影响其他服务的正常运行。
• 提升项目可维护性：业务拆分清晰，代码分工明确，问题排查更加高效。
• 容错性提升：单个服务故障，不会导致整个系统瘫痪，只会影响对应业务功能。

3、分布式架构要考虑的问题

• 服务拆分的细粒度如何界定 ？：拆分太粗，依旧存在耦合问题；拆分太细，会导致服务过多、运维成本飙升，需要合理把控拆分边界。
• 服务集群地址如何统一维护？：服务部署多节点集群后，如何统一管理所有服务的IP、端口地址，实现高效寻址。
• 服务之间如何实现远程调用？：各个独立服务不在同一个项目，无法直接调用，需要可靠的远程通信方案实现服务交互。
• 服务健康状态如何感知？：某一个服务宕机、异常时，系统如何快速感知，及时规避故障、避免业务阻塞。

三、微服务架构

1、核心定义

• 微服务架构是一种经过规范化、精细化架构设计的分布式架构方案。它在分布式业务拆分的基础上，进一步细化拆分规则、服务治理标准、运维规范，实现服务的高度自治、独立可控，是目前中大型互联网项目的主流架构。

2、核心特征

• 单一职责：微服务拆分细粒度更小，每一个服务都对应唯一的业务能力，做到单一职责，避免重复业务开发。
• 面向服务：所有微服务内部逻辑完全隐藏，仅通过标准化接口对外提供业务能力。服务之间的交互全部基于接口调用，不依赖内部代码，实现了服务的黑盒复用，无论后端技术如何迭代，只要接口不变，前端和其他服务无需改动。
• 高度自治
• • 团队独立：不同服务由不同团队独立开发、维护，分工明确、互不干扰；
• • 技术独立：各服务可根据自身业务需求选择技术栈，无需统一技术框架；
• • 数据独立：每个微服务拥有自己独立的数据库，彻底杜绝数据库耦合；
• • 部署独立：支持单个服务独立打包、独立部署、独立回滚，不影响整体系统。
• 隔离性强：微服务架构针对性解决了分布式架构的遗留问题，自带完善的容错、隔离、降级、熔断机制。