想学微服务做期末项目？这套实战方案请收好

一、期末项目选题：先用三个标准过滤

每到学期末，后端方向的同学常会遇到同一个问题：课程设计选题要么太简单，一个“增删改查管理系统”撑不起技术含量；要么太宏大，微服务、分布式全上，最后烂尾收场。建议先用三个标准过滤选题：

1. 技术覆盖度：能自然覆盖 HTTP 与 RESTful 接口设计、登录鉴权、数据库建模、缓存、消息队列、日志等主干知识点，而不是为了堆技术而堆技术；
2. 可演示性：答辩现场能完整跑通“登录 → 核心业务操作 → 结果反馈”的主链路，评委看得见效果；
3. 工作量可控：以 3～6 周课余时间为限，模块可以拆分给小组成员，也可以在时间紧张时按优先级裁剪。

按这套标准，“微服务架构的业务系统”是性价比很高的选题。它把一个完整系统拆成多个职责单一的小服务，每个服务代码量不大、便于分工，又能集中展示注册发现、网关鉴权、异步解耦等架构能力——即使个别旁路模块没做完，主链路依然可以完整演示。

二、总体架构：一个统一入口 + 十个独立服务

推荐的工程结构可以概括为“1 + 9”：网关服务固定占用 8080 端口，作为所有外部请求的唯一入口；其余服务从 8081 开始依次编排端口，各自独立启动、独立打包部署。以“校园课程平台”为例（换成在线商城、社区博客等选题，思路完全一致），模块划分如下：

• 网关服务（8080）：统一入口，负责 JWT 鉴权过滤、跨域（CORS）处理、请求日志记录、统一响应格式化；
• 用户服务：注册、登录、个人信息维护、角色与权限；
• 核心业务服务 A/B/C：对应选题的核心领域，例如课程管理、选课、课表；
• 消息通知服务：站内信、邮件等异步通知；
• 文件服务：头像与附件上传，底层可对接对象存储这类通用云产品；
• 搜索服务：关键词检索，初期用数据库全文索引即可；
• 调度服务：定时任务，如每日数据汇总、超时订单关闭；
• 统计服务：行为埋点采集与报表聚合。

这样拆分有三点好处：一是职责单一，便于多人协作；二是故障隔离，通知服务异常不影响下单主流程；三是答辩时“为什么这样拆、边界在哪里”本身就是体现架构思考的加分项。

三、四个值得深挖并写进报告的技术点

3.1 网关层：让所有请求先过一道闸

不要把鉴权逻辑散落在每个业务服务里，而是收敛到网关统一处理。网关核心过滤器的逻辑可以这样组织（示意代码）：

// 网关统一鉴权（示意）
public GatewayResponse preCheck(Request request) {
    String token = request.getHeader("Authorization");
    if (token == null || !token.startsWith("Bearer ")) {
        return GatewayResponse.error(401, "缺少访问凭证");
    }
    try {
        Map<String, Object> payload = JwtUtil.verify(token.substring(7), secretKey);
        // 校验通过后，把用户身份透传给下游服务，业务代码无需重复解析
        request.addHeader("X-User-Id", String.valueOf(payload.get("uid")));
        return GatewayResponse.pass(request);
    } catch (TokenExpiredException e) {
        return GatewayResponse.error(401, "登录已过期，请重新登录");
    }
}

登录成功后由用户服务签发令牌，载荷中放入用户标识、角色与过期时间，签名密钥只在网关与用户服务之间共享。跨域、请求日志、统一响应格式也都在网关以过滤器链的方式实现，业务服务专注业务本身。

3.2 注册中心：服务之间如何互相找到对方

拆成多个服务后，“调用方如何知道被调方的地址”成为新问题。通用做法是引入注册中心：每个服务启动时把自己的服务名、IP、端口上报注册表，并以心跳续约证明存活；调用方按服务名拉取可用实例列表，再做客户端负载均衡。实例下线或心跳超时后自动从注册表摘除，流量随之切换到健康实例。把“注册、发现、心跳、摘除、负载均衡”这套机制讲清楚，比堆砌更多组件更能体现理解深度。

3.3 消息队列：用异步事件总线解开服务耦合

以“选课成功”为例：除了写入选课记录，还需要发通知、加积分、更新统计。如果主流程同步调用这三个服务，耗时串行叠加，任一服务故障都会导致选课失败。更合理的做法是引入消息队列作为事件总线：

// 业务服务：事务提交后只负责发布事件（示意）
public void onEnrollSuccess(EnrollEvent event) {
    eventBus.publish("enroll.success", event);
}
// 通知服务：订阅事件，异步消费
eventBus.subscribe("enroll.success", event ->
    notificationService.send(event.getUserId(), "选课成功提醒")
);

主流程只依赖“发布事件”这一步，下游谁关心谁订阅，后续新增统计功能时业务代码一行不改。这正是“高内聚、低耦合”最直观的落地案例，答辩时非常好讲。

3.4 统一响应与全局异常处理

前后端联调效率很大程度取决于接口规范。建议全系统约定统一的 JSON 结构：

{ "code": 0, "message": "ok", "data": {}, "timestamp": 1719000000000 }

业务服务抛出的异常统一被捕获并转换为对应错误码，网关再做一次兜底格式化，保证前端永远拿到同构响应，避免到处写适配逻辑。

四、推荐的六周开发节奏

1. 第 1 周：定选题、画架构图与核心时序图、建代码仓库，统一代码规范、错误码表与响应结构；
2. 第 2 周：先用“单体版”把核心链路跑通（登录 + 核心业务增删改查），验证业务模型；
3. 第 3 周：引入注册中心与网关，把用户服务和核心业务拆成独立服务，打通网关鉴权；
4. 第 4 周：接入消息队列，完成通知、统计等旁路功能，验证异步解耦；
5. 第 5 周：补齐请求日志、接口文档与演示数据，做一轮自测联调；
6. 第 6 周：异常场景与并发测试、撰写报告、录制演示视频、准备答辩问答。

特别强调“先单体、后拆分”：先保证业务正确，再引入架构复杂度，是课程设计按时交付的关键。

五、常见踩坑与规避建议

• 一上来就拆微服务：极易烂尾，坚持先跑通单体再拆；
• 服务间循环调用：A 调 B、B 又调 A，应改用事件驱动，或把公共能力下沉；
• 纠结分布式事务：课程设计不必追求强一致，用“本地事务 + 消息重试 + 幂等消费”实现最终一致即可；
• 配置散落各处：数据库地址、密钥等集中到配置中心管理，区分开发与演示环境；
• 本地环境搭不起来：注册中心、消息队列等依赖可用容器镜像一键拉起；如果本地资源有限，也可以使用云平台的托管中间件——以百度智能云为代表的云服务商都提供消息队列、对象存储等通用产品类别，可显著降低搭建与运维成本；
• 没有统一错误码：前后端各说各话，务必在编码前先定错误码表。

六、写在最后

一份优秀的期末项目，价值不在“看起来大”，而在“讲得清、跑得通、有取舍”。把网关、注册中心、事件总线这几个机制背后的原理吃透，能在答辩中清晰回答“为什么这样设计、换一种方案行不行”，远比堆砌十个用不上的组件更有说服力。按上面的节奏推进，你完全可以在一个学期内交出一份既有演示效果、又有技术深度的答卷。