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

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

云原生与可观测性

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

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

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

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

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

可观测性≠监控

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

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

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

我们今年做了什么

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

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

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

以往的备战方式，是各个微服务系统的负责人根据所负责系统的自身以及上下游情况，各自为战。这样分而治之的做法虽然足够高效，却难免有疏漏，根本原因在于中台应用与实际业务场景的错位关系。以交易系统为例，一个交易系统会同时承载天猫、盒马、大麦、飞猪等多种类型的业务，而每种业务的