作者|MoonlightLiketheSea指南随着对用户体验的不断追求，时延分析已经成为大型分布式系统不可或缺的一部分。本文介绍了在线业务中常用的延迟分析方法，重点介绍了关键路径分析的原理和技术实现方案。实践表明，该方案效果显着，对耗时优化起到了重要作用。希望这些内容能够对感兴趣的读者有所启发和帮助。全文4528字，预计阅读时间12分钟。01背景近年来，互联网服务的响应延迟（latency）对用户体验的影响越来越大。但是，目前还没有很好的方法来分析服务接口的时延。特别是互联网业务迭代速度快，功能更新周期短，必须在最短时间内定位延迟瓶颈。但是服务器一般由分布式系统组成，内部存在着复杂的调度和并发调用关系。传统的时延分析方法效率低下，难以满足当前互联网业务的时延分析需求。关键路径分析（CriticalPathTracing）作为近年兴起的延迟分析方法，受到Google、Meta、Uber等公司的青睐，并广泛应用于在线服务中。作为拥有数亿用户的大规模分布式服务，百度应用推荐服务也成功应用了关键路径时延分析平台，在优化产品时延、保障用户体验方面发挥了重要作用。本文介绍了在线业务常用的延迟分析方法，并详细介绍了关键路径分析的技术实现和平台化方案。最后结合实际案例，阐述了如何在百度应用推荐服务中获得实际的商业利益。02常用的分布式系统延迟分析方法目前业界常用的服务延迟分析有RPC遥测（RPCtelemetry）、CPU剖析（CPUProfiling）、分布式追踪（DistributedTracing）。下面是具体的系统结构示例：△图1系统结构示例A、B、C、D、E分别为五个系统服务，A1～A4、B1～B5分别为A、B系统中的子组件（这可以理解为系统A和B中的更多细节）。组件），箭头标识服务或组件之间的调用关系。2.1RPC监控RPC是目前微服务系统间常用的一种调用方式。业界主要的开源RPC框架有BRPC、GRPC、Thrift。这些RPC框架通常集成了统计打印功能。打印出来的信息包含了具体的名字和对应的耗时信息，这些信息会被外部监控系统（比如Prometheus）采集并显示在仪表盘上。△图2RPC耗时监控UI实例这种分析方法比较简单直接。如果服务之间的调用关系比较简单，这种方法比较有效。如果系统比较复杂，基于RPC分析结果的优化往往没有预期的效果。如图1所示，A调用B，A2和A3是并行调用，A3在内部进行复杂的CPU计算任务。如果A2的耗时比A3高，那么分析A->B的RPC延迟是有意义的。如果A3高于A2的话，减少A->B的服务调用时间对整体耗时没有影响。另外，RPC分析无法检测系统内部的子组件，对整体延迟的分析有很大的局限性。2.2CPUProfilingCPU分析是收集和聚合函数调用栈的样本，频繁出现的函数被认为是主要的延迟路径。下图为CPU火焰图的展示效果：△图3cpu火焰图横向宽度表示样本数，纵向表示调用关系。火焰图通常取决于顶层的哪个函数具有最大宽度。“平顶”表示该函数存在性能问题。CPUProfiling可以解决上述RPC监控的不足。但是，由于仍然无法知道并行A2和A3中哪一个花费的时间最多，因此根据RPC链接分析结果或CPU分析结果进行优化会变得更有效。不确定，最好的方法是将它们全部优化，但这在大型复杂系统中将变得非常昂贵。可见CPUProfiling也有一定的局限性。2.3DistributedTracingDistributedTracing在各大公司都有很好的实践（比如Google的Dapper，Uber的Jaeger）。△图4DistributedTracing效果示例DistributedTracing会将要跟踪的“节点”标记为span，将span以特定的方式构建成trace。效果如图4所示，从左到右在时间轴上展示了不同节点的耗时情况，相同的起点意味着并发执行。这就需要收集所有的跨服务请求信息，包括调用的具体时间点和父子关系，从而对外还原系统调用的拓扑关系，包括每个服务工作的开始和结束时间，以及服务是并行运行还是串行运行。跑步。通常大部分分布式trace默认包含RPC访问，没有服务内部子组件信息，需要开发者根据自己系统的结构来完成。然而，有时系统中运行的组件数量过多，甚至达到数百或数千，这使得成本成为分布式跟踪详细延迟分析的主要障碍。为了在成本和数据量之间做出权衡，细粒度的追踪组件往往被放弃，这使得分析人员需要花费额外的精力来进一步分析延迟的真正“消耗点”。下面介绍关键路径分析的基本原理和实际应用。03关键路径分析3.1简介关键路径在服务内部被定义为耗时最长的路径。如果将以上子组件抽象成不同的节点，则关键路径由一组节点组成，这些节点是分布式系统中最慢的有序请求集合。一个系统中可能有成百上千个子组件，但关键路径可能只有几十个节点，这种数量级的减少可以大大降低成本。我们在上图的基础上添加了各个子模块的耗时信息。△图5带有耗时信息的示例系统结构如图5所示，在B中，B1并行调用B3、B4、B5，延时分别为100、150、120，然后调用内部的B2进行返回。关键路径为B1->B4->B2，时延为10+150+10=170，A中A1并行调用A2、A3。A2和A3都完成后调用A4，然后返回。关键路径为A1->A2->A4，延迟为15+170+10=195。因此，本系统的关键路径为红线的路径A1->A2->B1->B4->B2->A4。关键路径通过这个简单的分布式系统结构来表达，它描述了分布式系统中用于请求处理的最慢步骤的有序列表。可以看出，优化关键路径上的节点肯定可以达到降低整体时间消耗的目的。实际系统中的关键路径远比上述描述复杂。下面将进一步介绍关键路径分析的技术实现和平台解决方案。3.2实际应用方案从关键路径数据采集到可视化分析的过程如图所示：△图6数据处理流程3.2.1核心关键路径的输出和上报关键路径由业务自身产生，一般情况下大规模分布式所有服务采用基于算子的执行框架。只要将它们集成到框架中，所有依赖的服务都可以统一生成关键路径。对于基于算子的执行框架，考虑如下简单图结构：△图7一个简单的图结构P1-P4是4个策略算子，按图调度执行。采集SDK采集各算子的起止运行时间，汇总为关键路径基础数据上报。3.2.2核心关键路径的聚合计算一个服务内部的关键路径往往不能反映整个分布式系统延迟的正常情况，这就需要对不同服务的内部键进行聚合。这里的聚合是基于时间段的。这就需要采集器在收到数据后，根据上传结转的时间点，将数据划分到相应的时间窗口中。收集完成后，计算各种延迟指标和聚合关键路径。这里有三种聚合方式：1.节点关键路径聚合这里将系统的关键路径拼接在一起形成一条完整的路径，对每个节点进行聚合，选取出现次数最多的路径作为“最”核心”关键路径。2.服务关键路径聚合节点关键路径是节点粒度的表征，但是一个系统中服务的路径关系是怎样的呢？这就需要一个服务关键路径来表示。为了更好的表示服务内部的耗时情况，对节点进行了聚合和抽象。将所有的计算节点统一成一个叫做inner的节点，作为起始节点，其他访问外部服务的节点保持不变，在重新转换的路径中选择出现次数最多的路径作为服务关键路径，聚合路径的latency可以识别“自我”和“外部”服务的分布。3.Tiled节点类型聚合这部分主要是针对核心路径分散的子节点，比如B中的B1访问B3/B4/B5等多个下游（实际系统中可能会出现几十个节点）关键路径，但没有节点有绝对的核心占比，各节点在关键路径中相对分散，且经常周期性变化），直接统计筛选出核心占比>x%的情况（x%是根据a具体x越小，收集到的关键节点越细），需要注意的是这是一个平铺的节点，不是“核心”关键路径。3.2.3核心关键路径的存储与展示数据库存储计算结果，以时间、用户类型、流量来源等为查询关键词，方便多维度分析。这里使用OLAPEngine进行存储，方便数据分析和查询。显示的内容主要包括以下几个部分：核心比例：节点出现在关键路径的概率比例与核心贡献相乘即为综合测度的标准平均值：节点耗时的平均分位数：节点耗时的不同分位数值。分位数是统计学中的一个概念，就是把所有的值从小到大排序，取前N%位置的值作为分位数的值。常用的有50th、80th、90th等，核心占比高贡献低或贡献高贡献低的节点优化效果往往不是很明显。因此综合贡献作为核心比例和核心贡献的综合考虑。索引高的节点是我们需要关注的，也是优化收益最大的节点。从耗时优化的角度来看，这里主要有两个诉求。一是查询某段时间的关键路径，从而指导特定节点或阶段的优化。另外就是比较关键路径，找到diff的节点，挖掘出具体的优化原因。整体延迟的恶化通常是由特定节点的恶化引起的。这里的对比可以是不同时间、不同区域，甚至是不同交通分量的对比，为延误分析提供了多维度的指导依据。关键路径的效果如图8所示，可以在页面上根据具体维度进行排序，进一步筛选。△图8核心关键路径示例04百度App推荐系统应用内部搭建了关键路径延迟分析平台Focus，上线一年多，成功支撑了日常的耗时分析和优化工作，保证了推荐的准确性百度AppFeed流推荐界面毫秒级响应速度，为用户提供流畅的反馈体验。获得了研发、运维和算法团队的一致好评。以推荐服务的一个实际在线问题为例。某日，监控系统发现系统出口耗时超过了监控阈值。关键路径时延分析平台通过服务关键路径自动定位到某个服务B的问题，然后观察服务B节点的关键路径发现节点X有问题，但是节点的下游请求X是多个下游。这时通过节点类型拉平，发现平时耗时比较低的队列Y突然出现了延迟增加，核心占比和贡献都异常高，下游负责通知所有者找到它。发现是服务本身异常。整个定位过程完全自动化，无需人工检查每个模块。△图9系统延迟异常后的自动定位分析流程05总结在目前的大型分布式系统中，服务接口的低响应延迟是保证用户体验的重要关键。各大公司也都投入了大量精力对时延进行优化，但系统结构复杂，优化难度大，需要采用创新的优化方法。本文通过具体实例介绍了关键路径分析的原理，在百度App推荐系统中实际应用的平台化解决方案，最后分享了实际案例。延迟耗时分析方向还有很多新的发展方向和创新空间，欢迎对此方向感兴趣的业内同仁一起探讨。——END——推荐阅读：百度工程师教你玩转设计模式（装饰模式）百度工程师带你体验引擎中的nodejs揭秘百度智能测试在测试定位领域的秘密百度工程师带你探秘C++内存管理的秘密（ptmalloc篇））为什么OpenCV计算的视频FPS不对百度安卓直播秒开体验优化
