双11 背后的全链路可观测性：阿里巴巴鹰眼在“云原生时代”的全面升级

点击下载《不同的 双11 技术：阿里巴巴经济体云原生实践》

本文节选自《不同的 双11 技术：阿里巴巴经济体云原生实践》一书，点击上方图片便可下载！

做者：
周小帆（承嗣）  阿里云中间件技术部高级技术专家
王华锋（水彧）  阿里云中间件技术部技术专家
徐彤（绍宽）  阿里云中间件技术部技术专家
夏明（涯海）  阿里云中间件技术部技术专家

导读：做为一支深耕多年链路追踪技术 (Tracing) 与性能管理服务 (APM) 的团队，阿里巴巴中间件鹰眼团队的工程师们见证了阿里巴巴基础架构的屡次升级，每一次的架构升级都会对系统可观测性能力 (Observability) 带来巨大挑战，而此次的“云原生”升级，给咱们带来的新挑战又是什么呢？

云原生与可观测性

在刚刚过去的 2019 年 双11，咱们再次见证了一个技术奇迹：这一次，咱们花了一全年的时间，让阿里巴巴的核心电商业务全面上云，而且利用阿里云的技术基础设施顶住了 54 万笔/秒的零点交易峰值；咱们的研发、运维模式，也正式步入了云原生时代。

云原生所倡导的新范式，给传统的研发和运维模式带来巨大冲击：微服务、DevOps 等理念让研发变得更高效，但带来的倒是海量微服务的问题排查、故障定位的难度变得更大；容器化、Kubernetes 等容器编排技术的逐渐成熟让规模化软件交付变得容易，但带来的挑战是如何更精准地评估容量、调度资源，确保成本与稳定性的最好平衡。

今年阿里巴巴所探索的 Serverless、Service Mesh 等新技术，将来将完全地从用户手中接管运维中间件以及 IaaS 层的工做，对于基础设施的自动化程度来说则是一个更加巨大的挑战。

基础设施的自动化（Automation）是云原生的红利可以被充分释放的前提，而可观测性是一切自动化决策的基石。

若是每一个接口的执行效率、成败与否都能被精准统计、每个用户请求的前因后果都能被完整追溯、应用之间以及应用与底层资源的依赖关系能被自动梳理，那咱们就能基于这些信息自动判断业务的异常根因在哪？是否须要对影响业务的底层资源作迁移、扩容或是摘除？咱们就能根据 双11 的峰值，自动推算出每个应用所需准备资源是否充分且不浪费。

可观测性≠监控

许多人会问，“可观测性”是否就是“监控”换了一个说法，业界对这两件事的定义其实截然不同。

不一样于“监控”，监控更加注重问题的发现与预警，而“可观测性”的终极目标是为一个复杂分布式系统所发生的一切给出合理解释。监控更注重软件交付过程当中以及交付后（Day 1 & Day 2)，也就是咱们常说的“事中与过后”，而“可观测性”则要为全研发与运维的生命周期负责。

回到“可观测性”自己，依旧是由老生常谈的“链路(Tracing)”、“指标(Metric)”和“日志(Logging)”构成，单独拉出来看都是很是成熟的技术领域。只不过这三样东西与云基础设施如何整合？它们之间如何更好地关联、融合在一块儿？以及它们如何更好地和云时代的在线业务作结合？是咱们团队这一两年来努力探索的方向。

咱们今年作了什么

今年的 双11，鹰眼团队的工程师们在四个新方向的技术探索，为集团业务全面上云、双11 的自动化备战与全局稳定性提供了强有力的保障：

面向场景化的业务可观测性

随着阿里巴巴电商业态不断的复杂与多元化，大促备战也不断趋向于精细化与场景化。

以往的备战方式，是各个微服务系统的负责人根据所负责系统的自身以及上下游状况，各自为战。这样分而治之的作法虽然足够高效，却不免有疏漏，根本缘由在于中台应用与实际业务场景的错位关系。以交易系统为例，一个交易系统会同时承载天猫、盒马、大麦、飞猪等多种类型的业务，而每种业务的预期调用量、下游依赖路径等均不相同，做为交易系统的负责人，很难梳理清楚每种业务的上下游细节逻辑对自身系统的影响。

今年鹰眼团队推出了一种场景化链路的能力，结合业务元数据字典，经过无侵入自动打标的手段实现流量染色，将实际的流量业务化，打通了业务与下游各中间件的数据，从以往以应用为中心的视图，转变成了以业务场景为中心，也所以更加贴近于真实的大促模型。

如上图所示，这是一个查询商品的案例，四个系统 A、B、C、D 分别提供“商品详情”、“商品类型”、“价格详情”和“优惠详情”的查询能力。入口应用 A 提供了一个商品查询的接口 S1，经过鹰眼，咱们能够很快地发现应用 B、C、D 属于应用 A 的依赖，同时也是接口 S1 的下游，对于系统稳定性的治理而言，有这样一份链路数据已经足够。

但其实这样的视角并不具有业务的可观测性，由于在这样的一个依赖结构中包含着两种业务场景，这两种场景所对应的链路也是彻底不一样的：甲类商品所对应的链路是 A->B->C-D，而乙类商品对应的链路是A->B->C。假设平常态这两类商品的占比是 1:1，而大促态的占比是 1:9，那么仅从系统的角度或者业务的角度去梳理链路，是没法获得一个合理的流量预估模型的。

因此，若是咱们能在系统层经过打标的方式把两种流量染色，就能很方便地梳理出两种业务场景所对应的的链路，这样一份更加精细化的视角对于保证业务的稳定性、以及更加合理的依赖梳理和限流降级策略的配置显得尤其重要。

这样的业务场景化能力在今年的 双11 备战中发挥了巨大的价值，不少业务系统都基于这样的能力梳理出了本身核心的业务链路，备战更加从容且不会有遗漏；同时，一系列的服务治理工具，在鹰眼的赋能下，进行了全面的场景化升级，例如针对场景化的流量录制和回放、场景化的故障演练工具、场景化的精准测试回归等等。配合这些更加贴合业务场景的服务治理工具，帮助整个 双11 备战的可观测性颗粒度走进了“高清时代”。

基于可观测性数据的智能根因定位

云原生时代，随着微服务等技术的引入，业务规模的增加，应用的实例数规模不断增加，核心业务的依赖也变得越发复杂。一方面咱们享受着开发效率的指数提高的红利，同时也在承受着故障定位成本居高不下的痛苦。特别是当业务出现问题的时候，如何快速发现问题和止血变得很是困难。鹰眼团队做为集团内应用性能的“守护神”，如何帮助用户快速完成故障定位成为今年的新挑战。

要完成故障定位，首先要回答，什么是你认为的故障？这背后须要运维人员对业务深层次的理解，不少维护人员喜欢使用穷举式的手段配上全部可观测性的指标，各类告警加上，显得有“安全感”，实际上当故障来临时，满屏出现指标异常、不断增长的告警短信，这样的“可观测性”看上去功能强大，实际效果却拔苗助长。

团队对集团内的历年故障作了一次仔细梳理，集团内的核心应用一般有四类故障(非业务自身逻辑问题)：资源类、流量类、时延类、错误类。

再往下细分：

1. 资源类:  好比 cpu、load、mem、线程数、链接池；
2. 流量类：业务流量跌零 OR 不正常大幅度上涨下跌，中间件流量如消息提供的服务跌零等；
3. 时延类：系统提供的服务 OR 系统依赖的服务，时延忽然大幅度飙高了，基本都是系统有问题的前兆；
4. 错误类：服务返回的错误的总数量，系统提供服务 OR 依赖服务的成功率。

有了上面这些故障分类做为抓手后，后面要作的就是“顺藤摸瓜”，惋惜随着业务的复杂性，这根“藤”也来越长，以时延突增这个故障为例，其背后就隐藏着不少可能的根因：有多是上游业务促销致使请求量突增致使，有多是应用自身频繁 GC 致使应用总体变慢，还有多是下游数据库负载过大致使响应变慢，以及数不胜数的其它各类缘由。

鹰眼之前仅仅提供了这些指标信息，维护人员光看单条调用链数据，鼠标就要滚上好几番才能看完一条完整的 tracing 数据，更别说跨多个系统之间来回切换排查问题，效率也就无从谈起。

故障定位的本质就是一个不断排查、否认、再排查的过程，是一个“排除掉全部的不可能，剩下的就是真相”的过程。仔细想一想可枚举的可能+可循环迭代的过程，这个不就是计算机最擅长的处理动做吗？故障定位智能化项目在这样的背景下诞生了。

提起智能化，不少人第一反应是把算法关联在一块儿，把算法过分妖魔化。其实了解机器学习的同窗应该都知道：数据质量排第一，模型排第二，最后才是算法。数据采集的可靠性、完整性与领域模型建模才是核心竞争力，只有把数据化这条路走准确后，才有可能走智能化。

故障定位智能化的演进路线也是按照上面的思路来逐步完成的，但在这以前咱们先得保障数据的质量：得益于鹰眼团队在大数据处理上深耕多年，数据的可靠性已经能获得很是高质量的保障，不然出现故障还得先怀疑是否是本身指标的问题。

接下来就是数据的完备性和诊断模型的建模，这两部分是智能化诊断的基石，决定了故障定位的层级，同时这两部分也是相辅相成的，经过诊断模型的构建能够对可观测性指标查漏补缺，经过补齐指标也能够增长诊断模型的深度。

主要经过如下 3 方面结合来不断地完善：

• 第一，历史故障推演，历史故障至关于已经知道标准答案的考卷，经过部分历史故障+人工经验来构建最初的诊断模型，而后迭代推演其他的历史故障，可是这一步出来的模型容易出现过拟合现象；
• 第二，利用混沌工程模拟常见的异常，不断修正模型；
• 第三，线上人为打标的方式，来继续补齐可观测性指标、修正诊断模型。

通过以上三个阶段以后，这块基石基本创建完成了。接下来就要解决效率问题，从上面几步迭代出来的模型其实并非最高效的，由于人的经验和思惟是线性思惟，团队内部针对现有模型作了两方面的工做：边缘诊断和智能剪枝。将定位的过程部分下沉到各个代理节点，对于一些可能对系统形成影响的现象自动保存事发现场关键信息同时上报关键事件，诊断系统自动根据各个事件权重进行定位路径智能调整。

智能根因定位上线后，累计帮助数千个应用完成故障根因定位，并取得了很高的客户满意度，基于根因定位结论为抓手，可观测性为基石，基础设施的自动化能力会获得大大提高。今年的 双11 大促备战期间，有了这样的快速故障定位功能，为应用稳定性负责人提供了更加自动化的手段。咱们也相信在云原生时代，企业应用追求的运行的质量、成本、效率动态平衡再也不是高不可攀，将来可期！

最后一千米问题定位能力

什么是“最后一千米”的问题定位？“最后一千米”的问题有哪些特色？为何不是“最后一百米”、“最后一米”？

首先，咱们来对齐一个概念，什么是“最后一千米”？在平常生活中，它具有如下特色：

• 走路有点远，坐车又太近，不近不远的距离很难受；
• 最后一千米的路况很是复杂，多是宽阔大道，也多是崎岖小路，甚至是宛如迷宫的室内路程（这点外卖小哥应该体会最深）。

那么分布式问题诊断领域的最后一千米又是指什么呢，它又具有哪些特征？

• 在诊断流程上，此时已经离根因不会太远，基本是定位到了具体的应用、服务或节点，可是又没法肯定具体的异常代码片断；
• 可以定位根因的数据类型比较丰富，多是内存占用分析，也多是 CPU 占用分析，还多是特定的业务日志/错误码，甚至只是单纯的从问题表象，结合诊断经验快速肯定结论。

经过上面的分析，咱们如今已经对最后一千米的概念有了一些共识。下面，咱们就来详细介绍：如何实现最后一千米的问题定位？

首先，咱们须要一种方法，能够准确的到达最后一千米的起点，也就是问题根因所在的应用、服务或是机器节点。这样能够避免根源上的无效分析，就像送外卖接错了订单。那么，如何在错综复杂的链路中，准确的定界根因范围？这里，咱们须要使用 APM 领域较为经常使用的链路追踪（Tracing）的能力。经过链路追踪可以准确的识别、分析异常的应用、服务或机器，为咱们最后一千米的定位指明方向。

而后，咱们经过在链路数据上关联更多的细节信息，例如本地方法栈、业务日志、机器状态、SQL 参数等，从而实现最后一千米的问题定位，以下图所示：

• 核心接口埋点： 经过在接口执行先后插桩埋点，记录的基础链路信息，包括 TraceId、RpcId（SpanId）、时间、状态、IP、接口名称等。上述信息能够还原最基础的链路形态；
• 自动关联数据： 在调用生命周期内，能够自动记录的关联信息，包括 SQL、请求出入参数、异常堆栈等。此类信息不影响链路形态，但倒是某些场景下，精准定位问题的必要条件；
• 主动关联数据： 在调用生命周期内，须要人为主动记录的关联数据，一般是业务数据，好比业务日志、业务标识等。因为业务数据是很是个性化的，没法统一配置，但与链路数据主动关联后，能够大幅提高业务问题诊断效率；
• 本地方法栈： 因为性能与成本限制，没法对全部方法添加链路埋点。此时，咱们能够经过方法采样或在线插桩等手段实现精准的本地慢方法定位。

经过最后一千米的问题定位，可以在平常和大促备战态深度排查系统隐患，快速定位根因，下面举两个实际的应用案例：

• 某应用在总体流量峰值时出现偶发性的 RPC 调用超时，经过分析自动记录的本地方法栈快照，发现实际耗时都是消耗在日志输出语句上，缘由是 LogBack 1.2.x 如下的版本在高并发同步调用场景容易出现“热锁”，经过升级版本或调整为异步日志输出就完全解决了该问题；
• 某用户反馈订单异常，业务同窗首先经过该用户的 UserId 检索出下单入口的业务日志，而后根据该日志中关联的链路标识 TraceId 将下游依赖的全部业务流程、状态与事件按实际调用顺序进行排列，快速定位了订单异常的缘由（UID 没法自动透传到下游全部链路，但 TraceId 能够）。

监控告警每每只能反映问题的表象，最终问题的根因还须要深刻到源码中去寻找答案。鹰眼今年在诊断数据的“精细采样”上取得了比较大的突破，在控制成本不膨胀的前提下，大幅提高了最后一千米定位所需数据的精细度与含金量。在整个双11 漫长的备战期中，帮助用户排除了一个又一个的系统风险源头，从而保障了大促当天的“丝般顺滑”。

全面拥抱云原生开源技术

过去一年，鹰眼团队拥抱开源技术，对业界主流的可观测性技术框架作了全面集成。咱们在阿里云上发布了链路追踪（Tracing Analysis）服务，兼容 Jaeger(OpenTracing)、Zipkin、Skywalking 等主流的开源 Tracing 框架，已经使用了这些框架的程序，能够不用修改一行代码，只须要修改数据上报地址的配置文件，就可以以比开源自建低出许多的成本得到比开源 Tracing 产品强大许多的链路数据分析能力。

鹰眼团队同时也发布了全托管版的 Prometheus 服务，解决了开源版本部署资源占用过大、监控节点数过多时的写入性能问题，对于长范围、多维度查询时查询速度过慢的问题也作了优化。优化后的 Prometheus 托管集群在阿里巴巴内全面支持了 Service Mesh 的监控以及几个重量级的阿里云客户，咱们也将许多优化点反哺回了社区。一样，托管版的 Prometheus 兼容开源版本，在阿里云的容器服务上也能够作到一键迁移到托管版。

可观测性与稳定性密不可分，鹰眼的工程师们今年将这些年来可观测性、稳定性建设等相关一系列的文章、工具作了整理，收录在了 Github 上，欢迎你们一块儿来进行共建。

本书亮点

• 双11 超大规模 K8s 集群实践中，遇到的问题及解决方法详述
• 云原生化最佳组合：Kubernetes+容器+神龙，实现核心系统 100% 上云的技术细节
• 双 11 Service Mesh 超大规模落地解决方案

“ 阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的技术圈。”