作者簡介

唐巍，攜程用戶平臺部訂單服務(wù)組資深后端開發(fā)，在互聯(lián)網(wǎng)尤其是移動互聯(lián)網(wǎng)方面有豐富的經(jīng)驗，目前主要負責(zé)OrderIndex的維護和架構(gòu)升級工作。

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

?

一、什么是OI？

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

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

?

二、OI 1.0

OI1.0是目前支撐OI業(yè)務(wù)的主力系統(tǒng)，上線于2013年。查詢服務(wù)基于公司的SOA服務(wù)治理平臺開發(fā)。訂單同步和輔助Job基于公司的作業(yè)調(diào)度平臺（JosWS）開發(fā)。

??????

其中核心機制如下圖。

OI 1.0的訂單同步機制

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

數(shù)據(jù)同步以及下發(fā)流程如下：

1）對應(yīng)業(yè)務(wù)線訂單的訂單同步Job，從業(yè)務(wù)線的訂單數(shù)據(jù)庫通過掃描相關(guān)表的時間戳，來感知訂單變化（獲取變化的訂單號orderid）；

2）通過業(yè)務(wù)線提供的拉取訂單詳情的SQL從業(yè)務(wù)線訂單數(shù)據(jù)庫讀取訂單詳情相關(guān)數(shù)據(jù)；

3）根據(jù)業(yè)務(wù)線提供的業(yè)務(wù)，將從業(yè)務(wù)線數(shù)據(jù)庫拉取的訂單詳情相關(guān)數(shù)據(jù)轉(zhuǎn)化為實際的訂單數(shù)據(jù)，并規(guī)整后保存到OI的數(shù)據(jù)庫中；

4）在OI的接口調(diào)用方通過SOA服務(wù)來查詢訂單信息的時候，將我們同步過來的訂單信息透傳下發(fā)；

?

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

雖然目前OI 1.0看起來仍然運行良好，但是隨著 OI 業(yè)務(wù)的不斷擴展，我們也發(fā)現(xiàn)了一些問題。

?

1）業(yè)務(wù)線提供的數(shù)據(jù)源只支持直連DB，并且需要提供的接入信息非常復(fù)雜

• 需要Db提供生產(chǎn)核心訂單庫的訪問權(quán)限，有安全風(fēng)險

• 需提供所有相關(guān)表的表結(jié)構(gòu)以及字段說明，并提供跟實際訂單信息之間的關(guān)聯(lián)轉(zhuǎn)化邏輯

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

?

2）業(yè)務(wù)線提供的訂單數(shù)據(jù)源結(jié)構(gòu)各不相同，還需結(jié)合配套業(yè)務(wù)使用

• 訂單接入和修改需要我方產(chǎn)品、開發(fā)、和測試人員理解業(yè)務(wù)線的所有相關(guān)業(yè)務(wù)，并理解其原始數(shù)據(jù)到 OI 數(shù)據(jù)的轉(zhuǎn)化過程，溝通成本和出錯率高，響應(yīng)也相對較慢（上線周期長），易出錯。

• 由于各接入方數(shù)據(jù)不標(biāo)準(zhǔn)，驗證數(shù)據(jù)和業(yè)務(wù)的正確性需要熟悉業(yè)務(wù)的開發(fā)、測試人員人工進行，比對點和工作量都很大。

?

3）大量的訂單接入方（業(yè)務(wù)線），和 OI 服務(wù)的調(diào)用方希望我們接入大量的非標(biāo)準(zhǔn)字段，由于舊系統(tǒng)的各種限制，往往難以支持或者周期漫長

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

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

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

?

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

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

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

?

5）同步 Job 依賴于公司的 Job 調(diào)度平臺，由于調(diào)度平臺的限制，

• 每新增一個 Job 都需要開發(fā)一個對應(yīng)的 Job 類，并發(fā)布代碼，流程長，風(fēng)險大

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

?

6）公司內(nèi)的合作部門，有數(shù)據(jù)接入 OI 的需求，但是因為目前系統(tǒng)的實現(xiàn)機制評估下來工作量，以現(xiàn)有的人力完全無法支撐。

?

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

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

三、OI 2.0

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

OI 是一個提供了基于標(biāo)準(zhǔn)化流程接入，針對訂單數(shù)據(jù)提供統(tǒng)一匯聚、檢索、輸出、管理的數(shù)據(jù)平臺。

基于全新的定位，重新設(shè)計了OI，新的架構(gòu)如下：

OI 2.0的系統(tǒng)架構(gòu)

?

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

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

1）業(yè)務(wù)線訂單服務(wù)在更新訂單時推送變更消息。

優(yōu)點：時延最短

缺點：需業(yè)務(wù)線配合，開發(fā)成本高

2）基于訂單數(shù)據(jù)庫相關(guān)表的 Binlog 通過 Canal 組件推送變更消息。

優(yōu)點：時延可以接受<500ms，開發(fā)成本極低

缺點：中間環(huán)節(jié)多，故障點增多，并且只支持mysql數(shù)據(jù)庫

3）擴展了基于 sql 的變更檢測，無需業(yè)務(wù)線再提供 sql，而是提供關(guān)聯(lián) db 信息。

優(yōu)點：中間環(huán)節(jié)少，時延較低(<200ms)

缺點：耦合高，依賴業(yè)務(wù)線數(shù)據(jù)庫訪問權(quán)限

?

?訂單詳情標(biāo)準(zhǔn)服務(wù)化改造

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

OI平臺化

?

將訂單變更檢測和訂單詳情數(shù)據(jù)源，以及訂單的部分特殊標(biāo)準(zhǔn)信息（如訂單狀態(tài)等）全部作為meta通過統(tǒng)一配置管理平臺來進行管理，并且自研了 Job調(diào)度模塊以支持根據(jù)配置的數(shù)據(jù)源 MetaData，動態(tài)的生成同步 Job 來執(zhí)行數(shù)據(jù)同步任務(wù)，并進行數(shù)據(jù)校驗。

同樣，SOA 數(shù)據(jù)查詢服務(wù)基于相同的 MetaData， 來提供數(shù)據(jù)查詢服務(wù)。

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

平臺化后的訂單同步流程

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

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

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

4）通過統(tǒng)一的標(biāo)準(zhǔn) Facade Order Detail Service 獲取，標(biāo)準(zhǔn) MetaData 描述的訂單信息。

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

6）通過標(biāo)準(zhǔn) MetaData 的訂單實體信息查詢接口，將訂單數(shù)據(jù)下發(fā)給服務(wù)調(diào)用方。

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

4.1 重新設(shè)計了統(tǒng)一接入信息模板，通過統(tǒng)一配置管理服務(wù)管理

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

4.2 自研 Job 調(diào)度系統(tǒng)（JobHost）

我們放棄了使用公司已有的成熟通用 Job 調(diào)度系統(tǒng)，自研了一套 OI 定制的Job 調(diào)度系統(tǒng)，通過定制開發(fā)，支持了一些原本很難實現(xiàn)的功能。

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

2）運行狀態(tài)監(jiān)控粒度更細，由于定制開發(fā)，所以針對各種 Job 的不同運行步驟，設(shè)置了更豐富的監(jiān)控點，更好的了解 Job 的運行狀態(tài)。

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

4.3 自研的數(shù)據(jù)查詢引擎（Sql+內(nèi)存過濾, 根據(jù)策略編譯查詢條件）

為增加數(shù)據(jù)平臺對異構(gòu)數(shù)據(jù)存儲結(jié)構(gòu)的支持以及提供特定場景下的db數(shù)據(jù)讀取優(yōu)化，我們自研了一套簡易的數(shù)據(jù)查詢引擎。

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

?

五、改造完成后的成果

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

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

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

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

3）通過標(biāo)準(zhǔn)詳情接口，將溢出到 OI 的業(yè)務(wù)線訂單業(yè)務(wù)徹底歸還業(yè)務(wù)線，業(yè)務(wù)線業(yè)務(wù)發(fā)生變動的時候，直接同步修改詳情接口實現(xiàn)即可，無需再拉上 OI 一起排期改造，效率大大增加。

4）結(jié)合1-3帶來的效率提升，在 OI2.0 數(shù)據(jù)平臺上進行業(yè)務(wù)變動，在業(yè)務(wù)線準(zhǔn)備好的情況下，基本上都能實現(xiàn)T+0上線。

5）基于全新的標(biāo)準(zhǔn)化改造，我們可以針對不同運行環(huán)節(jié)增加統(tǒng)一的監(jiān)控點，實現(xiàn)更靈活的監(jiān)控擴展。

最后，來看一張圖：

這是之前，第一個里程碑完成時的 OI2.0交付情況。目前OI數(shù)據(jù)平臺，已經(jīng)能夠多訂單系統(tǒng)復(fù)用，支持攜程訂單體系和集團的某關(guān)聯(lián)企業(yè)訂單體系。

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

【推薦閱讀】

• 攜程機票 React Native 整潔架構(gòu)實踐

• React Hook的實現(xiàn)原理和最佳實踐

• 日部署 6000 次，攜程持續(xù)交付與構(gòu)建平臺實踐

• 前端如何實現(xiàn)業(yè)務(wù)解耦，攜程酒店查詢首頁的1.0到3.0

• 揭秘 Vue 3.0 最具潛力的 API

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。