1、后端1可视化全链路日志追踪1设计模式二三事26基于代价的慢查询优化建议49Java 系列|远程热部署在美团的落地实践71日志导致线程 Block 的这些坑，你不得不防92基于 AI 算法的数据库异常监测系统的设计与实现154Replication（上）：常见复制模型&分布式系统挑战171Replication（下）：事务，一致性与共识197TensorFlow 在美团外卖推荐场景的 GPU 训练优化实践234CompletableFuture 原理与实践-外卖商家端 API 的异步化258工程效能 CI/CD 之流水线引擎的建设实践291美团外卖搜索基于 Elasticsearch 的优化实践

2、312美团图灵机器学习平台性能起飞的秘密（一）332提升资源利用率与保障服务质量，鱼与熊掌不可兼得？350标准化思想及组装式架构在后端 BFF 中的实践371外卖广告大规模深度学习模型工程实践|美团外卖广告工程实践专题连载392数据库全量 SQL 分析与审计系统性能优化之旅427目录数据库异常智能分析与诊断438美团外卖广告智能算力的探索与实践（二）458Linux 下跨语言调用 C+实践480GPU 在外卖场景精排模型预估中的应用实践509美团集群调度系统的云原生实践528广告平台化的探索与实践|美团外卖广告工程实践专题连载540可视化全链路日志追踪作者：海友怀宇亚平立森1.背景1.1业务系

3、统日益复杂随着互联网产品的快速发展，不断变化的商业环境和用户诉求带来了纷繁复杂的业务需求。业务系统需要支撑的业务场景越来越广、涵盖的业务逻辑越来越多，系统的复杂度也跟着快速提升。与此同时，由于微服务架构的演进，业务逻辑的实现往往需要依赖多个服务间的共同协作。总而言之，业务系统的日益复杂已经成为一种常态。1.2业务追踪面临挑战业务系统往往面临着多样的日常客诉和突发问题，“业务追踪”就成为了关键的应对手段。业务追踪可以看做一次业务执行的现场还原过程，通过执行中的各种记录还原出原始现场，可用于业务逻辑执行情况的分析和问题的定位，是整个系统建设中重要的一环。目前在分布式场景下，业务追踪的主流实现方式包

4、括两类，一类是基于日志的 ELK方案，一类是基于单次请求调用的会话跟踪方案。然而随着业务逻辑的日益复杂，上述方案越来越不适用于当下的业务系统。1.2.1传统的 ELK 方案日志作为业务系统的必备能力，职责就是记录程序运行期间发生的离散事件，并且在后端22022年美团技术年货事后阶段用于程序的行为分析，比如曾经调用过什么方法、操作过哪些数据等等。在分布式系统中，ELK 技术栈已经成为日志收集和分析的通用解决方案。如下图 1 所示，伴随着业务逻辑的执行，业务日志会被打印，统一收集并存储至 Elasticsearch（下称 ES）2。图 1业务系统 ELK 案例传统的 ELK 方案需要开发者在编写代

5、码时尽可能全地打印日志，再通过关键字段从ES 中搜集筛选出与业务逻辑相关的日志数据，进而拼凑出业务执行的现场信息。然而该方案存在如下的痛点：日志搜集繁琐：虽然 ES 提供了日志检索的能力，但是日志数据往往是缺乏结构性的文本段，很难快速完整地搜集到全部相关的日志。日志筛选困难：不同业务场景、业务逻辑之间存在重叠，重叠逻辑打印的业务日志可能相互干扰，难以从中筛选出正确的关联日志。日志分析耗时：搜集到的日志只是一条条离散的数据，只能阅读代码，再结合逻辑，由人工对日志进行串联分析，尽可能地还原出现场。综上所述，随着业务逻辑和系统复杂度的攀升，传统的 ELK 方案在日志搜集、日志筛选和日志分析方面愈加的

6、耗时耗力，很难快速实现对业务的追踪。后端2022年美团技术年货力，待审对象的审核需要经过“初审”和“复审”两个环节（两个环节关联相同的taskId），因此整个审核环节的执行调用了两次审核接口。如图左侧所示，完整的审核场景涉及众多“业务逻辑”的执行，而分布式会话跟踪只是根据两次 RPC 调用生成了右侧的两条调用链路，并没有办法准确地描述审核场景业务逻辑的执行，问题主要体现在以下几个方面：图 3分布式会话跟踪案例(1)无法同时追踪多条调用链路分布式会话跟踪仅支持单个请求的调用追踪，当业务场景包含了多个调用时，将生成多条调用链路；由于调用链路通过 traceId 串联，不同链路之间相互独立，因此给完