企业官网建设流程全解析

简介：这是一套基于Java开发的民航订票管理系统完整实现方案，面向计算机专业本科生课程设计、Java Swing桌面应用实践及JDBC数据库编程学习者，解决航空业务场景下的航班查询、订退票、航线与延误管理、会员及客户信息维护等核心功能需求。资源包共118个文件，含30个Java源码（涵盖GUI界面、DAO层、业务逻辑类）、75个编译后class文件、5个XML配置文件、2个SQL建表与初始化脚本，辅以docx文档说明，整体压缩后仅2.29MB，结构清晰、模块划分明确。已有1815人下载学习，可直接导入Eclipse或IntelliJ IDEA运行，配套SQL Server数据库，代码规范、注释充分，包含登录、航班查询、订票订单处理、VIP注册、客户信息管理等典型模块，便于理解MVC分层思想与Swing事件驱动机制。

1. 项目概述：从“订票”到“系统”的认知跃迁

看到“民航订票管理系统设计+文档.zip”这个标题，很多刚入行的朋友可能会觉得，这不就是个带数据库的增删改查（CRUD）项目吗？无非是用户注册、查询航班、下单支付那一套。如果你也这么想，那可能就错过了这个项目背后最核心的价值。我做了十几年系统架构，带过不少团队，也面试过很多人，发现能把一个看似“简单”的订票系统讲清楚、设计扎实的人，凤毛麟角。这个项目之所以能成为经典，是因为它几乎涵盖了现代商业系统设计的全部核心挑战：高并发、强一致性、复杂业务状态机、外部系统集成、以及最要命的——分布式事务。它绝不是一个玩具，而是一个微缩的、完整的商业系统沙盘。

为什么这么说？想想你平时订机票的场景：海量用户同时搜索不同日期、不同航线的航班，系统要在毫秒级返回结果；你选中一个航班，点击“预订”，这个座位在接下来几分钟内就不能被别人买走（锁座）；当你支付成功，订单状态、座位库存、航司结算数据必须同时准确更新，不能出现“付了钱却没票”或者“没付钱却占了座”的情况。这背后是每秒可能上万次的请求，是分秒必争的资源竞争，是涉及用户、航司、支付网关、清算中心等多个实体的复杂协作。设计这样一个系统，考验的是你对业务本质的理解、对技术边界的把握，以及将两者融会贯通的架构能力。

所以，这个“设计+文档”包，真正的价值不在于那几行代码，而在于它强迫你像一名真正的系统架构师一样去思考：面对一个真实的、有血有肉的商业需求，你如何抽丝剥茧，定义出清晰的服务边界？如何权衡数据库的读写性能与一致性？如何设计一个既能快速响应查询，又能扛住瞬时洪峰的缓存策略？如何确保在某个服务宕机时，整个订票流程不会彻底崩溃？接下来，我就把自己这些年踩过的坑、总结的经验，掰开揉碎了，跟你聊聊怎么把这个“经典项目”做出“工业级”的味道。

2. 核心业务模型与领域驱动设计拆解

2.1 识别核心领域与聚合根

一上来就建表、写接口是新手最容易犯的错误。正确的姿势是先抛开技术，用业务语言把核心概念和它们之间的关系理清楚。在民航订票领域，我们可以识别出几个核心领域：

1. 用户（User）：系统的使用者，核心属性是身份标识和联系方式。
2. 航班（Flight）：一次具体的飞行计划，包含航班号、起降机场、计划时间、执飞机型等。它是资源的提供方。
3. 航班库存（FlightInventory）或 航班班次（FlightSchedule）：这是最容易被忽略也是最关键的模型。一个航班（如CA1234）每天都有，但1月1日的CA1234和1月2日的CA1234是两个不同的库存实体。它关联着具体的日期、舱位（如经济舱Y舱、公务舱C舱）、价格、以及最重要的——剩余座位数。这个实体是库存管理的核心，是并发争抢的焦点。
4. 订单（Order）：用户购买行为的载体。它关联用户、航班库存、乘客信息、订单金额、状态（待支付、已出票、已取消等）。
5. 乘客（Passenger）：乘机人信息，可能和下单用户不是同一个人。
6. 支付（Payment）：记录支付流水，与订单关联。

这里引入DDD（领域驱动设计）中一个非常重要的概念：聚合根（Aggregate Root）。聚合根是聚合（一组强关联对象的集合）的入口，外部只能通过聚合根来操作聚合内的对象。在这个系统里：

• 航班库存（FlightInventory）是一个强大的聚合根候选。因为它“拥有”座位数这个需要强一致保护的资源。对座位的占用、释放操作，必须通过它来完成，以确保在“一个库存”的边界内，座位数不会出现超卖。
• 订单（Order）是另一个聚合根。它封装了订单状态、订单项、支付信息等。订单状态的变迁（如从“待支付”到“已支付”）是一个复杂的业务流程，需要在聚合内保证一致性。

注意：不要把“航班（Flight）”作为库存管理的聚合根。因为航班是静态信息，而库存是动态的、按日期实例化的。将它们分离，模型更清晰，也更利于性能优化（比如缓存静态的航班信息）。

2.2 状态机设计：订单的生命周期

订单的状态流转是这个系统业务逻辑复杂性的集中体现。一个严谨的状态机设计，能避免出现“已取消的订单还能支付”之类的业务漏洞。一个典型的订单状态机可能包括：

• 初始化（INIT）：订单创建，但座位尚未锁定。
• 待支付（PENDING_PAYMENT）：成功锁定座位后进入此状态，等待用户支付。通常有超时时间（如15分钟），超时后自动取消并释放座位。
• 支付中（PAYING）：用户发起支付，等待支付网关异步回调。这是一个短暂且关键的状态，用于防止重复支付。
• 已支付（PAID）：支付成功。此时可以触发后续的出票流程。
• 出票中（TICKETING）：调用中航信或航司接口进行实际出票。
• 已出票（TICKETED）：出票成功，生成票号。订单完成。
• 取消中（CANCELLING）：用户发起取消（支付前或支付后），进行退款、释放座位等逆向操作。
• 已取消（CANCELLED）：取消完成。
• 失败（FAILED）：在支付、出票等环节出现不可恢复的错误。

设计状态机时，务必使用状态模式（State Pattern）在代码中固化这些规则。每个状态是一个类，订单的行为（如canPay(),canCancel()）和状态转移逻辑封装在对应的状态类中。这样，业务规则的变更只会影响特定的状态类，而不是散落在整个订单服务的if-else里。

2.3 库存管理模型：超卖问题的核心战场

“超卖”是电商和订票系统的噩梦。解决它的核心在于如何安全地扣减库存。常见方案有：

1. 悲观锁（Pessimistic Locking）：在更新库存的SQL语句中使用SELECT ... FOR UPDATE。这能保证绝对的安全，但在高并发下，大量请求排队等待锁，性能极差，不适合订票场景。
2. 乐观锁（Optimistic Locking）：在库存表中增加一个版本号（version）字段。更新时，SET quantity = quantity - 1, version = version + 1 WHERE id = ? AND version = ? AND quantity > 0。如果更新影响行数为0，说明版本号不对或库存不足，返回失败。这是最常用且有效的方案。它假设冲突不常发生，性能好，但在极高并发下，失败率会上升。
3. 预扣库存（预占）：这是订票系统的标准做法。用户点击“预订”时，并不直接扣减最终库存，而是在一个“预扣库存表”中占住这个座位，并设置一个较短的过期时间（如15分钟）。同时，真实库存（可售数）减少。订单支付成功后，再将预扣库存转为实际占用；支付超时或取消，则释放预扣库存，真实库存回增。这相当于把“下单”和“支付”两个动作之间的库存用“预扣”这个中间状态保护起来。

在我的实践中，会采用“乐观锁 + 预扣库存”的组合方案。在航班库存聚合根内，提供reserveSeat(userId, timeout)和confirmReservation(reservationId)等方法。reserveSeat内部使用乐观锁尝试扣减可售数，并生成一条预扣记录。这样，既保证了并发安全，又给予了用户支付缓冲期。

3. 系统架构设计与技术选型考量

3.1 单体还是微服务？这是一个问题

对于学习或中小型项目，一个设计良好的单体架构完全够用，且能避免分布式带来的复杂性。但为了体现现代架构思想，我们可以按界限上下文（Bounded Context）进行逻辑拆分，为未来演进留出空间。核心服务可以包括：

• 用户服务（User Service）：负责注册、登录、个人信息管理。
• 航班查询服务（Flight Search Service）：只读服务，提供复杂的航班搜索、筛选、排序功能。它需要极高的查询性能和吞吐量，数据来源于航班服务。
• 航班库存服务（Flight Inventory Service）：核心中的核心。负责航班库存的创建、查询、以及最重要的——库存的预占、确认、释放。所有涉及“座位数”变更的操作都必须经过此服务。
• 订单服务（Order Service）：负责订单的创建、状态管理、查询。它调用库存服务进行占座，调用支付服务发起支付。
• 支付服务（Payment Service）：封装与第三方支付网关（如支付宝、微信支付）的交互，处理支付回调。
• 出票服务（Ticketing Service）：在订单支付成功后，调用外部航司或GDS（全球分销系统）接口完成实际出票。

即使物理上部署在一个应用内，代码上也应按此服务边界进行模块化划分，明确接口契约（如使用内部API或领域事件通信）。

3.2 数据库选型与分库分表策略

• 核心交易型数据（订单、库存、支付）：必须选择强关系型数据库，如MySQL 或 PostgreSQL。因为我们需要ACID事务来保证资金和库存的绝对准确。对于订单和支付记录，随着时间推移数据量会暴涨，必须考虑分库分表。

  • 订单表分表：最常用的策略是按用户ID哈希或订单创建时间范围分表。按用户ID哈希能保证一个用户的订单落在同一张表，方便查询“我的订单”。按时间分表（如每月一张表）则便于归档历史数据。
  • 库存表：查询压力极大，且更新频繁。除了使用乐观锁，还可以考虑按“航班日期+航班号”进行分表，将热点数据分散。

• 航班信息等静态或准静态数据：可以考虑使用Redis进行缓存。甚至可以将复杂的航班搜索索引构建到Elasticsearch中。ES的全文检索、多条件过滤和排序能力，远超关系型数据库的LIKE和多个WHERE条件，能极大提升搜索体验和性能。

3.3 缓存策略设计：平衡性能与一致性

缓存用得好是神器，用不好就是“脏数据”的根源。订票系统的缓存设计要分场景：

1. 航班信息缓存：这是只读缓存的完美场景。航班号、起降时间、机场等基础信息几乎不变。可以设置较长的过期时间（如24小时），通过消息队列监听航班变更事件来更新缓存。
2. 航班库存（价格、座位数）缓存：这是读写缓存，且一致性要求极高。绝对不能简单地将库存数缓存几分钟，否则会导致严重的超卖。
   • 可行方案：使用Redis，但不缓存可售数，只缓存航班库存的ID、价格等静态信息。真正的可售数查询，直接走数据库（配合乐观锁）。虽然每次查询都访问数据库，但数据库本身可以通过连接池、索引和分表来抗住压力。这是一种用“保证一致性”来换取“设计复杂度降低”的权衡。
   • 激进方案：将库存扣减逻辑放在Redis中，利用Redis的原子操作（DECR）和Lua脚本保证原子性。但这需要将库存数据全量同步到Redis，并维护Redis与数据库之间的数据一致性，复杂度很高，适合有深厚Redis运维经验的团队。

实操心得：在绝大多数情况下，对于库存这种“钱和物”的核心数据，宁可慢一点，也要准一点。直接依赖数据库的事务和锁机制是最稳妥的。性能问题可以通过数据库读写分离、将库存表单独放在高性能实例上、以及优化查询语句（覆盖索引）来解决。不要过早引入分布式缓存带来的数据一致性问题。

3.4 分布式事务与最终一致性方案

这是微服务架构下最头疼的问题。用户支付成功后，需要更新订单状态、确认库存占用、记录支付流水。这三个操作分布在订单、库存、支付三个服务中，如何保证它们同时成功或失败？

1. 刚性分布式事务（如XA）：性能差，耦合度高，基本被业界抛弃。
2. 最终一致性（Event-Driven）：这是主流选择。以“支付成功”为例：
   • 支付服务收到支付网关回调，确认支付成功。
   • 支付服务本地事务更新支付单状态为成功，并发布一个“支付成功”领域事件到消息队列（如RocketMQ/Kafka）。
   • 订单服务订阅该事件，在本地事务中更新订单状态为“已支付”，并发布“订单已支付”事件。
   • 库存服务订阅“订单已支付”事件，在本地事务中将对应库存预占记录标记为“已确认”，完成最终扣减。
   • 出票服务订阅“订单已支付”事件，开始调用外部出票接口。

这个过程中，任何一个环节失败，都需要有补偿机制。例如，库存服务处理事件失败，消息队列会重投；多次重投失败后，消息进入死信队列，需要人工或自动的补偿job来处理，比如检查订单状态，重新尝试确认库存或释放库存。这就是所谓的“事务消息”或“最大努力交付”。

踩坑记录：事件一定要设计成“已发生的事实”，而不是“命令”。比如用PaymentCompletedEvent（支付已完成事件），而不是ConfirmInventoryCommand（确认库存命令）。事件携带足够的数据（如订单ID、支付金额、时间），让订阅方能够独立完成自己的工作。此外，事件发布必须在发布者的本地数据库事务提交之后，否则可能出现“数据库更新了，但事件没发出去”的尴尬情况，这可以通过“事务性发件箱（Transactional Outbox）”模式解决。

4. 核心功能模块的详细设计与实现

4.1 航班搜索：从简单查询到复杂推荐

搜索接口GET /api/flights的设计是门艺术。参数可能包括：出发城市、到达城市、出发日期、舱位、航空公司、排序方式（价格、时间）等。

后端实现要点：

1. 参数校验与规范化：城市名转城市代码，日期格式化，防止SQL注入。
2. 构建查询：使用MyBatis-Plus或JPA的Specification动态构建查询条件。对于status = ‘AVAILABLE‘（可售）和departureTime > now()（未来航班）这类固定条件要加上。
3. 分页：必须支持分页！使用数据库层面的LIMIT offset, size，而不是查出全部再内存分页。PageHelper（MyBatis）或JPA的Pageable都是好帮手。
4. N+1问题：航班信息往往关联机场、航空公司等表。务必使用JOIN查询或@EntityGraph注解一次性加载，避免循环查询。
5. 性能瓶颈：当条件组合复杂时，数据库查询可能变慢。这就是引入Elasticsearch的理由。你可以定期将航班库存数据同步到ES，搜索请求直接发给ES，它能在毫秒内返回结果。数据库只作为“系统记录”的存储。

进阶：缓存搜索结果对于热门航线（如京沪线）的常见搜索，可以将整个分页结果序列化后存入Redis，设置一个较短的过期时间（如30秒）。这能极大减轻数据库或ES的压力。键可以设计为flight_search:PEK:SHA:2023-10-01:ECONOMY:1（出发:到达:日期:舱位:页码）。

4.2 下单与库存预占：扣减的艺术

这是系统最核心的交互。接口POST /api/orders的处理流程必须设计得如履薄冰：

1. 参数校验：验证航班库存ID、乘客信息、联系人信息等。
2. 库存预占（关键步骤）：
   • 调用库存服务的/api/inventory/{id}/reserve接口，传入超时时间（如15分钟）。
   • 库存服务内部：开启事务，查询库存记录，检查available_seats > 0，使用乐观锁执行UPDATE ... SET available_seats = available_seats - 1, version = version + 1 ...。
   • 如果更新成功，插入一条seat_reservation记录，状态为RESERVED，并设置过期时间。
   • 返回预占唯一标识reservation_id。
3. 创建订单：订单服务收到预占成功的响应后，在本地事务中创建订单，状态为PENDING_PAYMENT，并保存reservation_id。
4. 响应客户端：返回订单ID、支付金额、支付倒计时。

整个过程中，任何一个步骤失败，都必须有回滚机制：

• 如果库存预占失败，直接返回“库存不足”给用户。
• 如果创建订单失败（比如数据库异常），需要同步调用库存服务的释放接口，回滚刚才的预占。这一步必须是同步的、强一致的，否则就会造成“占着茅坑不拉屎”的库存死锁。

4.3 支付与状态同步：异步世界的协作

支付通常跳转到第三方支付页面，因此后端采用的是异步回调机制。

1. 发起支付：订单服务调用支付服务，生成支付参数（订单号、金额、标题），支付服务调用支付宝/微信接口获取支付链接。订单状态可变为PAYING。
2. 前端跳转支付：用户扫码或输入密码完成支付。
3. 支付回调：支付网关会主动调用你预留的回调接口（Callback Endpoint）。这个接口必须：
   • 幂等：无论被回调多少次，处理结果都一样。通过支付网关的订单号或交易号来判重。
   • 验证签名：防止伪造回调请求。
   • 快速响应：回调逻辑要快，只做核心的状态更新和事件发布，复杂逻辑异步处理。通常先校验金额、订单状态，然后更新支付单为成功，并发布“支付成功事件”。
4. 订单状态更新：订单服务监听“支付成功事件”，将订单状态更新为PAID。这里可能涉及另一个本地事务。

注意事项：支付回调网络可能不稳定，支付网关有重试机制。你的回调接口一定要做好日志记录，并能处理重复回调。常见的做法是在支付记录表里加一个callback_received状态，或者用payment_transaction_id作为唯一键来保证幂等。

4.4 订单超时未支付处理：定时任务的智慧

用户下单后15分钟未支付，需要自动取消订单并释放库存。这是一个典型的延迟任务。

1. 数据库轮询：最简单但最不推荐。写个定时任务，每分钟扫描status = ‘PENDING_PAYMENT‘ AND created_at < now() - 15min的订单。数据量大了以后性能极差，且延迟精度低。
2. 延迟消息队列：推荐方案。在创建订单（状态为PENDING_PAYMENT）后，向RocketMQ或RabbitMQ发送一条延迟消息（延迟15分钟）。消息体包含订单ID。消费者收到消息后，检查订单状态，若仍是待支付，则执行取消逻辑。RocketMQ原生支持延迟级别，RabbitMQ可以用死信队列（DLX）实现。
3. 时间轮算法：高性能方案，Netty和Kafka都有实现。可以将超时任务放入一个时间轮中，到点自动触发。实现复杂度较高，一般业务系统用延迟消息队列就足够了。

取消逻辑本身也要保证幂等和事务性：检查订单状态 -> 更新订单状态为CANCELLED-> 调用库存服务释放预占座位。这个过程同样可能失败，需要有重试或告警机制。

5. 数据库表结构核心设计参考

光讲理论不够，这里给出几个核心表的设计思路，你可以在此基础上扩展。

1. 航班库存表 (flight_inventory)这是并发更新的热点表，字段设计要精简。

CREATE TABLE `flight_inventory` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT ‘主键‘, `flight_number` varchar(10) NOT NULL COMMENT ‘航班号，如CA1234‘, `departure_airport_code` varchar(10) NOT NULL COMMENT ‘出发机场三字码，如PEK‘, `arrival_airport_code` varchar(10) NOT NULL COMMENT ‘到达机场三字码，如SHA‘, `departure_time` datetime NOT NULL COMMENT ‘计划起飞时间‘, `arrival_time` datetime NOT NULL COMMENT ‘计划到达时间‘, `flight_date` date NOT NULL COMMENT ‘航班日期，与flight_number共同唯一标识一个库存‘, `cabin_class` varchar(20) NOT NULL COMMENT ‘舱位等级，如ECONOMY, BUSINESS‘, `cabin_code` varchar(5) NOT NULL COMMENT ‘舱位代码，如Y, C‘, `total_seats` int(11) NOT NULL DEFAULT 0 COMMENT ‘总座位数‘, `available_seats` int(11) NOT NULL DEFAULT 0 COMMENT ‘可售座位数 - 关键字段‘, `price` decimal(10,2) NOT NULL COMMENT ‘价格‘, `currency` varchar(3) NOT NULL DEFAULT ‘CNY‘, `version` int(11) NOT NULL DEFAULT 0 COMMENT ‘乐观锁版本号‘, `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_flight_date_number_cabin` (`flight_date`,`flight_number`,`cabin_code`), -- 唯一约束 KEY `idx_search` (`departure_airport_code`,`arrival_airport_code`,`flight_date`,`cabin_class`) -- 搜索索引 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT=‘航班库存表‘;

2. 座位预占表 (seat_reservation)记录每一次库存预占，用于超时释放和最终确认。

CREATE TABLE `seat_reservation` ( `id` varchar(32) NOT NULL COMMENT ‘预占ID，可以是UUID‘, `inventory_id` bigint(20) NOT NULL COMMENT ‘关联的库存ID‘, `order_id` bigint(20) DEFAULT NULL COMMENT ‘关联的订单ID，创建订单后更新‘, `status` varchar(20) NOT NULL COMMENT ‘状态：RESERVED, CONFIRMED, RELEASED, EXPIRED‘, `expires_at` datetime NOT NULL COMMENT ‘预占过期时间‘, `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_inventory_status` (`inventory_id`,`status`), KEY `idx_expires` (`expires_at`) COMMENT ‘用于扫描过期预占‘ ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT=‘座位预占表‘;

3. 订单表 (order)订单主表，状态驱动。

CREATE TABLE `order` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT ‘订单号，业务唯一，如20231001123456‘, `user_id` bigint(20) NOT NULL, `total_amount` decimal(10,2) NOT NULL COMMENT ‘订单总金额‘, `status` varchar(30) NOT NULL COMMENT ‘订单状态‘, `reservation_id` varchar(32) NOT NULL COMMENT ‘关联的座位预占ID‘, `flight_inventory_id` bigint(20) NOT NULL COMMENT ‘航班库存ID，冗余字段，方便查询‘, `contact_name` varchar(100) NOT NULL, `contact_phone` varchar(20) NOT NULL, `departure_info` varchar(500) NOT NULL COMMENT ‘出发信息快照，JSON格式，防止库存信息后续变更‘, `passenger_info` text NOT NULL COMMENT ‘乘客信息快照，JSON格式‘, `paid_at` datetime DEFAULT NULL COMMENT ‘支付时间‘, `ticketed_at` datetime DEFAULT NULL COMMENT ‘出票时间‘, `cancelled_at` datetime DEFAULT NULL, `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_user_status` (`user_id`,`status`), KEY `idx_reservation` (`reservation_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT=‘订单表‘;

6. 高并发与稳定性保障实战策略

6.1 限流与降级：守住系统的最后防线

再好的系统也有容量上限。当流量超过系统负载时，需要有限流措施，避免雪崩。

• 网关层限流：在Nginx或API Gateway（如Spring Cloud Gateway）上，对/api/flights/search和/api/orders等关键接口配置QPS限制。例如，每个IP每秒最多调用10次搜索接口。
• 服务层限流：使用Sentinel或Resilience4j。可以为“库存预占”接口设置线程数限流（比如最多同时处理50个请求），多余的请求快速失败，返回“系统繁忙”。这比让所有请求都堆积在数据库层面导致所有人超时更好。
• 降级：当航班搜索依赖的缓存或ES出现问题时，可以降级为直接查询数据库，虽然慢但能用。或者，当非核心功能（如航班准点率预测）出错时，直接返回空数据或默认值，保证核心订票流程畅通。

6.2 熔断与隔离：防止故障蔓延

在微服务架构中，要防止一个服务的故障导致整个系统崩溃。

• 熔断器模式：使用Hystrix或Sentinel。如果订单服务调用支付服务的失败率超过阈值（如50%），熔断器会“打开”，后续调用直接失败或走降级逻辑，不再请求已故障的服务。过一段时间后，进入“半开”状态试探性请求，成功则关闭熔断。
• 舱壁隔离：不同的服务调用使用不同的线程池。比如，订单服务调用库存服务和调用支付服务，使用两个独立的线程池。这样即使调用支付服务卡死，占满了它的线程池，也不会影响调用库存服务的线程，订单创建功能依然可用。

6.3 监控与告警：眼睛和耳朵

没有监控的系统就是在裸奔。至少要监控：

• 应用层面：JVM内存、GC次数、线程池状态、关键接口的QPS、RT（响应时间）、错误率。
• 数据库层面：连接数、慢查询、CPU/内存使用率。
• 缓存与中间件：Redis内存使用率、键数量、命中率；消息队列的堆积情况。
• 业务层面：每日下单量、支付成功率、库存预占失败率。

使用Prometheus收集指标，Grafana制作仪表盘，并配置告警规则（如错误率5分钟持续高于1%），通过钉钉、企业微信或短信通知研发人员。

7. 项目文档的书写要点与价值

“设计+文档”中的文档，其价值不亚于代码。一份好的文档能让你清晰地复盘设计，也能让接手的人快速理解。它应该包括：

1. 架构设计文档：画出系统架构图（服务划分、通信方式）、核心业务流程图（下单、支付）、数据流图。说明技术选型的理由。
2. API接口文档：使用Swagger/OpenAPI自动生成是基础。但更重要的是在文档中写明每个接口的业务含义、幂等性要求、限流策略、可能的错误码及处理建议。
3. 数据库设计文档：ER图，以及每个核心表的字段说明、索引设计理由（为什么在这个字段建索引？）。
4. 部署运维手册：环境要求（JDK版本、MySQL版本）、配置文件说明、启动命令、健康检查接口。如果是微服务，还需要服务注册发现、配置中心的配置方法。
5. 核心业务逻辑说明：用文字辅以流程图，详细说明“库存预占与释放”、“订单状态机”、“支付回调处理”等核心流程的细节和边界条件。

写文档的过程，是第二次设计。它能帮你发现之前考虑不周的地方。我个人的习惯是，在代码开发前先写主要的设计文档和接口定义，开发过程中再不断补充细节。这比事后补文档要高效和准确得多。

8. 从设计到实现：常见坑点与排查实录

即使设计得再完美，实际编码和运行时还是会遇到各种问题。这里分享几个我印象深刻的“坑”。

问题一：超卖依然发生了。

• 现象：监控发现，某个热门航班的已售座位数超过了总座位数。
• 排查：
  1. 检查库存扣减SQL，确认使用了available_seats > 0和version乐观锁。
  2. 检查日志，发现扣减成功的日志条数确实超过了总座位数。
  3. 根因：在“预占-创建订单”这个短链路上，如果创建订单失败，会同步调用库存释放接口。但就是这个“同步调用”在网络超时或服务瞬时异常时失败了！导致预占没有被释放。
• 解决：将“释放预占”这个补偿操作，从同步改为异步+重试。创建订单失败后，发送一条“释放预占”的延迟消息到MQ。由消费者负责重试释放。同时，需要一个后台定时任务，定期扫描状态为RESERVED但已过expires_at时间且没有关联有效订单的预占记录，强制释放。双重保障。

问题二：支付回调处理慢，导致用户看到支付成功但订单还是“待支付”。

• 现象：用户支付后，需要等待十几秒甚至更久，订单状态才更新。
• 排查：
  1. 查看支付回调接口的监控，发现平均RT很高。
  2. 检查代码，发现在回调接口里，除了更新支付状态，还同步调用了积分发放、短信通知、客服系统更新等多个外部接口。
• 解决：严格遵守“回调接口快速响应”原则。在回调接口里，只做最核心的更新支付状态和发布“支付成功”领域事件这两件事，且必须在同一个事务中完成。积分、短信等非关键逻辑，由其他服务监听领域事件后异步执行。改造后，回调接口RT从秒级降到毫秒级。

问题三：航班搜索偶尔特别慢。

• 现象：大部分搜索很快，但偶尔个别查询要好几秒。
• 排查：
  1. 分析慢查询日志，发现慢的SQL都涉及多个OR条件或模糊查询LIKE ‘%xxx%‘。
  2. 这些查询无法有效利用索引。
• 解决：
  • 限制前端复杂的、不可索引的搜索条件，或引导用户使用更精确的搜索。
  • 将复杂的多条件搜索需求，引流到Elasticsearch。ES正是为这种场景而生。
  • 在数据库层面，对于city_name这样的字段，建立“城市名称-城市代码”的映射表，让用户搜索城市代码，而不是直接LIKE城市名。

设计并实现一个民航订票管理系统，就像完成一次完整的全栈演练。它要求你从前端的用户体验，考虑到后端的并发安全；从数据库的表结构设计，权衡到缓存的一致性方案；从单体应用的业务逻辑，演进到微服务间的分布式协作。每一个技术选型的背后，都是对业务需求、性能、一致性和复杂度的一次权衡。把这个项目吃透，不仅仅是学会如何订票，更是掌握了一套应对复杂业务系统挑战的方法论。当你再面对其他业务系统时，这种结构化、分层次、抓核心矛盾的设计思想，会让你游刃有余。最后，记住系统设计的黄金法则：先保证正确性，再优化性能；先简化架构，再应对复杂度。在本地跑通核心流程后，试着用JMeter模拟一下100个用户同时抢10张票的场景，看看你的系统表现如何，那会是另一段有趣的旅程。

本文还有配套的精品资源，点击获取