携程数据基础平台主要组件包括：HDFS 分布式存储集群，YARN 计算集群，Spark、Hive 计算引擎。数据基础平台 1.0 版本的架构从 2017 年开始逐步成型，2018 年至 2021 年数据基础团队基于 1.0 的架构做了性能优化和各类 Bug 修复，支撑集群数据和计算任务高速增长。 进入 2023 年以来，随着业务恢复，数据平台存量数据也不断增长，单日数据量净增长超过数 PB，增速前所未见，2 个 IDC 的数据机房物理机架位告急。 在 OPS 团队的大力支持下，启动了第三个 IDC 数据机房建设项目，2 个月内交付了新 IDC。
在互联网早期时代，账号系统的功能非常广泛，包括账号管理、登录认证相关能力以及维护各类用户信息，比如头像、昵称、积分、等级等。随着业务的发展，每个功能逐渐分化出自己的需求和架构侧重点，独立出各自的领域服务也成了业界共识。 本文分享的账号系统，指的是提供用户账号管理、登录认证相关能力的系统。介绍了携程在不断发展的过程中，账号系统在领域化、中台化和多Region化方向上的演进、探索和一些思考。
日志，作为系统运行的忠实记录者，不仅是问题追踪的利器，更是性能调优的指南针。通过深入分析日志，我们可以洞悉系统运行的每一个细节，从而快速定位问题、优化性能。同时，日志也可以作为数据分析和决策的重要依据。研发流程中，如何使用好日志，还是存在着以下难点。
参照Apple、Booking和AirBnB等一众品牌在国际化的进程中始终保持品牌认知的一致性，Ctrip和Trip（以下简称为“C&T”）并驾齐驱的过程中，集团对于不同国度和不同客群的品牌效应有趋于统一的诉求。 研发的整体链路上同样存在由于C&T相似需求导致的重复开发工作量，服务链路上并没有完全做到抽象与统一，前端链路上存在复用率低以及缺失动态化能力的情况。 多终端存在功能不对齐的情况，造成用户体验不一致，结合C&T的场景进一步加剧了功能模块复用率低以及研发资源利用率低的问题。 综上三点，C&T一致与多端融合的问题等待技术给出答案。
AREX 是一款由携程开源的流量回放平台，孵化于机票BU内部。聚焦录制回放核心链路的建设，从基础方案建设到核心事业线的深入落地验证，在集团复杂业务场景下不断迭代和优化下，积累了大量经验，取得了可见的成果。在携程落地至今已有 4000+ 应用接入，交付率和缺陷数均有所改善。 本篇文章主要介绍AREX在携程内部落地实践过程中遇到的一系列挑战和解决方案，以及如何通过AREX快速部署一站式流量录制回放解决方案来降低接入成本，快速落地。
携程内部会有大量的部门或团队需要在App新版本、新站点完成研发阶段所有功能测试后，在上架前(Post Release)阶段，再进行无拘束的从客人视角验收的诉求（比如竞品对比、Localization体验等）。对于已经上架的版本，我们的客服人员在客人协助、新员工培训等场合，也有着使用生产资源来获得与客人同一视角的环境诉求，这对我们研发流程中已经存在的测试环境的适用性提出了巨大的挑战，无论从操作体验、还是资源对齐等多方面，测试环境都难以满足诉求。
在快速迭代的软件开发周期中，用户界面（UI）的自动化测试已成为提高效率和确保产品质量的关键。然而，随着应用程序变得日益复杂，传统的UI自动化方法逐渐显露出局限性。AI驱动的UI自动化出现了，但仍面临着准确性和可靠性的挑战。在这个背景下，本文提出一个创新的视角：通过实时调试技术，显著提升AI编写的UI自动化脚本的有效性。 这个问题不仅仅是技术上的挑战，它关系到如何在保证软件质量的同时加速软件的交付。本文将探讨实时调试如何帮助AI更准确地理解和执行UI测试脚本，以及这种方法如何能够为软件开发带来革命性的改变。
携程机票订单系统是由多个业务子系统组成，包括出票、改签、航变等等，获取订单行程信息复杂度较高。 例如：用户预订了一个包含了2个乘客的机票订单，该订单发生了航变，其中用户A选择了退票，用户B选择了改签。 业务系统需要获得该订单最新的行程信息以及行程变化轨迹，以进行展示和进一步处理。
携程酒店排序推荐广告工程（以下简称酒店推荐工程）在数据层面引入抽象化的统一数据协议UnifiedPB，解决了过去各场景各自维护，建立各自的数据流，网状开放式数据表，烟囱式迭代的问题，实现了全场景数据的标准化、规范化、统一化。 那么，UnifiedPB具体是什么呢？它是基于protobuf构建的统一工程、策略、数据三方的标准数据模型。从数据时效性上，我们抽象出三类：Online、NearLine、Offline；从数据类型归属上，我们抽象出四类：User、Item、User-Item、Common（公用字典）。
