本文详细介绍了QUIC协议在携程 Trip.com App上的实践方案，以及团队在QUIC高可用及性能提升方面所做的各类优化。首先介绍了QUIC多进程部署架构，随后分析了QUIC网络架构在生产应用中遇到的问题及其优化方案。在性能提升方面，分享了QUIC全链路埋点监控的实现思路及其收获，QUIC拥塞控制算法开发与调优思路等等。希望这些内容能够帮助大家了解QUIC协议及其在实际应用中的优化思路，并从中获得启发。
本文概述了携程门票预订交易系统在应对秒杀活动中面临的挑战与应对策略。第一部分阐述了业务激增对系统架构的考验；第二部分深入剖析了系统架构的优化路径，涵盖读热点、写入性能瓶颈、强一致性事务处理及流量精细化控制等关键问题的解决方案，并总结了确保系统高可用性与持续性的治理措施。希望这些内容能够对大家有所帮助或启发。
目前，携程大部分业务已经完成了微服务改造，基本架构如图。每一个微服务的实例都需要和注册中心进行通讯：服务端实例向注册中心注册自己的服务地址，客户端实例通过向注册中心查询得知服务端地址，从而完成远程调用。同时，客户端会订阅自己关心的服务端地址，当服务端发生变更时，客户端会收到变更消息，触发自己重新查询服务端地址。
istanbuljs 是一款优秀的JavaScript代码覆盖率工具，主要用于单元测试的代码覆盖率检测和生成本地覆盖率报告。然而，随着现代前端技术和UI自动化测试的发展，对端到端测试的代码覆盖率检测需求逐渐增加，istanbuljs提供的功能显得捉襟见肘。 在携程内部JavaScript代码覆盖率使用的是gitlab内置的coverage上报，也是只支持单元测试的覆盖率收集和概览数据展示。随着携程的前端技术日益精进，我们有了自己的前端流量录制平台，并且部署了相当大规模的模拟器集群进行UI自动化(flybirds)回放。这种场景下，需要对端到端测试的代码覆盖率进行收集和展示，以便开发同学更好的了解到自己的代码质量。 传统的istanbuljs提供的功能已经无法满足我们的需求。我们需要处理UI自动化过程中来自前端高并发的覆盖率上报，实时的覆盖率聚合，以及覆盖率数据的聚合展示。因此，我们在Istanbuljs的基础上开发了Canyon，解决端到端测试覆盖率难收集的问题。
携程数据基础平台主要组件包括：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体验等）。对于已经上架的版本，我们的客服人员在客人协助、新员工培训等场合，也有着使用生产资源来获得与客人同一视角的环境诉求，这对我们研发流程中已经存在的测试环境的适用性提出了巨大的挑战，无论从操作体验、还是资源对齐等多方面，测试环境都难以满足诉求。
