最近在帮学弟学妹们看毕业设计，发现一个挺普遍的现象：很多不错的项目，一到校园网环境里部署测试就“水土不服”。要么端口被封访问不了，要么服务器资源太少一压测就崩，本地跑得好好的，一上线就各种问题。正好我之前做过一个基于微服务的选课系统，踩了不少坑，也总结了一些在校园网这种“特殊环境”下做毕设的实战经验，今天就来分享一下。

1. 背景痛点：校园网里的“隐形围墙”

校园网环境对毕设项目来说，挑战主要来自几个方面：

• 网络限制严格：这是最大的拦路虎。出于安全和管理考虑，校园网通常会封锁大部分端口，只开放少数如80、443等常用端口。这意味着你想用默认的8080启动Spring Boot应用，或者用3306直连数据库，很可能从外部网络（比如宿舍、家里）根本无法访问。更麻烦的是，学生服务器通常没有公网IP，你没法像在云服务器上那样直接配置域名解析。
• 硬件资源捉襟见肘：学校提供的虚拟机或者老旧物理服务器，内存和CPU资源往往非常有限。同时运行多个微服务、数据库、缓存，很容易就内存溢出。我之前那台虚拟机就2核4G，跑三个服务加一个Redis，负载经常飙到90%以上。
• 部署流程复杂低效：没有成熟的运维体系，部署基本靠手动上传Jar包、手动执行脚本。服务一多，启动顺序、依赖检查就变得非常繁琐，更别提版本回滚、健康检查了。本地开发环境和线上环境的差异（如数据库地址、缓存配置）也容易导致部署失败。

基于这些痛点，我决定设计一个系统，目标很明确：高内聚低耦合，方便在资源受限的校园网内一键部署和水平扩展，并且能扛住选课这种典型的高并发场景。

2. 技术选型：为什么是它们？

面对琳琅满目的技术栈，怎么选才能让毕设既“高大上”又“接地气”？

• 后端框架：Spring Boot vs Flask/Django 这几乎是Java和Python阵营的对比。我选择Spring Boot，核心原因在于生态和工程化。毕业设计不仅是实现功能，更是展示你工程能力的机会。Spring Boot的“约定大于配置”极大简化了搭建过程，而其背后庞大的Spring Cloud Alibaba生态（Nacos, Sentinel, Seata）为微服务提供了开箱即用的解决方案。对于选课系统需要的分布式事务（虽然最终用了柔性事务）、限流降级等功能，集成起来更顺畅。反观Flask/Django，虽然开发速度快，但在构建复杂微服务架构时，需要自己集成和组装更多组件，对毕设的时间把控要求更高。

• 注册中心：Nacos vs Eureka Eureka是Netflix开源的老牌产品，但已停止维护。Nacos作为阿里开源的产品，在国内社区活跃，文档丰富，遇到问题更容易找到解决方案。更重要的是，Nacos“身兼多职”，它不仅是服务注册发现中心，还提供了配置管理功能。这意味着我可以用一个Nacos统一管理所有微服务的数据库连接、Redis地址等配置，通过监听配置变更实现服务热更新，避免了在校园网环境中频繁重启服务。这对于资源紧张的环境是个福音。

• 缓存与分布式锁：Redis 选课防超卖是核心，Redis的原子操作和Lua脚本能力是实现高并发下数据一致性的利器。相比数据库乐观锁，性能高出几个数量级。

• 部署方式：Docker容器化 为了解决环境一致性问题，我选择了Docker。将所有服务（Spring Boot应用、MySQL、Redis、Nacos）都容器化，编写一个docker-compose.yml文件，就可以在校园网服务器上通过一条命令启动所有服务，屏蔽了环境差异。

3. 核心实现：拆解三大难题

3.1 服务注册与发现：让服务互相找到彼此

在微服务架构下，选课服务需要调用课程信息服务和学生信息服务。硬编码IP地址是灾难。通过Nacos，每个服务启动时都自动注册。

// 在application.yml中配置Nacos
spring:
  application:
    name: course-selection-service
  cloud:
    nacos:
      discovery:
        server-addr: ${NACOS_HOST:localhost}:8848 # 支持环境变量，便于区分本地与线上

// 服务消费者通过Feign或RestTemplate + @LoadBalanced注解调用
@FeignClient(name = "course-info-service")
public interface CourseInfoClient {
    @GetMapping("/api/course/{courseId}")
    CourseDTO getCourseById(@PathVariable("courseId") Long courseId);
}

这样，即使课程信息服务换了IP或端口，选课服务也无需修改代码，由Nacos自动完成服务发现和负载均衡。

3.2 选课接口的幂等性设计：防止重复提交

网络抖动可能导致学生多次点击提交。幂等性保证同一请求执行一次和执行多次效果相同。我采用“Token机制”实现前端按钮防重，用“数据库唯一索引”保证后端最终一致性。

1. 进入选课页面时，后端生成一个唯一Token（如UUID）并存入Redis（设置较短过期时间），同时返回给前端。
2. 前端提交选课请求时，携带此Token。
3. 后端接口首先检查Redis中是否存在该Token，存在则删除并继续处理；不存在则视为重复请求，直接返回“请勿重复提交”。
4. 业务逻辑处理完成后，在选课记录表上，为(student_id, course_id, semester)建立唯一联合索引。这是最后一道防线，即使极端情况下请求穿透了Token检查，数据库也会因唯一键冲突而插入失败。

3.3 Redis + Lua 防超卖逻辑：守住库存底线

这是最关键的环节。单纯使用redis.decr()判断库存大于0存在“判断-执行”的间隙，并发时可能超卖。Lua脚本可以确保整个操作的原子性。

-- select_course.lua
-- KEYS[1]: 课程库存key (e.g., stock:course:1001)
-- ARGV[1]: 课程ID
-- ARGV[2]: 学生ID
-- 返回值：1-成功，0-库存不足， -1-已选过

-- 检查库存
local stock = tonumber(redis.call('get', KEYS[1]))
if not stock or stock <= 0 then
    return 0
end

-- 检查是否已选（使用Set存储已选该课程的学生ID）
local hasSelected = redis.call('sismember', 'selected:course:' .. ARGV[1], ARGV[2])
if hasSelected == 1 then
    return -1
end

-- 扣减库存，并记录选课关系
redis.call('decr', KEYS[1])
redis.call('sadd', 'selected:course:' .. ARGV[1], ARGV[2])
return 1

Java调用代码：

@Service
public class CourseSelectionService {
    @Autowired
    private StringRedisTemplate redisTemplate;

    private static final DefaultRedisScript<Long> SELECT_SCRIPT;

    static {
        SELECT_SCRIPT = new DefaultRedisScript<>();
        SELECT_SCRIPT.setLocation(new ClassPathResource("lua/select_course.lua"));
        SELECT_SCRIPT.setResultType(Long.class);
    }

    public SelectionResult selectCourse(Long courseId, Long studentId) {
        String stockKey = "stock:course:" + courseId;
        Long result = redisTemplate.execute(
                SELECT_SCRIPT,
                Collections.singletonList(stockKey),
                courseId.toString(), studentId.toString()
        );

        if (result == 1) {
            // Lua脚本成功，异步落库到MySQL，最终一致性
            asyncSaveToDatabase(courseId, studentId);
            return SelectionResult.success("选课成功");
        } else if (result == 0) {
            return SelectionResult.fail("课程库存不足");
        } else {
            return SelectionResult.fail("您已选择该课程");
        }
    }
}

要点：Redis只做高速的库存扣减和重复检查，真正的选课记录通过消息队列或异步任务持久化到数据库，实现最终一致性。这比直接操作数据库快得多。

4. 性能与安全：不能忽视的底线

• 冷启动与QPS：在2核4G的校园网服务器上，单个选课服务（无数据库压力，依赖Redis）的冷启动时间约25秒。通过JVM调优（如指定堆内存-Xms512m -Xmx512m）可以缩短。使用JMeter压测，上述Lua脚本方案，在Redis本机部署的情况下，QPS能达到3500+，完全满足一般高校选课场景（峰值预计在千级QPS）。
• SQL注入防护：坚持使用MyBatis的#{}预编译占位符，严禁字符串拼接SQL。这是最基本也最有效的防线。
• 越权访问防护：所有API接口都需要携带JWT Token。在网关层（如Spring Cloud Gateway）统一验证Token有效性并解析用户身份（学生ID）。业务服务中，对于涉及资源归属的操作（如“查询我的选课列表”），必须从Token解析出的学生ID作为查询条件，而非直接使用前端传入的参数，防止学生A查询到学生B的数据。

5. 生产环境避坑指南（校园网特供版）

1. 本地与线上配置分离：使用Spring Boot的application-{profile}.yml多环境配置。本地用application-local.yml，连接本地数据库；线上用application-prod.yml，通过环境变量注入Nacos、Redis的地址（校园网内网IP）。
2. 日志收集困境：校园网内没有ELK这种豪华套装。可以采用折中方案：所有服务的日志都输出到指定目录，使用docker logs命令查看实时日志，或者用logrotate工具对日志文件进行定期切割和归档，避免磁盘写满。
3. 数据库连接池配置陷阱：资源有限，连接池不是越大越好。HikariCP默认的10个连接在校园网小规格数据库上可能都多。建议根据实际压力调低（如3-5个），并设置合理的超时时间，避免大量请求堆积在等待数据库连接上，拖垮整个系统。
4. 端口映射的艺术：由于校园网只开放80/443，你需要一个反向代理（如Nginx）。将所有微服务的容器端口映射到宿主机不同端口（如18080， 18081），然后在Nginx中配置基于路径（/api/course/**）或子域名（course-selection.yoursite.com）的反向代理规则，将请求转发到对应的内部端口。这样对外只需要暴露Nginx的80端口即可。
5. 健康检查与优雅上下线：在docker-compose.yml中为每个服务配置healthcheck，确保服务完全启动后再接受流量。服务关闭前，先在Nacos中反注册，等待一段时间再停止容器，避免流量打到已停止的服务上。

写在最后

这个项目做下来，最大的感触是：在受限的校园网环境里做毕设，“简单、可靠、易部署”比追求技术的“新”和“全”更重要。微服务架构确实带来了清晰的分层和扩展性，但也引入了复杂度。通过Nacos统一治理，Redis扛住并发，Docker固化环境，我们能在有限的条件下搭建一个像模像样的分布式系统。

最后留一个思考题：在校园网没有公网IP、端口受限的条件下，如何实现最简单的CI/CD自动化？我的思路是：在服务器上部署一个Jenkins Agent，代码推送到Git仓库后，通过Webhook触发Jenkins Master（可以放在有公网IP的云服务器上）的任务，将构建指令发送给内网的Agent执行打包和部署。当然，这又是另一个有趣的话题了。

希望这篇笔记能给你带来一些启发。纸上得来终觉浅，绝知此事要躬行。不妨动手搭一搭，遇到问题解决问题，这个过程本身就是最好的学习。