K60至尊版狂暴引擎2.0加持：超177萬跑分斬獲性能第一
Redmi的后性能時代戰略發布會今天下午如期舉辦，在本次發布會上，Redmi公布了多項關于和聯發科的深度合作，以及新機K60 Ultra在軟件和硬件方面的特性，例如：“K60 至尊版，雙芯旗艦
作者簡介
py.an，攜程后端研發經理，關注性能優化、技術架構等領域
venson，攜程后端高級研發經理，關注性能優化、技術架構等領域
在全球化戰略的背景下，Trip.com作為一個面向國際市場的全球OTA平臺，正努力推進國際化戰略部署。Trip.com火車票正在積極投入資源和技術力量來拓展海外業務，通過將應用、數據部署新加坡、法蘭克福等中心，從而給全球用戶帶來更好的購票體驗和減少數據合規帶來的風險。
目前Trip.com火車票全球鐵路業務主要集中在英國、亞洲和歐洲各國，其中歐洲作為世界上經濟、交通非常發達的大洲，也成為更加關注的一站，未來還有更多更大的舞臺。
隨著全球疫情危機消退，旅游和出行需求得到釋放，在多語言，多幣種的場景支持下Trip.com火車票的全球化業務局面已逐步形成。
全球化背景下，除了要考慮全球的平滑部署來滿足應用可用性和用戶訪問性能要求外，還需要考慮數據出海的安全性、法律合規和數據隔離等嚴格要求。通過以下幾個角度舉例：
3.1 全球部署
改造前，Trip火車票業務應用和數據都部署在原機房的同城：存在IDC A+B兩中心的（同一個邏輯機房）同城雙活。
與改造前架構特點相對比，如表格所示：
容災級別 | 同一邏輯分區 | 用戶分區 | 就近訪問 | 數據多活 | 公共訪問 | |
改造前(同城雙活) | 跨機房級別 | 是 | 否 | 否 | 否 | 支持完善，成熟 |
全球多中心 | region級別 | 否 | 是，單元化分區 | 是 | 需嚴格遵守數據跨境政策 | 需支持多IDC場景 |
由此得知，多IDC場景下不可避免地需要去面臨數據分片、單元化、數據沖突和業務冪等問題。相比傳統分布式架構，不止是業務應用項目，還有PaaS平臺基礎設施在應對全球化技術體系都遇到了全新的挑戰，需要有巨大的調整。
3.2 性能問題
面對全球范圍內的用戶的業務請求響應，難免會有用戶因為網絡跨洋傳輸、鏈路傳輸距離過長等問題造成的業務訪問質量差。如何保證用戶的請求訪問鏈路最優，減少網絡延遲，提供更快服務響應。
3.3 數據合規和監管
如何嚴格遵守不同地區針對數據跨境流動、數據泄露等數據安全問題頒布的相關法律法規。
3.4 數據出海問題
3.5 全球擴展性
以輕松地擴大業務覆蓋范圍為目標，新業務擴展時，如何通過對業務和數據進行改造操作，達到便捷動態調整數據存儲策略，來應對動態多變的的數據合規政策。
下面將結合全球化面臨的挑戰和問題，從海外部署、數據合規、架構改造實踐等角度來詳細說明Trip火車票全球化出海的架構演進實踐。
4.1 Region(可用區)選擇
選擇適合的Region需要考慮用戶需求、法律和隱私、基礎設施和網絡、數據跨境風險評估以及成本和效益等多個因素。
Trip火車票根據以上因素和自身業務需求發展方向綜合考慮，并進行詳細的市場調研和分析，做出可用區選擇：把新加坡（SIN）和法蘭克福（FRA）作為火車業務出海部署的數據中心。
4.2 網絡接入層
Trip火車票如何設置網絡路由以實現可靠、高效的路由訪問和數據傳輸，總共分三種場景。
4.3 數據層
1）數據出海合規改造
數據出海合規改造是一項復雜而重要的任務，需要綜合考慮各種法律、法規和業務需求。通過以下改造措施，可以確保跨境數據傳輸和處理過程的合規性，并為用戶提供更可靠的數據保護：
2）DB多IDC部署
為確保能夠滿足業務需求，并提高數據庫的可用性和容錯能力，將出海DB進行多IDC部署方案。如下圖所示：
需要注意的是，各IDC之間同步時，應考慮各國家和地區的法律法規要求，確保同步數據的鏈路符合當地的數據存儲和隱私保護規定。
此外，多個DB數據相互同步時，架構會變得非常復雜。為確保各個IDC之間的網絡延遲低、數據同步穩定，要關注每條同步鏈路的延遲、網絡鏈路抖動和數據一致性問題，并且要定期進行監控、測試和演練，以驗證整個部署方案的可靠性和有效性。
3）同步延遲監控
如上圖所示，例如同步鏈路DRC同步延遲時間：
SIN<—>FRA:160ms+
4）數據庫多IDC擴展性
引入RegionCode：插入用戶數據時增加記錄機房標識RegionCode。
根據RegionCode確定數據所在Region，使得常用的數據查詢或業務處理操作可以在單個節點上執行，以達到數據單元化處理和數據合規策略動態調整的效果，從而避免跨節點帶來額外性能消耗和數據跨境合規問題。
4.4 基礎組件層
1）PaaS基礎組件多IDC接入
a. 分布式配置中心：
應用多IDC部署的場景下，就出現了不同IDC環境下配置文件不同的情況，此時也需要對配置中心的配置文件進行調整：接入子環境，引入多IDC配置文件，支持不同IDC不同的配置場景。
b. 分布式調度中心：
因為業務中大部分JOB都是通過掃表來對數據進行批量處理，所以多IDC場景下則基于存儲的RegionCode將任務分散到多個IDC，數據經過單元化過濾后，進行分片處理。
c. Redis:
不做雙向同步，多數據源。
業務中用到Redis的場景比較多，但Redis不同于業務數據庫場景所以不做雙向同步，每個IDC對應同單元內的Redis集群，每個Redis集群只服務于當前單元內的業務，所以不是全量的。所以在多IDC的場景下就有很多業務場景需要調整，基于Redis覆蓋業務要保證單元內閉環。
2）消息中心多IDC改造
MQ每個集群都是相互獨立相互隔離的，多IDC場景下就必然面臨了消息處理冪等的問題，所以對MQ進行了邏輯分組改造：
消息處理的改造流程圖如下圖所示：
4.5 項目業務層
1）業務單元化閉環改造
按照不同區域進行用戶分區和每個單元內可以獨立運作的原則。對項目業務進行改造，業務上盡可能保證所有業務在單元內可以獨立完成，每個IDC可以獨立承擔部分用戶的業務處理的能力。
2）請求鏈路改造
盡可能保證在同Region執行，減少跨洋請求造成的網絡耗時過長等問題。
3）跨Region場景改造
4.6 改造中的問題，演進中的思考點
在實際項目改造過程中，困難也屬于改造過程中的一部分。關鍵是要擁有一個積極應對和解決問題的心態，通過分析問題、制定解決方案、執行和學習經驗，從而克服困難并推動項目改造的順利進行。
以下是改造過程中遇到的問題點以及解決方案
1）DB同步沖突問題
在生產環境數據同步開啟后，突發了網絡不穩定造成DRC同步鏈路阻塞情況
如圖所示，在監控到DRC同步鏈路不穩定時，觸發了DRC同步沖突告警。
2）分布式鎖問題
當前項目中的分布式鎖是基于Redis實現的，因為不同IDC的Redis集群是相互隔離的，所以目前分布式鎖的粒度只支持到了Region級別。目前業務都是圍繞用戶場景加的分布式鎖，所以也可以滿足目前的實際業務場景。如果后續有全局獲取分布式鎖的業務，則需要進一步設計，即保證同一時間所有Region有且只有一個地方能夠獲得該資源，并且其他Region必須等待，這有可能犧牲掉相當大的性能來實現此功能。
3）多機房庫存問題
用戶的請求保證在同一機房內完成閉環，但部分場景并不適合劃分單元化，比如多機房庫存扣減問題。面對多機房庫存扣減問題目前的策略如下：
4.7 演進結果
通過以上的改造和優化，Trip.com火車票的系統架構演進和性能優化如下面所示：
1）架構演進圖
2）性能優化
通過對用戶網絡鏈路優化，減少用戶跨洋訪問。FRA接口耗時優化整體減少300-800ms。
當前背景下還有很多不完善的地方和非常多的技術挑戰，架構體系還需要持續演進迭代，接下來Trip.com火車票對于未來的全球化戰略方向還需進一步進行優化和改造：
5.1 單元化路由
接入集團UCS(unit control service)路由策略：根據用戶的區域信息作為ShardingKey映射指定IDC，以達到流量和組件多IDC場景下的完美落地。
5.2 數據單元化改造
當前第一指標是優先保證業務，各個Region的DB數據都會雙向同步，每個Region的數據都是全量，也增加容錯性，減少了數據出海異常情況時帶來的業務中斷的風險。但還需達到數據和業務單元內可以完全閉環的程度，可以隨時切斷同步鏈路避免數據跨境帶來的違規問題，以實現數據單元化。
5.3 業務中心機房調整
為了適應多變的數據合規政策和迎合業務發展趨勢，未來的中心機房設置為SIN數據中心，并且有能力移除原業務中心機房。
目前需要達到所有業務可以在海外閉環的能力后設置業務中心為SIN，以達到海外合規建站的能力。
5.4 結語
伴隨著Trip.com全球化的發展，火車票的技術發展也逐漸從原有的技術領域，延伸到要去應對更復雜的場景。想要建立起完善的全球化體系還有很長的路要走。在這種背景下，還需繼續突破自身技術邊界，實現單維能力向多維能力的轉變，提前布局，并面向業務持續交付技術價值。
本文鏈接：http://www.tebozhan.com/showinfo-26-10456-0.html攜程火車票出海架構演進之路
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號