干货 | 携程机票前台Trace系统的演进之路

关注

原创最新推荐文章于 2026-04-06 14:38:43 发布 2.4k 阅读 AI 写同款· GEO 优化 ›

携程商旅酒店直连平台的实践（一）现在才发现，离我上一篇博文竟然接近1年没有发过东西了。惊呆了我。我要每周都写了，就算不写技术也要写其他东西，不然真的是思考的多，没有留下记录都是空白。在携程商旅主要做酒店直连这一块。商旅酒店其实架构都很老，并且实践的技术很多不是很新。但是抗住了之前的压力，但是开始做直连之后就显得比较不行了。之前商旅的酒店类型区分为如下 1.OTA酒店 2.单体酒店 3.非直连套系酒店 4.直连套系酒店区... 阅读详情

作者简介

Devin，携程资深后端开发工程师，专注 Java相关领域以及自动化相关的研究

Hank，携程资深后端开发工程师，专注 java以及.net技术领域的研究

一、前言

随着微服务架构的普及，这些微服务构成了复杂的分布式网络，在支撑我们海量查询的同时，也带来了一些问题。

机票前台预订主流程服务现在有若干个系统，每个系统部署了多个服务，每个服务又依赖多个API，用户通过终端设备（手机、PC等）预订了机票产品，过程中出现“系统异常”该如何分析排查呢？

运营人员将问题抛给开发/测试人员定位，开发/测试人员只知道有异常，如何高效地从复杂的调用链条中找到原因，这对开发/测试人员会带来很大的挑战。

开发/测试人员借助单点日志逐个排查的效率是非常低的，特别是一些UI层的“待确认”的问题，只依赖一些日志报文进行排查效率是非常低下的。

如何提高开发/测试人员的排查效率，同时降低非开发人员的使用门槛？答案或许就是携程机票前台Trace系统。

二、Trace系统的发展历程

2.1 基于原始日志的Dev&Ops

机票前台的日志记录还是比较完善的，我们将系统中的服务以及上下游依赖的服务都进行了日志写入。依据业务属性制作了一些Kibana面板，结合一些解压缩工具是可以满足日常需求的。

在微服务架构中，随着业务的不断增加，复杂度同样也会越来高，对开发/测试以及运维人员的效率带来了很大的挑战，主要问题体现在：

不同的微服务，多个日志Topic，多个查询面板
需要人为手动聚合/串联不同的微服务的日志，还原用户行为
不同团队的服务，日志压缩方式存在差异，解压方式不同
面向开发的服务名称，可读性低
公司内部系统间未打通，互相之间操作需要手工方式处理

2.2 基础建设

经过长时间的实践和探索，机票前台的日志体系和自动化设施都较为完备。

日志体系在机票前台主要有以下三类日志，这三类日志可以满足日常开发运维的基本需求，实现对整个流程的精准把控。

UBT日志，主要记录用户的一些行为日志，便于解决用户反馈的问题
Mertics日志，主要记录一些业务指标，作为内部后续业务需求演进的依据
Trace日志，记录服务处理过程中所产生的信息日志，如接口报文，错误信息等。

自动化设施，大幅度降低日常运维开发的成本。

Mock平台：通过Mock平台可以实现数据源（接口、DB等）定制化，从而控制和分析程序的逻辑走向。
接口自动化平台：结合Mock平台实现服务接口的自动化测试

2.3 基于Chrome插件版本的Trace 工具

机票前台通过日志和自动化建设来保证日常开发运维的基本流程，通过Chrome插件来解决一些重复工作。比如：

解压缩日志报文
格式化解压后的报文
快捷复制

插件模式解决了一些重复工作，对效率有一定的提升。

2.4 遇到的问题

随着业务的不断膨胀，微服务越来越多。作为BFF层（Backends For Frontends 服务于前端的后端）我们需要聚合多个接口方提供的微服务，使得BFF层的调用关系也会越来越复杂。

现有的“插件模式”已经很难满足日常工作。

“插件模式Trace系统”遇到了如下一些问题：

如何通过日志清晰的展示调用关系
如何查询“过期日志”（ES有效期以外）
微服务越来越多，如何快速通过搜索条件检索目标微服务
如何高保真的还原用户预订时所见
如何与其他系统打通（例如Mock系统、用户行为系统等）
提高偏技术的“晦涩难懂”信息的可读性

三、系统设计

针对上述的问题，Trace系统进行了一些针对性的优化和演进。目前Trace系统大致架构如图所示。

业务层：根据业务使用方分为前台主流程、机酒业务、增值业务、IBU等
Web层：主要有四个部分，搜索条件、数据展示、页面回放、一键Mock
搜索引擎层：根据Web传达到服务的请求（搜索条件），构建Clickhouse的搜索SQL，从Clickhouse获取数据
数据处理层：根据业务线将CK数据进行加工组装、处理一键Mock请求，并将数据传送至Web进行反馈
配置信息：配置信息主要是针对引擎层做Clickhouse搜索配置以及业务层做业务字段配置
日志记录：隶属于各个业务方的具体应用

四、系统的功能介绍

4.1 友好的搜索条件

针对Kibana的搜索条件进行了降噪和业务封装，采用了更适合用户行为习惯的友好搜索条件，见下图标志1。

4.2 日志查看功能

报文日志一般记录在ES/Clickhouse中，并最终在Kibana中呈现。在Kibana中可以通过组合过滤条件来获取我们需要的日志，并且也可以实现聚合服务整个链路日志的目的，但是Kibana存有一些用户行为习惯上的问题。

Kibana暴露原始的查询条件，所以数据较多，对于业务人员来说有冗余条件。
Kibana聚合日志的方式需要人工组合，并且日志类别一致，链路层次感不够清晰。

结合这两点，Trace系统对搜索条件进行了降噪，并且对链路日志采用分层处理，给予用户友好的使用体验。对日志报文支持自动解压缩以及格式化。

4.3 聚合多平台

上面提到的日志体系，三类日志存放在不同的数据源，通过不同平台进行展示。这也就导致日常过程中需要游走于多平台进行数据采集和分析。

比如在分析服务日志的同时需要查询用户的UI访问日志，需要在两个平台间跳转，并且平台的搜索数据无法同步。为了解决该问题，Trace系统采用了外链的形式进行聚合并关联单次查询的搜索数据，如时间和用户标志等，进行多平台之间的传递，从而达到数据串联的效果。

之所以采用外链方式而非在系统内部集成多平台内容，主要的考虑在于该系统的定位是做链路的追踪处理。如果耦合了过多的数据，系统就会变的复杂，会给系统用户造成过多的干扰。

4.4 多业务场景聚合，过期日志补偿

系统在一次搜索中聚合多个业务线，如主流程预订，低价订阅，增值产品等，无需用户手动区分搜索渠道。并且对于Clickhouse过期（ClickHouse日志只存储半个月时间）数据采用Hive查询进行数据补偿。解决用户在ClieckHouse和Hive中切换。

4.5 基于CRN_Web技术的页面回放功能

日志体系和自动化设施的结合除了两者处于割裂状态之外，还有一个问题在于双方都是隶属于技术驱动，而对于非开发人员来说，具有较高的使用壁垒。比如在运维人员复现用户反馈问题的时候，需要开发人员介入，进行日志数据准备，环境Mock准备，而后才可以复现用户反馈的问题。而往往用户反馈的问题中，大多数是UI展示层面的问题，如果按照上述流程，则排障的成本较大。

因而Trace系统在链路追踪和自动Mock的基础上提供了用户页面回放的功能。系统会收集用户访问页面关联的所有服务请求的日志，将日志报文进行Mock，再通过CRNWeb技术，真实发起一次页面访问，此时服务会返回相应的Mock报文，从而达到页面回放的效果，让运维人员更加直观的了解用户所反馈的问题。

通过BatcheId关联一次页面访问中的同批次服务，系统进行自动拉取报文并进行Mock，然后将Mock结果关联当前用户标志，通过CRNWeb实现页面回放，高保真还原所见界面。