一、前言
随着微服务架构的普及，这些微服务构成了复杂的分布式网络，在支撑我们海量查询的同时，也带来了一些问题。
机票前台预订主流程服务现在有若干个系统，每个系统部署了多个服务，每个服务又依赖多个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实现页面回放，高保真还原所见界面。
4.6 一键Mock功能
日常工作中，日志体系和自动化设施处于割裂状态，主要体现在日志和Mock系统的结合使用。
在之前的使用流程中，我们需要在Kibana中搜索到链路日志，然后将接口调用的报文，在Mock系统中进行配置，这样的操作是比较费时费力的。有些服务调用的接口数量高达二三十个，这样的数据人工配置的话需要浪费非常长的时间。
针对这个问题，Trace系统在链路聚合的基础上提供了一键Mock的功能，将此次服务所涉及的链路调用全部自动配置到接口中，过程无需人工干涉，将之前需要十分钟的工作降低至五秒内，极大地提高了工作效率。
4.7 关键信息外露
针对一些服务的错误场景，将错误码转换为实际错误文案，友好提示系统用户。
4.8 联通报表系统
报表系统是前台用于日常业务的监控系统，它能实时监控异常的业务场景和业务处理结果。Trace系统联通报表系统，在报表系统中可以通过外链跳转至Trace系统，并传递异常场景的相关参数，如用户标志，场景限定等，从而获取异常场景的上下文（日志），见4.7示图。
4.9 外链其他平台
采用了外链的形式进行多平台功能聚合，并关联单次查询的搜索数据，如时间、用户标志等，进行多平台之间的传递，从而达到数据串联的效果。
五、总结
Trace系统是针对日常开发运维过程中所浮现的一些问题，所研发的效能工具系统，它以降低开发运维成本，提高日常产能为目标，提供了诸多便捷性功能。系统在上线投入使用后，效果显著，取得了较大的产出和成果。
5.1 降低非开发人员的使用门槛，提高问题筛查的自助率，提升相应效率
- 对数据进行业务含义转换，信息直接明了，提升自助率
- 还原用户预订场景，精准获取用户反馈信息的同时，提高问题自检力
5.2 降低人力成本
- 多业务场景聚合，解决多业务模块关联查询的费力度问题
- 提升非开发人员的自助率，减少人力成本
- 报文自动解压缩，一键Mock等自动化功能降低人工成本
