最近在帮学弟学妹们看毕设，发现很多同学对微服务项目既向往又头疼。向往的是它的技术光环和简历加分，头疼的是不知从何下手，网上资料要么太散，要么太深。今天我就结合自己踩过的坑，梳理一份从零搭建微服务毕设的“保姆级”指南，目标是让你能跑通一个结构清晰、五脏俱全的微服务项目，而不是只停留在理论。

1. 新手入门，先避开这几个“天坑”

很多同学一上来就想着把单体项目硬拆成微服务，结果往往是：

• “为微服务而微服务”：一个简单的图书管理系统，硬拆出用户、图书、借阅、日志四个服务，结果服务间调用比业务逻辑还复杂，本地调试像走迷宫。
• “依赖地狱”：Spring Cloud 组件版本和 Spring Boot 版本对不上，一启动就报各种 ClassNotFoundException，半天时间都花在解决依赖冲突上。
• “纸上谈兵”：只关注服务怎么拆，不考虑怎么联调、怎么部署、出了问题怎么查日志，导致演示时手忙脚乱。

我的建议是：毕设的核心是证明你掌握了技术栈和设计思想，而不是追求服务的数量。一个包含2-3个核心服务（例如用户服务和订单服务）的、能完整演示注册、发现、调用、配置管理的项目，远比一个庞大但跑不起来的项目更有说服力。

2. 技术栈怎么选？Spring Cloud 是新手友好之选

目前主流的微服务框架有 Spring Cloud 和 Apache Dubbo。对于毕设来说，我强烈推荐 Spring Cloud，原因很简单：

• 生态完整：Spring Cloud 提供了一站式解决方案，服务发现（Eureka/Nacos）、配置中心（Config/Nacos）、网关（Gateway）、负载均衡（Ribbon/LoadBalancer）等组件开箱即用，且与 Spring Boot 无缝集成。
• 学习资源丰富：作为 Java 领域的事实标准，社区活跃，遇到任何问题几乎都能找到解决方案或类似案例。
• 易于上手：基于注解和约定大于配置的理念，可以让你快速搭建出可运行的原型。

这里给出一个我验证过的、版本兼容性好的技术栈组合，能有效避免依赖冲突：

• Spring Boot: 2.7.18 (这是一个长期支持版本，非常稳定)
• Spring Cloud: 2021.0.8 (与 Boot 2.7.x 兼容的版本)
• 注册与配置中心: Nacos 2.2.3
• 服务调用: OpenFeign
• 网关: Spring Cloud Gateway
• 数据库: MySQL 8.0 + MyBatis-Plus

3. 手把手搭建最小可行架构 (MVA)

我们目标是先跑起来。假设我们做一个简易的电商场景，包含 user-service 和 order-service。

第一步：搭建父工程与公共模块

1. 创建一个 Maven 父工程，例如 microservice-demo。它的 pom.xml 主要做两件事：定义统一的依赖管理（<dependencyManagement>）和所有子模块共享的依赖（如 Lombok、Spring Boot Starter）。
2. 创建一个 common 模块，存放通用的工具类、常量、统一返回结果对象（如 Result<T>）和异常定义。这样其他服务模块直接依赖 common 即可。

第二步：引入 Nacos 作为服务注册与配置中心

为什么用 Nacos？因为它同时具备了服务注册发现和配置管理功能，一个组件解决两个问题，非常适合毕设这种轻量级场景。

1. 在 user-service 和 order-service 的 pom.xml 中引入 spring-cloud-starter-alibaba-nacos-discovery 和 spring-cloud-starter-alibaba-nacos-config。
2. 在 bootstrap.yml (注意不是 application.yml) 中配置 Nacos 服务器地址和应用名。

# user-service 的 bootstrap.yml
spring:
  application:
    name: user-service # 服务名，非常重要！
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848 # Nacos 服务器地址
      config:
        server-addr: localhost:8848
        file-extension: yaml # 配置格式

3. 在启动类上添加 @EnableDiscoveryClient 注解。
4. 启动 Nacos Server（从官网下载，bin 目录下 startup.cmd 或 startup.sh），然后启动你的服务，就能在 Nacos 控制台（http://localhost:8848/nacos）看到注册上去的服务了。

上图：服务成功注册到 Nacos，健康状态为 UP。

第三步：使用 OpenFeign 实现服务间调用

假设订单服务需要查询用户信息。

1. 在调用方（order-service）的 pom.xml 中引入 spring-cloud-starter-openfeign。
2. 在 order-service 的启动类上添加 @EnableFeignClients 注解。
3. 创建一个 Feign 客户端接口。

// 在 order-service 中创建
@FeignClient(name = "user-service") // name 对应服务提供方的 spring.application.name
public interface UserFeignClient {

    @GetMapping("/user/{id}") // 这里写的是 user-service 中真实接口的路径
    Result<UserDTO> getUserById(@PathVariable("id") Long userId);
}

4. 在 order-service 的业务代码中，像调用本地方法一样注入并使用 UserFeignClient。
5. 在被调用方（user-service）中，正常编写一个 UserController，暴露 /user/{id} 接口即可。

Feign 默认集成了 Ribbon（负载均衡）和 Hystrix（熔断，2021版本后需单独引入），你无需额外编码，就能实现对一个服务的多个实例的调用。

4. 本地调试与 Docker 部署的“丝滑”过渡

本地调试：

• 利用 IDEA 的 Run/Debug Configurations，可以很方便地启动多个服务实例。
• 调试时，善用网关。将 Spring Cloud Gateway 也启动起来，所有请求通过网关转发（如 localhost:9000/order/xxx 转发到 order-service）。这样能模拟真实的路由场景，也便于统一做鉴权、限流（后续可以加）。

Docker 部署（简化版）： 对于毕设演示，可以不用 K8s，直接用 Docker Compose 一键拉起所有环境。

1. 为每个服务编写 Dockerfile，基于 openjdk:8-jre-slim 镜像，将打好的 Jar 包复制进去。
2. 编写 docker-compose.yml，定义 nacos、mysql、user-service、order-service 等服务。
3. 关键点：在 Compose 文件中，服务间通信使用服务名作为 hostname（如 user-service 访问 mysql 的地址就是 mysql:3306），这与 Nacos 的服务发现理念一致。
4. 运行 docker-compose up -d，整个微服务集群就启动了。

5. 别忘了性能与安全的基础项

毕设答辩老师可能会问：“你的服务挂了怎么办？接口重复调用怎么办？” 提前准备：

• 超时与重试：在 Feign 配置中设置 connectTimeout 和 readTimeout，并可以配置重试策略，避免因网络抖动导致失败。
• 接口幂等性：对于创建订单等操作，可以通过 Token 机制（前端提交前先获取一个 token，服务端校验）或数据库唯一约束（如订单号）来防止重复提交。
• 基础鉴权：可以在网关层通过 Filter 校验一个简单的 JWT Token，判断用户是否登录。这一步不需要太复杂，能体现安全意识即可。

6. 生产环境思维：提前想好这些坑

虽然毕设可能不上生产，但拥有生产环境思维是加分项。

• 服务雪崩与熔断降级：引入 Resilience4j 或 Sentinel，为 Feign 调用配置熔断器。当 user-service 不可用时，order-service 可以快速失败或返回一个兜底数据（如默认用户信息），而不是一直等待导致自身线程池耗尽。
• 配置隔离：在 Nacos 中，可以为 dev、test、prod 不同环境创建不同的命名空间（Namespace）或配置分组（Group），实现配置的隔离管理。
• 日志追踪：一个请求穿过网关、订单服务、用户服务，怎么串联日志？引入 Spring Cloud Sleuth 并集成 Zipkin 或 SkyWalking，可以自动为请求注入 TraceId，在日志文件中打印出来，方便排查问题。
• API 文档：使用 SpringDoc OpenAPI（Swagger 3）为每个服务的接口生成在线文档，并配置统一的网关聚合文档地址，方便前端和答辩演示。

上图：通过调用链追踪，可以清晰看到一个请求在不同微服务间的流转路径和耗时。

最后，动手与思考

最好的学习方式是动手。你不妨就从今天提到的 用户-订单 基础场景开始：

1. 用上文的技术栈，搭建一个两服务的空架子，让它们能在 Nacos 中互相发现。
2. 实现一个简单接口：创建订单时，通过 Feign 调用用户服务，验证用户是否存在。
3. 把整个项目用 Docker Compose 跑起来。

做完这些，再深入思考一个问题：服务到底该怎么拆？ 是按业务功能（用户、订单、商品），还是按读写分离（订单写服务、订单读服务）？这没有标准答案，但你可以从“高内聚、低耦合”、“团队结构”、“变更频率”这几个维度在毕设文档中阐述你的设计理由，这能极大体现你的架构思考能力。

微服务不是银弹，对于毕业设计，清晰、可运行、体现了核心概念和良好工程规范的项目，远比一个庞大而脆弱的系统更有价值。希望这篇指南能帮你扫清入门障碍，把精力更多放在业务逻辑和设计思想的实现上。祝你毕设顺利！