可靠性与可观测性

在生产环境中运行的后端系统会持续暴露在不可预测的条件下。与受控环境不同，真实系统必须随时处理流量波动、部分故障和性能下降。这些问题不是例外——它们是系统正常行为的一部分。

可靠性是指系统即使在组件发生故障时，仍能继续正确运行的能力。这包括保持可用性、尽量减少停机时间，以及在发生错误时优雅地恢复。可靠的系统会假设故障一定会发生，并且会针对这种情况进行设计。

可观测性关注的是理解系统内部正在发生什么。当出现问题时，工程师需要能够看到内部状态和行为，以便找出根本原因。如果没有可观测性，故障就只能靠猜测，而不是可以诊断的问题。

在实践中，系统会遵循一个持续循环：发生故障，监控系统检测到异常行为，然后工程师使用可用数据进行排查。这个过程的速度和准确性会直接影响系统稳定性和用户体验。

后端系统中的每个操作都可能生成一条日志记录。例如，当收到请求、用户通过身份验证、执行数据库查询或发生错误时，每一步都可以被记录为日志。这些记录会形成一条按时间顺序排列的事件轨迹，供工程师分析。

日志是最基础的可观测性工具之一。当系统发生故障时，日志通常是工程师首先查看的地方，用来理解哪里出了问题。通过检查日志消息，工程师可以追踪导致故障的一系列操作，并找出根本原因。

常见的日志类型有几种。应用日志记录系统的一般行为，错误日志专注于故障和异常，访问日志记录传入请求，例如 HTTP 流量。结合起来，这些日志可以全面展示系统活动。

如果没有日志，系统就会变得不透明。工程师将无法可靠地重建过去发生的事件，这会让调试和事故响应变得困难得多。

与日志不同，日志会捕获详细的事件级信息，而指标关注的是聚合后的数值数据。常见示例包括每秒请求数、失败请求百分比、响应延迟和 CPU 使用率。这些值提供了系统行为的高层视图。

指标专为持续监控而设计。系统会随着时间收集并存储这些测量值，使工程师能够可视化趋势并识别模式。例如，延迟逐渐增加可能表示性能瓶颈正在加重，而错误率突然飙升可能意味着服务中断。

由于指标轻量且结构化，它们非常适合用于仪表板和告警系统。工程师依赖它们快速评估系统健康状况，而无需深入查看详细日志。

监控是收集、存储和分析这些指标的实践。它为系统性能提供持续洞察，并能够在问题升级为重大故障之前及早发现它们。

现代后端系统很少只是单个应用。相反，它们通常由多个彼此通信的服务组成。一个用户请求可能会先经过 API 服务、认证服务和数据库，然后才返回响应。

分布式追踪会记录整个过程。请求的每一步都会被记录为一个 trace，显示每个服务耗时多久，以及它们之间如何关联。这为查看请求在整个系统中的执行情况提供了完整视图。

Tracing 对于诊断性能问题尤其重要。例如，如果某个请求很慢，Tracing 可以揭示延迟来自 API 层、外部依赖，还是数据库查询。

如果没有 tracing，工程师在复杂系统中只能猜测问题发生在哪里。有了 tracing，他们就可以沿着请求的确切路径追踪，并准确识别瓶颈或故障。

在生产系统中，工程师无法一直手动查看仪表盘。告警通过持续监控指标，并在出现异常时触发通知，从而自动化这一过程。例如，错误率突然飙升、服务宕机，或数据库出现高延迟，都可能触发告警。

告警通常遵循一个简单流程：某个指标超过预定义阈值，系统生成告警，然后通过电子邮件、消息应用或事件管理工具等渠道通知工程师。

有效的告警需要仔细配置。如果阈值过于敏感，工程师会收到太多告警，导致告警疲劳，重要信号反而被忽略。如果阈值过于宽松，关键问题可能会被漏掉。

目标是设计出可执行的告警——告警应该指向需要干预的真实问题。设计良好的告警可以缩短响应时间，并帮助维持系统可靠性。

在分布式系统中，故障通常是短暂的。网络超时、服务暂时过载，或者数据库短暂异常，都可能导致请求失败，即使系统本身仍然可用。系统可以不立即返回错误，而是重试该请求。

重试遵循一个简单的模式：请求失败后，系统等待一小段时间，然后再次尝试该请求。在很多情况下，第二次尝试会成功，因为底层问题已经解决。

常见的重试策略包括在每次尝试之间添加固定延迟，或者使用指数退避，即每次失败后延迟时间都会增加。指数退避通过拉开重试间隔，减少对已经处于压力下的系统的影响。

重试必须谨慎使用。激进的重试行为会在故障期间放大负载，导致连锁问题。设计良好的重试逻辑会在恢复能力和系统稳定性之间取得平衡。

在分布式系统中，一个故障服务可能会引发连锁反应。如果某个服务在已经发生故障时仍持续接收请求，它可能会不堪重负，导致延迟或中断，并扩散到系统的其他部分。

熔断器通过监控失败率来解决这个问题。当失败次数超过阈值时，熔断器会“打开”，传入请求会被阻止，或者被立即拒绝，而不是发送到故障服务。

经过一段冷却时间后，系统可能会允许少量测试请求。如果这些请求成功，熔断器就会关闭，正常流量恢复。如果失败仍然持续，熔断器将保持打开状态。

这种模式可以防止对故障组件施加不必要的负载，并给系统恢复时间，因此它是维护分布式环境稳定性的关键工具。

后端系统必须同时处理来自许多客户端的流量。如果没有限制，单个客户端——或者一组客户端——可能会发送大量请求，导致性能下降或服务中断。

速率限制对请求频率设置边界。例如，系统可能允许每个用户每分钟发送 100 个请求。如果客户端超过这个限制，额外的请求会被拒绝，或者被延迟到下一个时间窗口。

这种机制有多个作用。它可以防止垃圾请求或拒绝服务攻击等滥用行为，保护后端资源不被压垮，并确保不同用户之间的公平使用。

速率限制通常使用令牌桶或漏桶等算法来实现，这些算法会随着时间跟踪并控制请求流量。

现代系统会生成大量遥测数据，包括日志、指标和追踪。可观测性工具会汇总这些数据，并通过仪表板、查询和告警让它们变得可用。

Prometheus 被广泛用于收集和存储时间序列指标，而 Grafana 提供强大的可视化能力，用于构建仪表板。Datadog 提供了一个集成平台，将监控、告警和分布式追踪结合在一起。OpenTelemetry 提供了一个标准化框架，用于跨系统收集遥测数据。

这些工具在一个流水线中协同工作：应用程序生成遥测数据，由监控系统收集和处理，然后在仪表板中可视化，并用于触发告警。

如果没有这些工具，工程师将无法以可扩展的方式理解系统行为。可观测性平台把原始系统数据转化为可操作的洞察，从而实现更快的调试和更可靠的系统。