作者｜Devin，携程高级后端开发工程师，专注于Java相关领域和自动化相关研究；Hank，携程高级后端开发工程师，专注于java和.net技术领域研究1.前言随着微服务架构的普及，这些微服务构成了一个复杂的分布式网络，在支撑我们海量查询的同时也带来了一些问题。前台订机票的主要流程服务有几个系统。每个系统部署多个服务，每个服务依赖多个API。用户通过终端设备（手机、PC等）预订机票，“系统异常”如何分析排查？运维人员将问题抛给开发/测试人员定位。开发人员/测试人员只知道有异常。如何高效地从复杂的调用链中查找原因，将给开发/测试人员带来极大的挑战。开发/测试人员借助单点日志逐一排查的效率很低，尤其是一些UI层“有待确认”的问题。只检查一些日志消息是非常低效的。如何提高开发/测试人员的排错效率，同时降低非开发人员的使用门槛？答案可能是携程机票前台的Trace系统。2.Trace系统的发展历程2.1从原始日志来看，Dev&Ops工单前台的日志记录比较完整。我们把系统中的服务和上下游依赖的服务的日志都写好了。一些Kibana面板是根据业务属性制作的，结合一些解压工具可以满足日常需求。在微服务架构中，随着业务的不断增加，复杂度也会随之增加，这给开发/测试和运维人员的效率带来了极大的挑战。主要问题体现在：不同微服务、多个日志主题和多个查询面板，需要手动聚合/拼接不同微服务的日志，用用户行为还原不同团队的服务。日志压缩方式不同，解压方式不同。面向开发的服务名称可读性低。内部系统互不连通，相互操作需要人工处理。2.2基础设施经过长期的实践和探索，售票前台的日志系统和自动化设施已经比较完备。日志系统主要包括以下三种票务前台日志。这三类日志可以满足日常开发和运维的基本需求，实现全流程的精准把控。UBT日志主要记录用户的一些行为日志，方便解决用户反馈问题。Mertics日志主要记录一些业务指标，作为内部后续业务需求演进的依据。Trace日志记录了业务处理过程中产生的信息日志，如接口消息、错误消息等。自动化的设施大大降低了日常运维开发的成本。Mock平台：可以通过Mock平台自定义数据源（接口、DB等），从而控制和分析程序的逻辑走向。接口自动化平台：结合Mock平台实现服务接口的自动化测试2.3基于Chrome插件版的Trace工具票务前台通过日志和自动化构建来保证日常开发维护的基本流程，解决一些重复的问题通过Chrome插件执行任务。例如：格式化解压后的日志信息，快速复制解压后的信息。插件模式解决了一些重复性的工作，一定程度上提高了效率。2.4遇到的问题随着业务的不断扩展，微服务越来越多。作为BFF层（BackendsForFrontends服务于前端后端），我们需要聚合多个接口方提供的微服务，使得BFF层的调用关系越来越复杂。现有的“插件模式”已经难以满足日常工作。“插件式Trace系统”遇到了以下问题：如何通过日志清晰展示调用关系，如何查询“过期日志”（超出ES的有效期）微服务越来越多，如何通过搜索条件快速检索到目标微服务，如何实现高保真如何与其他系统（如Mock系统、用户行为系统等）对接，提高偏技术的“晦涩”信息的可读性3.系统设计针对以上问题，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系统采用外链的形式，将单个query的搜索数据，如时间、用户logo等，进行聚合关联，并在多个平台之间传递，从而达到这样的效果的数据串联。采用外部链接而不是在系统内集成多平台内容的主要原因是系统的定位是跟踪链接。如果耦合过多的数据，系统将变得复杂，并对系统用户造成过多干扰。4.4多业务场景聚合，过期日志补偿系统一次搜索聚合多个业务线，如主流程预订、低价订阅、增值产品等，无需用户手动区分搜索渠道。而对于Clickhouse过期（ClickHouse日志只保存半个月）的数据，通过Hive查询进行数据补偿。解决用户在ClieckHouse和Hive之间切换的问题。4.5基于CRN_Web技术的页面播放功能的结合日志系统和自动化设施除了两者的分离，还有一个问题就是双方都是技术驱动，对于非开发者来说，使用门槛高。比如运维人员在复现用户反馈的问题时，需要开发者介入准备日志数据和环境Mock准备，才能复现用户反馈的问题。用户反馈的问题大部分是UI展示层面的问题。如果按照上述流程进行，故障排除的成本会比较高。因此Trace系统在链接跟踪和自动mocking的基础上提供了用户页面回放功能。系统会收集与用户访问页面相关的所有服务请求的日志，模拟日志消息，然后使用CRNWeb技术真正发起页面访问。此时服务会返回相应的Mock消息，达到页面播放的效果。让运维人员更直观的了解用户反映的问题。通过BatchId关联一次页面访问中的同一批服务，系统自动拉取消息并进行Mock，然后将Mock结果与当前用户logo关联起来，通过CRNWeb实现页面播放，高保真还原看到的界面。4.6一键Mock功能在日常工作中，日志系统和自动化设施处于分离状态，主要体现在日志和Mock系统的结合使用上。在之前的使用过程中，我们需要在Kibana中查找链接日志，然后在Mock系统中配置接口调用的数据包。这样的操作既费时又费力。有的服务调用接口多达20、30个，手工配置这些数据会耗费很长时间。为了解决这个问题，Trace系统在链路聚合的基础上提供了一键式Mock功能，自动将本次服务涉及的所有链路调用配置到接口中，过程中无需人工干预，耗时十分钟before缩短到五秒，大大提高工作效率。4.7关键信息暴露针对部分服务的错误场景，将错误码转化为实际的错误文本，友好提示系统用户。4.8联通报表系统报表系统是前台用于日常业务的监控系统，可以实时监控异常业务场景和业务处理结果。Trace系统连接到报告系统。在报表系统中，可以通过外部链接跳转到Trace系统，并传递异常场景的相关参数，如用户标识、场景限制等，从而获取异常场景的上下文（日志），见图4.7。4.9外链其他平台通过外链的形式聚合多平台功能，将时间、用户标识等单个查询的搜索数据关联起来，在多个平台之间传递，从而达到数据串联的效果。五、总结Trace系统是为了解决日常开发和维护过程中出现的一些问题而开发的一个效率工具系统。它旨在降低开发和维护成本并提高日常生产能力，并提供许多方便的功能。系统上线并投入使用后，效果显着，取得了较大的产出和效果。5.1降低非开发人员的使用门槛，提高问题排查的自助率，提高相应的效率，转化数据的业务意义。检力5.2降低人力成本多业务场景聚合，解决多业务模块关联查询费力问题提高非开发人员自助率，降低人力成本消息自动解压，一键Mock等自动化功能，降低人力成本5.3减少沟通成本提高了日常故障排除的生产率，在日常的问题反馈中，多使用Trace系统的外部链接进行信息共享。5.4开通举报系统后，异常场景排查形成闭环
