携程火车票出海架构演进之路

作者简介

py.an，携程后端研发经理，关注性能优化、技术架构等领域

venson，携程后端高级研发经理，关注性能优化、技术架构等领域

一、引言

在全球化战略的背景下，Trip.com作为一个面向国际市场的全球OTA平台，正努力推进国际化战略部署。Trip.com火车票正在积极投入资源和技术力量来拓展海外业务，通过将应用、数据部署新加坡、法兰克福等中心，从而给全球用户带来更好的购票体验和减少数据合规带来的风险。

二、业务背景

目前Trip.com火车票全球铁路业务主要集中在英国、亚洲和欧洲各国，其中欧洲作为世界上经济、交通非常发达的大洲，也成为更加关注的一站，未来还有更多更大的舞台。

随着全球疫情危机消退，旅游和出行需求得到释放，在多语言，多币种的场景支持下Trip.com火车票的全球化业务局面已逐步形成。

三、面临的挑战

全球化背景下，除了要考虑全球的平滑部署来满足应用可用性和用户访问性能要求外，还需要考虑数据出海的安全性、法律合规和数据隔离等严格要求。通过以下几个角度举例：

3.1 全球部署

改造前，Trip火车票业务应用和数据都部署在原机房的同城：存在IDC A+B两中心的（同一个逻辑机房）同城双活。

与改造前架构特点相对比，如表格所示：

由此得知，多IDC场景下不可避免地需要去面临数据分片、单元化、数据冲突和业务幂等问题。相比传统分布式架构，不止是业务应用项目，还有PaaS平台基础设施在应对全球化技术体系都遇到了全新的挑战，需要有巨大的调整。

3.2 性能问题

面对全球范围内的用户的业务请求响应，难免会有用户因为网络跨洋传输、链路传输距离过长等问题造成的业务访问质量差。如何保证用户的请求访问链路最优，减少网络延迟，提供更快服务响应。

3.3 数据合规和监管

如何严格遵守不同地区针对数据跨境流动、数据泄露等数据安全问题颁布的相关法律法规。

3.4 数据出海问题

• 数据一致性：多IDC读写场景下，全球范围内用户在多个数据中心创建和操作订单，多个数据中心之间相互同步和操作订单业务时，应该如何保证数据一致性的问题。
• 同步合规：因数据跨境政策影响，一般不进行异地多活，需要如何避免数据跨境流动所带来的违规。

3.5 全球扩展性

以轻松地扩大业务覆盖范围为目标，新业务扩展时，如何通过对业务和数据进行改造操作，达到便捷动态调整数据存储策略，来应对动态多变的的数据合规政策。

下面将结合全球化面临的挑战和问题，从海外部署、数据合规、架构改造实践等角度来详细说明Trip火车票全球化出海的架构演进实践。

四、出海架构演进实践

4.1 Region(可用区)选择

选择适合的Region需要考虑用户需求、法律和隐私、基础设施和网络、数据跨境风险评估以及成本和效益等多个因素。

Trip火车票根据以上因素和自身业务需求发展方向综合考虑，并进行详细的市场调研和分析，做出可用区选择：把新加坡（SIN）和法兰克福（FRA）作为火车业务出海部署的数据中心。

4.2 网络接入层

Trip火车票如何设置网络路由以实现可靠、高效的路由访问和数据传输，总共分三种场景。

• 外网：多路径、就近访问。
  考虑到不同地域之间的网络延迟和带宽限制，Trip火车票采用就近访问路由策略。即选择距离最近或带宽最大的路径进行数据传输，以减少延迟和提高速度。优势：保证同一用户就近访问网路链路最优的IDC。
  配置FRA、SIN多条路径进行数据传输，多路径路由。这样即使某一条路径出现故障，数据仍然可以通过其他路径传输。
• 内网：尽量访问同Region内的资源，实现同Region业务闭环。
• 跨Region访问场景：如果同Region内不存在需要获取的业务资源，必须跨Region访问时，则进行链路优化。比如，欧洲用户访问FRA通过专线链路请求SIN资源。这样避免直接跨洋访问其他Region，因网络跨洋传输、链路质量不稳定等问题导致网络耗时过长。

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进行了逻辑分组改造：

• 同Region内处理：同机房内的生产消费的MQ同Region内闭环处理
• 跨Region场景：需要跨Region的MQ通过BaseSubject同步到中心机房Region，来保证正常业务流程
• 消费端幂等处理：消费端根据RegionCode逻辑分组，进行单元化消费

消息处理的改造流程图如下图所示：

4.5 项目业务层

1）业务单元化闭环改造

按照不同区域进行用户分区和每个单元内可以独立运作的原则。对项目业务进行改造，业务上尽可能保证所有业务在单元内可以独立完成，每个IDC可以独立承担部分用户的业务处理的能力。

2）请求链路改造

尽可能保证在同Region执行，减少跨洋请求造成的网络耗时过长等问题。

3）跨Region场景改造

• 跨Region耗时请求下，由原来的串行调用外部接口的业务处理逻辑调整为异步并发处理和数据预加载优化。比如获取用户优惠券场景下，需要跨Region获取，则采取提前请求优惠券的方式，去除掉跨Region的影响。
• 多次跨Region的场景通过接口改造减少跨Region的次数从而达到减少跨洋的效果。
• 当核心业务中的非核心跨Region业务时：采用非即时性处理原则，通过业务拆分对非核心业务进行异步MQ改造处理。

4.6 改造中的问题，演进中的思考点

在实际项目改造过程中，困难也属于改造过程中的一部分。关键是要拥有一个积极应对和解决问题的心态，通过分析问题、制定解决方案、执行和学习经验，从而克服困难并推动项目改造的顺利进行。

以下是改造过程中遇到的问题点以及解决方案

1）DB同步冲突问题

在生产环境数据同步开启后，突发了网络不稳定造成DRC同步链路阻塞情况

如图所示，在监控到DRC同步链路不稳定时，触发了DRC同步冲突告警。

• 原因：通过对DB数据的排查发现SIN和FRA对同一订单进行的更新操作，因为网络延迟导致同步时发生了DRC冲突，导致其中一个更新操作被丢弃，从而影响到了后续订单流程。
• 解决方案：修改订单更新逻辑在同IDC内执行。双写发生同步延迟问题必然会遇到一致性冲突问题，长期方案还是单元化，避免出现跨Region操作同一条数据的情况。

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全球化的发展，火车票的技术发展也逐渐从原有的技术领域，延伸到要去应对更复杂的场景。想要建立起完善的全球化体系还有很长的路要走。在这种背景下，还需继续突破自身技术边界，实现单维能力向多维能力的转变，提前布局，并面向业务持续交付技术价值。