服务器 频道

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

  一、前言

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

  机票前台预订主流程服务现在有若干个系统,每个系统部署了多个服务,每个服务又依赖多个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等自动化功能降低人工成本

  5.3 降低沟通成本,提高了日常排障的产能,日常问题反馈中多以Trace系统外链进行信息共享

  5.4 打通报表系统后使得异常场景筛查形成闭环

0
相关文章