为什么云原生可观测性非常重要？

云原生可观测性 对于云原生软件系统以及软件工程领域都是一个比较新的概念。为什么在传统的单体软件系统中这个概念没有引起大家的注意呢？这主要是由于系统规模、复杂性以及生态化等多个方面的差异造成的。

首先，传统的单体软件系统规模和复杂度没那么高，开发人员可以通过IDE一次性加载全部或部分代码，并使用断点设置、单步调试等方法定位缺陷的根因和位置。云原生软件系统包含大量分布式的服务，难以一次性加载并进行调试，而且大量的服务间跨进程调用也使得单步调试无法进行。

其次，传统的单体软件系统运行环境的复杂性和不确定性没那么高，故障或问题一般都与代码自身或数据相关，较容易在开发环境下重现问题并进行调试。云原生软件系统往往涉及复杂的大规模分布式运行环境而且其中的服务实例可以动态创建和
销毁，因此运行时故障或问题可能与非常复杂的环境因素相关，难以在开发环境中重现。

再次，传统的单体软件系统运行时监控和观测手段较为单一，依赖于代码插桩的动态分析手段开销较大因此在生产环境中使用较少，与此同时软件的模块和组件结构不清晰、隐式交互难以捕捉等问题也限制了可观测性手段的作用。云原生可观测性
软件系统中各个服务实现了物理隔离，服务间通过跨进程通信进行交互，因此服务间边界清晰、服务间交互以一种显式和外化的方式实现。此外，云原生软件系统持续在线运行，同时有着完善的基础设施支持，因此较容易实现分布式链路追踪、指
标和日志监控体系等云原生可观测性手段。

最后，传统的单体软件系统可以以一种自顶向下的方式掌握整体体系结构设计并通过静态分析和演化分析实现架构看护，从而确保软件实现与高层架构设计保持一致。作为一种复杂的生态系统，云原生软件系统的持续演化难以通过一种自顶向下的方式进行掌控，各个局部的应用及相关服务以一种相对独立和自主的方式演化。例如，一些大规模微服务系统中出现长达四五百跳的服务调用链路以及依赖环路，这并不是因为开发人员技术能力和经验不足，而是由于“只见树木、不见森林”的局
部视野带来的问题。此外，各个服务独立开发、部署和运行，因此传统的静态分析和演化分析手段无法有效捕捉到服务之间的依赖和交互关系。

工业界对于云原生可观测性数据的分析和利用能力在不断提高。四年多前，我们针对工业界微服务系统故障分析与调试开展经验研究时发现[3]大部分企业的分析手段还如下图所示那样，停留在基于命令行工具的日志分析、日志事件统计等基本分析层面上，少数企业开始使用Zipkin等工具进行链路轨迹的可视化分析。

当前，很多企业都在深入探索云原生可观测性数据分析方法，其中的一个基本出发点是如何更好地融合指标、日志和链路轨迹三类不同的数据。例如，可以通过在日志中注入Trace ID将链路轨迹与日志关联起来。在分析方法方面，比较常见的一种做法是开发一个融合数据分析平台，通过不同类型数据之间的时空关联以及各种可视化分析手段进行故障分析和根因定位

]]>