消息队列和应用工具产品体系（四）

上一节压测告诉你系统的极限在哪。但压测毕竟是模拟场景，真实线上流量到底是什么状态，得靠监控——这一节看阿里云怎么解决"看得见"这个问题，顺带看两个真实落地的案例。

一次请求慢在哪里

微服务里，一次请求可能跨多个服务。分布式链路追踪把各段操作记为 Span，再借助传播的 Trace 上下文关联起来；同一条 Trace 中，Span 有各自的开始时间、结束时间和父子关系。

较长的数据库调用是排查入口，还不能直接断定数据库本身是根因，连接池等待、网络等也可能包含在这段时间内。要串起来看，相关服务必须传播上下文并采集 Span，日志也需记录相应标识；缺少接入或采样未保留的请求，不会凭空出现完整链路。机制可对照 OpenTelemetry 的Trace 说明和日志关联说明。

APM（应用性能管理）关注应用性能与问题诊断。排查时常结合三类信号：

• Metrics（指标）：QPS、错误率、响应时间等数字度量，用来观察整体变化
• Logs（日志）：具体事件、异常和业务上下文
• Traces（链路追踪）：一次请求中的操作路径、耗时与关联关系

ARMS 与 SLS 各看什么

ARMS（Application Real-Time Monitoring Service，应用实时监控服务）面向应用可观测性，课程介绍的核心功能模块有：

• 应用监控：无需修改代码，通过探针无侵入采集接口耗时、调用链路、异常堆栈这些应用性能数据
• 链路追踪：前面说的 TraceID / Span 机制在这里落地，把一次请求跨服务的完整路径可视化出来
• 前端监控（RUM，Real User Monitoring）：站在真实用户浏览器的角度看体验——页面加载速度、首屏时间、白屏时间、JS 报错、接口请求成功率
• Prometheus 监控：面向云原生场景，原生兼容开源 Prometheus 的指标协议，适合 Kubernetes 环境下的容器、Pod 级别监控

日志采集和分析方面，阿里云还有一个独立产品 SLS（日志服务），提供大规模日志的采集、查询、分析和可视化。ARMS 侧重应用性能指标和链路追踪，SLS 侧重日志的统一存储和检索，两者配合能覆盖更完整的可观测性场景。

这些数据还可以用于容量评估，或把技术指标与订单量、支付成功率等业务指标放在一起看，判断问题影响了哪些业务。

课程里的两个案例

申通快递：改造旧架构

申通快递原来的架构基于 VMware 虚拟化和 Oracle 数据库，很多业务逻辑写在 Oracle 的存储过程和触发器里，系统之间靠数据库同步工具（OGG）传递数据——典型的传统架构。

全面上云后，申通把架构迁移到基于 Kubernetes 的云原生体系（ACK + 神龙服务器 + 云数据库），做了两层改造：容器化改造先解决了开发、测试、生产环境不一致的老问题；微服务改造则引入 Kubernetes 的服务发现机制，把原来揉在一起的业务按业务域拆分成独立服务。改造后申通能支撑千万级日订单量、亿级物流轨迹数据处理，用超过 1300 个计算节点实时处理业务，也是快递行业里第一个全面上云的企业。这个案例说明：云原生不只是电商大促的专利，物流这类有明显波峰波谷、且历史包袱较重的传统行业，同样能通过容器化 + 微服务化解决弹性和维护性问题。

完美日记：应对大促

完美日记作为高速增长的美妆电商，面临的痛点很典型：开发迭代快导致线上问题多、频繁大促对系统稳定性压力很大、缺乏常态化的压测和容量评估机制、大促所需资源和日常资源差距悬殊导致要频繁手动扩缩容。

解决方案就是这一章讲过的产品组合：ACK 做容器化部署、Spring Cloud Alibaba 做微服务框架、PTS 做常态化压测、AHAS 做限流降级、链路追踪产品排查分布式问题。改造之后，2020 年 4 月完美日记三周年大促的系统吞吐量，相比半年前提升了 50 倍。这个案例基本是这一整章讲的产品体系（容器 + 微服务 + 压测 + 稳定性中间件 + 监控）在一个真实大促场景里的完整闭环。

课程提出的后续方向

官方课程收尾时对云原生下一步走向的判断，大方向可以概括为几点：云原生和 AI 基础设施的结合会更紧密（比如 AI 训练推理负载本身也需要弹性调度）、Serverless 化会覆盖更多场景而不只是边缘任务、资源利用率的持续优化本身也在呼应绿色低碳的诉求。这部分更多是方向性判断，不是需要死记的具体考点。

回头看第 5 章的四篇：消息队列负责解耦削峰，AHAS 负责主动防御和故障演练，PTS 负责提前摸清极限，ARMS 和 SLS 负责线上实时看清系统状态。这些能力还需要接入日常的开发、发布与反馈流程，第 6 章看 DevOps。