Expedia Group 将供应商付款交易时间从 1 天缩短到几秒

Expedia Group 拥有 Expedia、Vrbo、Hotels.com 和 Orbitz 等 20 多个预订网站，来自 70 多个国家/地区的旅客通过这些网站以 80 多种货币预订住宿、航班等。作为全球平台企业，其团队需要同时满足消费者和合作伙伴的支付需求。对于合作伙伴付款，Expedia 与供应商（例如酒店、邮轮公司和航空公司）进行互动，这些供应商的预订通过其平台分销。在其 Expedia Collect 模式中，Expedia 从消费者那里收款，然后将款项汇给供应商。2019 年，Expedia 处理了 76 亿 USD 的批发预订，比上一年增加了 25%。

但 Expedia 的增长开始对其应付账款对账 (APRecon) 部门产生影响。随着业务量的增加，任务需要更长的时间来执行，这造成了延迟的级联效应，并最终影响用户的体验。SQL Server 上的 APRecon 还需要大量人工干预，这影响了其运营人员。一些基于 .NET（一个开源开发者平台）的服务导致供应商锁定，限制了服务部署。

Expedia 决定迁移到云中的 Java 微服务驱动架构。Expedia Group 软件开发高级总监 Nirupama Jagarlamudi 解释说：“我们特意在面向微服务的架构中设计新系统，以便轻松使用 AWS 提供的功能进行扩展。”在对 SQL Server 和云产品进行分析和成本比较，以及对 SQL 和 PostgreSQL 进行后续分析后，该公司选择了 Amazon Aurora PostgreSQL。

Expedia 选择分阶段迁移到 Aurora PostgreSQL，并计划从 SQL Server 完全迁移到 AWS。在初始阶段，其首先将住宿业务从 APRecon 系统迁移走，该系统负责处理来自 Expedia 住宿合作伙伴的交易，这部分交易占 SQL Server 总业务量的 80%。数据库开发人员使用名为 Flyway 的新架构迁移工具，将架构从 SQL Server 重构为 Aurora PostgreSQL。“目的是将我们的业务逻辑保留在服务中，这样如果我们需要转移到不同的提供商或服务，我们就可以不受束缚，轻松完成，”Jagarlamudi 解释道。只用大约 2 周的时间便完成数据库迁移（包括架构更新）的开发和测试。重构架构后，该团队开始将构建在 .NET 软件框架上的组件迁移到 Linux 和基于 Java 的开源框架 Spring Boot。现在，Expedia 有 20 个基于 Spring Boot 堆栈构建的微服务。

AWS 上的新系统称为匹配和对帐系统 (MARS)，于 2020 年 5 月上线。它使用 AWS 开源服务，不仅统一了 Expedia 支付技术堆栈，而且打破了供应商锁定。Expedia 使用 Amazon Simple Queue Service (Amazon SQS)（一种完全托管式消息队列服务）来解耦和扩展微服务。“Amazon SQS 是我们通过持久重试功能在流程中构建弹性的一种简单方法，”Jagarlamudi 说。例如，Amazon SQS 与 Amazon Simple Storage Service (Amazon S3) 搭配使用处理供应商请求。后者是一种对象存储服务，可提供行业领先的可扩展性、数据可用性、安全性和性能。这为 Expedia 提供了事件驱动处理能力：Amazon SQS 会就新的供应商请求文件通知该组织，这样其团队就不必从 Amazon S3 中提取它们。

现在，Expedia 可以向其用户、供应商、业务情报部门和运营团队提供近乎实时的数据。所有 Expedia 支付用户，包括 Expedia 门户上的运营用户和外部供应商，都使用 Amazon Elasticsearch Service (Amazon ES)，它使用户能够有效地搜索、分析和可视化未结预订费用。当有新的预订，事件驱动处理流程可以在不到 1 秒的时间内将数据交付给运营团队或供应商，前 99% 的性能为 2.6 秒，而之前的服务器通过批处理需要一天多的时间。然后，MARS 会将结果传送给其用户和 Expedia 的业务情报组织。用户从搜索集群中获取数据，Expedia 使用 Amazon Kinesis Data Streams（一种可大规模扩展且持久的串流服务）来收集、处理和分析来自每个预订的实时串流数据，包括预订日期、停留时间、旅客信息、酒店信息、余额、结算历史和连锁预订。这些关键数据属性使 Expedia 运营团队能够调查问题并支持供应商查询。“我们与业务情报的集成更加灵活，这种模式让其他 Expedia Group 团队能够利用这些数据来履行其业务职能，”Jagarlamudi 说。

得益于微服务驱动架构，MARS 可以扩展以处理突发的、不可预见的流量突增，并在流量下降时缩减规模。例如，Expedia 能够纵向扩展其采购订单服务，以适应 15 个月历史预订的回填，在 2 周内每秒维持 200 笔交易。然后在活动结束时缩减服务规模，以符合正常的流量模式。虽然 Expedia 为 SQL Server 的预置、存储和许可支付固定成本（继续用于尚未迁移的旧式堆栈），但 Aurora 消除了许可费用并提供灵活的成本和基础架构。Expedia 不再需要为其数据中心未使用的容量花钱。“使用 Aurora PostgreSQL 时，我们只需为我们的使用量付费，并且它会随着数据增长而自动调整，”Jagarlamudi 说。这使 Expedia 能够在 COVID-19 疫情期间进行调整。完全托管式 AWS 系统还意味着 Expedia 在维护上花费的时间为零，并且不需要内部数据库管理员。

通过将其遗留系统迁移到 Aurora 并使用其他 AWS 服务，Expedia 降低了数据库成本，打破了供应商锁定，并能够进行扩展以应对流量峰值，同时不必再由内部团队执行手动流程和数据库管理。其还构建了一个系统，可近乎实时地处理预订，为其用户提供快速的性能并实现快速的业务洞察，例如更快地为供应商更新支付活动信息。