作者简介携程OLAP引擎开发组，专注于大数据OLAP引擎trino/starrocks的开发与大规模部署和运维。团队热招岗位：资深大数据平台开发工程师、OLAP分析引擎高级/资深开发工程师本文概述了面对公司数据报表平台遇到的查询性能挑战，数据平台组围绕数据缓存、物化视图、查询策略、SQL质量等方向所做的一系列治理工作，以提升平台的查询效率和稳定性。通过这些工作，平台的查询响应时间得到了显著的改善，其中平均响应时间从原来的8秒降低至4秒，响应时间90线由原先的约18秒降低至约8秒，总体性能指标提升幅度达50%以上。本文在各个小节中对各治理策略的关键原理和思路进行了阐述，希望能够为读者提供一定的参考和启发。一、背景二、平台设计概览三、多维度数据缓存3.1

作者简介Yiwen，携程数据分析师，专注用户增长、因果推断、数据科学等领域。团队热招岗位：高级数仓工程师、高级数据分析师、数据运营专员本文主要介绍SCNN模型及其代码的具体实现，以及如何将其应用在预测业务量上的实际操作过程，旨在面对一些拥有复杂时空结构的多元变量数据时，能更准确地进行预测。首先对模型原理进行简要阐释，随后展示代码逻辑，最后介绍在具体业务场景上的实践应用。一、背景二、现有方法及潜在问题三、模型介绍3.1

分层存储：热/温/冷三分层数据存储架构落地，对接云上对象冷归档存储，降低存储成本存储和计算引擎多方联动升级改造：支持热/温/冷分层，热数据放私有云热节点，温数据放私有云

Touch平台，可统一收口验收人员的设备管理，通过云平台提供统一的远程操作入口。这样不论我们的员工在世界任何驻地，都可以方便的使用中心化维护的设备，同时新站点的RC包将在Cloud

静态分析及存储通过静态分析可以得到方法间的调用关系，以及对方法进行标记（api、job、consumer、属性等）和染色（重写、继承、引用、可达等）。静态分析流程如下图所示：图6

作者简介玉修，携程技术专家，专注于电话音视频通信、智能客服机器人等领域。一、前言携程拥有庞大的呼叫中心，涉及上万客服人员，覆盖机票、酒店、火车票、度假等产线的售前售后业务，每天的电话业务量超百万通。近年来，通信技术、人工智能技术和智能终端等都在不断革新，我们也一直在思考如何去做更智能化、自动化的呼叫中心，为未来海量的客户需求提供稳定和优质的服务。携程呼叫中心的智能化包含多个方面：用户侧：智能在线聊天机器人（IM）、智能语音导航/智能语音客服机器人/智能邀评插件（电话）客服侧：智能工单和排班系统、智能质检系统、智能客户资源管理系统、服务渠道智能化系统基建：平台部署智能化、业务监控智能化本文旨在探讨携程实现呼叫中心电话智能语音客服机器人的基建服务——语音识别服务（即ASR）的负载均衡的演进历程，以及最佳实践。二、背景随着人工智能技术的发展，在呼叫中心业务中，传统的

作者简介九号，携程数据技术专家，关注数据仓库架构、数据湖、流式计算、数据治理。一、背景元数据MetaData狭义的解释是用来描述数据的数据，广义的来看，除了业务逻辑直接读写处理的那些业务数据，所有其它用来维持整个系统运转所需的信息／数据都可以叫作元数据。比如数据表格的Schema信息，任务的血缘关系，用户和脚本／任务的权限映射关系信息等等。在数据仓库的建设质量的评估中，一个必不可少的评价指标就是数据产出的及时性，特别是对于P0级别的流程，及时性指标的好坏一方面决定了下游应用方能否准时地获取所需的业务指标，直接影响到业务的工作效率；另一方面也反映了相应指标的数据架构的合理程度。数据及时性，顾名思义就是测试数据需要按时产出。及时性重点关注的三个要素是：定时调度时间、数据任务优先级以及数据产出deadline。其中任务的优先级决定了它获取数据计算资源的多少，影响了任务执行时长。数据deadline则是数据最晚产出时间的统一标准，需要严格遵守。这三要素中，属于业内统一认知且在质量保障阶段需要重点关注的是：数据deadline，这也是我们优化数据流程产出的最终评判标准。二、问题上述部分已经阐述了数据及时性的重要性和评判标准，在通常情况下，为了提升数据及时性，需要投入人力对重点数据流程进行优化。但针对数据仓库业界来讲，对于一个重要的数据结果，其上游可能存在几十个层级，数百个不同的数据处理任务，从最初的数据到最终的结果，数据流转过程极其复杂，传统的通过人工逐个排查的方式去定位影响数据流程产出的问题节点，存在如下的三项缺点：1）覆盖的任务范围有限；2）效率低下，判断标准不统一，判定准确率不高；3）无法形成知识沉淀，依赖于个人能力；如果数据流程未能充分优化，一方面会存在数据结果产出时间不稳定，影响数据的及时性；另一方面也会造成计算资源和存储资源的浪费，并且也不易于后续维护。三、方案为了避免上述的问题，提升数据流程优化的效率和质量，我们采用了从血缘元数据出发的方案。在数仓任务的执行中，都会依赖于一个调度系统组件，目前业内通用的是以DAG为核心的工作流系统，数据流程中的每个任务都会设置定时执行或者配置上游依赖，这些设置的上游依赖就是我们方案中需要的调度血缘的元数据。基于上述的血缘数据，我们的方案中需要实现以下两个功能：基于任务之间的血缘关系生成所有上游任务的层级依赖数据以调度系统本身的元数据作为出发点，调度系统自身的元数据就包含了一个任务的上游和下游依赖，基于这个数据，通过层级递归的扫描，就可以得到指定根节点任务的所有上游任务的层级依赖结果。设计合理的算法定位到有问题的任务在上一步骤得到指定根节点任务的所有上游任务的层级依赖结果后，通过如下三种逻辑定位有问题的任务：1）定位过度分层：JobA的下游只有JobA1在使用，且JobA是JobA1产出的关键路径，也即JobA1的产出时间由JobA决定，那么此种情形下，我们可以把JobA的逻辑合并到JobA1，这样一方面可以减少大数据任务的启动消耗时间和获取资源的时间；另一方面也可以减少依赖层级，方便后续维护。2）定位重复依赖：在较复杂的数据流程中，会出现如下的情况：JobB2依赖JobB1和JobB，而JobB1也同时依赖JobB，简化后的情况如下图：此时我们就可以检查JobB2的逻辑，考虑任务内容中涉及到JobB的逻辑合并到JobB1，从而可以实现流程依赖和代码逻辑的合并优化，降低维护成本，提升整体产出时间。3）定位关键路径:在完成上述两个步骤后，整个流程从结构上已经基本没问题，如果要进一步优化产出时间，需要针对特定任务进行调优，此时可以基于已有的上游层级依赖数据，计算得到每个层级的最晚产出的任务Id，这些任务Id串联在一起就是影响整个流程产出的关键路径，然后对关键路径上的任务进行调优。上述方案的整体设计图如下：四、案例在对酒店订单明细宽表的优化过程中，基于前期的元数据建设，主要的工作内容分为以下三个步骤：1）调度优化。调度优化的出发点是合理分配同步任务的优先级，将非核心任务的数据同步延后。从而降低0到2点，酒店订单宽表核心流程执行期间的集群资源压力。2）模型优化。在这一步骤中，我主要是从两个方向出发：减少跨层级重复依赖，避免相似逻辑代码的出现，提升数据结果的复用能力。避免滥用分层，对冗余的分层、中间表进行合并，减少任务调度链路的层级，减少Job数量，节省Job的启动时间。3）任务优化。通过调整参数设置、SQL逻辑优化的方式对具体任务进行优化需要优化的任务。这一步骤的工作也就是传统认知中的任务优化。其中第二步和第三步就是基于本文中的方案快速定位到问题任务，整体优化后的效果如下：酒店订单明细宽表的7日平均产出时间由2:51提前到1:36，提升45%全流程任务总数量从211个降到145个，减少32%可控上游依赖任务(非外BU任务)总数量由180降到117，减少35%关键链路调度层级由11层减少到6层，且其中两层是外部BU任务五、展望基于元数据和血缘建设，本方案后续有如下三点可以深入优化：跨多层判断重复依赖。由于上述实际案例中的酒店订单流程相对不复杂，在仅进行一层的重复依赖判断后，就已经达到了比较满意的优化效果，所以为继续进行多层重复依赖的判断，但从血缘结构上是可以支持多层判断的。定位多Job中重复/相似逻辑。多个任务依赖同一个上游任务，可以人工进行判断是否存在可合并的重复/相似逻辑；这一点如果要提升效率，需要再结合表的血缘关系一起判断。多数据流程的优化。在数仓的工作中，一个主题域产出的结果表，通常会存在多张，在进行整个主题域流程的优化或者重构中，也可以利用本案的思想，结构化进行优化工作，提升效率。【推荐阅读】贝叶斯结构模型在全量营销效果评估的应用节约60%开发工时，离在线一体化数仓系统在携程旅游的落地实践提速10倍+，StarRocks

作者简介Michael，携程全栈开发专家，追求以技术手段解决业务上的共性问题，构建灵活可配置且可视化的系统，提高生产力，降低沟通成本。CunShun，携程后端开发工程师，专注系统架构、稳定性、低代码等领域。一、引言IVR（交互式语音应答，Interactive

作者简介ck，携程后端开发专家，关注技术架构、高并发、性能调优等领域；Geralt，携程前端开发专家，关注前端框架及性能优化；Kaoru，携程资深前端开发工程师，关注前端性能及开发工具；概述PGClowcode平台是携程市场内容PGC团队搭建的主要用于后台页面开发的低代码平台，第一版于23年3月上线，截至10月平台已经拥有100+用户，在平台上开发了130+个应用和180+个页面。本文将主要介绍团队采用低代码平台的背景、方案调研、落地过程中遇到的问题以及解决方案，同时也大致介绍了该低代码平台提供的能力。一、研究背景1.1

作者简介Kurtis，携程后端开发专家，关注性能优化、技术架构等领域。一、前言在电子商务平台上，商品结构起着至关重要的作用。它不仅承载着预订和服务流程中的商品信息，还在商户运营效率、平台可扩展性以及终端用户体验等多个维度产生显著影响。通过高度结构化的商品信息，平台能够运用数据分析和算法，更精准地推荐合适商品给目标用户群，更加高效地为买卖家用户创造价值，从而提升交易效率和客户满意度。本文介绍了门票活动商品结构的演进和过程中的技术挑战。二、背景与发展轨迹2.1

作者简介py.an，携程后端研发经理，关注性能优化、技术架构等领域venson，携程后端高级研发经理，关注性能优化、技术架构等领域一、引言在全球化战略的背景下，Trip.com作为一个面向国际市场的全球OTA平台，正努力推进国际化战略部署。Trip.com火车票正在积极投入资源和技术力量来拓展海外业务，通过将应用、数据部署新加坡、法兰克福等中心，从而给全球用户带来更好的购票体验和减少数据合规带来的风险。二、业务背景如图所示，目前Trip.com火车票全球铁路业务主要集中在英国、亚洲和欧洲各国，其中欧洲作为世界上经济、交通非常发达的大洲，也成为更加关注的一站，未来还有更多更大的舞台。随着全球疫情危机消退，旅游和出行需求得到释放，在多语言，多币种的场景支持下Trip.com火车票的全球化业务局面已逐步形成。三、面临的挑战全球化背景下，除了要考虑全球的平滑部署来满足应用可用性和用户访问性能要求外，还需要考虑数据出海的安全性、法律合规和数据隔离等严格要求。通过以下几个角度举例：3.1

作者简介Yiwen，携程数据分析师，专注用户增长、因果推断、数据科学等领域。一、背景如何科学地推断某个产品策略对观测指标产生的效应非常重要，这能够帮助产品和运营更精准地得到该策略的价值，从而进行后续方向的迭代及调整。在因果推断框架下，效果评估的黄金准则一定是“AB实验”，因为实验的分流被认为是完全随机且均匀的，在此基础上对比实验组与对照组的指标差异就可以体现某个干预带来的增量值。但是很多场景下，我们较难进行严格的AB实验，例如对于酒店的定价；现金奖励的发放等等，不适宜向不同人群展现不同的内容。对于这些问题，我们会采取因果推断的方法来进行策略的效果评估。本文主要介绍BSTS模型原理以及CausalImpact对模型的代码实现，旨在面对一些具有特定周期性特点的数据时，更精准科学地进行因果效应值的估计。下文将首先对模型原理进行简要阐释；随后利用模拟数据展示代码逻辑，最后在具体的业务场景中进行实践。二、现有方法及潜在问题大部分运营和产品在评估一些全量上线的策略效果时，最常用的方式就是看上线前后的效果差异。但这种方法最大的问题在于其假设前提：假设上线的功能是唯一影响效果的变量（即没有任何其他干预和混淆变量），但这个假设现实中往往很难实现。于是我们尝试使用更多因果推断的方法，例如PSM（倾向分匹配法），在所有非实验组的用户群中，找到与实验组用户的特征非常相似的一群人，将他们的指标数据（例如下单率，订单收益等等）与实验组的用户进行对比，从而体现出干预带来的影响。但这个方法较为依赖选取的用户特征与最后的匹配效果。再例如SCM（合成控制方法），利用一些未受干预的地区合成一个“类似的虚拟地区”来与“上线策略的地区”进行整体的对比。但这也需要一个关键假设：可以找到长期变化趋势高度同步的地区来进行对照，而这个条件往往也很难实现。进而在传统SCM的基础上，我们企图通过类似集成学习的方法，将多个未干预的对照组作为输入值，再结合实验组自身长期的时间序列波动情况，拟合出一个未受干预的虚拟对照组，从而将“对照组与实验组高度同步”的强假设降为弱假设。本文介绍的BSTS模型就是用来刻画某种“长期的时间序列波动”的数据模型，CausalImpact是用来针对这样的数据进行因果效应值的估计。下文中我们将详细介绍这两个工具。三、模型介绍BSTS模型

的用例结构来进行构建该生成器的目的内容。因为文本节点的结构是一致的，我们需要手动给不同的文本节点赋上不同的语句含义，在此处我们通过在平台上给视觉稿图层打标签进行实现。在实现上，通过递归

作者简介零一，携程算法工程师，专注于智能告警、容量管理、根因定位等领域。一、背景携程作为在线旅游公司，对外提供机票、酒店、火车票、度假等丰富的旅游产品，其系统稳定性关乎用户是否具有顺滑的出行体验。然而，流量激增、代码发布、运维变更等都会给系统稳定性带来挑战。我们在2020年对生产故障的“发现-定位-解决效率”提出了“1-5-10”的目标（即一分钟发现故障，五分钟定位故障，十分钟解决故障），这无疑对监控告警提出了很高的要求。订单量是生产故障异常检测场景中最核心最显性的指标，订单量在自身形态上具有周期性、规律上升和下降、业务高峰和低谷等特点，影响因素包括节假日、促销等。倘若数以万计的业务线通过人工配置规则的方式来覆盖到所有业务场景，并且做到高准确率和召回率，是非常不现实的。因此，迫切需要一套配置费力度低、普适性强、准确率高、时效性强的智能异常检测算法体系来及时发现异常。指标异常检测是智能运维领域的重要落地场景，携程AIOPS团队致力于提升告警质量，寻找告警效率、准确率和真实故障召回率三者之间的平衡点。我们将统计学方法和机器学习方法结合，根据指标的历史数据，将训练的多个模型组成一套异常检测系统，在覆盖真实故障的基础上，减少告警数量，产生更有价值的告警。二、告警质量提升2.1

作者简介haibing，携程研发能效经理和SRE，关注自动化测试，能效提升方向的工具技术。一、背景随着携程机票BU业务规模的不断提高，业务系统日趋复杂，各种问题和挑战也随之而来。对于研发测试团队，面临着各种效能困境，包括业务复杂度高、数据构造工作量大、回归测试全量回归、沟通成本高、测试用例数量多且难以复用、测试数据维护量大以及自动化用例管理等问题。每个都会影响测试团队的效率和质量，给软件研发过程带来挑战。总结下来主要是两个核心困难点：成本与复杂度。成本方面，我们通常需要在成本和质量之间做出取舍，需要在快速迭代的同时保证质量，又需要在限定的投入下保证质量。复杂度方面，当业务规则积累一段时间后，业务流程、规则、场景和数据处理的复杂度在叠加后呈二次或者指数等形式增加，给测试质量工作带来很大的挑战。二、探索：自动化回归测试的探索与实践为了应对这些挑战，我们在质量和测试工作中进行了一些持续性探索：1）AUTO

作者简介Chengrui，携程后端开发专家，关注实时数据处理、AI基础平台建设以及数据产品等领域。本文主要介绍离在线数据仓库建设在携程旅游团队的落地与实践，将从业务痛点、业务目标、项目架构、项目建设等维度展开。一、业务痛点随着数据实时化需求增多，离线数仓暴露出来的业务痛点也越来越多，例如：实时需求烟囱开发模式中间数据可复用性差离在线数据开发割裂数据生产->服务周期长实时表/任务杂乱、无法管理实时血缘/基本信息/监控等缺失实时数据

作者简介Mega，携程国际机票工程师，关注Java、devops领域。一、前言大多数的技术研发都对重构有所了解，而每个研发又都有自己的理解。从代码重构到架构重构，我参与了携程大型全链路重构项目，积累了一点经验心得，在此抛砖引玉和大家分享。二、重构的定义重构是指在不改变外部行为的情况下，改进其内部结构的软件系统更改过程。三、重构的原因3.1

hydrateRoot(document.getElementById('root'),)})这时，控制台的报错内容全部消失了，同时页面上也正常展示了从服务器中获取的评论数据。直接通过

({"test":"index-module__test___Bm2J6","txt":"index-module__txt___nIysk"});//

{flutterEngine.getActivityControlSurface().detachFromActivityForConfigChanges();}

性能优化以上方案在实践的过程中，做了很多优化，大致可以归纳成以下几点：1）消息积压由于需要处理的延迟消息会因为消费能力不足的情况导致消息积压的问题。优化这一问题主要从以下几个方面入手：Delay

作者简介Kane，携程高级数仓经理，专注数仓建设、数据应用和分析；Wn，大数据平台开发专家，专注大数据领域。携程火车票事业群运营着铁友、携程火车票和去哪儿火车票等重要的业务和品牌，目前正在积极地拓展海外市场。火车票的指标平台旨在为业务人员提供便捷的指标查询服务，让业务人员能够快速灵活地获得这些业务和品牌相关的指标数据。一、早期

作者简介Seven，数据分析师，专注用户增长、数据科学等领域。一、背景携程作为旅游平台，跟用户需求息息相关，理解和识别各个策略/系统对转化/收益的因果关系尤为重要，在这个过程中需要将影响因变量的其他因素进行控制，但这些因素通常是复杂且难以测量的。在关系识别困难的情况下，如何使用更为科学的方法，对策略进行微观和宏观的建模分析，如何系统性的评估各种策略的长期影响，是要解决的重要问题。在火车票

操作的次数，以提高动画的性能和流畅度。四、结论动画给予了页面丰富的视觉体验。我们应该尽力避免使用会触发重布局和重绘的属性，以免失帧。最好提前申明动画，这样能让浏览器提前对动画进行优化。由于

}};由此，不管什么场景下，我们都可以用类似的方式实现与宿主环境的通信。再看下“在合适的时机显示组件”这种场景，首先我们理解下什么是“合适的时机”，也许你会想，在符合特定业务逻辑的前提下，让

作者简介Wen，携程资深后端开发工程师，专注系统性能、稳定性、交易系统等领域。一、背景在现今的信息时代，微服务技术已成为一种重要的解决方案，微服务技术可以使系统的规模和功能变的更加灵活，从而获得更高的可扩展性和可用性。然而，微服务调用中出现的超时问题，却也成为系统可用性的一大隐患。超时会导致客户端的性能下降，甚至可能无法正常工作。本文针对超时问题，提出相关的优化手段，降低微服务调用超时的风险。1.1

作者简介Senna，携程前端开发工程师，关注组件化开发，低代码平台建设。Yuan，携程前端开发工程师，专注前端组件化和低代码平台建设。一、背景携程各个BU各个时期都有不同营销页面，数量众多，其中很重要的一块是产品模块，运营需求的产品卡片样式众多，各个BU展示字段差别巨大，无法利用通用样式，因此如需新增卡片或字段，传统做法是运营提需求给设计，再提需求给开发，经过需求评审，正式开发，发布测试上线等等。每次遇到大促活动或者接入新的业务方，都需要重新设计及开发商卡，而新的商卡大多只是新增一些换肤样式，或个别字段，这却需要开发人员多写一套样式代码或新增字段样式，同一个样式应用于不同的业务方也需要重新进行开发，极大地浪费了开发和设计资源。在DIY商品卡片系统开发前，由于开发成本的限制，营销页面上常用的商品卡片样式基本固定为十几种，这在用户看来缺乏新意，吸引力不足，从而在一定程度上影响了营销页面商卡的点击量。综上所述，为解决传统商卡存在的以下问题：即使样式差别很小也需要重复开发，耗时耗力。没法多平台统一卡片样式，难于管理、复用性低。样式固定、对用户吸引力低导致点击率及订单转化率低。我们从UI和逻辑解耦，UI模板在平台配置生成的角度考虑解决问题，设计了DIY商品卡片系统。二、系统介绍商卡系统将UI和逻辑进行解耦，UI部分可在商卡配置后台进行配置，逻辑部分由开发人员处理后引入原子UI组件进行最终渲染。2.1

Stage:pre这里由于我们需要一些环境的依赖，因此我这里做了一下几个环境的check，我们配置了对几个依赖项的版本check，当然这里也可以增加一些校验为安装的情况下补充安装的步骤等。3.3

图5：通过versionPath文件控制版本模块aar的核心在于对依赖项的控制。我们想要的是一个app壳+部分源码模块+部分aar模块+其他依赖的结构，因此下面几点是要考虑到的：在所有子模块发布

Harness）对三种字符串格式化方法和一种字符串拼接方法进行耗时测试。测试结果表明，使用Java8的replace方法实现的字符串格式化性能最差，而使用Apache的字符串拼接函数性能最佳。表1

小程序webview内嵌H5H5页面投放在小程序WebView，在配置完合法域名后，即可在小程序应用中展示。那么，针对不同厂商小程序，可能法务、厂商合规有所差异，需要H5判断所在的环境，去调用不同

作者简介携程前端框架团队，为携程集团各业务线在PC、H5、小程序等各阶段提供优秀的Web解决方案。产品涉及各类前端/Node端应用框架、研发工作台、前端中台化、静态资源发布系统等。当前主要专注方向包括：新一代研发模式探索，Rust构建工具链路升级、Serverless应用框架开发、在线文档系统开发、低代码平台搭建、适老化与无障碍探索等。摘要携程小程序自动化错误预警方案是一套完整且通用的小程序前端错误监控方案。此方案提供小程序错误自动采集SDK，并对错误所在的页面路径进行偏移矫正，能够准确通知相应的开发负责人；将错误信息分为生产、测试、开发3种阶段，根据错误发生的阶段提供相应的错误预警及处理方案；开发负责人只需在小程序管理平台配置告警所需信息，即可快速接入、实时监控生产报错、生成告警通知；源码映射能力可以帮助开发者快速定位错误原因，提升修复效率。接入此方案可实时捕获开发环境错误，确保在小程序发布上线前发现并解决业务报错，可极大地减少线上小程序的错误量。一、为什么要做错误监控携程小程序产品是to

目前查询服务已经在jemalloc上生产运行了数个月，至今还没有观察到再次出现堆外溢出的问题；同时RSS的波动非常稳定，即使遇到流量高峰也不会出现内存尖刺，可以保持良好的响应时间和稳定。

数据结构：（3）问题3：“构建布局关系”是所有步骤中最复杂的一步，因为它涉及到许多技术难点，且几乎没有可供借鉴的开源资料。我们可能需要通过不断的尝试来解决问题。实际上，构建布局关系是基于之前提到的

会在每次事件执行完毕后释放函数，相当于每次事件执行完毕都会进行一次“去水合”的过程。所以，当你触发一次事件和无数次事件函数在执行过程中对于内存占用来说是相差无几的。当然相较于传统

作者简介李羽，携程高级前端研发工程师，专注前端跨平台框架领域的开发与研究。Hyme，携程前端研发经理，专注前端小程序/H5领域的开发与研究。Chao，携程前端研发经理，关注前端跨平台领域与前端研发效率提升。一、项目背景随着小程序用户的增长，APP和小程序在需求迭代上呈齐头并进的趋势。与此同时，前端研发人员面对多套平台代码的维护与开发，研发投入上耗时耗力。目前携程内部急需一种跨平台的开发框架，来节约不必要的多套开发量。

作者简介提挈，携程资深数据库工程师，专注于数据库自动化运维和分布式数据库的研究。Cong，携程数据库专家，主要负责MySQL和分布式数据库运维及研究。Typhoon，携程高级数据库工程师，负责分布式数据库的运维和工具设计。一、前言MySQL在业界流行多年，很好地支撑了携程的业务发展。但随着技术多元化及业务的不断发展，MySQL也遇到了新的挑战，主要体现在：业务数据模型呈现多元化，OLTP和OLAP出现融合的趋势；在MySQL数据库上慢查询治理成本高；使用传统的分库分表方案对开发不友好，核心数据库改造成分库分表方案，时间一般以年为单位。分布式数据库能比较好地解决上述问题，同时也带来了新的挑战。2021年，OceanBase（简称OB）开源，携程开始逐步探索OceanBase的基本特性和应用场景。OceanBase兼容大部分MySQL的功能和语法，同时提供水平扩展性、强一致性和高可用性，能满足业务需求并降低运维成本。因此，我们开始推进部分MySQL实例迁移到OB。为保证迁移顺畅，我们设计了迁移评估工具、OB迁移流程、OB监控大盘和OB故障诊断工具等。并将迁移过程中遇到的问题和大家进行分享。二、评估工具平滑迁移异构数据库，我们需要进行兼容性、性能和分区适应性等各项检查。提前把不兼容或有可能引起迁移异常的场景找出来并解决。官方提供了OceanBase

作者简介秋石，携程数据仓库专家，关注大数据、数据仓库、数据治理等领域；九号，携程数据技术专家，关注数据仓库架构、数据湖、数据治理；魁伟，携程资深数据工程师，关注实时&离线大数据产品及技术。一、实时数仓当前，企业对于数据实时性的需求越来越迫切，因此需要实时数仓来满足这些需求。传统的离线数仓的数据时效性通常为

作者简介Dongyu，资深云原生研发工程师，专注于日志与OLAP领域，主要负责携程日志平台和CHPaas平台的研发及其运维管理工作。本文将从以下五部分切入，讲述日志系统的演进之路：携程日志的背景和现状、如何搭建一套日志系统、从

作者简介Xiaoxing，携程IT资深软件工程师，深耕前后端全栈技术，专注WinForm应用，自动化、效率提升类工具开发。Hui，携程IT桌面支持经理，致力于用户服务相关平台、工具的功能优化和体验升级。术语本地服务：以系统权限（Local

类型关系在确定了基本的语法规则后，我们需要定义一些基本的类型关系，这无论是在面向对象编程还是函数式编程中都非常重要。这些类型关系可以在代码编写阶段约束一些语法准则，避免将

作者简介HongLiang，携程高级技术专家，专注系统性能、稳定性、承载能力和交易质量，在技术架构演进、高并发等领域有丰富的实践经验。一、背景微服务架构在中大型互联网公司中被广泛应用，随着业务的发展，应用数越来越多、调用关系也越来越复杂。中台化后，交易系统要支持业务线多，系统复杂性高，原系统虽然能支撑业务量的持续增长，但在稳定性、吞吐力和资源利用率上面，还存在优化空间。分享的目的本文站在业务开发角度介绍开发在微服务架构下遇到的相关问题（微服务架构的优缺点这里不再赘述），以门票活动预订流程查询引擎为例，分享微服务治理的实战经验，希望能给遇到同样问题的同学提供一些借鉴思路。如下图所示，蓝色部分为本文的重点图1

作者简介Lyan，携程资深后端开发工程师，负责自动化测试框架及平台类工具开发，关注Devops、研发效能领域。一、背景随着敏捷开发，DevOps开发模式的流行，代码质量分析作为研发质量保证体系的重要组成部分，不仅能有效的降低因频繁迭代带来的故障风险，而且对整个工程团队的效能提升有着巨大的价值。携程很久以前就已经开始进行DevOps的建设，通过Gitlab

作者简介携程前端框架团队，为携程集团各业务线在PC、H5、小程序等各阶段提供优秀的Web解决方案。当前主要专注方向包括：新一代研发模式探索，Rust构建工具链路升级、Serverless应用框架开发、在线文档系统开发、低代码平台搭建、适老化与无障碍探索等。一、项目背景2022，携程PC版首页终于迎来了首次改版，完成了用户体验与技术栈的全面升级。作为与用户连接的重要入口，旧版PC首页已经陪伴携程走过了22年，承担着重要使命的同时，也遇到了很多问题：维护/更新困难祖传代码黑盒逻辑过多，产品也难以推动新需求的上线，旧版首页已经不能满足高速发展的业务需求。技术栈陈旧且不统一互联网技术日新月异，旧版首页的整体架构设计和技术栈都相对落后，且大首页中各个组件的研发涉及多事业部合作，存在技术选型差异的问题，增加了维护成本。用户体验有待改善旧版携程首页的设计风格沿用至今，在视觉和交互层面上，都已经难以满足用户不断提升的互联网体验和审美需求。综合上述情况，为了给用户提供更好的服务，携程首页的整体改造迫在眉睫。二、需求分析携程首页改造需要考虑的核心问题包括以下几个方面：技术选型为了优化首屏性能，提升用户体验，携程新版首页采用服务端渲染模式。在技术选型上，考虑到我们希望应用层是轻量的，只做页面HTML拼接和响应两件事情，最终决定基于Node.js构建应用载体，客户端则统一使用公司主流的React技术栈。跨团队合作首页作为携程的重要门户，涉及多业务线的流量入口。如图1所示，我们可以将整个页面进行切割，按业务线划分成多个组件模块。图1

作者简介Flora，携程高级研发经理，关注Node.js相关领域。本文主要记录一次静态资源服务源站更新了跨域策略后，引发的客户端跨域请求失败的案例。如果对跨域不太熟悉的同学，可以阅读一下MDN

world.1989年，英国科学家蒂姆-伯纳斯-李在欧洲核子研究中心工作时发明了万维网（WWW）。万维网最初是为了满足世界各地大学和研究所的科学家之间自动分享信息的需求而构思和开发的。Web

作者简介jzg，携程资深前端开发工程师，专注Android开发；zcc，携程高级前端开发工程师，专注iOS开发。一、前言随着移动端短视频的火热，音视频编辑工具在做内容类APP上的地位举足轻重。丰富的转场方式可以给短视频带来更多炫酷的效果，从而更好地赢得用户青睐。本议题主要包含了对OpenGL的简单介绍及相关API使用，GLSL着色器语言的基本使用，以及如何通过编写自定义的着色器程序来实现图片的转场效果。二、为什么使用OpenGL以及使用的难点2.1

作者简介Kenny，携程高级前端开发工程师。2021年加入携程，从事小程序/H5相关研发工作。一、背景随着项目的不断迭代，规模日益增大，而基于Taro3的运行时弊端也日渐凸显，尤其在复杂列表页面上表现欠佳，极度影响用户体验。本文将以复杂列表的性能优化为主旨，尝试建立检测指标，了解性能瓶颈，通过预加载、缓存、优化组件层级、优化数据结构等多种方式，实验后提供一些技术方案的建议，希望可以给大家带来一些思路。二、问题现状及分析我们以酒店某一多功能列表为例(下图)，设定检测标准(setData次数及该setData的响应时效作为指标)，检测情况如下:指标setData次数渲染耗时(ms)第一次进入列表页72404下拉长列表更新31903多屏列表下

查找了大量资料，发现AppleScript是一个与macOS结合非常紧密的脚本语言，它显著的特点就是可以控制其他macOS上的应用程序，通过使用它可以完成一些繁琐重复的工作。代码如下：

作者简介Harry，携程资深后端开发工程师，负责直连平台建设，关注系统高可用、数据驱动等领域。一、前言携程门票活动供应商直连平台（以下简称“直连平台”）通过API对接多个供应商的订单和商品系统，实现自动化信息同步和状态流转。随着业务的高速发展，供应商的对接需求与日俱增，这不仅对直连平台接入供应商的上线效率提出更高的要求，同时供应商系统的物理网络限制、稳定性参差不齐等情况也给直连平台带来不小的挑战。本文将从提高供应商接入效率和增强系统稳定性两个方面分享直连平台的实践经验。二、背景2.1