单体架构与微服务架构对比：Spring Cloud 微服务入门指南—
1.1 什么是单体架构
单体架构（Monolithic Architecture）是指把应用的所有功能模块全部打进同一个程序里，部署后跑在同一个进程中的架构模式。它是传统软件开发中最常见、最基础的架构形态。## 1.2 单体架构优缺点
单体架构的优点
| 优点 | 说明 |
|---|---|
| 开发简单直观 | 代码都在一个工程里，不用处理分布式问题，IDE 友好、调试方便，小团队能快速启动 |
| 部署方便快捷 | 打一个 WAR/JAR 包即可发布，不需要容器编排和服务编排 |
| 测试容易集成 | 端到端测试起一个应用就行，不用为服务间依赖做一堆 mock，集成测试覆盖率高 |
| 性能开销小 | 模块间是进程内调用，没有网络和序列化开销，响应延迟低 |
| 技术栈统一 | 团队只学一套技术体系，培训和招人成本低 |
| 事务一致性简单 | 本地事务就能保证数据一致，不用碰分布式事务 |
单体架构的缺点
| 缺点 | 说明 |
|---|---|
| 代码高度耦合 | 功能一多模块边界就模糊，改一处牵全身，维护成本涨得很快 |
| 扩展困难 | 只能整个应用一起扩容，没法单独给某个高负载模块扩容，资源利用率低 |
| 技术栈受限 | 全局一套选型，想给某个模块换技术很难，新技术的采用受制于历史包袱 |
| 部署影响面大 | 改一处就要全量发布，风险高，一次发布可能让整个系统不可用 |
| 启动越来越慢 | 代码膨胀后，启动时间从几秒涨到几分钟，开发体验和弹性伸缩都受影响 |
| 团队协作困难 | 多团队改同一个代码库，冲突频繁，合并和发布的协调成本很高 |
| 单点故障风险 | 任何一个模块的内存泄漏或异常都可能拖垮整个进程，故障隔离能力弱 |
| 技术债务累积 | "改不动、不敢改"的模块越来越多，架构腐化加剧，新人上手门槛持续升高 |
二、微服务架构
上面介绍了单体架构，这时候就要引入微服务架构了。
2.1 什么是微服务架构
微服务架构（Microservices Architecture）是把单一应用拆成一组小型、独立部署的服务的架构风格。每个服务围绕一个明确的业务能力构建，跑在自己的进程里，服务间通过轻量级通信机制（如 HTTP/REST、消息队列）协作。
简单来说，单体架构就像是把一堆药材堆在一起，而微服务架构则是把这堆药材按功效做了分类。
2.2 单体架构 与 微服务架构对比
| 对比维度 | 单体架构 | 微服务架构 |
|---|---|---|
| 架构理念 | 一个应用包含一切 | 每个服务做好一件事 |
| 通信机制 | 进程内方法调用，零网络开销 | 网络远程调用，存在序列化与网络开销 |
| 数据管理 | 共享单一数据库 | 每服务独享数据库，数据边界清晰 |
| 部署粒度 | 全量构建全量部署 | 单服务独立构建独立部署 |
| 扩展能力 | 整体复制，无法精准扩容 | 按服务负载独立扩缩容 |
| 故障隔离 | 弱，一处异常全盘崩溃 | 强，故障可隔离在单个服务 |
| 运维复杂度 | 低，一套部署一套监控 | 高，需服务治理、分布式监控、容器编排 |
| 适用阶段 | 项目初期、小型应用、团队≤10人 | 业务复杂、团队规模化、需快速迭代 |
选型建议：架构选型没有绝对优劣，关键是匹配业务阶段。项目初期优先用单体架构快速验证业务模式；当业务复杂度上升再逐步向微服务演进。盲目提前微服务化只会带来不必要的复杂度。
2.3 微服务架构优缺点
微服务解决了单体的扩展瓶颈，但也引入了分布式系统固有的复杂度。要不要上微服务，需要把好处和代价都看明白。
微服务架构的优点
| 优点 | 说明 |
|---|---|
| 独立部署与交付 | 每个服务能独立构建、测试、部署，发布周期从"周级"缩短到"天级"甚至"小时级"，CI/CD 友好 |
| 弹性扩展 | 可以只给某个高负载服务单独扩容，资源利用率高，成本可控 |
| 故障隔离 | 单个服务故障不会拖垮全局，配合熔断降级能做到优雅降级而不是雪崩 |
| 技术演进灵活 | 单个服务能独立重构、升级甚至重写，技术债务可控、迭代灵活 |
| 可复用与可组合 | 服务以 API 暴露能力，可被多个前端或第三方复用，沉淀企业能力中心 |
微服务架构的缺点
| 缺点 | 说明 |
|---|---|
| 分布式复杂性 | 网络不可靠、调用可能超时、服务可能宕机，要处理重试、幂等、超时、降级等难题 |
| 运维成本高 | 服务从 1 个变成 N 个，需要容器编排（K8s）、配置中心、服务网格、全链路监控等基础设施支撑 |
| 数据一致性难 | 跨服务事务无法用本地 ACID 保证，要引入 Saga、TCC、消息最终一致性等分布式事务方案 |
| 服务通信开销 | 网络调用带来序列化/反序列化和网络延迟开销，对时延敏感场景要专门优化 |
| 调试与排障困难 | 一个请求跨多个服务，传统单机调试失灵，要依赖分布式链路追踪（如 Sleuth/Zipkin）定位问题 |
| 接口契约管理 | 服务间 API 变更需版本管理和兼容性控制，否则容易引发调用方故障 |
| 测试复杂度高 | 端到端测试要编排多服务依赖，环境搭建和 mock 成本明显上升 |
| 安全边界扩大 | 服务间网络通信带来新的攻击面，需要服务间鉴权与 mTLS 等机制 |
2.4 微服务拆分
拆分是微服务落地最核心也最难的环节。拆得好，系统清晰好维护；拆得不好，服务是拆了但耦合还在。
拆分原则
拆分的第一原则是围绕业务能力拆，而不是按技术分层拆。按技术分层拆的意思是把"用户接口""数据访问"这些技术层单独拆成服务，这样做每个业务变更都要横跨多个服务协作，服务自治就名存实亡了。而拆分方式也主要分为按模块纵向拆分和抽取公共模块横向拆分。
拆分时还要注意以下原则：
- 高内聚低耦合：经常一起变更的功能放进同一个服务，跨服务调用越少越好。
- 单一职责：一个服务对应一个明确的业务能力，避免"大而全"。
- 独立数据所有权：拆服务的同时把数据边界划好，每个服务独占自己的数据存储，禁止别的服务直接连它的数据库表。
三、Spring Cloud
前面主要介绍微服务相关的概念，接下来将简单介绍微服务项目中常见的一个微服务架构——Spring Cloud
Spring Cloud 是什么
Spring Cloud是基于 Spring Boot 构建的、面向微服务架构的一站式治理框架，可以理解成微服务架构的"基础设施全家桶"：服务注册发现、配置管理、API 网关、负载均衡、熔断降级、分布式链路追踪，都有对应的组件。
有个很形象的区分：Spring Boot 解决"单个微服务怎么快速构建"，Spring Cloud 解决"多个微服务怎么协作治理"。而且 Spring Cloud 本身是一套规范和抽象，底层实现可以替换——比如服务注册发现既可以用 Netflix 的 Eureka，也可以用阿里的 Nacos，Spring Cloud 定义统一接口，具体实现由各家提供。
它的核心价值是：你不用从零搭建分布式基础设施，靠注解和自动配置就能快速接入服务治理能力，把精力放在业务逻辑本身。
