作者｜Devin ，携程e系携程资深后端开发工程师 ，机票专注 Java相关领域以及自动化相关的前台研究；Hank ，携程资深后端开发工程师，演进专注 java以及.net技术领域的携程e系研究
随着微服务架构的机票普及 ，这些微服务构成了复杂的前台分布式网络，在支撑我们海量查询的演进同时，也带来了一些问题。携程e系
机票前台预订主流程服务现在有若干个系统 ，机票每个系统部署了多个服务 ，前台每个服务又依赖多个API ，亿华云演进用户通过终端设备（手机 、携程e系PC等）预订了机票产品 ，机票过程中出现“系统异常”该如何分析排查呢 ？前台
运营人员将问题抛给开发/测试人员定位 ，开发/测试人员只知道有异常 ，如何高效地从复杂的调用链条中找到原因 ，这对开发/测试人员会带来很大的挑战 。
开发/测试人员借助单点日志逐个排查的效率是非常低的 ，特别是一些UI层的“待确认”的问题 ，云计算只依赖一些日志报文进行排查效率是非常低下的。
如何提高开发/测试人员的排查效率 ，同时降低非开发人员的使用门槛 ？答案或许就是携程机票前台Trace系统 。
机票前台的日志记录还是比较完善的 ，我们将系统中的服务器租用服务以及上下游依赖的服务都进行了日志写入 。依据业务属性制作了一些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系统大致架构如图所示 。
针对Kibana的搜索条件进行了降噪和业务封装 ，采用了更适合用户行为习惯的友好搜索条件，见下图标志1 。
报文日志一般记录在ES/Clickhouse中 ，并最终在Kibana中呈现 。在Kibana中可以通过组合过滤条件来获取我们需要的日志 ，并且也可以实现聚合服务整个链路日志的目的 ，但是Kibana存有一些用户行为习惯上的问题 。
Kibana暴露原始的查询条件 ，所以数据较多 ，对于业务人员来说有冗余条件 。Kibana聚合日志的方式需要人工组合 ，并且日志类别一致，链路层次感不够清晰 。结合这两点，Trace系统对搜索条件进行了降噪 ，并且对链路日志采用分层处理 ，给予用户友好的使用体验 。对日志报文支持自动解压缩以及格式化 。
上面提到的日志体系 ，三类日志存放在不同的数据源，通过不同平台进行展示 。这也就导致日常过程中需要游走于多平台进行数据采集和分析 。
比如在分析服务日志的同时需要查询用户的UI访问日志 ，需要在两个平台间跳转 ，并且平台的搜索数据无法同步 。为了解决该问题 ，Trace系统采用了外链的形式进行聚合并关联单次查询的搜索数据 ，如时间和用户标志等 ，进行多平台之间的传递 ，从而达到数据串联的效果 。
之所以采用外链方式而非在系统内部集成多平台内容 ，主要的考虑在于该系统的定位是做链路的追踪处理 。如果耦合了过多的数据 ，系统就会变的复杂 ，会给系统用户造成过多的干扰 。
系统在一次搜索中聚合多个业务线 ，如主流程预订 ，低价订阅，增值产品等 ，无需用户手动区分搜索渠道。并且对于Clickhouse过期（ClickHouse日志只存储半个月时间）数据采用Hive查询进行数据补偿 。解决用户在ClieckHouse和Hive中切换 。
4.5 基于CRN_Web技术的页面回放功能日志体系和自动化设施的结合除了两者处于割裂状态之外 ，还有一个问题在于双方都是隶属于技术驱动 ，而对于非开发人员来说 ，具有较高的使用壁垒 。比如在运维人员复现用户反馈问题的时候 ，需要开发人员介入 ，进行日志数据准备 ，环境Mock准备 ，而后才可以复现用户反馈的问题 。而往往用户反馈的问题中，大多数是UI展示层面的问题，如果按照上述流程，则排障的成本较大 。
因而Trace系统在链路追踪和自动Mock的基础上提供了用户页面回放的功能 。系统会收集用户访问页面关联的所有服务请求的日志 ，将日志报文进行Mock ，再通过CRNWeb技术 ，真实发起一次页面访问 ，此时服务会返回相应的Mock报文 ，从而达到页面回放的效果，让运维人员更加直观的了解用户所反馈的问题。
通过BatcheId关联一次页面访问中的同批次服务 ，系统进行自动拉取报文并进行Mock ，然后将Mock结果关联当前用户标志 ，通过CRNWeb实现页面回放 ，高保真还原所见界面 。
日常工作中，日志体系和自动化设施处于割裂状态 ，主要体现在日志和Mock系统的结合使用 。
在之前的使用流程中 ，我们需要在Kibana中搜索到链路日志 ，然后将接口调用的报文 ，在Mock系统中进行配置 ，这样的操作是比较费时费力的 。有些服务调用的接口数量高达二三十个 ，这样的数据人工配置的话需要浪费非常长的时间 。
针对这个问题 ，Trace系统在链路聚合的基础上提供了一键Mock的功能，将此次服务所涉及的链路调用全部自动配置到接口中 ，过程无需人工干涉 ，将之前需要十分钟的工作降低至五秒内，极大地提高了工作效率 。
针对一些服务的错误场景 ，将错误码转换为实际错误文案 ，友好提示系统用户 。
报表系统是前台用于日常业务的监控系统，它能实时监控异常的业务场景和业务处理结果 。Trace系统联通报表系统 ，在报表系统中可以通过外链跳转至Trace系统 ，并传递异常场景的相关参数 ，如用户标志 ，场景限定等 ，从而获取异常场景的上下文（日志） ，见4.7示图。
4.9 外链其他平台采用了外链的形式进行多平台功能聚合 ，并关联单次查询的搜索数据 ，如时间、用户标志等 ，进行多平台之间的传递 ，从而达到数据串联的效果 。
Trace系统是针对日常开发运维过程中所浮现的一些问题 ，所研发的效能工具系统，它以降低开发运维成本 ，提高日常产能为目标 ，提供了诸多便捷性功能 。系统在上线投入使用后 ，效果显著 ，取得了较大的产出和成果 。
5.1 降低非开发人员的使用门槛 ，提高问题筛查的自助率 ，提升相应效率对数据进行业务含义转换，信息直接明了 ，提升自助率还原用户预订场景 ，精准获取用户反馈信息的同时，提高问题自检力5.2 降低人力成本多业务场景聚合 ，解决多业务模块关联查询的费力度问题提升非开发人员的自助率 ，减少人力成本报文自动解压缩，一键Mock等自动化功能降低人工成本5.3 降低沟通成本 ，提高了日常排障的产能 ，日常问题反馈中多以Trace系统外链进行信息共享5.4 打通报表系统后使得异常场景筛查形成闭环
技术雷达站
