单体架构指的是：将业务的所有功能集中在一个项目中开发，最后打成一个包统一部署。在此之前，我们的项目都是单体架构。

但随着业务不断变复杂，所有功能都绑在一个服务里，并发量逐渐升高，单体项目的问题也会越来越明显。

一般来说，当单体服务已经难以承受并发压力，或者开发、部署、维护成本明显升高时，就可以考虑拆成微服务。

微服务会把原来一个大项目中的功能，按照业务边界拆成多个独立服务。比如用户服务、商品服务、订单服务、支付服务等。

这样做之后，每个服务可以独立开发、独立部署、独立扩容。

不过，微服务不是无脑升级。它只是把单体里的复杂度拆开了，同时又引入了新的复杂度，比如服务之间怎么调用、怎么注册发现、配置怎么统一管理、某个服务挂了怎么办、链路怎么追踪等。

所以微服务适合解决大型系统的扩展和维护问题，但不适合在小项目里强行上复杂架构。

微服务技术栈

在 Java 生态里，Spring Cloud 是常用的微服务框架体系。它基于 Spring Boot，整合了微服务开发中常见的组件，并通过自动装配降低使用成本。

常见能力包括：

• 服务注册与发现：Eureka、Nacos、Consul
• 服务远程调用：OpenFeign、Dubbo
• 统一配置管理：Spring Cloud Config、Nacos
• 统一网关路由：Spring Cloud Gateway、Zuul
• 服务保护与降级：Hystrix、Sentinel
• 链路追踪与监控：Zipkin、Sleuth

版本关系

Spring Cloud 是基于 Spring Boot 构建的，所以两者版本必须匹配，比较常见的老项目搭配是：

Spring Cloud Greenwich  +  Spring Boot 2.1.x

因为升级 Spring Cloud 往往也要升级 Spring Boot，继续往上还可能牵扯到 Java 版本、第三方依赖、部署环境等一整套变化。

所以在企业项目里，稳定可用的老版本并不少见。

服务拆分原则

服务拆分时，主要关注两个原则：

• 高内聚：一个服务内部应该围绕同一类业务展开，不要什么功能都塞进去。
• 低耦合：服务之间不要互相依赖得太死，尽量减少牵一发而动全身的情况。

常见拆分方式如下。

一种是纵向拆分，也就是按照业务功能拆分。比如：

用户服务
商品服务
订单服务
支付服务

另一种是横向拆分，也就是抽取公共能力。比如：

认证服务
文件服务
消息服务
通知服务

实际项目里，不用把这些概念想得太玄。拆分的目标很简单：让系统边界更清楚，维护更方便，扩展更灵活。

如果拆完之后服务更多了，但调用更混乱、排查更困难，那就不是好拆分。

工程结构

微服务工程常见两种组织方式。

一种是独立 Project。

也就是每个服务都是一个独立项目，有自己的代码仓库、构建配置和部署流程。大型项目更常用这种方式，因为服务边界清楚，也方便不同团队独立维护。

另一种是 Maven 聚合工程。

也就是使用一个父工程管理多个子模块。每个子模块可以对应一个服务，也可以放公共模块。学习阶段和中小型项目更常用这种方式，因为依赖版本、公共配置和代码结构都比较方便统一管理。

例如：

mall-parent
├── user-service
├── product-service
├── order-service
├── gateway-service
└── common

其中 mall-parent 负责统一管理依赖版本，user-service、product-service、order-service 分别是不同业务服务，common 通常存放一些公共工具类、通用返回结果、异常处理等内容。