南瓜丶奇迹师1. 项目背景与核心目标
EE308FZ_Beta Spring项目是我们团队在敏捷开发实践中的一次重要迭代。作为Beta阶段的冲刺总结，这篇文章将完整复盘我们在Spring框架技术栈下的开发历程、技术决策和团队协作经验。
不同于常规的技术文档，本文更聚焦于真实项目环境中的工程实践细节。我们将从技术架构选型、迭代过程管理、质量保障体系三个维度，还原一个中型规模Spring Boot项目从零到交付的全链路实践。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术架构设计与选型
2.1 基础技术栈确定
项目初期面临的首要决策是技术栈的选型。基于以下核心考量，我们确定了以Spring Boot 2.7为核心的基础架构：
- 团队现有技术储备与Spring生态的匹配度
- 微服务架构的扩展需求
- 与现有CI/CD管道的兼容性
具体技术矩阵包括：
| 组件类型 | 选型方案 | 替代方案对比 |
|---|---|---|
| Web框架 | Spring Boot 2.7 + MVC | Quarkus（性能更优但生态较弱） |
| 数据访问 | Spring Data JPA + QueryDSL | MyBatis（更灵活但需要更多手写SQL） |
| 缓存 | Redis + Spring Cache | Caffeine（本地缓存但无法分布式） |
2.2 模块化设计实践
采用领域驱动设计（DDD）思想进行模块划分时，我们特别注重了边界上下文的设计：
java复制com.example.betaspring
├── domain
│ ├── order
│ ├── payment
│ └── inventory
├── application
│ ├── service
│ └── dto
└── infrastructure
├── repository
└── client
这种结构在初期增加了些许开发成本，但在后期微服务拆分时展现出巨大优势。例如订单模块的领域模型完整保留了业务语义，迁移时仅需调整基础设施层实现。
3. 迭代过程管理
3.1 冲刺规划实践
每个Sprint周期（2周）的执行流程如下：
- 需求梳理会议（3小时）
- 使用MoSCoW法则进行优先级划分
- 明确DoD（Definition of Done）标准
- 技术方案设计（1个工作日）
- 架构决策记录（ADR）编写
- 接口契约定义（使用Swagger/OAS3）
- 每日站会（15分钟强制时间盒）
- 采用"昨日进展/今日计划/阻塞问题"三板斧格式
- 禁止技术细节讨论（会后单独解决）
3.2 分支策略优化
经过多次实践验证，最终采用的Git工作流方案：
mermaid复制graph LR
A[main] --> B[release/v1.0]
B --> C[feature/login]
B --> D[feature/payment]
C --> E[hotfix/oauth-bug]
关键经验：
- 所有特性分支从release分支切出
- hotfix同时合并到release和main
- 采用Rebase而非Merge保持提交历史线性
4. 质量保障体系
4.1 分层测试策略
构建了金字塔结构的自动化测试体系：
- 单元测试（JUnit5 + Mockito）：覆盖率要求≥80%
- 集成测试（Testcontainers）：重点验证数据访问层
- API测试（RestAssured）：契约测试优先于UI测试
一个典型的测试类结构示例：
java复制@SpringBootTest
@AutoConfigureMockMvc
class OrderControllerTest {
@MockBean
private PaymentService paymentService;
@Test
void shouldReturn409WhenInventoryInsufficient() {
// given
when(inventoryService.checkStock(any())).thenReturn(false);
// when
ResultActions result = mockMvc.perform(post("/orders")
.contentType(APPLICATION_JSON)
.content(testOrderJson));
// then
result.andExpect(status().isConflict());
}
}
4.2 代码质量门禁
通过SonarQube搭建的质量关卡：
- 新增代码重复率≤3%
- 单元测试覆盖率差值≥-5%
- 0新增Blocker级别问题
特别在静态代码分析中，我们发现并修复了多个Spring特有的问题：
- @Transactional未指定rollbackFor
- Controller中直接注入HttpServletRequest
- 循环依赖（通过@Lazy临时解决）
5. 性能优化实践
5.1 JVM参数调优
针对AWS EC2 c5.xlarge实例的最终JVM配置：
bash复制-XX:MaxRAMPercentage=75
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:InitiatingHeapOccupancyPercent=45
关键调整依据：
- 通过GC日志分析发现CMS收集器在流量突增时出现promotion failed
- G1的Region设计更适合我们的内存分配模式
- 保留25%内存给操作系统和文件缓存
5.2 数据库访问优化
通过Spring Data JPA + Hibernate的二级缓存配置：
yaml复制spring:
jpa:
properties:
hibernate:
cache:
region.factory_class: org.hibernate.cache.ehcache.EhCacheRegionFactory
use_second_level_cache: true
use_query_cache: true
配合QueryDSL实现的动态查询缓存方案：
java复制@Cacheable(value = "orderQueryCache",
key = "#customerId + '-' + #status.name()")
public List<Order> findOrdersByCustomer(Long customerId, OrderStatus status) {
return queryFactory.selectFrom(order)
.where(order.customerId.eq(customerId)
.and(order.status.eq(status)))
.fetch();
}
6. 典型问题排查案例
6.1 内存泄漏事件
现象：Pod在运行48小时后出现OOM。通过以下步骤定位：
- 使用jmap生成堆转储文件
- MAT分析发现Spring CGLIB代理对象堆积
- 追溯至@Cacheable方法未设置过期时间
- 最终解决方案：
java复制@Cacheable(value = "productCache",
key = "#id",
cacheResolver = "ttlCacheResolver")
6.2 事务传播异常
一个典型的嵌套事务问题：
java复制@Service
class OrderService {
@Transactional
void createOrder() {
inventoryService.reduceStock(); // 需要新事务
paymentService.process(); // 需要加入当前事务
}
}
@Service
class InventoryService {
@Transactional(propagation = Propagation.REQUIRES_NEW)
void reduceStock() { ... }
}
排查工具链：
- 开启spring.jpa.show-sql=true
- 使用TransactionSynchronizationManager日志
- 最终通过AOP切面增加事务边界日志
7. 团队协作经验
7.1 代码审查规范
制定的CR Checklist包含Spring特定条目：
- [ ] 是否合理使用@Async
- [ ] @Scheduled的cron表达式是否配置时区
- [ ] REST接口是否遵循HATEOAS
- [ ] 异常处理是否使用@ControllerAdvice
7.2 知识沉淀机制
建立的项目Wiki包含：
- Spring最佳实践文档
- 常见问题排错手册
- 架构决策记录库
- 技术债务看板
特别有价值的是一套自研的Spring健康检查端点：
java复制@Endpoint(id = "customHealth")
@Component
public class CustomHealthEndpoint {
@ReadOperation
public Map<String, Object> health() {
return Map.of(
"db", checkDatabase(),
"cache", checkRedis(),
"mq", checkRabbitMQ()
);
}
}
在项目推进过程中，我们深刻体会到：Spring生态的强大在于其灵活性，但这也要求团队必须建立严格的技术规范。特别是在模块边界划分、事务管理和缓存策略等方面，前期看似过度的设计投入，在系统演进过程中都获得了超预期的回报。