Expedia Global 將供應商付款交易從 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) (一種全受管訊息佇列服務) 來分離和擴展微型服務。Jagarlamudi 表示：「Amazon SQS 是我們透過持久的重試功能在程序中建置復原能力的簡單方法。例如，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 個月的歷史預訂回填，在兩週期間內每秒維持處理 200 筆交易。然後，它會在活動結束時縮減服務，以符合正常的流量模式。並且，Expedia 透過 SQL Server 支付佈建、儲存和授權的固定成本，這些成本會繼續用於尚未遷移的舊式堆疊；相比之下，Aurora 可省去授權費用，並提供靈活的成本和基礎設施。Expedia 的資料中心不再需要購買未使用的容量。「使用 Aurora PostgreSQL 時，我們只需為我們的用量付費，並且它會隨著資料增長而自動調整。」Jagarlamudi 說道。這使 Expedia 能夠在 COVID-19 疫情期間進行調整。全受管 AWS 系統還意味著 Expedia 在維護上花費的時間為零，並且不需要內部資料庫管理員。

透過將其舊式系統遷移到 Aurora 並使用其他 AWS 服務，Expedia 降低了資料庫成本，打破了供應商鎖定，並能夠進行擴展以應對流量尖峰，同時不必再由內部團隊執行手動程序和資料庫管理。公司還建置一個系統，以近乎即時的方式處理預訂，為用戶提供快速的效能並實現快速的業務洞見，例如為供應商提供更快的付款活動更新。