作者簡介

唐巍，攜程用戶平臺部訂單服務組資深后端開發，在互聯網尤其是移動互聯網方面有豐富的經驗，目前主要負責OrderIndex的維護和架構升級工作。

經過團隊幾個月的努力，我們最近終于完成了OI（訂單索引服務）從1.0到2.0升級的里程碑，上線了新的數據同步平臺和對應的數據查詢服務。在這里我們總結了其中的經驗和心得，希望能給大家，尤其是有做跨多業務線或者復雜系統需要升級改造的同學們，一點啟發或者是幫助。

?

一、什么是OI？

攜程的眾多業務線訂單信息分布在各業務線不同的訂單系統之中，有各自獨立的查詢服務，而公司內部又存在著大量跨業務線查詢統一訂單信息的訴求，為解決這樣的痛點，OI 項目應運而生。

OI的全稱是OrderIndex（訂單索引服務），是“攜程APP-我的攜程-訂單列表”的訂單信息數據源，是一個以“聚合不同數據來源的訂單信息，并提供統一分類查詢功能”為核心業務的系統。

?

二、OI 1.0

OI1.0是目前支撐OI業務的主力系統，上線于2013年。查詢服務基于公司的SOA服務治理平臺開發。訂單同步和輔助Job基于公司的作業調度平臺（JosWS）開發。

??????

其中核心機制如下圖。

OI 1.0的訂單同步機制

? ? ? ? ? ? ? ? ? ? ? ? ? ?

數據同步以及下發流程如下：

1）對應業務線訂單的訂單同步Job，從業務線的訂單數據庫通過掃描相關表的時間戳，來感知訂單變化（獲取變化的訂單號orderid）；

2）通過業務線提供的拉取訂單詳情的SQL從業務線訂單數據庫讀取訂單詳情相關數據；

3）根據業務線提供的業務，將從業務線數據庫拉取的訂單詳情相關數據轉化為實際的訂單數據，并規整后保存到OI的數據庫中；

4）在OI的接口調用方通過SOA服務來查詢訂單信息的時候，將我們同步過來的訂單信息透傳下發；

?

基于這樣的架構和機制，截止目前，OI 1.0聚合了超過50+數據源，160+業務線的訂單數據，總量超過5億條。并通過實時數據查詢服務以及訂單變更消息通知以毫秒級的訂單同步延遲，支撐了下游超過200個系統共計日均4億+次的訂單查詢需求，并且，這些數字還在不斷的變大。可以預見，OI 在之后還會承擔更重要的責任。

雖然目前OI 1.0看起來仍然運行良好，但是隨著 OI 業務的不斷擴展，我們也發現了一些問題。

?

1）業務線提供的數據源只支持直連DB，并且需要提供的接入信息非常復雜

• 需要Db提供生產核心訂單庫的訪問權限，有安全風險

• 需提供所有相關表的表結構以及字段說明，并提供跟實際訂單信息之間的關聯轉化邏輯

• 絕大部分情況下，訂單的信息變更必須反映到訂單主表的時間戳變更上，否則無法感知到訂單變化

?

2）業務線提供的訂單數據源結構各不相同，還需結合配套業務使用

• 訂單接入和修改需要我方產品、開發、和測試人員理解業務線的所有相關業務，并理解其原始數據到 OI 數據的轉化過程，溝通成本和出錯率高，響應也相對較慢（上線周期長），易出錯。

• 由于各接入方數據不標準，驗證數據和業務的正確性需要熟悉業務的開發、測試人員人工進行，比對點和工作量都很大。

?

3）大量的訂單接入方（業務線），和 OI 服務的調用方希望我們接入大量的非標準字段，由于舊系統的各種限制，往往難以支持或者周期漫長

• 1.0系統并不支持擴展字段的添加，所有的擴展字段添加都需要定制開發（從指定?db?指定表的指定字段獲取數據，再經過某種業務進行處理，最后落我們空余的某個 db?字段），若無空余字段，則無法支持

• 由于1.0系統中我們的字段大多有固定含義，所以能借用存放的空余字段不多

• 由于借用空余字段的存放，所以下發的部分字段，在不同場景下有不同的含義，數據使用方需知業務線原始業務，以及 OI 的字段命名映射邏輯（OI 下發的數據字段名跟業務方字段名不同）

?

4）OI感知訂單變化依賴于業務線提供的 Sql 定制開發，出于對性能考慮通常只能掃描訂單主表的變更，若訂單變更有獨立于訂單主表之外的，感知訂單變化的部分的實現會特別復雜。

• 一旦業務線修改感知訂單變化的業務或者新加渠道，OI 都需要重新修改代碼，或者新增 Job 支持

• 訂單直接物理刪除，感知不到變化，需業務線配合，新增物理刪除訂單信息同步

?

5）同步 Job 依賴于公司的 Job 調度平臺，由于調度平臺的限制，

• 每新增一個 Job 都需要開發一個對應的 Job 類，并發布代碼，流程長，風險大

• 若一個實例需要多活，需要在 Job 調度平臺中針對每個實例，單獨手工配置 Job 調度任務

?

6）公司內的合作部門，有數據接入 OI 的需求，但是因為目前系統的實現機制評估下來工作量，以現有的人力完全無法支撐。

?

下圖是我們迫切需要解決的問題：

于是我們決定對 OI 進行改造升級，徹底解決這些問題。

三、OI 2.0

首先，我們對于 OI 進行了重新定義：

OI 是一個提供了基于標準化流程接入，針對訂單數據提供統一匯聚、檢索、輸出、管理的數據平臺。

基于全新的定位，重新設計了OI，新的架構如下：

OI 2.0的系統架構

?

主要改造方向有如下幾點：

針對訂單變更檢測重新設計，提供新的接入方案。

1）業務線訂單服務在更新訂單時推送變更消息。

優點：時延最短

缺點：需業務線配合，開發成本高

2）基于訂單數據庫相關表的 Binlog 通過 Canal 組件推送變更消息。

優點：時延可以接受<500ms，開發成本極低

缺點：中間環節多，故障點增多，并且只支持mysql數據庫

3）擴展了基于 sql 的變更檢測，無需業務線再提供 sql，而是提供關聯 db 信息。

優點：中間環節少，時延較低(<200ms)

缺點：耦合高，依賴業務線數據庫訪問權限

?

?訂單詳情標準服務化改造

我們針對獲取訂單詳情方式進行了重新設計，拋棄了過去通過 sql 直連 db 讀取數據，在同步 Job 中進行轉化的模式，重新抽象了訂單的基礎 MetaData，并以此為基礎設計了一套新的標準詳情服務接口契約，以此將業務進行抽像，將具體的業務實現從 OI 中剝離了出來，返還給了業務線。

OI平臺化

?

將訂單變更檢測和訂單詳情數據源，以及訂單的部分特殊標準信息（如訂單狀態等）全部作為meta通過統一配置管理平臺來進行管理，并且自研了 Job調度模塊以支持根據配置的數據源 MetaData，動態的生成同步 Job 來執行數據同步任務，并進行數據校驗。

同樣，SOA 數據查詢服務基于相同的 MetaData， 來提供數據查詢服務。

基于新的設計，訂單同步流程也采用了新的模式。

平臺化后的訂單同步流程

1）首先，將需要同步的數據源 Meta 信息通過配置管理錄入。

2）OI 同步平臺根據數據源 Meta 信息生成同步 Task 和對應的同步 Job （若同一數據源有配置多種感知渠道，則生成多組同步 Task 及對應 Job）。

3）通過配置的訂單感知渠道（db，消息隊列，SOA服務），感知訂單變化。

4）通過統一的標準 Facade Order Detail Service 獲取，標準 MetaData 描述的訂單信息。

5）將訂單信息經過校驗和變更比對后，更新（加入）到 OI 數據庫。

6）通過標準 MetaData 的訂單實體信息查詢接口，將訂單數據下發給服務調用方。

四、OI 2.0平臺化，我們做了哪些具體的工作？

4.1 重新設計了統一接入信息模板，通過統一配置管理服務管理

基于平臺化后的系統，重新設計了一份標準訂單接入的信息模板，用來取代之前跟每個業務線針對所有數據源逐一討論商定的接入信息文檔。（不過暫時不支持接入方自主錄入，需線下提供，審核完畢后，再錄入Meta信息）。通過這個改變，將過去接入過程中貫穿始末的業務討論時長從數周縮短到了一兩次會議（電話或者面談）就能溝通完畢的程度。

4.2 自研 Job 調度系統（JobHost）

我們放棄了使用公司已有的成熟通用 Job 調度系統，自研了一套 OI 定制的Job 調度系統，通過定制開發，支持了一些原本很難實現的功能。

1）結合統一信息模板，極大的簡化了訂單同步 Job 的復雜度，OI 的JobHost 默認會基于配置動態生成常規（Normal）同步 Task，同時也支持手工指定要同步的數據源來生成任意多個自定義的同步 Task（如針對部分數據進行數據清洗的補償 Job，OI 1.0由于設計原因僅支持一個），并支持通過對數據源的開啟標志的控制，實現對相關Job的實時聯動控制（公司的調度系統需手工操作）。

2）運行狀態監控粒度更細，由于定制開發，所以針對各種 Job 的不同運行步驟，設置了更豐富的監控點，更好的了解 Job 的運行狀態。

3）除了守護 Task 會保持心跳，檢查 JobHost 中運行的 Job 健康狀態，嘗試進行自動恢復外，我們還設計了人工干預的機制，可以針對運行在每一個實例中的任意 Job 進行更細微的調整。

4.3 自研的數據查詢引擎（Sql+內存過濾, 根據策略編譯查詢條件）

為增加數據平臺對異構數據存儲結構的支持以及提供特定場景下的db數據讀取優化，我們自研了一套簡易的數據查詢引擎。

上層服務只需要將數據查詢請求，轉化成平臺統一的 OrderQuery，再注入一套 OrderQuery 編譯策略，以支持將 OrderQuery 中的查詢請求和過濾條件，轉化為 DB 執行的 SQL語句以及內存中過濾的OrderFilter（同一過濾條件，在不同場景下通過SQL直接過濾，或者內存中過濾，效率可能會不同，查詢引擎會根據編譯策略，選擇將該過濾條件build進sql語句中，或者是生成對應的OrderFilter）。

?

五、改造完成后的成果

前面零零散散講了很多細節，大家對改造效果可能沒有很直觀的認識，我們再來看一張圖。

這是我們在確認改造方案后，第一階段的整體目標。

1）通過平臺化改造以后，OI 不用再針對每一個業務線（訂單業務類型）做定制開發，通過平臺提供統一支持即可，整體復雜度降到了 O(1)，即使不熟悉 OI 的訂單接入方，或者組內同學，又或者測試的同學，憑著簡單的文檔，也可以直接上手了，不用業務線再提供 sql 和 db 字段說明，也不用再提供 db 字段到實際訂單數據的業務邏輯。

2）改造完成后，新接入一種訂單（數據源），或者下線一個數據源只需要通過配置管理配置好數據源的 MetaData 即可，無需修改代碼，也無需重啟服務，實現了熱插拔和熱更新。

3）通過標準詳情接口，將溢出到 OI 的業務線訂單業務徹底歸還業務線，業務線業務發生變動的時候，直接同步修改詳情接口實現即可，無需再拉上 OI 一起排期改造，效率大大增加。

4）結合1-3帶來的效率提升，在 OI2.0 數據平臺上進行業務變動，在業務線準備好的情況下，基本上都能實現T+0上線。

5）基于全新的標準化改造，我們可以針對不同運行環節增加統一的監控點，實現更靈活的監控擴展。

最后，來看一張圖：

這是之前，第一個里程碑完成時的 OI2.0交付情況。目前OI數據平臺，已經能夠多訂單系統復用，支持攜程訂單體系和集團的某關聯企業訂單體系。

基于這還算堅實的第一步，我們會繼續一步一個腳印，繼續去完成我們所描繪的藍圖。

【推薦閱讀】

• 攜程機票 React Native 整潔架構實踐

• React Hook的實現原理和最佳實踐

• 日部署 6000 次，攜程持續交付與構建平臺實踐

• 前端如何實現業務解耦，攜程酒店查詢首頁的1.0到3.0

• 揭秘 Vue 3.0 最具潛力的 API

總結

以上是生活随笔為你收集整理的干货 | 跨多业务线挑战下，携程订单索引服务的1.0到2.0的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。