必码

Appearance

三种架构模式深度对比：SpringBoot 单体 vs Dubbo RPC vs Spring Cloud 微服务 ​

作者： 必码 ｜ bima.cc

前言 ​

在 Java 后端开发领域，架构选型是每个技术团队在项目启动时必须面对的核心决策。SpringBoot 单体架构、Dubbo RPC 架构和 Spring Cloud 微服务架构，代表了从简单到复杂、从集中到分布的三种典型技术路线。然而，市面上的技术对比文章往往停留在理论层面，缺乏基于真实项目的深度剖析。

本文基于 smart-scaffold 系列项目的三套真实代码——smart-scaffold-springboot、smart-scaffold-dubbo、smart-scaffold-springcloud，从模块划分、通信机制、接口定义、注册中心、负载均衡、ORM选型、部署方案、代码复用等十个维度进行全方位深度对比，帮助读者建立对三种架构模式的系统性认知，并为实际项目的技术选型提供可量化的决策依据。

三套项目均基于 Spring Boot 3.5.12 + Java 17 技术栈，实现了相同的业务功能（用户模型管理、部门管理、中间件集成等），这使得对比具有高度的可信度和参考价值。

一、架构模式概述 ​

1.1 单体分层架构（SpringBoot） ​

单体分层架构是 Java Web 开发中最经典、最成熟的架构模式。其核心思想是将整个应用打包为一个独立的可执行单元，内部通过分层（Layered Architecture）来组织代码结构。

在 smart-scaffold-springboot 项目中，单体架构的体现尤为典型。项目采用 Maven 多模块结构，将代码按照技术职责划分为四个子模块：

smart-scaffold-springboot/          # 父POM，统一版本管理
├── smart-scaffold-common/          # 通用层：工具类、常量、基础组件
├── smart-scaffold-dao/             # 数据访问层：Mapper接口、XML映射文件
├── smart-scaffold-service/         # 业务逻辑层：Service实现类
└── smart-scaffold-web/             # 表现层：Controller、启动类、配置文件

这种架构的本质特征是所有模块最终被打包成一个可执行 JAR 文件。在 smart-scaffold-web 模块的 pom.xml 中，通过 spring-boot-maven-plugin 的 repackage 目标实现这一打包方式：

xml
<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <configuration>
        <mainClass>cc.bima.scaffold.ScaffoldWebApplication</mainClass>
        <includeSystemScope>true</includeSystemScope>
    </configuration>
    <executions>
        <execution>
            <goals>
                <goal>repackage</goal>
            </goals>
            <phase>package</phase>
        </execution>
    </executions>
</plugin>

单体架构的优势在于：

  • 开发简单：所有代码在同一个 IDE 工程中，调试方便，代码跳转无缝衔接
  • 部署简单：一个 JAR 文件即可运行，无需考虑服务间依赖和启动顺序
  • 事务管理简单：本地事务（@Transactional）即可满足大多数业务需求
  • 运维成本低：只需监控一个进程，日志集中，问题排查效率高

单体架构的局限在于：

  • 扩展受限：无法对单个业务模块进行独立水平扩展
  • 技术耦合：所有模块共享同一个技术栈，难以引入差异化技术选型
  • 发布风险：任何模块的修改都需要整体重新部署，影响面大
  • 团队协作：随着团队规模扩大，代码冲突和合并问题日益严重

1.2 分布式RPC架构（Dubbo） ​

Dubbo RPC 架构是一种面向服务的分布式架构模式。它将应用拆分为服务提供者（Provider）和服务消费者（Consumer）两个独立进程，通过高性能的 RPC 框架实现跨进程的方法调用。

smart-scaffold-dubbo 项目的模块划分清晰地展现了这种架构的核心理念：

smart-scaffold-dubbo/               # 父POM
├── smart-scaffold-api/             # API模块：服务接口定义、DTO、枚举
├── smart-scaffold-provider/        # 服务提供者：接口实现、数据访问、业务逻辑
└── smart-scaffold-consumer/        # 服务消费者：Controller、前端交互、Feign调用

与单体架构最大的不同在于，Dubbo 架构引入了一个关键的 API 模块。这个模块是 Provider 和 Consumer 之间的"契约"，定义了所有可被远程调用的服务接口。在 smart-scaffold-dubbo 中，API 模块的包结构如下：

smart-scaffold-api/src/main/java/cc/bima/scaffold/api/
├── face/                           # 服务接口定义包
│   ├── IMybatisUserModelService.java
│   ├── IMybatisDepartmentInfoService.java
│   ├── IRedisService.java
│   ├── IMongoService.java
│   ├── IKafkaService.java
│   └── ...
├── dto/                            # 数据传输对象
│   ├── UserModelDTO.java
│   ├── UserModelQueryDTO.java
│   └── ...
├── entity/                         # 实体类
│   ├── UserModel.java
│   └── DepartmentInfo.java
├── service/                        # 通用服务类
│   ├── ApiResult.java
│   ├── PageDTO.java
│   └── PageQueryDTO.java
├── enums/                          # 枚举定义
│   └── BaseResultEnum.java
├── po/                             # 持久化对象
│   └── ModelPO.java
└── constants/                      # 常量定义
    └── Constants.java

Dubbo 架构的 Provider 端通过 @DubboService 注解将服务实现类发布为远程服务：

java
@DubboService
@Service("MybatisUserModelService")
public class MybatisUserModelService extends BaseService<UserModelMapper, UserModelDTO, UserModelQueryDTO>
        implements IMybatisUserModelService {
    // ... 实现方法
}

Consumer 端通过 @DubboReference 注解引用远程服务：

java
@RestController
@RequestMapping("/mybatis-usermodel")
public class MybatisUserModelController {

    @DubboReference
    private IMybatisUserModelService mybatisUserModelService;

    // ... Controller方法
}

Dubbo 架构的优势在于：

  • 高性能通信：基于二进制序列化协议（Hessian2），相比 HTTP/JSON 有显著的性能优势
  • 服务治理能力：内置服务注册发现、负载均衡、服务降级、流量管控等治理能力
  • 接口契约清晰：API 模块作为独立的契约层，Provider 和 Consumer 解耦
  • 平滑演进：可以从单体架构逐步拆分，演进路径清晰

Dubbo 架构的局限在于：

  • 语言耦合：RPC 调用基于 Java 接口，跨语言支持不如 HTTP REST 友好
  • 运维复杂度增加：需要维护 Zookeeper 注册中心和多个服务进程
  • 调试困难：跨进程调用增加了问题排查的难度
  • 学习曲线：需要掌握 Dubbo 框架的配置和使用
  • 事务一致性：分布式事务处理比本地事务复杂得多，需要引入 Seata 等分布式事务框架
  • 数据一致性：Provider 和 Consumer 可能访问不同的数据库实例，数据同步成为新的挑战

Dubbo 架构的适用场景：

  1. 内部高频调用：当系统内部存在大量服务间调用（如每秒数千次以上），Dubbo 的 RPC 性能优势明显
  2. Java 技术栈为主：当团队的技术栈以 Java 为主，不需要频繁跨语言调用
  3. 对性能敏感：如金融交易系统、实时风控系统等对延迟敏感的场景
  4. 已有 Dubbo 生态：当团队已有 Dubbo 使用经验和相关基础设施

Dubbo 3.x 的新特性：

Apache Dubbo 3.x（smart-scaffold 使用的是 3.2.0 版本）引入了许多重要的新特性：

  • Triple 协议：基于 gRPC 的下一代通信协议，同时支持 gRPC 和 REST 风格的调用
  • 应用级服务发现：从接口级服务发现升级为应用级，减少了注册中心的数据量
  • 云原生支持：更好地适配 Kubernetes 和 Service Mesh
  • 元数据服务：独立的元数据中心，减轻注册中心的负担
yaml
# Dubbo 3.x 应用级服务发现配置示例
dubbo:
  application:
    name: smart-scaffold-dubbo-provider
    register-mode: instance  # 应用级服务发现
  registry:
    register-mode: instance

1.3 微服务HTTP架构（SpringCloud） ​

Spring Cloud 微服务架构基于 HTTP REST 协议实现服务间通信，是目前业界最主流的微服务实现方案之一。与 Dubbo 的 RPC 方式不同，Spring Cloud 采用"协议标准化"的设计哲学，使用 HTTP 作为服务间通信的统一协议。

smart-scaffold-springcloud 项目的模块划分与 Dubbo 版本有相似之处，但内部实现机制截然不同：

smart-scaffold-springcloud/         # 父POM
├── smart-scaffold-common/          # 通用模块：DTO、Entity、枚举、工具类
├── smart-scaffold-provider/        # 服务提供者：业务逻辑、数据访问、REST端点
└── smart-scaffold-consumer/        # 服务消费者：Feign客户端、Controller、前端

Spring Cloud 版本的核心区别在于 Common 模块 替代了 Dubbo 版本的 API 模块。Common 模块不定义服务接口，而是提供共享的 DTO、Entity 等数据结构：

smart-scaffold-common/src/main/java/cc/bima/scaffold/common/
├── dto/
│   ├── db1/
│   │   ├── UserModelDTO.java
│   │   └── UserModelQueryDTO.java
│   └── db2/
│       ├── DepartmentDTO.java
│       └── DepartmentQueryDTO.java
├── entity/
│   ├── db1/
│   │   └── UserModel.java
│   └── db2/
│       └── Department.java
├── service/
│   ├── ApiResult.java
│   ├── PageDTO.java
│   └── PageQueryDTO.java
├── enums/
│   └── BaseResultEnum.java
├── po/
│   └── ModelPO.java
└── constants/
    └── Constants.java

在 Consumer 端，服务接口通过 @FeignClient 注解定义，这是一个声明式的 HTTP 客户端：

java
@FeignClient(name = "smart-scaffold-springcloud-provider",
             path = "/mybatis-usermodel",
             contextId = "userModelService")
public interface IMybatisUserModelService {

    @PostMapping({ "/list/page" })
    ApiResult<?> listPage(
        @RequestParam(value = Constants.USER_ID_KEY, required = false) String userId,
        @RequestParam(value = Constants.USER_NAME_KEY, required = false) String userName,
        @RequestBody UserModelQueryDTO queryDTO);

    @PostMapping({ "/add" })
    ApiResult<?> add(
        @RequestParam(value = Constants.USER_ID_KEY, required = false) String userId,
        @RequestParam(value = Constants.USER_NAME_KEY, required = false) String userName,
        @RequestBody UserModelDTO dto);

    // ... 更多方法
}

Provider 端需要同时暴露 REST 端点供 Feign 客户端调用，同时内部实现业务逻辑。这意味着 Provider 端既承担了业务处理职责，也承担了 HTTP 接口暴露职责。

Spring Cloud 架构的优势在于：

  • 协议通用性强：基于 HTTP REST，任何语言都可以轻松接入
  • 生态丰富：拥有完善的服务发现、配置管理、熔断器、网关等组件生态
  • 标准化程度高：OpenAPI/Swagger 规范支持好，接口文档自动化
  • 云原生友好：与 Kubernetes、Service Mesh 等云原生技术栈天然契合

Spring Cloud 架构的局限在于：

  • 性能开销大：HTTP + JSON 序列化/反序列化的开销显著高于 RPC 二进制协议
  • 配置复杂：需要引入大量 Spring Cloud 组件，配置项繁多
  • 依赖链路长：一个请求可能经过网关、负载均衡、服务发现等多个环节
  • 调试困难：分布式链路追踪是必需品而非可选项
  • 版本兼容性：Spring Cloud 版本与 Spring Boot 版本有严格的兼容性要求，升级路径复杂
  • 资源消耗：每个微服务都是一个独立的 JVM 进程，内存开销（基础 200-500MB）远大于模块化单体

Spring Cloud 生态核心组件：

在实际生产环境中，Spring Cloud 通常需要配合以下组件使用：

组件功能smart-scaffold 是否使用
Spring Cloud OpenFeign声明式 HTTP 客户端是
Spring Cloud Zookeeper Discovery服务发现是
Spring Cloud LoadBalancer客户端负载均衡是
Spring Cloud GatewayAPI 网关否（可扩展）
Spring Cloud Circuit Breaker熔断器（Resilience4j）否（可扩展）
Spring Cloud Config配置中心否（使用 Profile）
Spring Cloud Sleuth分布式链路追踪否（可扩展）
Spring Cloud Stream消息驱动微服务否（直接使用 MQ 客户端）

在 smart-scaffold-springcloud 项目中，只使用了核心的三个组件（OpenFeign、Zookeeper Discovery、LoadBalancer），这是一个精简但完整的微服务基础设施。在生产环境中，建议根据实际需求逐步引入网关、熔断器和链路追踪等组件。

1.4 架构演进路径 ​

理解三种架构之间的关系，关键在于认识到它们并非互相替代的关系，而是不同业务阶段的技术选择。下图展示了典型的架构演进路径：

┌──────────────┐     业务增长      ┌──────────────┐     规模扩大      ┌──────────────┐
│              │  ──────────────>  │              │  ──────────────>  │              │
│  SpringBoot  │                   │    Dubbo     │                   │ Spring Cloud │
│  单体架构     │                   │  RPC架构      │                   │  微服务架构    │
│              │                   │              │                   │              │
│ 初创期/验证期 │                   │ 成长期/扩展期 │                   │ 成熟期/大规模  │
└──────────────┘                   └──────────────┘                   └──────────────┘
     团队: 1-5人                       团队: 5-15人                      团队: 15+人
     用户: <10万                       用户: 10-100万                    用户: 100万+
     服务: 1个JAR                      服务: 2-5个JAR                    服务: 10+个JAR

演进的核心驱动力：

  1. 业务复杂度增长：当单体应用的业务模块超过一定阈值（通常认为 10-15 个核心模块），模块间的代码耦合和发布冲突会显著影响开发效率
  2. 流量规模增长：当系统需要应对高并发场景时，不同业务模块的流量特征差异巨大，需要独立扩展
  3. 团队规模增长：当开发团队超过一定规模时，单体代码库的协作效率会急剧下降
  4. 技术异构需求：某些业务模块可能需要使用不同的技术栈（如 AI 推理使用 Python，实时计算使用 Flink）

值得注意的是，在实际项目中，三种架构并非严格的线性替代关系。很多成熟企业会同时使用多种架构模式：核心交易链路使用 Dubbo RPC 保证性能，边缘服务使用 Spring Cloud 微服务保证灵活性，内部管理后台使用 SpringBoot 单体保证开发效率。

二、模块划分策略对比 ​

模块划分是架构设计的第一步，也是最容易被忽视的环节。不同的架构模式对模块划分有着截然不同的理念和约束。本节将深入分析三种架构模式下的模块划分策略，并基于 smart-scaffold 三套真实项目进行对比。

2.1 SpringBoot：按技术层划分 ​

SpringBoot 单体架构采用经典的**按技术层（Technical Layer）**划分策略。这种策略的核心思想是：将代码按照在技术栈中的角色进行分组，每一层只负责特定的技术职责。

在 smart-scaffold-springboot 项目中，四个模块的职责划分如下：

smart-scaffold-common（通用层）

通用层是整个项目的基础设施层，提供所有其他层都可能使用的通用组件。在 smart-scaffold 项目中，common 模块通常包含：

  • 工具类（字符串处理、日期处理、加密解密等）
  • 常量定义（业务常量、系统常量）
  • 通用枚举（状态码、业务类型等）
  • 基础 DTO/VO 定义
  • 自定义异常类

smart-scaffold-dao（数据访问层）

数据访问层封装了所有与数据库交互的逻辑，包含：

  • MyBatis Mapper 接口（如 UserModelMapper.java）
  • MyBatis XML 映射文件
  • 数据源配置类
  • 数据库相关的工具类

在 smart-scaffold-springboot 中，dao 模块依赖 common 模块，并通过 Maven 依赖引入 MyBatis 相关依赖：

xml
<!-- smart-scaffold-dao/pom.xml 核心依赖 -->
<dependencies>
    <dependency>
        <groupId>cc.bima.scaffold</groupId>
        <artifactId>smart-scaffold-common</artifactId>
        <version>1.0.0-SNAPSHOT</version>
    </dependency>
    <!-- MyBatis 依赖 -->
    <dependency>
        <groupId>org.mybatis.spring.boot</groupId>
        <artifactId>mybatis-spring-boot-starter</artifactId>
        <version>3.0.5</version>
    </dependency>
</dependencies>

smart-scaffold-service（业务逻辑层）

业务逻辑层是整个应用的核心，包含所有的业务规则和流程编排：

  • Service 实现类（如 MybatisUserModelService.java）
  • 业务规则校验
  • 事务管理
  • 缓存策略
  • 消息发送逻辑

smart-scaffold-web（表现层）

表现层负责处理 HTTP 请求和响应，是应用与外部交互的入口：

  • Controller 类（如 MybatisUserModelController.java）
  • Spring Boot 启动类
  • 应用配置文件（application.yml 及多环境配置）
  • 前端模板（Thymeleaf）
  • 过滤器和拦截器

模块依赖关系：

web ──> service ──> dao ──> common

这种单向依赖关系确保了每一层只依赖其下一层，避免了循环依赖。web 模块通过 spring-boot-maven-plugin 打包为可执行 JAR，其他模块作为嵌套 JAR 被包含在内。

2.2 Dubbo：按服务角色划分 ​

Dubbo RPC 架构采用**按服务角色（Service Role）**划分策略。这种策略的核心思想是：将代码按照在分布式系统中的角色进行分组，强调服务提供者和服务消费者之间的边界。

smart-scaffold-dubbo 项目的三个模块各自承担不同的角色：

smart-scaffold-api（服务契约层）

API 模块是 Dubbo 架构中最独特的模块，它是 Provider 和 Consumer 之间的"契约"。API 模块的核心内容：

  • face 包：服务接口定义，所有可被远程调用的方法签名
  • dto 包：数据传输对象，用于服务间数据传递
  • entity 包：实体类定义
  • service 包：通用服务类（如 ApiResult、PageDTO）
  • enums 包：枚举定义
  • constants 包：常量定义

API 模块的设计原则是最小化依赖。在 smart-scaffold-dubbo 中，API 模块的 pom.xml 只引入了最基本的依赖：

xml
<!-- smart-scaffold-api/pom.xml -->
<dependencies>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <scope>provided</scope>
    </dependency>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-lang3</artifactId>
    </dependency>
    <dependency>
        <groupId>commons-io</groupId>
        <artifactId>commons-io</artifactId>
        <version>2.15.0</version>
    </dependency>
    <dependency>
        <groupId>com.fasterxml.jackson.core</groupId>
        <artifactId>jackson-databind</artifactId>
    </dependency>
</dependencies>

注意 API 模块不依赖 MyBatis、Spring Web、数据库驱动等任何重量级组件，确保 Consumer 端引入 API 模块时不会带入不必要的依赖传递。

smart-scaffold-provider（服务提供者）

Provider 模块是服务的实现端，包含：

  • 服务实现类（使用 @DubboService 注解）
  • MyBatis Mapper 接口和 XML
  • 数据源配置
  • 业务逻辑处理
  • 中间件集成（Redis、Kafka、MongoDB、Elasticsearch 等）

Provider 模块依赖 API 模块，并实现了 API 模块中定义的所有接口。在 smart-scaffold-dubbo 中，Provider 模块的依赖非常丰富：

xml
<!-- smart-scaffold-provider/pom.xml 核心依赖 -->
<dependencies>
    <!-- API 依赖 -->
    <dependency>
        <groupId>cc.bima.scaffold</groupId>
        <artifactId>smart-scaffold-api</artifactId>
    </dependency>
    <!-- Dubbo 依赖 -->
    <dependency>
        <groupId>org.apache.dubbo</groupId>
        <artifactId>dubbo-spring-boot-starter</artifactId>
        <version>3.2.0</version>
    </dependency>
    <!-- Zookeeper 相关 -->
    <dependency>
        <groupId>org.apache.curator</groupId>
        <artifactId>curator-recipes</artifactId>
        <version>5.1.0</version>
    </dependency>
    <!-- MyBatis -->
    <dependency>
        <groupId>org.mybatis.spring.boot</groupId>
        <artifactId>mybatis-spring-boot-starter</artifactId>
        <version>3.0.5</version>
    </dependency>
    <!-- 中间件：Redis、Kafka、RabbitMQ、MongoDB、ES、RocketMQ -->
    <!-- ... -->
</dependencies>

smart-scaffold-consumer（服务消费者）

Consumer 模块是服务的调用端，包含：

  • Controller 类（使用 @DubboReference 引用远程服务）
  • 前端模板（Thymeleaf）
  • OAuth2 认证过滤器
  • HTTP 客户端配置

Consumer 模块同样依赖 API 模块，但不依赖数据库驱动和 MyBatis：

xml
<!-- smart-scaffold-consumer/pom.xml 核心依赖 -->
<dependencies>
    <!-- API 依赖 -->
    <dependency>
        <groupId>cc.bima.scaffold</groupId>
        <artifactId>smart-scaffold-api</artifactId>
    </dependency>
    <!-- Dubbo 依赖 -->
    <dependency>
        <groupId>org.apache.dubbo</groupId>
        <artifactId>dubbo-spring-boot-starter</artifactId>
        <version>3.2.0</version>
    </dependency>
    <!-- Web + Thymeleaf -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <!-- 注意：没有 MyBatis 和数据库驱动依赖 -->
</dependencies>

模块依赖关系：

provider ──> api
consumer ──> api

Provider 和 Consumer 之间没有直接的 Maven 依赖，它们通过 API 模块建立联系。这种"菱形"依赖结构是 Dubbo 架构的典型特征。

2.3 SpringCloud：按服务角色划分 ​

Spring Cloud 微服务架构同样采用按服务角色划分策略，但与 Dubbo 版本在细节上存在重要差异。

smart-scaffold-springcloud 项目的三个模块：

smart-scaffold-common（共享数据层）

与 Dubbo 版本的 API 模块不同，Spring Cloud 版本的 Common 模块不定义服务接口。它只提供共享的数据结构：

  • dto 包：按数据源分包（db1/、db2/），包含 DTO 和 QueryDTO
  • entity 包：按数据源分包，包含数据库实体类
  • service 包：通用返回结果类（ApiResult、PageDTO、PageQueryDTO）
  • enums 包：枚举定义
  • po 包：持久化对象
  • constants 包：常量定义
xml
<!-- smart-scaffold-common/pom.xml -->
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
    </dependency>
    <!-- Jackson、Commons-Lang3、Commons-IO 等 -->
</dependencies>

smart-scaffold-provider（服务提供者）

Provider 模块同时承担了业务逻辑处理和 HTTP REST 端点暴露的双重职责：

  • REST Controller（暴露 HTTP 接口供 Feign 调用）
  • Service 实现类
  • MyBatis Mapper + MyBatis-Plus
  • 数据源配置
  • 中间件集成

Provider 模块的启动类使用了 @EnableDiscoveryClient 注解，将服务注册到 Zookeeper：

java
@EnableDiscoveryClient
@SpringBootApplication(scanBasePackages = { "cc.bima.scaffold" },
    exclude = { DataSourceAutoConfiguration.class,
        com.baomidou.mybatisplus.autoconfigure.MybatisPlusAutoConfiguration.class,
        com.baomidou.mybatisplus.autoconfigure.MybatisPlusLanguageDriverAutoConfiguration.class })
public class ProviderWebApplication {
    public static void main(String[] args) {
        SpringApplication.run(ProviderWebApplication.class, args);
    }
}

smart-scaffold-consumer（服务消费者）

Consumer 模块包含：

  • Feign 客户端接口（使用 @FeignClient 注解定义）
  • Controller 类（使用 @Autowired 注入 Feign 客户端）
  • 前端模板（Thymeleaf）
  • OAuth2 认证过滤器

Consumer 的启动类同时启用了服务发现和 Feign 客户端：

java
@EnableDiscoveryClient
@SpringBootApplication(scanBasePackages = { "cc.bima.scaffold" },
    exclude = { DataSourceAutoConfiguration.class })
@EnableFeignClients(basePackages = "cc.bima.scaffold")
public class ConsumerWebApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConsumerWebApplication.class, args);
    }
}

模块依赖关系：

provider ──> common
consumer ──> common

2.4 三种划分策略优劣分析 ​

维度SpringBoot（按技术层）Dubbo（按服务角色）SpringCloud（按服务角色）
模块数量4个（common/dao/service/web）3个（api/provider/consumer）3个（common/provider/consumer）
依赖方向单向链式依赖菱形依赖菱形依赖
接口定义位置service 模块内部独立的 api 模块consumer 模块的 Feign 接口
代码隔离度低（同一进程）高（不同进程）高（不同进程）
部署粒度整体部署Provider/Consumer 独立部署Provider/Consumer 独立部署
新增业务模块在对应层添加文件在 api 定义接口 + provider 实现在 common 添加 DTO + provider 暴露 + consumer 定义 Feign
依赖传递控制通过 Maven scope 控制API 模块最小化依赖Common 模块最小化依赖

关键差异分析：

  1. SpringBoot 的 common/dao/service/web 划分是最直观的，每个开发者都能快速理解各层职责。但这种划分在业务规模增长后，service 层会变得异常庞大，成为代码冲突的重灾区。

  2. Dubbo 的 api/provider/consumer 划分强制性地将接口定义与实现分离，这种"面向接口编程"的约束在大型团队中尤为重要。API 模块作为独立产物，可以被多个 Consumer 同时引用，天然支持多消费者场景。

  3. Spring Cloud 的 common/provider/consumer 划分与 Dubbo 类似，但 Common 模块不包含服务接口定义。服务接口（Feign 客户端）定义在 Consumer 端，这意味着 Provider 端不需要知道 Consumer 的存在——Provider 只需暴露标准的 REST 端点。这种设计使得 Provider 可以被任何支持 HTTP 的客户端调用，通用性更强。

三、服务通信机制对比 ​

服务通信机制是三种架构模式最本质的差异所在。从进程内方法调用到 RPC 二进制序列化，再到 HTTP REST，通信方式的选择直接决定了系统的性能特征、开发体验和运维复杂度。

3.1 SpringBoot：进程内方法调用 ​

在 SpringBoot 单体架构中，Controller 调用 Service 是标准的进程内方法调用（In-Process Method Invocation）。这种方式的特点是：

  • 零网络开销：方法调用在同一个 JVM 进程内完成，不涉及网络传输
  • 零序列化开销：对象以引用方式传递，无需序列化和反序列化
  • 零注册中心开销：不需要服务发现和负载均衡
  • 共享事务上下文：Spring 事务管理器可以无缝管理跨多个 Service 的数据库操作

在 smart-scaffold-springboot 中，Controller 通过 @Autowired 注入 Service，然后直接调用其方法：

java
@RestController
@RequestMapping("/mybatis-usermodel")
public class MybatisUserModelController {

    @Autowired
    private MybatisUserModelService userModelService;

    @PostMapping({ "/list/page" })
    public BaseResult<?> listPage(...) {
        // 直接方法调用，零网络开销
        PageEntity<UserModelDTO> userDTOs = userModelService.selectPageBy(queryDTO);
        return BaseResult.success(userDTOs);
    }

    @PostMapping({ "/add" })
    public BaseResult<?> add(...) {
        // 直接方法调用，共享事务上下文
        userModelService.save(dto, userId, userName);
        return BaseResult.success(dto.getId());
    }
}

这种调用方式的性能是最优的。一次方法调用的开销主要来自：

  1. JVM 方法栈帧创建：约 10-50 纳秒
  2. Spring AOP 代理调用：如果 Service 使用了 @Transactional 等注解，会经过 CGLIB 或 JDK 动态代理，增加约 100-500 纳秒
  3. 对象引用传递：几乎零开销，只是传递内存地址

总体延迟：通常在 0.001-0.01 毫秒 级别，对业务逻辑的执行时间几乎不产生影响。

3.2 Dubbo：RPC二进制序列化通信 ​

Dubbo 采用自定义的 RPC 协议进行服务间通信。在 smart-scaffold-dubbo 中，使用的是 Apache Dubbo 3.2.0 版本，默认采用 dubbo:// 协议，序列化方式为 Hessian2。

Dubbo 的通信流程如下：

Consumer 端                                    Provider 端
┌──────────────┐                                ┌──────────────┐
│ Controller   │                                │ Service      │
│     │        │                                │     │        │
│ @DubboReference                              │ @DubboService│
│     │        │                                │     │        │
│     ▼        │                                │     ▲        │
│ Proxy 代理   │                                │ Proxy 代理   │
│     │        │                                │     │        │
│     ▼        │    ┌──────────────────┐        │     ▲        │
│ Hessian2     │───>│  Network (TCP)   │───>    │ Hessian2    │
│ 序列化       │    │  Dubbo Protocol  │        │ 反序列化     │
│     │        │    └──────────────────┘        │     │        │
│     ▼        │                                │     ▼        │
│ 发送请求     │                                │ 执行方法     │
└──────────────┘                                └──────────────┘

在 smart-scaffold-dubbo 中，Consumer 端的 Controller 使用 @DubboReference 注入远程服务代理：

java
@RestController
@RequestMapping("/mybatis-usermodel")
public class MybatisUserModelController {

    @DubboReference
    private IMybatisUserModelService mybatisUserModelService;

    @PostMapping({ "/list/page" })
    public ApiResult<?> listPage(...) {
        // 通过 Dubbo RPC 调用远程服务
        Object userDTOs = mybatisUserModelService.selectPageBy(queryDTO);
        return ApiResult.success(userDTOs);
    }
}

Provider 端的 Service 使用 @DubboService 注解发布服务：

java
@DubboService
@Service("MybatisUserModelService")
public class MybatisUserModelService extends BaseService<UserModelMapper, UserModelDTO, UserModelQueryDTO>
        implements IMybatisUserModelService {

    @Override
    public PageDTO<UserModelDTO> selectPageBy(UserModelQueryDTO queryDTO) {
        return super.selectPageBy(queryDTO);
    }
}

Dubbo 通信的性能特征：

  1. 连接管理：Dubbo 默认使用长连接，避免了 TCP 三次握手的开销
  2. 序列化效率：Hessian2 是一种高效的二进制序列化协议，序列化/反序列化速度约为 JSON 的 3-5 倍
  3. 协议开销：Dubbo 协议头仅 16 字节，远小于 HTTP 协议的数百字节
  4. 线程模型：Dubbo 默认使用 Netty 作为网络通信框架，采用 Reactor 线程模型

总体延迟：通常在 0.5-3 毫秒 级别（局域网环境），主要开销来自序列化/反序列化和网络传输。

3.3 SpringCloud：OpenFeign HTTP REST通信 ​

Spring Cloud 采用 OpenFeign 作为声明式 HTTP 客户端，通过标准的 HTTP 协议进行服务间通信。在 smart-scaffold-springcloud 中，Consumer 端通过 @FeignClient 注解定义服务调用接口：

java
@FeignClient(name = "smart-scaffold-springcloud-provider",
             path = "/mybatis-usermodel",
             contextId = "userModelService")
public interface IMybatisUserModelService {

    @PostMapping({ "/list/page" })
    ApiResult<?> listPage(
        @RequestParam(value = Constants.USER_ID_KEY, required = false) String userId,
        @RequestParam(value = Constants.USER_NAME_KEY, required = false) String userName,
        @RequestBody UserModelQueryDTO queryDTO);

    @PostMapping({ "/add" })
    ApiResult<?> add(
        @RequestParam(value = Constants.USER_ID_KEY, required = false) String userId,
        @RequestParam(value = Constants.USER_NAME_KEY, required = false) String userName,
        @RequestBody UserModelDTO dto);

    @GetMapping({ "/{id}/detail" })
    ApiResult<?> detail(
        @RequestParam(value = Constants.USER_ID_KEY, required = false) String userId,
        @RequestParam(value = Constants.USER_NAME_KEY, required = false) String userName,
        @PathVariable("id") Long id);

    @DeleteMapping({ "/{id}/delete" })
    ApiResult<?> delete(
        @RequestParam(value = Constants.USER_ID_KEY, required = false) String userId,
        @RequestParam(value = Constants.USER_NAME_KEY, required = false) String userName,
        @PathVariable("id") Long id);
}

Consumer 端的 Controller 通过 @Autowired 注入 Feign 客户端：

java
@RestController
@RequestMapping("/mybatis-usermodel")
public class MybatisUserModelController {

    @Autowired
    private IMybatisUserModelService userModelService;

    @PostMapping({ "/list/page" })
    public ApiResult<?> listPage(...) {
        // 通过 Feign HTTP 调用远程服务
        return userModelService.listPage(userId, userName, queryDTO);
    }
}

Spring Cloud 通信的完整链路：

Consumer 端                                    Provider 端
┌──────────────┐                                ┌──────────────┐
│ Controller   │                                │ Controller   │
│     │        │                                │     │        │
│ @Autowired   │                                │ @RestController│
│     ▼        │                                │     │        │
│ Feign Proxy  │                                │     ▲        │
│     │        │                                │     │        │
│     ▼        │    ┌──────────────────┐        │     ▲        │
│ LoadBalancer │───>│  服务发现        │───>    │ Dispatcher   │
│ (选择实例)   │    │  (Zookeeper)     │        │ Servlet      │
│     │        │    └──────────────────┘        │     │        │
│     ▼        │                                │     ▼        │
│ JSON序列化   │───>│  HTTP Request     │───>    │ JSON反序列化  │
│ (Jackson)    │    │  (TCP)            │        │ (Jackson)    │
│     │        │    └──────────────────┘        │     │        │
│     ▼        │                                │     ▼        │
│ HTTP发送     │                                │ Service执行   │
└──────────────┘                                └──────────────┘

Spring Cloud 通信的性能特征：

  1. HTTP 协议开销：每次请求都需要携带 HTTP 头部（通常 200-500 字节）
  2. JSON 序列化：Jackson 序列化/反序列化的性能约为 Hessian2 的 1/3 到 1/5
  3. 服务发现开销：每次调用需要从 Zookeeper 获取服务实例列表（通常有本地缓存）
  4. 负载均衡开销：Spring Cloud LoadBalancer 在每次调用时选择目标实例
  5. 连接管理：默认使用 HTTP 连接池，但每次请求仍有 HTTP 协议解析开销

总体延迟：通常在 2-10 毫秒 级别（局域网环境），主要开销来自 HTTP 协议解析和 JSON 序列化/反序列化。

3.4 序列化协议深度对比 ​

序列化是分布式通信的核心环节，三种架构模式在序列化方面的选择差异巨大：

Hessian2（Dubbo 默认）

Hessian2 是一种轻量级的二进制序列化协议，具有以下特点：

  • 自描述性：序列化数据中包含类型信息，无需额外的 schema
  • 跨语言支持：支持 Java、Python、C++ 等多种语言
  • 压缩效率：二进制格式，数据体积约为 JSON 的 30-50%
  • 性能：序列化/反序列化速度快，适合高频调用场景
// Hessian2 序列化后的数据示例（二进制格式）
// 体积约为 JSON 的 40%

JSON（Spring Cloud 默认）

JSON 是一种文本格式的序列化协议，具有以下特点：

  • 可读性强：人类可以直接阅读和调试
  • 通用性极强：几乎所有编程语言都原生支持
  • 体积较大：文本格式，数据体积约为二进制的 2-3 倍
  • 解析速度较慢：需要解析文本字符串，性能不如二进制协议
json
// JSON 序列化后的数据示例
{
    "code": 200,
    "message": "success",
    "data": {
        "id": 1,
        "userName": "admin",
        "status": false,
        "timeCreate": "2024-01-15T10:30:00",
        "timeUpdate": "2024-01-15T10:30:00"
    }
}

Protobuf（可选方案）

Protocol Buffers 是 Google 开发的高效二进制序列化协议，可以作为 Dubbo 或 Spring Cloud 的替代序列化方案：

  • 极致性能：序列化/反序列化速度极快，体积最小
  • 强类型约束：需要预定义 .proto 文件，编译生成代码
  • 向后兼容：支持字段编号，新增字段不影响旧版本
  • 不适合动态场景：需要预编译，不适合动态类型场景

序列化性能对比表：

指标Hessian2JSON (Jackson)Protobuf
序列化速度~8000 ops/ms~3000 ops/ms~15000 ops/ms
反序列化速度~5000 ops/ms~2000 ops/ms~12000 ops/ms
数据体积100% (基准)200-300%50-70%
可读性差优差
跨语言良优优
动态类型支持支持不支持
学习成本低低中

3.5 通信延迟量化对比 ​

基于实际测试经验，三种通信方式的延迟对比如下：

通信方式单次调用延迟吞吐量（单连接）适用场景
进程内方法调用0.001-0.01 ms>100万 QPS单体应用内部调用
Dubbo RPC (Hessian2)0.5-3 ms5-15万 QPS高频内部服务调用
Spring Cloud (HTTP/JSON)2-10 ms1-5万 QPS通用服务间调用
Spring Cloud (HTTP/Protobuf)1-5 ms3-8万 QPS性能敏感的跨语言调用

延迟构成分析：

以一次 Dubbo RPC 调用为例，延迟构成如下：

总延迟 = 代理调用(0.01ms) + 序列化(0.1ms) + 网络传输(0.3ms) + 反序列化(0.1ms) + 方法执行(0.5ms)
       ≈ 1.0 ms

以一次 Spring Cloud HTTP 调用为例，延迟构成如下：

总延迟 = 代理调用(0.01ms) + 服务发现(0.01ms) + 负载均衡(0.01ms)
       + JSON序列化(0.3ms) + HTTP协议解析(0.1ms) + 网络传输(0.3ms)
       + HTTP协议解析(0.1ms) + JSON反序列化(0.3ms) + 方法执行(0.5ms)
       ≈ 1.6 ms

关键结论：

  1. 对于绝大多数业务场景（响应时间 > 100ms），三种通信方式的延迟差异可以忽略不计
  2. 对于高频内部调用（如每秒 > 1万次），Dubbo RPC 的性能优势开始显现
  3. 对于需要跨语言调用的场景，Spring Cloud HTTP REST 是更自然的选择
  4. 在实际项目中，数据库查询（通常 5-50ms）和网络 IO（通常 10-100ms）才是真正的性能瓶颈，服务间通信的延迟占比很小

实际场景中的性能考量：

在 smart-scaffold 项目中，一个典型的用户模型查询请求的完整链路耗时分析如下：

SpringBoot 单体：
  HTTP 请求解析(0.1ms) + Controller处理(0.01ms) + Service方法调用(0.01ms)
  + MyBatis查询(5-20ms) + JSON序列化(0.5ms) + HTTP响应(0.1ms)
  ≈ 6-21 ms

Dubbo RPC：
  HTTP 请求解析(0.1ms) + Controller处理(0.01ms) + Dubbo RPC调用(1-3ms)
  + MyBatis查询(5-20ms) + Dubbo返回(1-3ms) + JSON序列化(0.5ms) + HTTP响应(0.1ms)
  ≈ 8-27 ms

SpringCloud HTTP：
  HTTP 请求解析(0.1ms) + Controller处理(0.01ms) + Feign调用(2-10ms)
  + HTTP解析(0.1ms) + Provider Controller(0.01ms) + MyBatis查询(5-20ms)
  + JSON序列化(0.5ms) + HTTP返回(2-10ms) + JSON反序列化(0.3ms) + HTTP响应(0.1ms)
  ≈ 10-41 ms

从以上分析可以看出，数据库查询耗时占据了整个请求链路的 60-80%，服务间通信的额外开销在绝对值上并不显著。因此，在选择架构模式时，不应该过度关注通信性能的差异，而应该更多地考虑开发效率、运维成本和团队协作等因素。

高并发场景下的性能差异：

虽然单次调用的延迟差异不大，但在高并发场景下，通信方式的选择会对系统整体吞吐量产生显著影响：

  • SpringBoot 单体：由于没有网络开销，单机吞吐量最高，但受限于单进程的 CPU 和内存上限
  • Dubbo RPC：二进制序列化和长连接复用使得网络开销最小化，在多实例部署时整体吞吐量接近单体
  • SpringCloud HTTP：HTTP 协议开销和 JSON 序列化在高并发下会成为瓶颈，需要更多的实例来达到相同的吞吐量

假设一个服务方法的数据库查询耗时为 10ms，那么：

架构模式单次请求耗时单机 QPS 上限（8核CPU）达到 10万 QPS 所需实例数
SpringBoot~12ms~6000~17
Dubbo~15ms~5000~20
SpringCloud~20ms~3500~29

注意：以上数据为估算值，实际性能取决于硬件配置、网络环境、JVM 调优等多种因素。

四、接口定义方式对比 ​

接口定义是服务间协作的"契约"，不同的架构模式对接口定义有着截然不同的设计理念和实现方式。本节将深入分析三种架构模式下的接口定义方式，并探讨接口版本管理的最佳实践。

4.1 SpringBoot：Java接口直接引用 ​

在 SpringBoot 单体架构中，接口定义是最简单直接的。Controller 直接引用 Service 的 Java 接口或实现类，通过 Spring 的依赖注入机制完成装配。

在 smart-scaffold-springboot 中，Controller 直接注入 Service 实现类：

java
@RestController
@RequestMapping("/mybatis-usermodel")
public class MybatisUserModelController {

    @Autowired
    private MybatisUserModelService userModelService;

    // 直接调用 Service 方法
}

Service 类本身就是一个标准的 Spring Bean：

java
@Service("MybatisUserModelService")
public class MybatisUserModelService extends BaseService<UserModelMapper, UserModelDTO, UserModelQueryDTO> {

    public UserModelDTO save(UserModelDTO dto, String userId, String userName) {
        // 业务逻辑
    }

    public PageEntity<UserModelDTO> selectPageBy(UserModelQueryDTO queryDTO) {
        // 分页查询
    }
}

这种方式的特征：

  1. 无接口契约层：Controller 直接依赖 Service 实现类，没有独立的接口定义
  2. 编译时检查：所有方法签名在编译时即可确定，IDE 支持完善
  3. 重构友好：修改 Service 方法签名后，IDE 可以自动更新所有调用方
  4. 零配置：不需要任何额外的注解或配置来声明服务接口

潜在问题：

  1. 耦合度高：Controller 直接依赖 Service 实现类，而非接口，违反了依赖倒置原则
  2. 测试困难：Mock Service 实现类比 Mock 接口更复杂
  3. 无法跨进程复用：如果将来需要拆分为微服务，需要重新定义接口

4.2 Dubbo：Java接口 + face包 ​

Dubbo 架构强制要求将服务接口定义在独立的 API 模块中。在 smart-scaffold-dubbo 中，接口定义位于 api 模块的 face 包下：

java
package cc.bima.scaffold.api.face;

import java.util.List;
import cc.bima.scaffold.api.dto.UserModelDTO;
import cc.bima.scaffold.api.dto.UserModelQueryDTO;
import cc.bima.scaffold.api.service.PageDTO;

/**
 * 用户模型服务接口
 *
 * @author 必码 bima.cc
 */
public interface IMybatisUserModelService {

    UserModelDTO save(UserModelDTO dto, String userId, String userName);

    UserModelDTO get(Long id);

    void update(UserModelDTO dto, String userId, String userName);

    void delete(Long id);

    Object list(UserModelQueryDTO queryDTO);

    PageDTO<UserModelDTO> selectPageBy(UserModelQueryDTO queryDTO);

    List<UserModelDTO> selectBy(UserModelQueryDTO queryDTO);

    void remove(Long id);
}

face 包的命名约定：

在 smart-scaffold-dubbo 中，服务接口统一放在 face 包下，这是一种常见的命名约定。"face" 即 "Facade"（门面）的缩写，暗示这些接口是服务对外暴露的"门面"。这种命名约定的好处：

  1. 语义清晰：开发者一眼就能识别哪些是服务接口
  2. 包结构整洁：与 dto、entity、enums 等包并列，结构清晰
  3. 避免冲突：不会与 Provider 端的 Service 实现类产生包名冲突

Provider 端实现接口：

java
@DubboService
@Service("MybatisUserModelService")
public class MybatisUserModelService extends BaseService<UserModelMapper, UserModelDTO, UserModelQueryDTO>
        implements IMybatisUserModelService {
    // 实现所有接口方法
}

Consumer 端引用接口：

java
@RestController
@RequestMapping("/mybatis-usermodel")
public class MybatisUserModelController {

    @DubboReference
    private IMybatisUserModelService mybatisUserModelService;

    // 通过 Dubbo 代理调用远程方法
}

Dubbo 接口定义的核心优势：

  1. 编译时类型安全：Consumer 端引用的是 Java 接口，方法签名在编译时即可确定
  2. IDE 支持完善：代码补全、重构、跳转定义等 IDE 功能完全可用
  3. 契约优先：接口定义独立于实现，支持并行开发和版本管理
  4. 多消费者支持：一个 API 模块可以被多个 Consumer 同时引用

4.3 SpringCloud：Java接口 + @FeignClient注解 ​

Spring Cloud 架构中，服务接口通过 @FeignClient 注解定义在 Consumer 端。与 Dubbo 不同，Spring Cloud 的接口定义不是纯粹的 Java 接口，而是带有 HTTP 语义注解的声明式客户端。

在 smart-scaffold-springcloud 中，Consumer 端的 Feign 接口定义：

java
@FeignClient(name = "smart-scaffold-springcloud-provider",
             path = "/mybatis-usermodel",
             contextId = "userModelService")
public interface IMybatisUserModelService {

    @PostMapping({ "/list/page" })
    ApiResult<?> listPage(
        @RequestParam(value = Constants.USER_ID_KEY, required = false) String userId,
        @RequestParam(value = Constants.USER_NAME_KEY, required = false) String userName,
        @RequestBody UserModelQueryDTO queryDTO);

    @PostMapping({ "/list" })
    ApiResult<?> list(
        @RequestParam(value = Constants.USER_ID_KEY, required = false) String userId,
        @RequestParam(value = Constants.USER_NAME_KEY, required = false) String userName,
        @RequestBody UserModelQueryDTO queryDTO);

    @PostMapping({ "/add" })
    ApiResult<?> add(
        @RequestParam(value = Constants.USER_ID_KEY, required = false) String userId,
        @RequestParam(value = Constants.USER_NAME_KEY, required = false) String userName,
        @RequestBody UserModelDTO dto);

    @PutMapping({ "/{id}/edit" })
    ApiResult<?> edit(
        @RequestParam(value = Constants.USER_ID_KEY, required = false) String userId,
        @RequestParam(value = Constants.USER_NAME_KEY, required = false) String userName,
        @RequestBody UserModelDTO dto,
        @PathVariable("id") Long id);

    @GetMapping({ "/{id}/detail" })
    ApiResult<?> detail(
        @RequestParam(value = Constants.USER_ID_KEY, required = false) String userId,
        @RequestParam(value = Constants.USER_NAME_KEY, required = false) String userName,
        @PathVariable("id") Long id);

    @DeleteMapping({ "/{id}/delete" })
    ApiResult<?> delete(
        @RequestParam(value = Constants.USER_ID_KEY, required = false) String userId,
        @RequestParam(value = Constants.USER_NAME_KEY, required = false) String userName,
        @PathVariable("id") Long id);
}

@FeignClient 注解的关键参数：

  • name：目标服务名，对应 Provider 在注册中心注册的服务名
  • path：接口的基础路径前缀
  • contextId：当同一个服务有多个 Feign 客户端时，用于区分不同的客户端 Bean

Spring Cloud 接口定义的特征：

  1. HTTP 语义丰富：每个方法都明确标注了 HTTP 方法（GET/POST/PUT/DELETE）
  2. 参数映射明确：通过 @RequestParam、@RequestBody、@PathVariable 注解清晰定义参数映射
  3. 返回值统一：所有方法返回 ApiResult<?>，通过 HTTP 状态码和 JSON body 传递结果
  4. Provider 端无感知：Provider 端只需暴露标准的 REST Controller，不需要知道 Feign 的存在

与 Dubbo 接口定义的关键差异：

维度Dubbo 接口SpringCloud Feign 接口
定义位置API 模块（独立于 Provider 和 Consumer）Consumer 模块
注解类型纯 Java 接口，无注解Spring MVC 注解（@PostMapping 等）
参数传递Java 方法参数，直接传递HTTP 参数映射（@RequestParam 等）
返回值任意 Java 对象通常为 ApiResult 包装类型
版本管理Dubbo 接口版本号URL 路径版本号
跨语言需要额外适配天然支持（HTTP REST）

4.4 接口版本管理策略 ​

在长期演进的项目中，接口版本管理是不可回避的问题。三种架构模式有不同的版本管理策略：

Dubbo 接口版本管理

Dubbo 原生支持接口版本号，通过 version 属性实现：

java
// Provider 端 - 发布 v2.0 版本
@DubboService(version = "2.0.0")
public class MybatisUserModelServiceV2 implements IMybatisUserModelService {
    // 新版本实现
}

// Consumer 端 - 引用指定版本
@DubboReference(version = "2.0.0")
private IMybatisUserModelService mybatisUserModelService;

Dubbo 的版本管理优势在于：同一个接口可以有多个版本同时运行，Consumer 可以按需选择版本。这对于灰度发布和兼容性迁移非常有用。

Spring Cloud 接口版本管理

Spring Cloud 通常通过 URL 路径进行版本管理：

java
@FeignClient(name = "smart-scaffold-springcloud-provider",
             path = "/v2/mybatis-usermodel",
             contextId = "userModelServiceV2")
public interface IMybatisUserModelServiceV2 {
    // v2 版本接口
}

对应的 Provider 端也需要调整路径：

java
@RestController
@RequestMapping("/v2/mybatis-usermodel")
public class MybatisUserModelControllerV2 {
    // v2 版本实现
}

SpringBoot 接口版本管理

单体架构中，接口版本管理通常通过 URL 路径前缀实现：

java
@RestController
@RequestMapping("/v2/mybatis-usermodel")
public class MybatisUserModelControllerV2 {
    // v2 版本实现
}

由于所有代码在同一个进程中，版本管理相对简单，但也意味着旧版本代码会持续占用内存。

五、注册中心与配置中心 ​

注册中心和配置中心是分布式架构的基础设施组件。三种架构模式在注册中心和配置中心的选择上有着显著差异，这直接影响着系统的运维复杂度和灵活性。

5.1 SpringBoot：无需注册中心 ​

SpringBoot 单体架构不需要注册中心，因为所有组件运行在同一个 JVM 进程中，服务发现通过 Spring 的依赖注入机制在本地完成。

在 smart-scaffold-springboot 中，配置管理通过 Spring Boot 的 Profile 机制实现多环境配置：

yaml
# application.yml - 主配置文件
spring:
  profiles:
    active: dev  # 默认使用开发环境

项目提供了三套环境配置：

  • application-dev.yml：开发环境配置
  • application-qa.yml：测试环境配置
  • application-prd.yml：生产环境配置

配置管理特点：

  1. 配置文件内嵌：所有配置文件打包在 JAR 中，修改配置需要重新打包
  2. 环境切换简单：通过 spring.profiles.active 或启动参数 -Dspring.profiles.active=prd 切换
  3. 无动态更新：修改配置需要重启应用
  4. 集中管理困难：多实例部署时，需要确保每个实例的配置一致

适用场景：

  • 单实例或少量实例部署
  • 配置变更不频繁
  • 不需要动态配置更新

5.2 Dubbo：Zookeeper三中心合一 ​

Dubbo 架构使用 Zookeeper 作为注册中心，在 smart-scaffold-dubbo 中，Zookeeper 同时承担了三个角色：注册中心、配置中心和元数据中心。

在 Provider 端的配置中，Dubbo 的配置非常简洁：

yaml
# smart-scaffold-dubbo-provider application.yml
dubbo:
  application:
    name: smart-scaffold-dubbo-provider
  scan:
    base-packages: cc.bima.scaffold.provider
  provider:
    timeout: 20000
    retries: 1

Dubbo 默认使用 Zookeeper 作为注册中心，无需显式配置注册中心地址（如果 Zookeeper 运行在默认端口 2181）。Dubbo 在 Zookeeper 中创建的节点结构如下：

/dubbo
├── cc.bima.scaffold.api.face.IMybatisUserModelService
│   ├── providers
│   │   └── dubbo://192.168.1.100:20880/cc.bima.scaffold.api.face.IMybatisUserModelService?...
│   ├── consumers
│   │   └── dubbo://192.168.1.101:20880/cc.bima.scaffold.api.face.IMybatisUserModelService?...
│   └── routers
│       └── ...
├── cc.bima.scaffold.api.face.IMybatisDepartmentInfoService
│   ├── providers
│   ├── consumers
│   └── routers
└── ...

Zookeeper 三中心合一的优势：

  1. 运维简单：只需维护一个 Zookeeper 集群
  2. 一致性保证：Zookeeper 的 ZAB 协议保证了服务注册信息的一致性
  3. Watch 机制：Consumer 可以实时感知 Provider 的上下线变化
  4. 临时节点：Provider 注册的节点为临时节点，Provider 宕机后自动摘除

Zookeeper 三中心合一的局限：

  1. 配置管理能力有限：Zookeeper 不如 Nacos、Apollo 等专业配置中心
  2. 配置变更通知：不支持配置的灰度发布和版本管理
  3. 控制台缺失：没有可视化的配置管理界面
  4. 集群运维：Zookeeper 集群的运维需要专业知识

Dubbo 配置参数解析：

yaml
dubbo:
  application:
    name: smart-scaffold-dubbo-provider  # 应用名，用于服务注册
  scan:
    base-packages: cc.bima.scaffold.provider  # 扫描 @DubboService 注解的包路径
  provider:
    timeout: 20000  # 服务调用超时时间（毫秒）
    retries: 1      # 调用失败重试次数
  • timeout: 20000：设置服务调用的超时时间为 20 秒。这个值需要根据业务场景调整，对于数据库操作密集的服务，适当增大超时时间
  • retries: 1：设置调用失败后的重试次数为 1 次。注意：重试只对幂等操作有效，非幂等操作（如新增）不应重试

5.3 SpringCloud：Zookeeper服务发现 + Profile配置 ​

Spring Cloud 架构同样使用 Zookeeper，但主要用作服务发现（Service Discovery），配置管理则通过 Spring Boot Profile 机制实现。

在 smart-scaffold-springcloud 中，Provider 端的 Zookeeper 配置：

yaml
# smart-scaffold-springcloud-provider application.yml
spring:
  application:
    name: smart-scaffold-springcloud-provider
  cloud:
    zookeeper:
      connect-string: 192.168.1.30:2181
      discovery:
        prefer-ip-address: true

Consumer 端的配置：

yaml
# smart-scaffold-springcloud-consumer application.yml
spring:
  application:
    name: smart-scaffold-springcloud-consumer
  cloud:
    zookeeper:
      connect-string: 192.168.1.30:2181

Spring Cloud Zookeeper 服务发现的节点结构：

/spring-cloud
├── services
│   └── smart-scaffold-springcloud-provider
│       ├── 192.168.1.100:8081
│       │   ├── name: smart-scaffold-springcloud-provider
│       │   ├── id: ...
│       │   └── address: 192.168.1.100
│       └── 192.168.1.101:8081
│           ├── name: smart-scaffold-springcloud-provider
│           ├── id: ...
│           └── address: 192.168.1.101
└── ...

与 Dubbo 的关键差异：

  1. 注册粒度不同：Dubbo 按接口注册，Spring Cloud 按应用（服务实例）注册
  2. 发现机制不同：Dubbo Consumer 订阅特定接口，Spring Cloud Consumer 查询特定服务名
  3. 配置分离：Spring Cloud 将服务发现和配置管理分离，更灵活但也更复杂

Spring Cloud 的配置管理策略：

在 smart-scaffold-springcloud 中，配置管理采用与 SpringBoot 相同的 Profile 机制：

yaml
spring:
  profiles:
    active: dev  # 默认使用开发环境

Provider 和 Consumer 各自维护独立的环境配置文件（application-dev.yml、application-qa.yml、application-prd.yml），配置变更需要重新部署。

进阶配置中心方案：

在生产环境中，Spring Cloud 通常配合以下配置中心使用：

  • Spring Cloud Config：Spring 官方配置中心，支持 Git/SVN 作为配置存储
  • Nacos：阿里巴巴开源的配置中心和服务发现合一的解决方案
  • Apollo：携程开源的分布式配置中心，支持灰度发布和权限管理

5.4 三种模式对比总结 ​

维度SpringBootDubboSpringCloud
注册中心无需Zookeeper（内置）Zookeeper（spring-cloud-starter-zookeeper-discovery）
配置中心ProfileZookeeper（内置）Profile（可扩展为 Nacos/Apollo）
元数据中心无需Zookeeper（内置）无需
服务发现粒度N/A按接口按服务实例
配置动态更新不支持支持（有限）支持（需额外组件）
运维复杂度低中中-高
基础设施依赖无ZookeeperZookeeper

六、负载均衡 ​

负载均衡是分布式系统中的核心能力之一。当服务存在多个实例时，负载均衡策略决定了请求如何分配到各个实例上，直接影响系统的吞吐量、延迟和可用性。

6.1 SpringBoot：无需负载均衡 ​

SpringBoot 单体架构只有一个服务实例，不存在负载均衡的需求。如果需要提高可用性，通常在应用前面部署 Nginx 或 HAProxy 作为反向代理和负载均衡器：

                    ┌──────────────────┐
                    │   Nginx / LB     │
                    │  (L4/L7 负载均衡) │
                    └────────┬─────────┘
                             │
              ┌──────────────┼──────────────┐
              │              │              │
     ┌────────▼──────┐ ┌────▼───────┐ ┌────▼───────┐
     │ SpringBoot #1 │ │ SpringBoot │ │ SpringBoot │
     │  (实例1)       │ │  #2 (实例2)│ │  #3 (实例3)│
     └───────────────┘ └────────────┘ └────────────┘

这种模式下的负载均衡由外部组件（Nginx）完成，应用本身不需要感知负载均衡的存在。

6.2 Dubbo：内置多种负载均衡策略 ​

Dubbo 内置了丰富的负载均衡策略，在 Consumer 端进行客户端负载均衡。Dubbo 支持以下四种内置策略：

1. Random（随机，默认）

随机选择一个服务提供者实例。这是 Dubbo 的默认策略，在流量均匀分布的场景下表现良好。

yaml
# 配置方式
dubbo:
  consumer:
    loadbalance: random

2. RoundRobin（轮询）

按顺序依次选择服务提供者实例，确保每个实例接收到的请求数量大致相同。

yaml
dubbo:
  consumer:
    loadbalance: roundrobin

3. LeastActive（最少活跃调用数）

选择当前活跃调用数最少的提供者实例。这种策略能够动态感知各实例的负载情况，将请求分配给当前最空闲的实例。

yaml
dubbo:
  consumer:
    loadbalance: leastactive

4. ConsistentHash（一致性哈希）

基于一致性哈希算法，相同的参数总是路由到同一个提供者实例。这种策略适用于有状态的服务场景。

yaml
dubbo:
  consumer:
    loadbalance: consistenthash

Dubbo 负载均衡的执行位置：

Dubbo 的负载均衡在 Consumer 端执行（客户端负载均衡），流程如下：

Consumer 发起调用
    │
    ▼
从注册中心获取 Provider 列表（本地缓存）
    │
    ▼
负载均衡策略选择一个 Provider 实例
    │
    ▼
通过 Netty 发起 RPC 调用

Dubbo 负载均衡的优势：

  1. 策略丰富：四种内置策略覆盖了大多数业务场景
  2. 客户端负载均衡：避免了集中式负载均衡器的单点问题
  3. 可扩展：支持自定义负载均衡策略
  4. 方法级别配置：可以为不同的服务方法配置不同的负载均衡策略

6.3 SpringCloud：Spring Cloud LoadBalancer ​

Spring Cloud 使用 Spring Cloud LoadBalancer 作为客户端负载均衡器。在 smart-scaffold-springcloud 中，通过引入 spring-cloud-starter-loadbalancer 依赖启用负载均衡功能。

Spring Cloud LoadBalancer 的核心策略：

1. RoundRobinLoadBalancer（轮询，默认）

按顺序依次选择服务实例，与 Dubbo 的 RoundRobin 策略类似。

2. RandomLoadBalancer（随机）

随机选择一个服务实例。

Spring Cloud 负载均衡的执行位置：

Consumer 发起 Feign 调用
    │
    ▼
从 Zookeeper 获取 Provider 实例列表（本地缓存）
    │
    ▼
Spring Cloud LoadBalancer 选择一个实例
    │
    ▼
构造 HTTP 请求，发送到目标实例

与 Dubbo 负载均衡的差异：

  1. 策略数量：Spring Cloud LoadBalancer 内置策略较少（2种），Dubbo 内置策略较多（4种）
  2. 自定义扩展：两者都支持自定义策略，但 Dubbo 的扩展接口更成熟
  3. 权重支持：Dubbo 支持基于权重的负载均衡，Spring Cloud 需要自定义实现
  4. 健康检查：Spring Cloud LoadBalancer 可以与服务健康检查集成，自动剔除不健康的实例

6.4 负载均衡策略对比 ​

维度SpringBootDubboSpringCloud
负载均衡位置外部（Nginx）客户端客户端
内置策略数N/A4种2种
默认策略N/ARandomRoundRobin
权重支持支持（Nginx）支持需自定义
健康检查支持（Nginx）支持支持
自定义扩展N/A容易容易
方法级配置N/A支持不支持
灰度发布支持（Nginx）支持（路由规则）支持（自定义）

七、ORM框架选型 ​

ORM（Object-Relational Mapping）框架是 Java 后端开发中与数据库交互的核心工具。smart-scaffold 三套项目在 ORM 框架的选型上存在有趣的差异，反映了不同架构模式对数据访问层的不同考量。

7.1 SpringBoot版：MyBatis 3.0.5 ​

smart-scaffold-springboot 使用 MyBatis 3.0.5 作为 ORM 框架。MyBatis 是一种半自动化的 ORM 框架，开发者需要手动编写 SQL 语句，同时享受对象关系映射的便利。

在 smart-scaffold-springboot 的 dao 模块中，MyBatis 的使用方式如下：

xml
<!-- pom.xml 依赖 -->
<dependency>
    <groupId>org.mybatis.spring.boot</groupId>
    <artifactId>mybatis-spring-boot-starter</artifactId>
    <version>3.0.5</version>
</dependency>

Mapper 接口定义：

java
public interface UserModelMapper {
    UserModelDTO selectByPrimaryKey(Long id);
    int insertSelective(UserModelDTO dto);
    int updateByPrimaryKeySelective(UserModelDTO dto);
    int deleteByPrimaryKey(Long id);
    List<UserModelDTO> selectByCondition(UserModelQueryDTO queryDTO);
    int selectCountByCondition(UserModelQueryDTO queryDTO);
}

对应的 XML 映射文件定义 SQL 语句：

xml
<mapper namespace="cc.bima.scaffold.dao.db1.UserModelMapper">
    <select id="selectByPrimaryKey" resultType="cc.bima.scaffold.dao.dto.db1.UserModelDTO">
        SELECT * FROM user_model WHERE id = #{id}
    </select>
    <insert id="insertSelective" parameterType="cc.bima.scaffold.dao.dto.db1.UserModelDTO">
        INSERT INTO user_model
        <trim prefix="(" suffix=")" suffixOverrides=",">
            <if test="userName != null">user_name,</if>
            <if test="status != null">status,</if>
            <if test="timeCreate != null">time_create,</if>
        </trim>
        <trim prefix="VALUES (" suffix=")" suffixOverrides=",">
            <if test="userName != null">#{userName},</if>
            <if test="status != null">#{status},</if>
            <if test="timeCreate != null">#{timeCreate},</if>
        </trim>
    </insert>
</mapper>

7.2 Dubbo版：MyBatis 3.0.5 ​

smart-scaffold-dubbo 同样使用 MyBatis 3.0.5，版本和配置与 SpringBoot 版本完全一致。在 Provider 模块的 pom.xml 中：

xml
<dependency>
    <groupId>org.mybatis.spring.boot</groupId>
    <artifactId>mybatis-spring-boot-starter</artifactId>
    <version>3.0.5</version>
</dependency>
<dependency>
    <groupId>org.mybatis</groupId>
    <artifactId>mybatis</artifactId>
    <version>3.5.14</version>
</dependency>

Dubbo 版本的数据源配置使用了 Druid 连接池：

xml
<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>druid</artifactId>
    <version>1.2.22</version>
</dependency>

7.3 SpringCloud版：MyBatis 3.0.5 + MyBatis-Plus 3.5.3.1 ​

smart-scaffold-springcloud 是唯一同时引入 MyBatis 和 MyBatis-Plus 的版本。在 Provider 模块的 pom.xml 中：

xml
<!-- MyBatis Spring Boot 启动器 -->
<dependency>
    <groupId>org.mybatis.spring.boot</groupId>
    <artifactId>mybatis-spring-boot-starter</artifactId>
    <version>3.0.5</version>
</dependency>
<!-- MyBatis 核心依赖 -->
<dependency>
    <groupId>org.mybatis</groupId>
    <artifactId>mybatis</artifactId>
    <version>3.5.14</version>
</dependency>
<!-- MyBatis-Plus 依赖 -->
<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-boot-starter</artifactId>
    <version>3.5.3.1</version>
</dependency>

值得注意的是，Spring Cloud 版本的 Provider 启动类显式排除了 MyBatis-Plus 的自动配置：

java
@EnableDiscoveryClient
@SpringBootApplication(scanBasePackages = { "cc.bima.scaffold" },
    exclude = {
        DataSourceAutoConfiguration.class,
        com.baomidou.mybatisplus.autoconfigure.MybatisPlusAutoConfiguration.class,
        com.baomidou.mybatisplus.autoconfigure.MybatisPlusLanguageDriverAutoConfiguration.class
    })
public class ProviderWebApplication {
    // ...
}

这种排除配置表明项目使用了自定义的多数据源配置，而不是依赖 MyBatis-Plus 的自动配置。MyBatis-Plus 在此项目中主要用于提供增强的 CRUD 功能（如 BaseMapper、IService），而非数据源管理。

7.4 MyBatis vs MyBatis-Plus 深度对比 ​

MyBatis 的特点：

  1. SQL 完全可控：开发者手写每一行 SQL，可以精确控制查询性能
  2. 学习曲线平缓：只需掌握 XML 映射文件和注解两种方式
  3. 灵活性极高：支持复杂的 SQL 查询、存储过程、动态 SQL
  4. 调试方便：SQL 语句清晰可见，便于性能调优

MyBatis-Plus 的增强功能：

  1. 通用 CRUD：继承 BaseMapper<T> 即可获得基本的增删改查方法，无需编写 XML
  2. 条件构造器：QueryWrapper 和 LambdaQueryWrapper 提供了类型安全的条件查询
  3. 分页插件：内置物理分页插件，自动处理分页逻辑
  4. 代码生成器：可以根据数据库表结构自动生成 Entity、Mapper、Service 代码
  5. 逻辑删除：通过 @TableLogic 注解实现逻辑删除
  6. 自动填充：通过 @TableField(fill = FieldFill.INSERT) 实现字段自动填充

性能对比：

指标MyBatisMyBatis-Plus
简单查询性能优优（几乎无差异）
复杂查询性能优（手写SQL）良（Wrapper 有一定开销）
开发效率中（需编写XML）高（通用CRUD免XML）
代码量多（XML + Mapper）少（BaseMapper）
学习成本低中
灵活性极高高（可混用原生SQL）

选型建议：

  • 如果项目以复杂查询为主，且对 SQL 性能有极致要求，选择纯 MyBatis
  • 如果项目以 CRUD 为主，且追求开发效率，选择 MyBatis-Plus
  • 如果项目两者兼有，可以混用：通用 CRUD 用 MyBatis-Plus，复杂查询用原生 MyBatis

smart-scaffold 中的多数据源配置实践：

三套项目都涉及多数据源配置（db1 和 db2），这是企业级项目中常见的需求。在 smart-scaffold 中，多数据源通过自定义配置类实现：

java
// SpringBoot 版本的多数据源配置示例
@Configuration
@MapperScan(basePackages = "cc.bima.scaffold.dao.db1",
           sqlSessionFactoryRef = "db1SqlSessionFactory")
public class SmartScaffold1Config {

    @Primary
    @Bean(name = "db1DataSource")
    @ConfigurationProperties(prefix = "spring.datasource.db1")
    public DataSource db1DataSource() {
        return DataSourceBuilder.create().build();
    }

    @Primary
    @Bean(name = "db1SqlSessionFactory")
    public SqlSessionFactory db1SqlSessionFactory(
            @Qualifier("db1DataSource") DataSource dataSource) throws Exception {
        SqlSessionFactoryBean bean = new SqlSessionFactoryBean();
        bean.setDataSource(dataSource);
        bean.setMapperLocations(
            new PathMatchingResourcePatternResolver()
                .getResources("classpath:mapper/db1/*.xml"));
        return bean.getObject();
    }
}

在 Dubbo 和 SpringCloud 版本中，类似的多数据源配置被放置在 Provider 模块的 config 包下（如 SmartScaffold1Config.java 和 SmartScaffold2Config.java），确保每个数据源对应独立的 SqlSessionFactory 和事务管理器。

MyBatis-Plus 与多数据源的兼容性：

在 smart-scaffold-springcloud 中，Provider 启动类显式排除了 MyBatis-Plus 的自动配置类：

java
@SpringBootApplication(
    exclude = {
        DataSourceAutoConfiguration.class,
        MybatisPlusAutoConfiguration.class,
        MybatisPlusLanguageDriverAutoConfiguration.class
    })

这种排除是必要的，因为 MyBatis-Plus 的自动配置会与自定义的多数据源配置产生冲突。排除后，项目可以手动控制 MyBatis-Plus 的初始化过程，确保与多数据源配置的兼容性。

ORM 框架的版本选择策略：

smart-scaffold 三套项目统一使用 MyBatis 3.0.5 版本，这是一个经过大量生产验证的稳定版本。在实际项目中，ORM 框架的版本选择应遵循以下原则：

  1. 稳定性优先：选择经过大量生产验证的版本，避免使用最新但未充分验证的版本
  2. 兼容性检查：确保 ORM 框架版本与 Spring Boot 版本兼容
  3. 安全补丁：及时关注和升级安全补丁版本
  4. 渐进升级：大版本升级应在充分测试后进行，避免在生产环境中直接升级

八、部署方案对比 ​

部署方案是架构选型的重要考量因素。不同的架构模式对部署环境、部署流程和运维工具链有着截然不同的要求。

8.1 SpringBoot：单个JAR部署 ​

SpringBoot 单体架构的部署是最简单的。整个应用打包为一个可执行 JAR 文件，通过 java -jar 命令即可启动。

在 smart-scaffold-springboot 中，最终的构建产物是 smart-scaffold-web 模块打包生成的 JAR 文件：

xml
<build>
    <finalName>smart-scaffold-web-${project.version}</finalName>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <configuration>
                <mainClass>cc.bima.scaffold.ScaffoldWebApplication</mainClass>
            </configuration>
            <executions>
                <execution>
                    <goals><goal>repackage</goal></goals>
                    <phase>package</phase>
                </execution>
            </executions>
        </plugin>
    </build>
</plugins>

部署命令：

bash
# 开发环境
java -jar smart-scaffold-web-1.0.0-SNAPSHOT.jar --spring.profiles.active=dev

# 生产环境
java -jar smart-scaffold-web-1.0.0-SNAPSHOT.jar --spring.profiles.active=prd \
    -Xms2g -Xmx2g -XX:+UseG1GC

部署特点：

  1. 单进程：只需启动一个 Java 进程
  2. 无依赖：不需要 Zookeeper 等外部依赖（数据库除外）
  3. 启动快：通常 5-15 秒即可启动完成
  4. 回滚简单：替换 JAR 文件并重启即可

8.2 Dubbo：两个JAR部署 ​

Dubbo 架构需要部署两个独立的 JAR 文件：Provider 和 Consumer。

Provider 部署：

bash
java -jar smart-scaffold-provider-1.0.0-SNAPSHOT.jar --spring.profiles.active=prd

Consumer 部署：

bash
java -jar smart-scaffold-consumer-1.0.0-SNAPSHOT.jar --spring.profiles.active=prd

部署依赖：

  • Zookeeper 集群（3 节点推荐）
  • MySQL 数据库
  • Redis（可选）
  • 其他中间件（Kafka、MongoDB 等，可选）

启动顺序：

1. 启动 Zookeeper 集群
2. 启动 Provider（等待注册到 Zookeeper 完成）
3. 启动 Consumer（等待从 Zookeeper 发现 Provider）

8.3 SpringCloud：两个JAR部署 ​

Spring Cloud 架构同样需要部署两个 JAR 文件，部署方式与 Dubbo 类似。

Provider 部署：

bash
java -jar smart-scaffold-provider-1.0.0-SNAPSHOT.jar --spring.profiles.active=prd

Consumer 部署：

bash
java -jar smart-scaffold-consumer-1.0.0-SNAPSHOT.jar --spring.profiles.active=prd

部署依赖：

  • Zookeeper（服务发现）
  • MySQL 数据库
  • Redis（可选）
  • 其他中间件（可选）

8.4 Docker多阶段构建 ​

三套项目都提供了 Dockerfile，采用多阶段构建（Multi-stage Build）来优化镜像大小。以 smart-scaffold-springboot 为例：

dockerfile
# 阶段1：构建
FROM maven:3.9.9-eclipse-temurin-17 AS builder
WORKDIR /app

# 优化 Maven 构建配置
RUN mkdir -p ~/.m2 \
    && echo "<settings>...</settings>" > ~/.m2/settings.xml

# 复制项目文件
COPY . .

# 构建：生成 Spring Boot 可执行 JAR
RUN chmod 755 ./mvnw || true \
    && (if [ -f ./mvnw ]; then ./mvnw clean package -DskipTests -T 1C; \
       else mvn clean package -DskipTests -T 1C; fi)

# 复制构建产物
RUN mkdir -p /app/build \
    && first_jar=$(ls /app/smart-scaffold-web/target/*.jar | head -n 1) \
    && cp "$first_jar" /app/build/app.jar

# 阶段2：纯运行
FROM azul/zulu-openjdk:17 AS runner
WORKDIR /docker

# 复制构建产物
COPY --from=builder /app/build/app.jar /docker/app.jar

# 复制 entrypoint.sh
COPY entrypoint.sh /docker/entrypoint.sh

# 设置权限 + 环境变量
RUN chmod +x /docker/entrypoint.sh
ENV PATH $PATH:$JAVA_HOME/bin:/docker

# 暴露端口
EXPOSE 8080

# 启动入口
ENTRYPOINT ["/docker/entrypoint.sh"]

Docker 部署对比：

维度SpringBootDubboSpringCloud
镜像数量1个2个2个
基础镜像azul/zulu-openjdk:17azul/zulu-openjdk:17azul/zulu-openjdk:17
构建阶段2阶段2阶段2阶段
镜像大小~200MB~200MB x 2~200MB x 2
Docker Compose简单需要Zookeeper需要Zookeeper

8.5 端口分配策略 ​

三套项目的端口分配策略如下：

服务SpringBootDubboSpringCloud
Web 服务8080Consumer: 8080Consumer: 8080
Provider 服务N/A80818081
Dubbo 协议端口N/A20880（默认）N/A
ZookeeperN/A21812181

在 Dubbo 版本中，Provider 的 application.yml 配置了 Web 端口为 8081：

yaml
server:
  port: 8081

Consumer 的 application.yml 配置了 Web 端口为 8080：

yaml
server:
  port: 8080

Spring Cloud 版本采用了完全相同的端口分配策略，Provider 为 8081，Consumer 为 8080。这种一致性使得三套项目可以在同一台机器上同时运行而不会产生端口冲突。

Docker Compose 部署示例：

对于 Dubbo 和 SpringCloud 架构，需要使用 Docker Compose 编排多个服务。以下是一个简化的 Docker Compose 配置示例：

yaml
# docker-compose.yml（Dubbo 版本示例）
version: '3.8'

services:
  zookeeper:
    image: zookeeper:3.9
    ports:
      - "2181:2181"
    environment:
      ZOO_MY_ID: 1
      ZOO_SERVERS: server.1=zookeeper:2888:3888

  mysql:
    image: mysql:8.0
    ports:
      - "3306:3306"
    environment:
      MYSQL_ROOT_PASSWORD: root123
    volumes:
      - mysql-data:/var/lib/mysql

  provider:
    build:
      context: .
      dockerfile: smart-scaffold-provider/Dockerfile
    ports:
      - "8081:8081"
    depends_on:
      - zookeeper
      - mysql
    environment:
      SPRING_PROFILES_ACTIVE: dev

  consumer:
    build:
      context: .
      dockerfile: smart-scaffold-consumer/Dockerfile
    ports:
      - "8080:8080"
    depends_on:
      - zookeeper
      - provider
    environment:
      SPRING_PROFILES_ACTIVE: dev

volumes:
  mysql-data:

Kubernetes 部署考量：

在 Kubernetes 环境中，三种架构模式的部署策略有所不同：

SpringBoot（单 Deployment）：

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: smart-scaffold-springboot
spec:
  replicas: 3
  selector:
    matchLabels:
      app: smart-scaffold-springboot
  template:
    spec:
      containers:
      - name: app
        image: smart-scaffold-web:1.0.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "512Mi"
            cpu: "500m"
          limits:
            memory: "2Gi"
            cpu: "2"
---
apiVersion: v1
kind: Service
metadata:
  name: smart-scaffold-springboot
spec:
  selector:
    app: smart-scaffold-springboot
  ports:
  - port: 80
    targetPort: 8080
  type: ClusterIP

Dubbo / SpringCloud（双 Deployment）：

yaml
# Provider Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: smart-scaffold-provider
spec:
  replicas: 2
  selector:
    matchLabels:
      app: smart-scaffold-provider
  template:
    spec:
      containers:
      - name: app
        image: smart-scaffold-provider:1.0.0
        ports:
        - containerPort: 8081
---
# Consumer Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: smart-scaffold-consumer
spec:
  replicas: 2
  selector:
    matchLabels:
      app: smart-scaffold-consumer
  template:
    spec:
      containers:
      - name: app
        image: smart-scaffold-consumer:1.0.0
        ports:
        - containerPort: 8080
---
# Consumer Service（对外暴露）
apiVersion: v1
kind: Service
metadata:
  name: smart-scaffold-consumer
spec:
  selector:
    app: smart-scaffold-consumer
  ports:
  - port: 80
    targetPort: 8080
  type: LoadBalancer

Kubernetes 部署的关键差异：

  1. Pod 数量：SpringBoot 只需一种 Pod，Dubbo/SpringCloud 需要两种 Pod
  2. 独立扩缩容：Dubbo/SpringCloud 可以对 Provider 和 Consumer 独立进行水平扩缩容
  3. 资源分配：Dubbo/SpringCloud 的 Provider 通常需要更多内存（数据库连接池），Consumer 需要更多 CPU（HTTP 请求处理）
  4. 健康检查：Dubbo/SpringCloud 需要配置更复杂的健康检查（依赖 Zookeeper 连通性）
  5. 滚动更新策略：Dubbo/SpringCloud 需要确保 Provider 先于 Consumer 更新，避免服务不可用

九、代码复用与差异分析 ​

smart-scaffold 三套项目实现了相同的业务功能，因此它们之间存在大量的代码复用。分析这些复用和差异，有助于理解三种架构模式对代码组织的影响。

9.1 三个项目共享的业务逻辑 ​

尽管架构模式不同，三套项目的核心业务逻辑高度一致。以下是在三个项目中都存在的核心功能：

  1. 用户模型管理（CRUD）：用户模型的增删改查、分页查询、条件查询
  2. 部门信息管理（CRUD）：部门信息的增删改查、分页查询
  3. 中间件集成：Redis、MongoDB、Kafka、RabbitMQ、RocketMQ、Elasticsearch
  4. AI 服务集成：Spring AI、Ollama、OpenAI 兼容接口
  5. OAuth2 认证：CAS OAuth2 集成
  6. 通用返回结果：ApiResult / BaseResult 统一返回格式
  7. 分页功能：PageDTO / PageEntity 分页封装
  8. 异常处理：GlobalExceptionHandler 全局异常处理
  9. 请求日志：RequestLoggingInterceptor 请求日志拦截器

9.2 SpringBoot版代码复用方式 ​

SpringBoot 版本通过 Maven 模块依赖实现代码复用。所有模块在同一个 Maven 工程中，模块间的依赖关系为单向链式：

web ──> service ──> dao ──> common

Controller 直接注入 Service 实现类，Service 直接注入 Mapper 接口。代码复用的粒度为方法级别，同一个 Service 方法可以被多个 Controller 调用。

代码示例对比（用户模型列表查询）：

java
// Controller 层
@PostMapping({ "/list/page" })
public BaseResult<?> listPage(...) {
    queryDTO.setFields("id");
    queryDTO.setOrder("desc");
    PageEntity<UserModelDTO> userDTOs = userModelService.selectPageBy(queryDTO);
    return BaseResult.success(userDTOs);
}

9.3 Dubbo版代码复用方式 ​

Dubbo 版本通过 API 模块实现代码复用。API 模块作为独立的 JAR 包，被 Provider 和 Consumer 同时引用。

代码复用结构：

┌─────────────────────────────────────────────┐
│              smart-scaffold-api              │
│  ┌─────────┐ ┌─────────┐ ┌───────────────┐ │
│  │ face/   │ │ dto/    │ │ service/      │ │
│  │ 接口定义│ │ 数据传输│ │ ApiResult等  │ │
│  └─────────┘ └─────────┘ └───────────────┘ │
└──────────────┬──────────────┬───────────────┘
               │              │
     ┌─────────▼──────┐ ┌────▼───────────┐
     │   Provider     │ │   Consumer     │
     │  实现接口       │ │  引用接口       │
     │  数据访问       │ │  HTTP 接口      │
     └────────────────┘ └────────────────┘

Consumer 端的 Controller 代码与 SpringBoot 版本高度相似：

java
// Dubbo Consumer Controller
@PostMapping({ "/list/page" })
public ApiResult<?> listPage(...) {
    queryDTO.setFields("id");
    queryDTO.setOrder("desc");
    Object userDTOs = mybatisUserModelService.selectPageBy(queryDTO);
    return ApiResult.success(userDTOs);
}

关键差异：

  1. Service 注入方式从 @Autowired 变为 @DubboReference
  2. 返回值类型从 BaseResult 变为 ApiResult
  3. Service 方法签名遵循 API 模块中定义的接口

9.4 SpringCloud版代码复用方式 ​

Spring Cloud 版本通过 Common 模块实现代码复用。Common 模块提供共享的 DTO、Entity 和工具类。

代码复用结构：

┌─────────────────────────────────────────────┐
│            smart-scaffold-common            │
│  ┌─────────┐ ┌─────────┐ ┌───────────────┐ │
│  │ dto/    │ │ entity/ │ │ service/      │ │
│  │ 数据传输│ │ 实体类  │ │ ApiResult等  │ │
│  └─────────┘ └─────────┘ └───────────────┘ │
└──────────────┬──────────────┬───────────────┘
               │              │
     ┌─────────▼──────┐ ┌────▼───────────┐
     │   Provider     │ │   Consumer     │
     │  REST端点      │ │  Feign客户端   │
     │  业务逻辑      │ │  HTTP 接口     │
     └────────────────┘ └────────────────┘

Consumer 端的 Controller 代码：

java
// SpringCloud Consumer Controller
@PostMapping({ "/list/page" })
public ApiResult<?> listPage(...) {
    queryDTO.setFields("id");
    queryDTO.setOrder("desc");
    return userModelService.listPage(userId, userName, queryDTO);
}

关键差异：

  1. Service 注入方式为 @Autowired，注入的是 Feign 客户端代理
  2. Controller 方法直接透传调用 Feign 客户端，不做额外处理
  3. Feign 客户端接口定义了 HTTP 路径映射

9.5 代码量与复杂度对比 ​

维度SpringBootDubboSpringCloud
总模块数433
总 Java 文件数~30~45~50
配置文件数4 (yml)8 (yml)8 (yml)
Dockerfile 数122
启动类数122
接口定义文件0（直接引用）1（face包）1（Feign接口）
代码重复度低中（Controller相似）中（Controller相似）
新增业务复杂度低中中-高

核心发现：

  1. Controller 层代码高度相似：三个项目的 Controller 代码结构几乎完全一致，差异仅在于 Service 注入方式和返回值类型
  2. Service 层代码差异最大：SpringBoot 的 Service 直接操作数据库，Dubbo 的 Service 通过 RPC 暴露，SpringCloud 的 Service 通过 REST 暴露
  3. 公共代码占比高：约 60-70% 的业务逻辑代码在三个项目中是相同或高度相似的
  4. 架构相关代码占比低：仅有 10-15% 的代码与具体的架构模式相关（如注解、配置等）

中间件集成代码的分布差异：

三套项目都集成了丰富的中间件（Redis、MongoDB、Kafka、RabbitMQ、RocketMQ、Elasticsearch），但中间件代码的分布位置存在显著差异：

中间件SpringBootDubboSpringCloud
Redisservice 模块provider 模块provider 模块
MongoDBservice 模块provider 模块provider 模块
Kafkaservice 模块provider 模块provider 模块
RabbitMQservice 模块provider 模块provider 模块
RocketMQservice 模块provider 模块provider 模块
Elasticsearchservice 模块provider 模块provider 模块

在 SpringBoot 版本中，所有中间件的集成代码集中在 service 模块，Controller 直接调用对应的 Service。在 Dubbo 和 SpringCloud 版本中，中间件集成代码集中在 provider 模块，Consumer 端通过 RPC/HTTP 间接调用。

这意味着：

  1. 在 Dubbo/SpringCloud 架构中，如果 Consumer 需要直接使用某个中间件（如 Redis 缓存），需要在 Consumer 模块中单独引入依赖和配置
  2. 中间件的使用模式在三种架构中基本一致，架构迁移时中间件代码的改动量最小
  3. 中间件的连接配置（如 Redis 地址、Kafka 地址）在分布式架构中需要确保 Provider 和 Consumer 的一致性

统一返回结果封装的对比：

三套项目都实现了统一的返回结果封装，但类名和包路径有所不同：

  • SpringBoot：BaseResult（位于 common 模块）
  • Dubbo：ApiResult（位于 api 模块的 cc.bima.scaffold.api.service 包）
  • SpringCloud：ApiResult（位于 common 模块的 cc.bima.scaffold.common.service 包）

Dubbo 和 SpringCloud 版本的 ApiResult 代码几乎完全一致，都包含以下核心方法：

java
// 成功返回
public static <T> ApiResult<T> success(T data)
public static <T> ApiResult<T> success(String msg, T data)
public static ApiResult<?> success()

// 失败返回
public static <T> ApiResult<T> fail(String msg)
public static <T> ApiResult<T> fail(Integer code, String message)

// 分页返回
public static ApiResult<?> successPage(Map<String, ?> pageMap, List<?> list)

这种高度的一致性验证了一个重要的架构原则：业务逻辑代码应该与架构模式解耦。良好的代码抽象可以使架构迁移的成本降到最低。

十、性能、复杂度、运维成本量化对比 ​

本节将从开发效率、部署复杂度、运维成本、团队要求和扩展性五个维度，对三种架构模式进行量化对比。

10.1 开发效率对比 ​

开发效率评估指标：

指标SpringBootDubboSpringCloud
项目初始化时间0.5天1天1-2天
新增一个CRUD模块2小时3-4小时3-4小时
本地调试启动时间10秒20秒（两个进程）25秒（两个进程+Zookeeper）
代码热重载支持（spring-devtools）部分支持部分支持
IDE 代码跳转无缝跳转跨模块跳转跨模块跳转
单元测试编写简单中等（需Mock远程服务）中等（需Mock Feign）
集成测试编写简单复杂（需启动多进程）复杂（需启动多进程+Zookeeper）

新增一个 CRUD 模块的工作量对比：

以新增一个"商品管理"模块为例：

SpringBoot（约 2 小时）：

  1. 在 common 模块添加 Entity 和 DTO（20 分钟）
  2. 在 dao 模块添加 Mapper 接口和 XML（30 分钟）
  3. 在 service 模块添加 Service 实现类（30 分钟）
  4. 在 web 模块添加 Controller（20 分钟）
  5. 测试和调试（20 分钟）

Dubbo（约 3.5 小时）：

  1. 在 api 模块添加接口定义和 DTO（30 分钟）
  2. 在 provider 模块添加 Service 实现（30 分钟）
  3. 在 provider 模块添加 Mapper 和 XML（30 分钟）
  4. 在 consumer 模块添加 Controller（30 分钟）
  5. 配置 Dubbo 服务注册（10 分钟）
  6. 测试和调试（50 分钟，需要启动两个进程和 Zookeeper）

SpringCloud（约 4 小时）：

  1. 在 common 模块添加 DTO 和 Entity（20 分钟）
  2. 在 provider 模块添加 Service 实现（30 分钟）
  3. 在 provider 模块添加 Mapper 和 XML（30 分钟）
  4. 在 provider 模块添加 REST Controller（30 分钟）
  5. 在 consumer 模块添加 Feign 客户端接口（30 分钟）
  6. 在 consumer 模块添加 Controller（20 分钟）
  7. 配置 Zookeeper 服务发现（10 分钟）
  8. 测试和调试（50 分钟）

10.2 部署复杂度对比 ​

指标SpringBootDubboSpringCloud
部署产物数量1个JAR2个JAR2个JAR
外部依赖数量1（数据库）2+（数据库+Zookeeper）2+（数据库+Zookeeper）
部署脚本复杂度低中中
启动顺序要求无有（ZK > Provider > Consumer）有（ZK > Provider > Consumer）
滚动更新复杂度低中中
蓝绿部署简单中等中等
Docker Compose1个service3个service3个service
K8s 部署1个Deployment2个Deployment + 1个Service2个Deployment + 1个Service

10.3 运维成本对比 ​

指标SpringBootDubboSpringCloud
监控指标数量少（JVM+应用）中（+Dubbo指标）多（+SC指标+HTTP指标）
日志收集简单（单进程）中等（多进程）中等（多进程）
链路追踪不需要需要（Dubbo Filter）需要（Sleuth+Zipkin）
故障排查简单中等复杂
扩缩容整体扩缩容Provider/Consumer独立扩缩容Provider/Consumer独立扩缩容
日常运维人力0.5人1人1-2人
告警配置少中多

10.4 团队要求对比 ​

指标SpringBootDubboSpringCloud
最低团队规模1人2-3人3-5人
推荐团队规模1-5人5-15人10-30人
技术栈要求SpringBoot基础+Dubbo+Zookeeper+SpringCloud+Zookeeper
DevOps 要求基础中级高级
架构设计能力低中高
新人上手时间1周2周3周

10.5 扩展性对比 ​

指标SpringBootDubboSpringCloud
水平扩展粒度整体Provider/Consumer独立Provider/Consumer独立
新增服务类型新增模块新增API+Provider新增Common+Provider+Consumer
多语言支持不支持有限（需Dubbo客户端）良好（HTTP REST）
跨团队协作困难中等良好
技术异构不支持有限良好
服务粒度调整困难中等良好

10.6 综合评分矩阵 ​

以下评分基于 1-10 分制，10 分为最优：

维度权重SpringBootDubboSpringCloud
开发效率20%976
部署简单性15%966
运维成本15%965
通信性能15%1086
扩展性15%379
通用性10%559
团队友好度10%965
加权总分100%7.856.556.45

解读：

  • SpringBoot 在小规模场景下综合得分最高，开发效率、部署简单性和运维成本三项优势明显
  • Dubbo 在性能和扩展性之间取得了良好平衡，适合对性能有要求的中大型项目
  • SpringCloud 在扩展性和通用性方面领先，但开发和运维成本较高，适合大型分布式系统

评分的动态变化：

需要特别指出的是，上述评分是基于"当前时间点"的静态评估。随着业务规模的增长，各维度的权重和得分会发生动态变化：

业务初期（1-10人团队，日活<1万）：
  开发效率权重增加 → SpringBoot 优势放大
  扩展性权重降低 → SpringCloud 优势缩小

业务中期（10-50人团队，日活1-100万）：
  性能权重增加 → Dubbo 优势显现
  运维成本权重增加 → SpringBoot 优势保持

业务成熟期（50+人团队，日活>100万）：
  扩展性权重增加 → SpringCloud 优势放大
  通用性权重增加 → SpringCloud 优势放大
  团队友好度权重降低 → SpringBoot 优势缩小

因此，架构选型不是一次性的决策，而是需要随着业务发展持续评估和调整的动态过程。

成本效益分析：

从经济角度分析三种架构模式的成本效益：

成本项SpringBoot（月）Dubbo（月）SpringCloud（月）
服务器成本1台 x 4核8G = ~200元3台 x 4核8G = ~600元3台 x 4核8G = ~600元
Zookeeper 集群不需要3台 x 2核4G = ~300元3台 x 2核4G = ~300元
监控基础设施基础 = ~100元中等 = ~300元完整 = ~500元
人力运维成本0.5人 = ~5000元1人 = ~10000元1.5人 = ~15000元
月总成本（估算）~5300元~11200元~16400元

注：以上成本为估算值，实际成本取决于云服务商、地域、配置等因素。人力成本按初级运维工程师月薪 10000 元估算。

从成本效益角度看，SpringBoot 的总拥有成本（TCO）最低，约为 Dubbo 的 47%，SpringCloud 的 32%。这也是为什么在项目初期，选择 SpringBoot 单体架构是最经济的选择。

十一、架构选型决策树 ​

经过前面十个维度的深度对比，本节将给出实用的架构选型决策指南。架构选型没有绝对的对错，关键在于匹配业务规模、团队规模和技术栈。

11.1 根据业务规模选择 ​

小型项目（日活 < 1万，数据量 < 100万条）

推荐：SpringBoot 单体架构

选择理由：
- 开发效率最高，1-2人团队即可快速交付
- 部署运维成本最低，1台服务器即可运行
- 性能足够应对，单实例可支撑数千 QPS
- 技术栈简单，新人上手快

典型场景：
- 企业内部管理系统
- 创业项目 MVP
- 个人博客/社区
- 小型电商后台

中型项目（日活 1-100万，数据量 100万-1亿条）

推荐：Dubbo RPC 架构

选择理由：
- Provider/Consumer 分离，支持独立扩展
- RPC 通信性能优异，适合高频内部调用
- 内置服务治理能力，运维可控
- 从单体迁移成本相对较低

典型场景：
- 中型电商平台
- SaaS 平台
- 金融交易系统
- 物联网平台

大型项目（日活 > 100万，数据量 > 1亿条）

推荐：Spring Cloud 微服务架构

选择理由：
- 服务粒度细，支持独立部署和扩展
- HTTP REST 通用性强，支持多语言微服务
- 生态丰富，组件齐全
- 适合多团队协作开发

典型场景：
- 大型互联网平台
- 跨国企业应用
- 微服务矩阵（10+个服务）
- 需要跨语言调用的系统

11.2 根据团队规模选择 ​

┌─────────────────────────────────────────────────────────────┐
│                     团队规模决策矩阵                         │
├──────────────┬──────────────────┬───────────────────────────┤
│   团队规模    │   推荐架构        │   理由                    │
├──────────────┼──────────────────┼───────────────────────────┤
│ 1-3人        │ SpringBoot       │ 沟通成本低，无需服务治理    │
│ 3-8人        │ SpringBoot       │ 代码库统一，协作效率高      │
│              │ 或 Dubbo         │ （如果性能有要求）          │
│ 8-20人       │ Dubbo            │ 服务拆分，减少代码冲突      │
│              │                  │ RPC性能满足内部调用需求      │
│ 20-50人      │ Dubbo            │ 多团队并行开发              │
│              │ 或 SpringCloud   │ （如果需要跨语言）          │
│ 50人+        │ SpringCloud      │ 服务粒度细，团队自治        │
│              │                  │ 生态完善，治理能力强        │
└──────────────┴──────────────────┴───────────────────────────┘

11.3 根据技术栈选择 ​

┌─────────────────────────────────────────────────────────────┐
│                     技术栈决策矩阵                           │
├──────────────────┬──────────────────────────────────────────┤
│   技术特征        │   推荐架构                               │
├──────────────────┼──────────────────────────────────────────┤
│ 纯 Java 技术栈    │ SpringBoot 或 Dubbo                     │
│ 需要跨语言调用    │ SpringCloud（HTTP REST 天然支持）         │
│ 高频内部服务调用  │ Dubbo（RPC 性能优势）                     │
│ 对外 API 服务    │ SpringCloud（HTTP REST 标准化）           │
│ 需要 gRPC        │ SpringCloud + gRPC                       │
│ 已有 Dubbo 生态  │ 继续使用 Dubbo                            │
│ 已有 Spring 生态 │ SpringCloud（平滑升级）                   │
│ 需要 AI/ML 集成  │ SpringCloud（Python 微服务 + Java 网关）  │
└──────────────────┴──────────────────────────────────────────┘

11.4 演进路径建议 ​

路径一：SpringBoot → Dubbo（推荐）

这是最自然的演进路径，适合大多数 Java 技术栈的团队：

阶段1：SpringBoot 单体
  │
  │  业务增长，模块增多
  ▼
阶段2：SpringBoot + Maven 多模块
  │  （按技术层拆分：common/dao/service/web）
  │
  │  性能瓶颈，需要独立扩展
  ▼
阶段3：抽取 API 模块
  │  （将 Service 接口抽取到独立的 API 模块）
  │
  │  团队扩大，需要服务拆分
  ▼
阶段4：引入 Dubbo
     （Provider 实现 API 接口，Consumer 通过 RPC 调用）

路径二：SpringBoot → SpringCloud

适合需要跨语言或已经使用 Spring 生态的团队：

阶段1：SpringBoot 单体
  │
  │  业务增长
  ▼
阶段2：SpringBoot + Maven 多模块
  │
  │  需要微服务化 + 跨语言
  ▼
阶段3：抽取 Common 模块
  │  （DTO、Entity 抽取到 Common 模块）
  │
  │  服务拆分
  ▼
阶段4：引入 SpringCloud
     （Provider 暴露 REST，Consumer 通过 Feign 调用）

路径三：Dubbo → SpringCloud

适合需要从 Java 生态扩展到多语言生态的团队：

阶段1：Dubbo RPC 架构
  │
  │  需要引入非 Java 服务
  ▼
阶段2：Dubbo + SpringCloud 混合
  │  （核心链路用 Dubbo，边缘服务用 SpringCloud）
  │
  │  全面微服务化
  ▼
阶段3：全面迁移到 SpringCloud
     （或保持混合架构）

演进的核心原则：

  1. 不要过早微服务化：在业务模式验证之前，单体架构是最快验证假设的方式
  2. 渐进式演进：不要一次性重写，而是逐步拆分，确保每个阶段系统都可运行
  3. 保持接口兼容：在拆分过程中，保持 API 接口的向后兼容性
  4. 基础设施先行：在引入分布式架构之前，先建立监控、日志、链路追踪等基础设施

常见架构选型误区：

在实际项目中，以下是一些常见的架构选型误区，需要特别注意：

误区一：微服务一定比单体好

很多团队在项目初期就选择了微服务架构，认为这样可以"面向未来"。然而，过早微服务化会带来以下问题：

  • 开发效率大幅下降：一个简单的功能需要修改多个服务的代码
  • 测试复杂度增加：需要启动多个服务才能进行集成测试
  • 运维成本飙升：需要维护服务注册中心、配置中心、链路追踪等基础设施
  • 团队精力分散：过多的精力花在服务治理上，而非业务开发

正确做法：从单体开始，在业务验证成功后再考虑微服务化。

误区二：Dubbo 和 SpringCloud 只能选其一

实际上，Dubbo 和 SpringCloud 可以混合使用。很多大型企业采用以下混合架构：

  • 核心交易链路使用 Dubbo RPC（高性能）
  • 对外 API 使用 Spring Cloud Gateway（通用性）
  • 内部管理后台使用 SpringBoot 单体（开发效率）
  • 数据分析服务使用 Python + HTTP（跨语言）

误区三：忽略数据架构的影响

架构选型不仅仅是服务拆分，还涉及数据架构的调整：

  • 数据库拆分：单体架构使用一个数据库，分布式架构需要考虑分库分表
  • 事务一致性：从本地事务到分布式事务，需要引入 Seata 等框架
  • 数据同步：不同服务可能需要访问不同的数据库，数据同步成为新的挑战
  • 缓存策略：分布式环境下的缓存一致性比单体环境复杂得多

误区四：忽视监控和可观测性

从单体迁移到分布式架构后，监控和可观测性变得至关重要：

  • 日志聚合：多进程环境需要集中式日志收集（如 ELK）
  • 链路追踪：分布式调用链路需要 TraceID 串联（如 Zipkin、SkyWalking）
  • 指标监控：需要监控每个服务的 JVM 指标、Dubbo/HTTP 调用指标
  • 告警体系：需要建立完善的告警规则和通知机制

误区五：盲目追求新技术

有些团队在架构选型时倾向于选择最新的技术方案，如 gRPC、Service Mesh、Serverless 等。然而，新技术的成熟度、社区支持和团队学习成本都是需要考虑的因素。smart-scaffold 项目选择 Dubbo 3.2.0 和 Spring Cloud 2025.0.0，都是在充分验证后的稳定版本选择。

总结 ​

通过对 smart-scaffold 三套真实项目的全方位深度对比，我们可以得出以下核心结论：

1. 没有银弹，只有合适的选择

三种架构模式各有优劣，不存在"最好的架构"，只有"最适合当前阶段的架构"。SpringBoot 单体架构在开发效率和运维成本方面具有显著优势；Dubbo RPC 架构在性能和扩展性之间取得了良好平衡；Spring Cloud 微服务架构在扩展性和通用性方面领先。

2. 架构演进的成本远高于预期

从 smart-scaffold 三套项目的代码对比可以看出，从单体架构迁移到分布式架构，不仅仅是技术框架的切换，更是代码组织方式、团队协作模式、运维体系的全面变革。因此，不要为了微服务而微服务，应该在业务真正需要时再进行架构演进。

3. 代码复用率高于预期

三套项目中约 60-70% 的业务逻辑代码是相同或高度相似的，差异主要集中在接口定义方式、服务注解和配置文件上。这意味着，如果建立了良好的代码抽象，架构迁移的成本可以大幅降低。

4. 技术选型的关键决策因子

在实际项目中，架构选型应该综合考虑以下因素（按重要性排序）：

  1. 业务规模和增长预期（最关键）
  2. 团队规模和技术能力
  3. 性能要求
  4. 运维能力
  5. 技术栈约束

5. 混合架构是未来的趋势

在大型企业中，纯单一架构模式越来越少见。更多的情况是：核心交易链路使用 Dubbo RPC 保证性能，对外 API 网关使用 Spring Cloud 保证通用性，内部管理后台使用 SpringBoot 单体保证开发效率。理解每种架构模式的优劣，才能在实际项目中做出最优的技术决策。

版权声明： 本文为必码（bima.cc）原创技术文章，仅供学习交流。

本文内容基于实际项目源码解析整理，代码示例均为教学简化版本，仅供学习参考。

文档内容提取自项目源码与配置文件，如需获取完整项目代码，请访问 bima.cc。

© 2024-至今 北京必码科技工作室 bima.cc