云计算

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

br/本文摘自《不一样的 双11 技术：阿里巴巴经济体云原生实践》。点击上图下载！

作者：

周(继承人)？阿里云中间件技术部高级技术专家

王华峰(水法)阿里云中间件技术部技术专家

徐彤(邵宽)阿里云中间件技术部技术专家

夏明(亚海)阿里云中间件技术部技术专家

导读：作为深耕链接追踪技术和性能管理服务(APM)多年的团队，阿里巴巴鹰眼中间件团队的工程师见证了阿里巴巴基础设施的多次升级，每一次升级都会给系统的可观测性带来巨大挑战。这次“云原生”升级给我们带来了哪些新的挑战？

云原生和可观察性

在刚刚过去的2019年双11，我们再次见证了一个技术奇迹：这一次，我们用了整整一年的时间，让阿里巴巴的核心电商业务完全上云，利用阿里云的技术基础设施，承受了每秒54万笔交易的峰值；我们的研发、运维模式也正式进入了云原生时代。

云原生倡导的新范式给传统的R&D和运维模式带来了巨大的冲击：微服务和DevOps的概念让R&D更加高效，但带来了海量微服务的故障排查和故障定位的更多困难；容器化、Kubernetes等容器调度技术的逐渐成熟，使得交付大规模软件变得容易，但挑战在于如何更准确地评估容量和调度资源，并确保成本和稳定性之间的最佳平衡。

阿里巴巴今年探索的无服务器、服务网格等新技术，未来将从用户手中完全接管运维中间件和IaaS层的工作，这对基础设施的自动化是更大的挑战。

基础设施的自动化是云的原始红利得以充分释放的前提，可观测性是所有自动化决策的基石。

如果能够准确统计每个接口的执行效率、成败，能够完整追溯每个用户请求的上下文，能够自动梳理应用之间、应用与底层资源之间的依赖关系，那么我们就可以根据这些信息自动判断业务异常的根本原因。您是否需要迁移、扩展或删除影响业务的底层资源？我们可以根据双11的峰值，自动计算出每个应用所需的准备资源是否充足，没有浪费。

可观察性和监控

很多人会问“可观测性”是不是“监控”。换句话说，这两个东西在业内的定义其实差别很大。

与“监控”不同，监控更注重问题的发现和预警，“可观测性”的最终目的是对复杂分布式系统中发生的事情给出合理的解释。监控更关注软件交付过程和交付后(Day 1 Day 2)，也就是我们常说的“交付期间和交付后”，而“可观测性”则负责R&D的整个生命周期和运维。

回到“可观测性”本身，还是由“跟踪”、“度量”、“日志”等老生常谈组成，单独拉出来都是非常成熟的技术领域。这三样东西是如何与云基础设施集成的呢？它们如何更好地关联和整合？以及他们如何在云时代更好地与线上业务融合？是我们团队这一两年一直在努力探索的方向。

今年我们做了什么？

今年双11，鹰眼团队工程师在四个新方向的技术探索，为集团业务的全面发展、双11的自动备战和整体稳定提供了有力保障：

面向场景的业务可观察性

随着阿里巴巴电商业态的不断复杂化和多样化，大促的准备工作也趋于精细化和场景化。

以前的备战方式是各微服系统负责人根据系统本身和上下游情况各自为战。虽然这种分而治之的方式足够高效，但难免会有疏漏。根本原因在于中台应用与实际业务场景的错位关系。以交易系统为例，一个交易系统会同时承载天猫、盒马、大麦、飞猪等多种类型的业务。而且每个业务的预期呼叫量和下游依赖路径都不一样。作为交易系统的负责人，很难理清每项业务的上下游详细逻辑对自身系统的影响。

今年鹰眼团队推出了场景链接能力，结合业务元数据字典，通过无创自动标记实现流量着色，将实际流量商业化，打通业务和下游中间件的数据，从之前以应用为中心的视图，到以业务场景为中心的视图，因此更接近真实的推广模式。

如上图所示，这是一个查询商品的案例。A、B、C、D四个系统分别提供“商品明细”、“商品类型”、“价格明细”、“优惠明细”的查询能力。门户应用A提供了商品查询的接口S1。通过鹰眼，我们可以很快发现应用B、C、D属于应用A的依赖，也是接口S1的下游。对于系统稳定性的治理，有这样一个环节数据就足够了。

但实际上这个视角并不具备商业的可观测性，因为这样一个依赖结构中有两个商业场景，这两个场景对应的链路是完全不同的：A类商品对应的链路是A-B-C-D，B类商品对应的链路是A-B-C，假设这两种商品的比例在平时是1:1，大规模推广是1:9，那么仅仅从系统或者商业的角度是无法得到合理的流量预测模型的。

所以，如果能通过标记在系统层面染两种流量，就很容易梳理出两种业务场景对应的链接。这样一个更加细化的视角，对于保证业务的稳定性和更加合理的配置依赖梳理和限流降级策略尤为重要。

这种商业场景的能力在今年双11的准备中发挥了很大的作用。很多业务系统都基于这种能力梳理了自己的核心业务环节，准备更加从容，不会有疏漏；同时，一系列服务治理工具，在鹰眼的赋能下，全面场景化升级，如基于场景的流量记录回放、基于场景的故障演练工具、基于场景的精准测试回归等等。有了这些更适合业务场景的服务治理工具，双11备战的可观察粒度进入了“高清时代”。

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

云原生时代，随着微服务等技术的引入，业务规模增大，应用实例增多，对核心业务的依赖越来越复杂。我们一方面享受着开发效率指数级提升的红利，同时也在承受着故障定位的高成本。尤其是出现业务问题时，如何快速发现问题并止血变得非常困难。作为群内应用性能的“守护神”，如何帮助用户快速完成故障定位成为今年的新挑战。

要完成故障定位，首先要回答，你认为是什么故障？这背后需要运维人员对业务的深入了解。许多维护人员喜欢使用穷尽手段来匹配所有可观察的指标。有了各种警报，他们似乎有了“安全感”。事实上，当故障来临时，屏幕上有异常指示灯和不断增加的报警信息。这种“可观察性”看起来很强大，实际效果却适得其反。

团队仔细梳理了集团多年来的败笔。组内核心应用通常有四类故障(非业务逻辑问题):资源、流量、延迟和错误。

进一步细分：

资源类：如cpu、负载、mem、线程数、连接池；

流量类：业务流量降为零或异常涨跌，中间件流量，如消息提供的服务降为零；

延迟类：系统提供的服务或者系统依赖的服务，延迟突然急剧上升，基本是系统出现问题的前兆；

错误类：服务返回的错误总数，以及系统提供服务或依赖服务的成功率。

以上面的故障分类为起点，后面需要做的就是循迹而行。可惜随着业务的复杂，这根“藤蔓”越来越长。以延迟突然增大的故障为例，其背后可能有多种根源：可能是上游业务推广导致的请求数量突然增大造成的，可能是应用本身频繁的GC造成的，可能是下游数据库由于负载过大导致的响应缓慢造成的，还有无数其他原因。

鹰眼之前只提供这些指数信息。维护人员只是看一个单一的调用链数据，鼠标都要滚动几次才能读取一个完整的追溯数据，更不用说在多个系统之间来回切换排查问题了，效率是不可能的。

故障定位的本质是一个不断调查、否定、再调查的过程，是一个“排除一切不可能，留下真相”的过程。仔细考虑可以枚举和可能迭代的流程。这不就是计算机最擅长的处理动作吗？故障测距智能化工程就是在这种背景下诞生的。

提到智能，很多人的第一反应是联想到算法，过度妖魔化。其实懂机器学习的同学应该知道，数据质量排第一，模型排第二，最后才是算法。数据采集和领域模型建模的可靠性和完整性是核心竞争力。只有准确的走了数字化的道路，才能智能化。

智能故障定位的演进路线也是按照上述思路逐步完成的，但在此之前，我们要保证数据的质量：得益于鹰眼团队多年来在大数据处理方面的深耕，数据的可靠性得到了非常高的质量保证，否则我们不得不怀疑这是不是我们自己的指标。

接下来是数据的完备性和诊断模型的建模，这是智能诊断的基石，决定了故障定位的水平。同时，这两部分是相辅相成的。通过诊断模型的构建，可观测性指标可以被检查和填充，通过填充指标可以增加诊断模型的深度。

主要通过以下三个方面的结合来持续改进：

第一，历史断层推演。历史断层相当于一张已知标准答案的试卷。初始诊断模型是通过一些历史故障人工经验构建的，然后对其余的历史故障进行迭代推导。然而，从这一步出来的模型容易过度拟合。

其次，利用混沌工程模拟常见异常，不断修正模型；

第三，采用在线人工标记的方法，继续补充可观测性指标，修正诊断模型。

经过以上三个阶段，这个基石已经基本确立。接下来就是解决效率的问题了。从以上步骤迭代出来的模型其实并不是最高效的，因为人的经验和思维都是线性思维，团队针对现有模型做了两方面的工作：边缘诊断和智能剪枝。定位过程的一部分下沉到各个代理节点，对于一些可能影响系统的现象，自动保存事发地点的关键信息并上报关键事件，诊断系统根据每个事件的权重自动智能调整定位路径。

智能根本原因定位上线后，已帮助数千个应用完成故障根本原因定位，取得了较高的客户满意度。基于根本原因定位的结论，基础设施的自动化能力将大大提高。今年备战双11大促期间，有了这样的快速故障定位功能，为负责应用稳定性的人提供了更加自动化的手段。我们还认为，在云诞生的时代，追求质量、成本和效率的动态平衡

「最后一公里」的问题导向是什么？“最后一公里”问题有什么特点？为什么不是“最后一百米”或者“最后一米”？

首先，我们来对齐一个概念。什么是“最后一公里”？在日常生活中，它有以下特点：

走路有点远，坐车太近。不在身边很难受。

最后一公里的路况非常复杂，可能是宽阔的大道，也可能是崎岖的小路，甚至是迷宫一样的室内旅程(外卖小哥应该最清楚这一点)。

那么分布式问题诊断领域的最后一公里是什么，它有什么特点？

在诊断过程中，此时离根本原因不太远，基本定位到具体的应用、服务或节点，但无法确定具体的异常代码片段；

可以定位根本原因的数据类型有很多，可能是内存占用分析、CPU占用分析、具体的业务日志/错误代码，甚至是单纯从问题的症状出发，结合诊断经验快速确定结论。

通过以上分析，我们现在对最后一公里的概念已经有了一些共识。下面，我们将详细介绍：如何实现最后一公里的问题定位？

首先，我们需要一种方法来准确到达最后一公里的起点，即问题根源所在的应用、服务或机器节点。这样可以避免无效分析的根本原因，就像发货错单一样。那么，如何在纷繁复杂的环节中准确界定根本原因范围呢？这里需要用到APM领域常用的链接追踪能力。通过链接跟踪，我们可以准确识别和分析异常的应用、服务或机器，为我们的最后一公里定位指明方向。

然后，通过关联更详细的链接数据信息，如本地方法堆栈、业务日志、机器状态、SQL参数等。我们可以在最后一公里定位问题，如下图所示：

核心接口埋点：接口执行前后插入埋点记录的基本链路信息，包括TraceId、RpcId(SpanId)、时间、状态、IP、接口名称等。以上信息可以还原最基本的链接形式；

自动关联数据：在调用生命周期中可以自动记录的关联信息，包括SQL、请求访问参数、异常堆栈等。这类信息不影响链接形式，但在某些场景下是准确定位问题的必要条件；

主动关联数据：在呼叫生命周期中需要人们主动记录的关联数据，通常是业务数据，如业务日志、业务标识等。由于业务数据非常个性化，无法统一配置，但主动关联链接数据后，可以大大提高业务问题诊断的效率；

本地方法栈：由于性能和成本的限制，不可能给所有方法都添加链接隐藏点。此时，我们可以通过方法采样或在线插桩的方式实现精确的局部慢方法定位。

通过最后一公里的问题定位，可以在日常和大型准备中彻底排查系统隐患，快速定位根源。下面是两个实际应用案例：

在总流量峰值时，应用程序偶尔会出现RPC调用超时。通过分析自动记录的本地方法栈快照，发现实际时间花费在日志输出语句上，因为LogBack 1.2.x以下版本在高并发同步调用场景下容易出现“热锁”，通过升级版本或者调整为异步日志输出，彻底解决了这个问题。

当用户反馈异常订单时，业务生首先通过用户的UserId检索订单条目的业务日志，然后根据日志中关联的链接标识符TraceId整理下游所依赖的所有业务流程、状态和事件，从而快速定位订单异常的原因(UID不能自动传递给下游所有链接，但TraceId可以)。

监控报警只能反映问题的表象，问题的根源需要深入到源代码中去寻找答案。鹰眼今年在诊断数据的“精细采样”上有了很大的突破，在不通胀控制成本的前提下，大大提高了最后一公里定位所需数据的精细度和含金量。在双11漫长的准备期内，帮助用户消除了一个又一个系统风险源，从而保证了促销日的“丝滑”。

a name='AzFr5'/a

完全接受云原生开源技术

在过去的一年里，鹰眼团队拥抱开源技术，全面整合了业界主流的可观测性技术框架。我们在阿里云上发布了追踪分析的服务，兼容Jaeger(开放追踪)、Zipkin、Skywalking等主流开源追踪框架。我们已经使用了这些框架的程序，不用修改一行代码，就能以比自建低得多的成本，获得比开源跟踪产品强得多的链接数据分析能力。

同时，鹰眼团队还发布了Prometheus service的全托管版本，解决了开源版本部署资源过大、监控节点数量过多时的写性能问题，优化了长范围、多维度查询时的查询速度慢的问题。优化后的Prometheus托管集群全面支持服务Mesh和阿里巴巴多个重量级阿里云客户的监控，我们也向社区反馈了很多优化点。同样，Prometheus的托管版兼容开源版，阿里云的容器服务也可以一键迁移到托管版。

可观性和稳定性是不可分的。今年鹰眼工程师整理了一系列历年来与可观测性和稳定性构建相关的文章和工具，收录在Github上。欢迎大家共同建设。

这本书的亮点

详细描述了超大型K8s集群在双11实践中遇到的问题及解决方案。

云原创生化最佳组合：Kubernetes容器神龙，实现核心系统100% %u4E0A云的技术细节。

双11服务网格超大规模落地解决方案

“阿里云专注于微服务、无服务器、容器、服务网格等技术领域，专注于云原生流行技术趋势、云原生大规模落地实践，是最懂云原生开发者的技术圈。”

更多关于云服务器，域名注册，虚拟主机的问题，请访问西部数码代理官网：www.chenqinet.cn。