作者簡介

py.an，攜程后端研發(fā)經理，關注性能優(yōu)化、技術架構等領域

venson，攜程后端高級研發(fā)經理，關注性能優(yōu)化、技術架構等領域

一、引言

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

二、業(yè)務背景

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

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

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

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

3.1 全球部署

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

與改造前架構特點相對比，如表格所示：

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

3.2 性能問題

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

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

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

3.4 數據出海問題

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

3.5 全球擴展性

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

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

四、出海架構演進實踐

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

選擇適合的Region需要考慮用戶需求、法律和隱私、基礎設施和網絡、數據跨境風險評估以及成本和效益等多個因素。

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

4.2 網絡接入層

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

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

4.3 數據層

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

數據出海合規(guī)改造是一項復雜而重要的任務，需要綜合考慮各種法律、法規(guī)和業(yè)務需求。通過以下改造措施，可以確?？缇硵祿鬏敽吞幚磉^程的合規(guī)性，并為用戶提供更可靠的數據保護：

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

2）DB多IDC部署

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

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

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

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

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

SIN<—>FRA:160ms+

4）數據庫多IDC擴展性

引入RegionCode：插入用戶數據時增加記錄機房標識RegionCode。

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

4.4 基礎組件層

1）PaaS基礎組件多IDC接入

a. 分布式配置中心：

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

b. 分布式調度中心：

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

c. Redis:

不做雙向同步，多數據源。

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

2）消息中心多IDC改造

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

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

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

4.5 項目業(yè)務層

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

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

2）請求鏈路改造

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

3）跨Region場景改造

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

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

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

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

1）DB同步沖突問題

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

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

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

2）分布式鎖問題

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

3）多機房庫存問題

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

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

4.7 演進結果

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

1）架構演進圖

2）性能優(yōu)化

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

五、新起點，新征程

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

5.1 單元化路由

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

5.2 數據單元化改造

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

5.3 業(yè)務中心機房調整

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

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

5.4 結語

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