1. 项目概述：机票预定系统的现代技术实现
机票预定系统作为航空业的核心业务支撑平台，其技术架构的演进直接反映了企业级Java开发的变迁。十年前我们还在用Struts2+Spring+Hibernate的"重型"组合，如今SpringBoot已经让这类系统的开发效率提升了至少3倍。这个基于SpringBoot的机票预定系统，本质上是通过现代Java技术栈解决三个核心问题：如何快速构建高并发的航班查询服务、如何确保分布式环境下的票务一致性、以及如何提供接近实时的事务处理能力。
我去年带队重构某中型航空公司的订票系统时，实测SpringBoot的自动配置特性让基础环境搭建时间从原来的2周缩短到2天。特别是当需要紧急添加短信提醒功能时，SpringBoot Starter的集成方式让我们在4小时内就完成了从引入依赖到生产部署的全流程。
2. 核心架构设计
2.1 技术选型决策矩阵
我们采用的技术组合不是随意拼凑的，每个组件都经过严格的压力测试：
- SpringBoot 3.1.5：放弃2.x版本选择最新的3.x系列，看中的不仅是Native Image支持，更重要的是其虚拟线程(Virtual Threads)特性。在模拟1000并发用户订票的场景下，相比传统线程池模式内存占用降低40%
- MyBatis-Plus 3.5.3：在对比JPA后选择它，是因为航空业复杂的票价计算规则需要精细控制SQL。其Lambda表达式写法让动态查询代码量减少60%
- Redis 7.0：用作分布式锁和缓存层时，采用Redisson客户端而非Lettuce，因其看门狗机制能有效防止死锁
2.2 微服务拆分策略
机票系统看似简单，但拆分成以下服务后发现复杂性倍增：
- 航班服务：处理CRUD和时刻表变更，采用CQRS模式分离读写
- 库存服务：最核心也最复杂，使用Redis+Lua实现原子性的座位锁定
- 支付服务：集成支付宝/微信时，用Spring Cloud Gateway做协议转换
- 通知服务：处理短信/邮件异步发送，基于RabbitMQ实现最终一致性
关键教训：不要过度拆分！我们曾把票价计算单独拆服务，结果RPC调用延迟导致超时，最终回退到本地调用+分布式事务
3. 关键技术实现细节
3.1 高并发库存控制
机票超卖是致命问题，我们采用三级防护：
java复制// Redis分布式锁实现
RLock lock = redisson.getLock("flight:"+flightNo);
try {
if(lock.tryLock(1, 10, TimeUnit.SECONDS)) {
// 使用Lua保证原子性
String script = "if redis.call('get', KEYS[1]) >= ARGV[1] then " +
"return redis.call('decrby', KEYS[1], ARGV[1]) " +
"else return -1 end";
Long remain = redisTemplate.execute(
new DefaultRedisScript<>(script, Long.class),
Collections.singletonList(seatKey),
String.valueOf(seats));
}
} finally {
lock.unlock();
}
3.2 动态票价计算
航空公司常有复杂的票价规则，我们设计规则引擎：
java复制// 使用Spring EL实现规则解析
ExpressionParser parser = new SpelExpressionParser();
StandardEvaluationContext context = new StandardEvaluationContext();
context.setVariable("user", currentUser);
context.setVariable("flight", flight);
String rule = "user.vipLevel > 3 && flight.distance > 1000 ? basePrice*0.8 : basePrice*0.9";
Double finalPrice = parser.parseExpression(rule).getValue(context, Double.class);
4. 性能优化实战记录
4.1 查询加速方案
航班查询要应对峰值5000QPS，我们采用：
- 多级缓存：本地Caffeine(2s过期)+Redis(5分钟)+数据库
- 索引优化：为航线组合建立复合索引
idx_route(departure, arrival) - 结果预处理：夜间Job预计算热门航线价格
4.2 数据库分库策略
按业务垂直拆分：
- 用户数据：16库，按user_id哈希
- 订单数据：32库，按order_time范围+航空公司ID哈希
- 日志数据：单独时序数据库
5. 生产环境踩坑实录
5.1 分布式事务陷阱
最初使用Seata时遇到的典型问题：
- 超时设置不当：机票锁定默认30秒超时，但支付渠道可能需2分钟
- 修复：调整
seata.tx-service.timeout=180000
- 修复：调整
- 连接池耗尽：高并发时Seata全局锁占用连接
- 修复：单独配置
seata.datasource.max-active=200
- 修复：单独配置
5.2 缓存一致性难题
航班变更时缓存更新策略对比：
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 先更新DB再删缓存 | 实现简单 | 存在短暂不一致 | 变更频率低 |
| 双写+重试机制 | 强一致 | 实现复杂 | 核心业务 |
| 异步监听binlog | 完全解耦 | 延迟高 | 非实时业务 |
我们最终选择方案2，因为航班时刻变更必须实时生效
6. 安全防护体系
6.1 防刷单机制
- 行为指纹：记录用户设备/IP/操作习惯
- 滑动窗口限流：使用Redis实现令牌桶
java复制// 每手机号每分钟限5次
String key = "limit:" + phone;
long count = redisTemplate.opsForValue().increment(key, 1);
if(count == 1) {
redisTemplate.expire(key, 60, TimeUnit.SECONDS);
}
if(count > 5) {
throw new BusinessException("操作过于频繁");
}
6.2 支付安全加固
- 敏感数据加密：采用国密SM4算法
- 接口签名验证：每个请求携带HMAC-SHA256签名
- 金额二次确认：支付前必须重新查询最新金额
7. 监控与运维方案
7.1 全链路监控
- 指标收集：Prometheus+Grafana监控JVM/DB/缓存
- 日志分析：ELK收集业务日志，特别关注订单状态变更
- 链路追踪：SkyWalking定位慢请求，优化95线耗时
7.2 灰度发布策略
采用双维度发布控制：
- 按用户分组：内部员工先体验新功能
- 按航线分组：选择非热门航线先行验证
8. 扩展性设计
8.1 插件化架构
通过Spring的@Conditional实现可插拔功能：
java复制@Configuration
@ConditionalOnProperty(name = "sms.enable", havingValue = "true")
public class SmsAutoConfiguration {
@Bean
public SmsService smsService() {
return new AliSmsServiceImpl();
}
}
8.2 多租户支持
通过ThreadLocal传递租户上下文：
java复制public class TenantContext {
private static final ThreadLocal<String> CURRENT_TENANT = new ThreadLocal<>();
public static void setTenant(String tenant) {
CURRENT_TENANT.set(tenant);
}
// 在MyBatis拦截器中自动添加tenant_id条件
}
这个项目让我深刻体会到，好的架构不是设计出来的，而是演进出来的。最初我们追求完美的DDD实现，后来发现过度设计反而拖慢进度。现在的经验法则是：先用最简单的方式实现核心流程，等业务跑通后再逐步重构。比如支付状态机就经历了三次重写，最终采用Spring StateMachine才解决所有边角case。