可观测架构（Observability Architecture）

系统架构设计师 · 第14章 云原生架构设计理论与实践 · 主要架构模式
📚 教材第14.2.3节 ⭐ 重点考点 🎯 云原生七大架构模式之一

📑 目录

  1. 可观测架构概述
  2. 三大支柱：Logging / Tracing / Metrics
  3. 开源框架与规范要求
  4. SLO 与 SLA：度量目标
  5. 可观测原则（架构设计原则）
  6. 在云原生架构中的位置
  7. 考试要点速记 & 自测题

一、可观测架构概述

可观测架构（Observability Architecture） 是云原生七大主要架构模式之一, 它包括 Logging（日志）、Tracing（链路追踪）、Metrics（度量） 三个方面, 通过这三大支柱使分布式系统中的服务调用、性能、状态对运维、开发和业务人员实时可见。

为什么需要可观测架构？

大部分企业的软件规模都在不断增长。原来单机可以对应用做完所有调试,但在分布式环境下需要对多个主机上的信息做关联,才可能回答清楚以下问题：

可观测性与传统的 监控、业务探活、APM 等系统提供的能力不同。 前者是在云这样的分布式系统中,主动通过日志、链路跟踪和度量等手段, 使得一次点击背后的多次服务调用的耗时、返回值和参数都清晰可见, 甚至可以下钻到每次三方软件调用、SQL 请求、节点拓扑、网络响应等。

可观测架构能带来什么？

二、三大支柱:Logging / Tracing / Metrics

可观测架构包括 Logging、Tracing、Metrics 三个方面—— 这是最高频的考点,必须熟记三者的区别与各自的特点。

Logging（日志）

提供多个级别的详细信息跟踪

级别（5级）:

  • verbose 详细
  • debug 调试
  • warning 警告
  • error 错误
  • fatal 致命

特点: 由应用开发者主动提供

Tracing（链路追踪）

提供一个请求从前端到后端的完整调用链路跟踪

核心价值:

  • 对分布式场景尤其有用
  • 使用 spanid/traceid 关联
  • 支持分布式链路分析

Metrics(度量)

提供对系统量化的多维度度量

典型度量维度:

  • 并发度
  • 耗时
  • 可用时长
  • 容量

三者对比一览表

维度 Logging(日志) Tracing(链路追踪) Metrics(度量)
主要作用 详细信息记录 完整调用链路跟踪 量化的多维度度量
数据形式 多级别文本信息 请求链路的 span/trace 数值化指标
提供方式 应用开发者主动提供 框架埋点 + 上下文传播 系统采集 + 聚合
典型场景 异常排查、故障定位 分布式调用分析、性能瓶颈 SLO 度量、容量规划
分布式适用性 一般 尤其有用 必备

三、开源框架与规范要求

架构决策者的三项关键工作

架构决策者在落地可观测架构时,需要做以下三件事:

序号 工作内容 关键细节
1 选择合适的、支持可观测的开源框架 例如 Open Tracing、Open Telemetry
2 规范上下文的可观测数据规范 例如方法名、用户信息、地理位置、请求参数等
3 规划数据传播路径 规划这些可观测数据在哪些服务和技术组件中传播
利用日志和 Tracing 信息中的 spanid/traceid, 确保进行分布式链路分析时有足够的信息进行快速关联分析。

常见开源框架

四、SLO 与 SLA:度量的最终目标

建立可观测性的主要目标是对服务 SLO(Service Level Objective) 进行度量, 从而优化 SLA(Service Level Agreement)。

核心概念

缩写 全称 中文 含义
SLO Service Level Objective 服务等级目标 组件内部定义的服务质量目标（架构师定义）
SLA Service Level Agreement 服务等级协议 与用户签订的服务质量协议（对外承诺）
架构设计上需要为各个组件定义清晰的 SLO,包括但不限于:
定义 SLO → 可观测性度量 → 优化 SLA

五、可观测原则(云原生架构设计原则之一)

在云原生架构的七大设计原则中,可观测原则是第3条(教材14.2.2)。 这一原则与"可观测架构"模式相互呼应,共同构成了云原生体系下对系统透明度的要求。

云原生架构的七大设计原则

序号 原则 核心含义
1服务化原则以接口契约定义业务关系
2弹性原则系统部署规模可随业务量变化自动调整
3可观测原则 ⭐通过日志、链路跟踪、度量主动感知系统状态
4韧性原则抵御软硬件异常,提升 MTBF
5所有过程自动化原则IaC、GitOps、OAM、Kubernetes Operator 等
6零信任原则以身份为中心进行访问控制
7架构持续演进原则架构需具备持续演进能力

可观测原则的关键论述

可观测原则的关键能力:

易混淆考点:"可观测性"与传统监控、业务探活、APM 系统提供的能力不同!
区别在于:可观测性是分布式系统中的主动感知能力,而传统监控更多是被动检测。

六、在云原生架构中的位置

云原生架构的七大主要架构模式

可观测架构是云原生七大主要架构模式中的第 6 项:

序号 架构模式 核心思想
1服务化架构模式微服务、小服务模式
2Mesh 化架构模式中间件框架从业务进程中分离
3Serverless 模式把应用运行委托给云
4存储计算分离模式解决分布式 CAP 困难
5分布式事务模式XA / BASE / TCC / SAGA / SEATA AT
6可观测架构 ⭐Logging + Tracing + Metrics
7事件驱动架构(EDA)事件具有 schema,带 QoS 保障

典型云原生架构反模式(对比理解)

以下是教材中明确列出的典型云原生架构反模式,与"可观测架构"等正确模式形成对比:
  1. 庞大的单体应用—— 缺乏依赖隔离
  2. 单体应用"硬拆"为微服务—— 过分服务化拆分
  3. 缺乏自动化能力的微服务—— 接口增多导致维护成本飙升

七、考试要点速记 & 自测题

🔑 必背知识点

  1. 可观测架构 = Logging + Tracing + Metrics(三大支柱)
  2. Logging:5个级别(verbose / debug / warning / error / fatal),由应用开发者主动提供
  3. Tracing:请求从前端到后端的完整调用链路,对分布式场景尤其有用
  4. Metrics:对系统量化的多维度度量
  5. 常用开源框架:Open Tracing、Open Telemetry
  6. 关键标识符:spanid / traceid(用于分布式链路关联分析)
  7. 主要目标:度量 SLO,优化 SLA
  8. SLO 要包含:并发度、耗时、可用时长、容量
  9. 云原生架构七大设计原则:服务化、弹性、可观测、韧性、所有过程自动化、零信任、架构持续演进
  10. 云原生架构七大主要模式:服务化、Mesh化、Serverless、存储计算分离、分布式事务、可观测、事件驱动

💡 自测题

题目 1:可观测架构包括以下哪三个方面?

点击查看答案
答案:Logging(日志)、Tracing(链路追踪)、Metrics(度量)。
说明:这是三大支柱,缺一不可。

题目 2:Logging 提供哪几个级别的详细信息跟踪?

点击查看答案
答案:5 个级别——verbose、debug、warning、error、fatal。
说明:由应用开发者主动提供。

题目 3:Tracing 中用于分布式链路分析的关键标识符是什么?

点击查看答案
答案:spanid 和 traceid。
说明:利用日志和 tracing 信息中的 spanid/traceid,可以在分布式链路分析时进行快速关联分析。

题目 4:建立可观测性的主要目标是什么?

点击查看答案
答案:对服务 SLO(Service Level Objective,服务等级目标)进行度量,从而优化 SLA(Service Level Agreement,服务等级协议)。
说明:SLO 应包括并发度、耗时、可用时长、容量等指标。

题目 5:架构决策者在选择支持可观测的开源框架时,通常会考虑哪些?

点击查看答案
答案:Open Tracing、Open Telemetry 等。
说明:同时还需要规范上下文的可观测数据规范(方法名、用户信息、地理位置、请求参数等),并规划这些可观测数据在哪些服务和技术组件中传播。

题目 6:可观测性与传统的监控、业务探活、APM 系统的本质区别是什么?

点击查看答案
答案:可观测性是在云这样的分布式系统中,主动通过日志、链路跟踪和度量等手段,使得一次点击背后的多次服务调用的耗时、返回值和参数都清晰可见,甚至可以下钻到每次三方软件调用、SQL 请求、节点拓扑、网络响应等。
关键词:分布式、主动、下钻、关联分析。

📋 一句话记忆法

"三柱(Logging/Tracing/Metrics)护 SLO,Open框架配 traceid,云原生中度可观,优化 SLA 不掉队。"
📘 内容整理自 《系统架构设计师教程(第2版)》第14章 云原生架构设计理论与实践
可观测架构 · 第14.2.3节"主要架构模式"第6点 & 第14.2.2节"主要设计原则"第3点