分享一次参与交易系统升级项目的经验，具体说明技术选型（如微服务架构）、架构调整与实施过程。
答案
1) 【一句话结论】原单体交易系统在高并发下订单处理量降至5万/秒，响应超时率30%，故障恢复30分钟。升级为微服务架构后，订单处理量提升至8万/秒，响应超时率降至5%，故障恢复缩短至10分钟。
2) 【原理/概念讲解】老师会解释单体架构的性能瓶颈——所有交易模块（订单、撮合、清算）部署在单一进程，共享数据库，高并发时数据库连接池耗尽，响应时间从100ms飙升至500ms以上。微服务架构的核心是“服务拆分+独立部署+轻量级通信”：将订单、撮合、清算拆分为独立服务，每个服务独立部署（如订单服务用Spring Boot+MySQL，撮合服务用gRPC+Redis），通过API网关统一入口，服务间通过Kafka（异步）或gRPC（同步）通信。类比：单体是“大超市”，微服务是“生鲜区、服装区”，每个区域独立运营，顾客去对应区域，超市整体效率提升。
3) 【对比与适用场景】
| 架构类型 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 单体架构 | 所有功能模块部署在单一应用中，共享数据库 | 代码耦合度高，扩展性差，部署复杂 | 业务逻辑简单，团队小，开发周期短 | 难以应对高并发，故障影响全系统 |
| 微服务架构 | 将应用拆分为一组小型、独立的服务，每个服务运行在自己的进程中 | 服务独立部署，低耦合，技术异构 | 业务复杂，需要快速迭代，高并发场景 | 服务间通信开销，数据一致性挑战，运维复杂 |
4) 【示例】以订单服务为例，展示接口和流程。订单服务（OrderService）的订单创建接口：
- 接口：POST /orders
- 请求体（JSON）：
{
"userId": "user123",
"stockCode": "600000",
"price": 10.5,
"quantity": 100
}
- 响应：
{
"orderId": "order-20231026-001",
"status": "pending"
}
架构调整后，订单服务独立部署，通过API网关接收请求，调用MySQL存储订单数据，并调用Kafka发送消息至撮合服务，触发价格匹配流程。
5) 【面试口播版答案】各位面试官好，我分享一次参与交易系统升级的经验。原单体架构在高并发交易时，订单处理量从10万/秒降至5万/秒，响应超时率30%，故障恢复需30分钟。我们采用微服务架构重构，将订单、撮合、清算拆分为独立服务。技术选型上，订单服务用Spring Boot+MySQL，撮合服务用gRPC+Redis（缓存撮合结果），清算服务用Python+Kafka+MySQL。实施分三步：第一步拆分服务，定义RESTful接口规范；第二步容器化部署（Docker+K8s），实现弹性伸缩；第三步引入Kafka处理异步流程，提升吞吐量。压力测试显示，系统性能提升约30%，故障恢复时间从30分钟缩短到10分钟。
6) 【追问清单】
- 问题1：微服务拆分的边界是如何确定的？比如订单服务是否应包含清算逻辑？
回答要点：根据业务职责拆分，订单服务负责订单全生命周期（创建、查询、取消），清算服务负责资金结算，通过消息队列异步触发，避免职责交叉。 - 问题2：技术选型中为什么选择gRPC而非RESTful？比如性能对比？
回答要点：gRPC基于HTTP/2，支持二进制传输，比RESTful延迟降低20%，吞吐量提升15%，适合高并发服务间通信。 - 问题3：如何保证微服务间的数据一致性？比如订单状态与资金状态的一致性？
回答要点：采用最终一致性，通过消息队列异步通知，结合补偿机制处理失败场景。 - 问题4：实施过程中遇到的最大挑战是什么？如何解决的？
回答要点：服务拆分后的数据一致性挑战，引入Seata分布式事务和Kafka确保异步流程的可靠性。
7) 【常见坑/雷区】
- 坑1：过度拆分服务，导致服务间通信开销过大，反而降低性能。
- 雷区2：忽略数据一致性，导致业务逻辑错误，如订单已撮合但资金未到账。
- 坑3：未考虑团队协作，微服务架构需跨团队沟通，若沟通不畅导致开发效率低下。
- 雷区4：技术选型过于复杂，如引入过多新技术，导致运维成本高。
- 坑5：未做充分压力测试，架构调整后未验证高并发下的稳定性。