作者簡介

py.an，攜程后端研發(fā)經(jīng)理，關(guān)注性能優(yōu)化、技術(shù)架構(gòu)等領(lǐng)域

venson，攜程后端高級研發(fā)經(jīng)理，關(guān)注性能優(yōu)化、技術(shù)架構(gòu)等領(lǐng)域

一、引言

在全球化戰(zhàn)略的背景下，Trip.com作為一個面向國際市場的全球OTA平臺，正努力推進國際化戰(zhàn)略部署。Trip.com火車票正在積極投入資源和技術(shù)力量來拓展海外業(yè)務(wù)，通過將應(yīng)用、數(shù)據(jù)部署新加坡、法蘭克福等中心，從而給全球用戶帶來更好的購票體驗和減少數(shù)據(jù)合規(guī)帶來的風(fēng)險。

二、業(yè)務(wù)背景

目前Trip.com火車票全球鐵路業(yè)務(wù)主要集中在英國、亞洲和歐洲各國，其中歐洲作為世界上經(jīng)濟、交通非常發(fā)達的大洲，也成為更加關(guān)注的一站，未來還有更多更大的舞臺。

隨著全球疫情危機消退，旅游和出行需求得到釋放，在多語言，多幣種的場景支持下Trip.com火車票的全球化業(yè)務(wù)局面已逐步形成。

三、面臨的挑戰(zhàn)

全球化背景下，除了要考慮全球的平滑部署來滿足應(yīng)用可用性和用戶訪問性能要求外，還需要考慮數(shù)據(jù)出海的安全性、法律合規(guī)和數(shù)據(jù)隔離等嚴格要求。通過以下幾個角度舉例：

3.1 全球部署

改造前，Trip火車票業(yè)務(wù)應(yīng)用和數(shù)據(jù)都部署在原機房的同城：存在IDC A+B兩中心的（同一個邏輯機房）同城雙活。

與改造前架構(gòu)特點相對比，如表格所示：

由此得知，多IDC場景下不可避免地需要去面臨數(shù)據(jù)分片、單元化、數(shù)據(jù)沖突和業(yè)務(wù)冪等問題。相比傳統(tǒng)分布式架構(gòu)，不止是業(yè)務(wù)應(yīng)用項目，還有PaaS平臺基礎(chǔ)設(shè)施在應(yīng)對全球化技術(shù)體系都遇到了全新的挑戰(zhàn)，需要有巨大的調(diào)整。

3.2 性能問題

面對全球范圍內(nèi)的用戶的業(yè)務(wù)請求響應(yīng)，難免會有用戶因為網(wǎng)絡(luò)跨洋傳輸、鏈路傳輸距離過長等問題造成的業(yè)務(wù)訪問質(zhì)量差。如何保證用戶的請求訪問鏈路最優(yōu)，減少網(wǎng)絡(luò)延遲，提供更快服務(wù)響應(yīng)。

3.3 數(shù)據(jù)合規(guī)和監(jiān)管

如何嚴格遵守不同地區(qū)針對數(shù)據(jù)跨境流動、數(shù)據(jù)泄露等數(shù)據(jù)安全問題頒布的相關(guān)法律法規(guī)。

3.4 數(shù)據(jù)出海問題

• 數(shù)據(jù)一致性：多IDC讀寫場景下，全球范圍內(nèi)用戶在多個數(shù)據(jù)中心創(chuàng)建和操作訂單，多個數(shù)據(jù)中心之間相互同步和操作訂單業(yè)務(wù)時，應(yīng)該如何保證數(shù)據(jù)一致性的問題。
• 同步合規(guī)：因數(shù)據(jù)跨境政策影響，一般不進行異地多活，需要如何避免數(shù)據(jù)跨境流動所帶來的違規(guī)。

3.5 全球擴展性

以輕松地擴大業(yè)務(wù)覆蓋范圍為目標，新業(yè)務(wù)擴展時，如何通過對業(yè)務(wù)和數(shù)據(jù)進行改造操作，達到便捷動態(tài)調(diào)整數(shù)據(jù)存儲策略，來應(yīng)對動態(tài)多變的的數(shù)據(jù)合規(guī)政策。

下面將結(jié)合全球化面臨的挑戰(zhàn)和問題，從海外部署、數(shù)據(jù)合規(guī)、架構(gòu)改造實踐等角度來詳細說明Trip火車票全球化出海的架構(gòu)演進實踐。

四、出海架構(gòu)演進實踐

4.1 Region(可用區(qū))選擇

選擇適合的Region需要考慮用戶需求、法律和隱私、基礎(chǔ)設(shè)施和網(wǎng)絡(luò)、數(shù)據(jù)跨境風(fēng)險評估以及成本和效益等多個因素。

Trip火車票根據(jù)以上因素和自身業(yè)務(wù)需求發(fā)展方向綜合考慮，并進行詳細的市場調(diào)研和分析，做出可用區(qū)選擇：把新加坡（SIN）和法蘭克福（FRA）作為火車業(yè)務(wù)出海部署的數(shù)據(jù)中心。

4.2 網(wǎng)絡(luò)接入層

Trip火車票如何設(shè)置網(wǎng)絡(luò)路由以實現(xiàn)可靠、高效的路由訪問和數(shù)據(jù)傳輸，總共分三種場景。

• 外網(wǎng)：多路徑、就近訪問。
  考慮到不同地域之間的網(wǎng)絡(luò)延遲和帶寬限制，Trip火車票采用就近訪問路由策略。即選擇距離最近或帶寬最大的路徑進行數(shù)據(jù)傳輸，以減少延遲和提高速度。優(yōu)勢：保證同一用戶就近訪問網(wǎng)路鏈路最優(yōu)的IDC。
  配置FRA、SIN多條路徑進行數(shù)據(jù)傳輸，多路徑路由。這樣即使某一條路徑出現(xiàn)故障，數(shù)據(jù)仍然可以通過其他路徑傳輸。
• 內(nèi)網(wǎng)：盡量訪問同Region內(nèi)的資源，實現(xiàn)同Region業(yè)務(wù)閉環(huán)。
• 跨Region訪問場景：如果同Region內(nèi)不存在需要獲取的業(yè)務(wù)資源，必須跨Region訪問時，則進行鏈路優(yōu)化。比如，歐洲用戶訪問FRA通過專線鏈路請求SIN資源。這樣避免直接跨洋訪問其他Region，因網(wǎng)絡(luò)跨洋傳輸、鏈路質(zhì)量不穩(wěn)定等問題導(dǎo)致網(wǎng)絡(luò)耗時過長。

4.3 數(shù)據(jù)層

1）數(shù)據(jù)出海合規(guī)改造

數(shù)據(jù)出海合規(guī)改造是一項復(fù)雜而重要的任務(wù)，需要綜合考慮各種法律、法規(guī)和業(yè)務(wù)需求。通過以下改造措施，可以確?？缇硵?shù)據(jù)傳輸和處理過程的合規(guī)性，并為用戶提供更可靠的數(shù)據(jù)保護：

• 數(shù)據(jù)分類和標記：對業(yè)務(wù)數(shù)據(jù)進行分類和標記，明確標識出敏感數(shù)據(jù)、個人身份信息等受保護的數(shù)據(jù)。這有助于在數(shù)據(jù)傳輸和處理過程中更好地掌握敏感數(shù)據(jù)的位置和處理方式。
• 數(shù)據(jù)加密和匿名化：采用適當?shù)募用芗夹g(shù)和數(shù)據(jù)匿名化方法，對敏感數(shù)據(jù)進行保護。加密可以有效防止數(shù)據(jù)在傳輸和儲存過程中被未經(jīng)授權(quán)的訪問者獲取，而數(shù)據(jù)匿名化則可以保護個人身份信息的隱私。
• 出海數(shù)據(jù)業(yè)務(wù)剝離改造：數(shù)據(jù)跨境流動許多國家實施數(shù)據(jù)本地化策略，數(shù)據(jù)出海時需同時考慮數(shù)據(jù)輸出地和輸入地的數(shù)據(jù)跨境規(guī)則?？缇硵?shù)據(jù)傳輸時需要進行風(fēng)險識別和相關(guān)的數(shù)據(jù)控制措施，對業(yè)務(wù)數(shù)據(jù)進行剝離改造。

2）DB多IDC部署

為確保能夠滿足業(yè)務(wù)需求，并提高數(shù)據(jù)庫的可用性和容錯能力，將出海DB進行多IDC部署方案。如下圖所示：

需要注意的是，各IDC之間同步時，應(yīng)考慮各國家和地區(qū)的法律法規(guī)要求，確保同步數(shù)據(jù)的鏈路符合當?shù)氐臄?shù)據(jù)存儲和隱私保護規(guī)定。

此外，多個DB數(shù)據(jù)相互同步時，架構(gòu)會變得非常復(fù)雜。為確保各個IDC之間的網(wǎng)絡(luò)延遲低、數(shù)據(jù)同步穩(wěn)定，要關(guān)注每條同步鏈路的延遲、網(wǎng)絡(luò)鏈路抖動和數(shù)據(jù)一致性問題，并且要定期進行監(jiān)控、測試和演練，以驗證整個部署方案的可靠性和有效性。

3）同步延遲監(jiān)控

如上圖所示，例如同步鏈路DRC同步延遲時間：

SIN<—>FRA:160ms+

4）數(shù)據(jù)庫多IDC擴展性

引入RegionCode：插入用戶數(shù)據(jù)時增加記錄機房標識RegionCode。

根據(jù)RegionCode確定數(shù)據(jù)所在Region，使得常用的數(shù)據(jù)查詢或業(yè)務(wù)處理操作可以在單個節(jié)點上執(zhí)行，以達到數(shù)據(jù)單元化處理和數(shù)據(jù)合規(guī)策略動態(tài)調(diào)整的效果，從而避免跨節(jié)點帶來額外性能消耗和數(shù)據(jù)跨境合規(guī)問題。

4.4 基礎(chǔ)組件層

1）PaaS基礎(chǔ)組件多IDC接入

a. 分布式配置中心：

應(yīng)用多IDC部署的場景下，就出現(xiàn)了不同IDC環(huán)境下配置文件不同的情況，此時也需要對配置中心的配置文件進行調(diào)整：接入子環(huán)境，引入多IDC配置文件，支持不同IDC不同的配置場景。

b. 分布式調(diào)度中心：

因為業(yè)務(wù)中大部分JOB都是通過掃表來對數(shù)據(jù)進行批量處理，所以多IDC場景下則基于存儲的RegionCode將任務(wù)分散到多個IDC，數(shù)據(jù)經(jīng)過單元化過濾后，進行分片處理。

c. Redis:

不做雙向同步，多數(shù)據(jù)源。

業(yè)務(wù)中用到Redis的場景比較多，但Redis不同于業(yè)務(wù)數(shù)據(jù)庫場景所以不做雙向同步，每個IDC對應(yīng)同單元內(nèi)的Redis集群，每個Redis集群只服務(wù)于當前單元內(nèi)的業(yè)務(wù)，所以不是全量的。所以在多IDC的場景下就有很多業(yè)務(wù)場景需要調(diào)整，基于Redis覆蓋業(yè)務(wù)要保證單元內(nèi)閉環(huán)。

2）消息中心多IDC改造

MQ每個集群都是相互獨立相互隔離的，多IDC場景下就必然面臨了消息處理冪等的問題，所以對MQ進行了邏輯分組改造：

• 同Region內(nèi)處理：同機房內(nèi)的生產(chǎn)消費的MQ同Region內(nèi)閉環(huán)處理
• 跨Region場景：需要跨Region的MQ通過BaseSubject同步到中心機房Region，來保證正常業(yè)務(wù)流程
• 消費端冪等處理：消費端根據(jù)RegionCode邏輯分組，進行單元化消費

消息處理的改造流程圖如下圖所示：

4.5 項目業(yè)務(wù)層

1）業(yè)務(wù)單元化閉環(huán)改造

按照不同區(qū)域進行用戶分區(qū)和每個單元內(nèi)可以獨立運作的原則。對項目業(yè)務(wù)進行改造，業(yè)務(wù)上盡可能保證所有業(yè)務(wù)在單元內(nèi)可以獨立完成，每個IDC可以獨立承擔(dān)部分用戶的業(yè)務(wù)處理的能力。

2）請求鏈路改造

盡可能保證在同Region執(zhí)行，減少跨洋請求造成的網(wǎng)絡(luò)耗時過長等問題。

3）跨Region場景改造

• 跨Region耗時請求下，由原來的串行調(diào)用外部接口的業(yè)務(wù)處理邏輯調(diào)整為異步并發(fā)處理和數(shù)據(jù)預(yù)加載優(yōu)化。比如獲取用戶優(yōu)惠券場景下，需要跨Region獲取，則采取提前請求優(yōu)惠券的方式，去除掉跨Region的影響。
• 多次跨Region的場景通過接口改造減少跨Region的次數(shù)從而達到減少跨洋的效果。
• 當核心業(yè)務(wù)中的非核心跨Region業(yè)務(wù)時：采用非即時性處理原則，通過業(yè)務(wù)拆分對非核心業(yè)務(wù)進行異步MQ改造處理。

4.6 改造中的問題，演進中的思考點

在實際項目改造過程中，困難也屬于改造過程中的一部分。關(guān)鍵是要擁有一個積極應(yīng)對和解決問題的心態(tài)，通過分析問題、制定解決方案、執(zhí)行和學(xué)習(xí)經(jīng)驗，從而克服困難并推動項目改造的順利進行。

以下是改造過程中遇到的問題點以及解決方案

1）DB同步?jīng)_突問題

在生產(chǎn)環(huán)境數(shù)據(jù)同步開啟后，突發(fā)了網(wǎng)絡(luò)不穩(wěn)定造成DRC同步鏈路阻塞情況

如圖所示，在監(jiān)控到DRC同步鏈路不穩(wěn)定時，觸發(fā)了DRC同步?jīng)_突告警。

• 原因：通過對DB數(shù)據(jù)的排查發(fā)現(xiàn)SIN和FRA對同一訂單進行的更新操作，因為網(wǎng)絡(luò)延遲導(dǎo)致同步時發(fā)生了DRC沖突，導(dǎo)致其中一個更新操作被丟棄，從而影響到了后續(xù)訂單流程。
• 解決方案：修改訂單更新邏輯在同IDC內(nèi)執(zhí)行。雙寫發(fā)生同步延遲問題必然會遇到一致性沖突問題，長期方案還是單元化，避免出現(xiàn)跨Region操作同一條數(shù)據(jù)的情況。

2）分布式鎖問題

當前項目中的分布式鎖是基于Redis實現(xiàn)的，因為不同IDC的Redis集群是相互隔離的，所以目前分布式鎖的粒度只支持到了Region級別。目前業(yè)務(wù)都是圍繞用戶場景加的分布式鎖，所以也可以滿足目前的實際業(yè)務(wù)場景。如果后續(xù)有全局獲取分布式鎖的業(yè)務(wù)，則需要進一步設(shè)計，即保證同一時間所有Region有且只有一個地方能夠獲得該資源，并且其他Region必須等待，這有可能犧牲掉相當大的性能來實現(xiàn)此功能。

3）多機房庫存問題

用戶的請求保證在同一機房內(nèi)完成閉環(huán)，但部分場景并不適合劃分單元化，比如多機房庫存扣減問題。面對多機房庫存扣減問題目前的策略如下：

• 業(yè)務(wù)扣庫存邏輯不調(diào)整，還是同步扣庫存，但事先根據(jù)流量分配好每個機房庫存
• 增加庫存調(diào)配機制，當庫存不足時觸發(fā)庫存調(diào)配，從有多余庫存的機房進行調(diào)配， 
• 增加監(jiān)控和庫存不足告警通知，除了自動資源調(diào)配，對活動上線后進行機房間的庫存情況實時觀測和實時手動調(diào)配。

4.7 演進結(jié)果

通過以上的改造和優(yōu)化，Trip.com火車票的系統(tǒng)架構(gòu)演進和性能優(yōu)化如下面所示：

1）架構(gòu)演進圖

2）性能優(yōu)化

通過對用戶網(wǎng)絡(luò)鏈路優(yōu)化，減少用戶跨洋訪問。FRA接口耗時優(yōu)化整體減少300-800ms。

五、新起點，新征程

當前背景下還有很多不完善的地方和非常多的技術(shù)挑戰(zhàn)，架構(gòu)體系還需要持續(xù)演進迭代，接下來Trip.com火車票對于未來的全球化戰(zhàn)略方向還需進一步進行優(yōu)化和改造：

5.1 單元化路由

接入集團UCS(unit control service)路由策略：根據(jù)用戶的區(qū)域信息作為ShardingKey映射指定IDC，以達到流量和組件多IDC場景下的完美落地。

5.2 數(shù)據(jù)單元化改造

當前第一指標是優(yōu)先保證業(yè)務(wù)，各個Region的DB數(shù)據(jù)都會雙向同步，每個Region的數(shù)據(jù)都是全量，也增加容錯性，減少了數(shù)據(jù)出海異常情況時帶來的業(yè)務(wù)中斷的風(fēng)險。但還需達到數(shù)據(jù)和業(yè)務(wù)單元內(nèi)可以完全閉環(huán)的程度，可以隨時切斷同步鏈路避免數(shù)據(jù)跨境帶來的違規(guī)問題，以實現(xiàn)數(shù)據(jù)單元化。 

5.3 業(yè)務(wù)中心機房調(diào)整

為了適應(yīng)多變的數(shù)據(jù)合規(guī)政策和迎合業(yè)務(wù)發(fā)展趨勢，未來的中心機房設(shè)置為SIN數(shù)據(jù)中心，并且有能力移除原業(yè)務(wù)中心機房。

目前需要達到所有業(yè)務(wù)可以在海外閉環(huán)的能力后設(shè)置業(yè)務(wù)中心為SIN，以達到海外合規(guī)建站的能力。

5.4 結(jié)語

伴隨著Trip.com全球化的發(fā)展，火車票的技術(shù)發(fā)展也逐漸從原有的技術(shù)領(lǐng)域，延伸到要去應(yīng)對更復(fù)雜的場景。想要建立起完善的全球化體系還有很長的路要走。在這種背景下，還需繼續(xù)突破自身技術(shù)邊界，實現(xiàn)單維能力向多維能力的轉(zhuǎn)變，提前布局，并面向業(yè)務(wù)持續(xù)交付技術(shù)價值。