Day33-11｜14.4.1 某旅行公司云原生改造：高峰流量下的业务与架构演进

一、教材定位与学习目标

14.4.1“某旅行公司云原生改造”是云原生章节中的典型行业案例。旅行平台具有明显的季节性和突发性：节假日、热门演唱会、极端天气和临时促销会使搜索、库存查询和订单请求在短时间内快速增长；酒店、机票、景区和支付等外部系统又具有不同的接口、容量和一致性约束。因此，这类系统不能简单依赖增加服务器解决问题，而要通过业务边界、缓存、消息、弹性、限流、降级和供应商适配构建完整架构。

本篇学习目标是：

1. 识别旅行平台传统架构在高峰、外部依赖和快速变化方面的瓶颈。
2. 设计搜索、库存、订单、支付和营销等业务能力的云原生边界。
3. 说明缓存、消息、限流、弹性和降级如何配合保护核心交易。
4. 设计对接酒店、航司和支付供应商的适配器与可靠性机制。
5. 按案例题要求完成现状分析、改造方案、迁移步骤和效果验证。

二、业务背景与架构挑战

某旅行公司经营机票、酒店和景区门票业务，用户通过 Web、移动端和合作渠道查询产品、比较价格、下单、支付和办理退改。系统还需要接入多个航空公司、酒店集团、票务供应商和支付平台。原系统采用单体应用和固定服务器，商品、库存、订单、会员、促销和供应商适配代码混在一起。

在日常流量下系统基本可用，但在长假前和热门目的地促销时出现以下问题：

这些问题同时涉及性能、可用性、一致性、可维护性和成本。改造不能只选择一个技术，而要针对不同业务特征选择不同模式。

三、总体云原生改造目标

改造目标可以归纳为四类：

1. 高峰可承载：搜索和浏览流量增加时能够快速扩展，非核心功能不会挤占交易资源。
2. 核心交易可控：库存、订单和支付有明确状态、幂等和补偿策略，不能因为重复请求造成错误结果。
3. 供应商可隔离：外部航司、酒店和支付接口通过适配器接入，某个供应商故障不会拖垮全部业务。
4. 持续可交付：搜索、营销、推荐等变化频繁的能力可以独立发布，具备灰度、回滚和可观测能力。

总体结构可以表示为：

Web / App / 合作渠道
         ↓
CDN/WAF/API网关：认证、路由、限流、聚合
         ↓
产品搜索、价格、库存、订单、支付、会员、营销服务
         ↓
消息平台、缓存、搜索引擎、关系数据库、对象存储、分析平台
         ↓
航空/酒店/景区/支付供应商适配器

平台层横向提供配置、服务发现、密钥、日志、指标、追踪、流水线和资源治理。供应商适配器可以独立扩展和熔断，不能让第三方错误码直接泄露到核心订单模型。

四、业务边界与服务设计

4.1 搜索与产品目录

搜索服务负责目的地、日期、价格区间、房型和航班等条件查询，使用搜索索引和缓存提升读性能。它可以返回候选产品，但不应把搜索结果视为最终库存承诺。产品和价格数据通过批量同步或事件更新，需带有版本和有效时间。

4.2 库存与预订

库存服务负责可售数量、预占、确认和释放。旅行产品库存可能由外部供应商掌握，本地服务要明确“本地库存”“供应商实时确认”和“预订处理中”三种状态，不能简单把一个缓存数字当成权威。

4.3 订单与支付

订单服务负责订单生命周期、金额快照和退改状态；支付服务负责支付单、回调和对账。订单服务不应直接调用支付供应商数据库，支付成功也不能只依赖浏览器跳转。支付回调需验签、核对订单和金额，并使用支付流水号幂等处理。

4.4 会员与营销

会员服务负责身份、等级和权益，营销服务负责优惠规则、优惠券和活动配置。营销规则变化频繁，可以独立发布，但最终优惠结果应记录到订单中，历史订单不能因规则变化而重新计算。

4.5 供应商适配

不同供应商的请求格式、认证、错误码、超时和退改规则不同。适配器将供应商协议转换为内部标准模型，并负责限流、重试、熔断、签名、映射和审计。核心业务只使用标准接口和状态，不直接依赖供应商 SDK。

五、搜索与缓存架构

旅行平台的搜索流量远大于下单流量，适合采用读写分离、搜索索引、缓存和内容分发。热门目的地、酒店详情和静态图片可以缓存；动态库存和价格必须设置短有效期，或者在下单时再次向权威来源确认。

缓存设计要考虑穿透、击穿和雪崩。对不存在的目的地或产品可以缓存空结果并设置较短时间；热点键失效时使用互斥更新或请求合并；大量缓存同时过期时使用随机过期时间和预热；缓存故障时应限制回源，避免数据库被瞬间冲击。

搜索索引不是交易权威数据。索引更新延迟时，用户看到的产品可能已经售罄，订单流程必须重新校验。搜索服务可以接受最终一致，而库存和订单服务需要更严格的业务约束。

六、订单与库存一致性

6.1 订单状态机

旅行订单可以包含待确认、待支付、已支付、出票或已预订、待出行、已完成、取消中、已取消和退款中等状态。状态迁移要由业务服务控制，并记录事件、时间、操作者和供应商流水。

6.2 预占与确认

如果供应商支持预占，可以先创建本地订单并请求供应商预占，成功后进入待支付；支付超时则释放本地和供应商资源。如果供应商只能实时确认，系统需要把外部确认结果作为异步状态，并向用户展示处理中。不可把“请求已发送”误认为“预订成功”。

6.3 幂等与补偿

用户重复点击、网关重试、供应商回调重发都很常见。订单创建使用用户请求幂等键，库存预占使用订单号，支付回调使用供应商流水号，退改操作使用业务操作编号。失败时通过重试、补偿、人工审核和对账闭环，避免只依赖数据库状态猜测。

七、外部依赖治理

供应商接口的可靠性和容量不可完全控制，因此每个适配器要设置连接超时、读取超时、整体截止时间和并发上限。对临时网络错误可以有限重试，对业务拒绝和参数错误应快速失败；某供应商持续异常时熔断并切换备用供应商或展示处理中。

不同产品不能简单共用一个线程池。酒店搜索供应商慢，不应耗尽订单预订线程；支付接口异常，不应阻塞退款查询和订单展示。可以按供应商、业务优先级和操作类型进行线程池、连接池和并发隔离。

供应商降级要有业务定义。例如推荐供应商不可用时可以关闭推荐；某酒店库存查询失败时可以展示缓存并标记需实时确认；支付状态未知时不能直接判定失败或成功，应进入查询和对账流程。降级结果要可解释，避免用户获得误导信息。

八、流量治理与弹性

入口网关按照渠道、用户、接口和优先级限流，搜索和详情可以共享弹性资源，订单和支付使用独立资源池。自动扩缩可以根据请求数、P95 延迟、队列长度和业务成功率触发，但要考虑实例启动时间和供应商承载力。

大促前应进行容量预估和预热，不能完全依赖实时扩容。缓存、搜索索引和连接池提前准备，非核心任务延后处理；高峰期间可以使用排队、预约和分级服务。扩容后如果所有实例同时查询相同热点或打开大量数据库连接，反而会加重故障，因此弹性必须覆盖下游资源。

九、事件驱动与异步处理

订单创建、支付完成、库存确认和退改结果可以发布领域事件，供通知、积分、报表、搜索索引和数据分析消费。事件平台要持久化消息，记录事件编号、版本、业务键和处理状态；消费者必须幂等，失败后采用延迟重试和死信。

异步化不等于用户永远看不到结果。订单页面应展示处理中、确认失败或待人工处理等业务状态，并提供查询和刷新机制。核心决策与后续动作的边界要清楚：库存和支付确认可能决定订单状态，短信、推荐和报表通常可以异步。

十、云原生交付与可观测

服务使用不可变镜像和统一流水线交付，流水线包含单元测试、契约测试、供应商模拟测试、镜像扫描、部署、灰度和回滚。外部供应商不能在每次测试中直接调用生产接口，应使用沙箱、模拟器和录制回放，并对真实回调做脱敏验证。

可观测性要同时覆盖技术和业务：入口请求率、服务延迟、数据库连接、缓存命中、消息积压、供应商错误率、订单成功率、支付完成率、库存异常率和退款时长。每次请求贯穿请求标识、订单号、供应商流水号、服务版本和地区信息。敏感数据必须脱敏，审计日志独立留存。

十一、迁移实施路径

旅行平台不适合一次性重写。可采用以下阶段：

1. 盘点业务、依赖、数据和质量目标，先建设流水线、日志、指标和追踪。
2. 将静态内容、图片、搜索和读多写少的查询能力迁移到云资源，验证缓存和弹性。
3. 从单体中抽取供应商适配层和支付回调等边界清晰的模块，建立标准接口。
4. 逐步拆分订单、库存和营销能力，明确数据所有权和状态机，保留旧系统回退路径。
5. 通过双写、事件同步或适配层完成数据衔接，按流量、地区或渠道灰度切换。
6. 进行峰值压测、供应商故障、重复回调、数据库恢复和回滚演练，最后清理旧链路。

每一步都要定义成功标准和退出条件。例如搜索迁移要验证结果正确率、索引延迟、缓存命中和回源压力；订单迁移要验证状态一致、支付对账和故障恢复，不能只看服务是否启动。

十二、案例题参考答题框架

答题时可以按“问题—架构—机制—验证”四段写：

1. 问题：固定容量、单体耦合、供应商同步依赖、库存不准、发布风险和缺少观测。
2. 架构：网关、搜索、库存、订单、支付、营销服务，消息、缓存、搜索、数据库和供应商适配器，平台统一治理。
3. 机制：无状态弹性、缓存保护、限流熔断、线程池隔离、订单状态机、幂等、可靠消息、补偿和对账。
4. 验证：峰值压测、供应商故障、重复回调、数据校验、灰度回滚和业务指标监控。

若题目要求说明权衡，还要写明搜索和推荐允许最终一致，库存和支付需要更严格校验；服务拆分提高独立扩展和发布能力，但增加网络与治理成本；按量资源降低低峰浪费，但需要成本监控和容量边界。

十三、课后练习

练习一：选择题

旅行平台的酒店搜索结果显示“有房”，但用户下单时仍需再次确认库存，主要原因是（ ）。

A. 搜索索引和真实库存可能存在延迟，搜索结果不是交易权威

B. 浏览器一定会修改库存

C. 缓存永远不能使用

D. 订单服务不需要库存服务

答案：A。 搜索和缓存适合提升读取性能，但动态库存可能变化，最终订单必须在权威服务或供应商处重新确认。

练习二：简答题

请说明旅行平台为什么需要供应商适配器。

参考答案： 不同航司、酒店和支付供应商的协议、认证、字段、错误码、超时和退改规则不同。适配器负责协议转换、字段映射、签名、错误统一、超时重试和审计，使核心业务只依赖稳定的内部接口；同时可以对每个供应商独立限流、熔断和升级，避免第三方差异扩散到订单和库存核心逻辑。

练习三：案例题

某旅行平台大促期间搜索服务大量回源，数据库连接耗尽，订单也无法提交。请分析并提出改进。

参考答案： 可能存在热点缓存同时失效、缓存击穿、搜索结果未充分使用索引、搜索与订单共享数据库连接池和资源池等问题。应使用搜索索引和分层缓存，设置随机过期和请求合并，缓存失效时限制回源并保护数据库；搜索和订单使用独立服务、连接池和资源配额；入口按接口和优先级限流，搜索过载时返回缓存或简化结果，不能影响订单核心；订单和支付设置独立资源和超时；大促前预热热点数据并进行端到端压测。通过缓存命中率、回源量、数据库连接、搜索延迟和订单成功率验证改进效果。

十四、论文写作素材

本案例适合用于“论旅游平台云原生改造”“论高峰流量下的微服务架构设计”或“论外部依赖治理”。论文背景写节假日峰值、供应商异构和旧系统单体瓶颈；正文重点展开搜索缓存、订单库存一致性、供应商适配、限流熔断、事件驱动和渐进迁移；结尾写搜索延迟、订单成功率、供应商故障影响范围和发布周期等效果。

写作时尤其要突出业务权衡：不能为了搜索速度直接承诺实时库存，也不能为了强一致把所有供应商调用放入一个长事务。要说明哪些数据允许短暂不一致，哪些结果必须重新确认，以及发生异常后如何通过状态机、补偿和对账恢复。

十五、今日复盘清单

• 我能否说出旅行平台的流量峰值和外部依赖特点？
• 我能否区分搜索结果、缓存数据和交易权威库存？
• 我能否画出订单、库存、支付和供应商适配器的关系？
• 我能否说明缓存保护、限流、隔离、熔断和降级如何配合？
• 我能否设计重复下单、支付回调和供应商超时的处理方式？
• 我能否给出不间断迁移、灰度、回滚和效果验证方案？

本节的核心结论是：旅行公司的云原生改造必须以业务边界和高峰场景为中心，将搜索、交易和外部供应商分层治理，通过缓存、弹性、限流、隔离、状态机、幂等、消息和补偿保护核心链路，再以自动化交付和可观测性支撑渐进迁移与持续演进。