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

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

APM 为什么要进化：从看单机日志到分布式链路追踪

单体应用时代，排查问题很直接：登上那台机器，查日志、看 CPU/内存指标，基本就能定位。

但微服务架构下，一次请求可能跨十几个服务，第 1 章提过"登录一台机器看日志"已经行不通了，需要能跨服务追踪一次请求完整路径的手段，也就是分布式链路追踪。实现思路是：每个请求进来时生成一个全局唯一的 TraceID，这个 ID 随着请求跨服务传递，每经过一跳就记录一段 Span（跨度），最后能把所有 Span 拼接成一张完整的调用链路图，清楚看到请求在哪一跳耗时最久、在哪一跳出的错。

这套能力统称 APM（应用性能管理），业界公认可观测性建立在三大支柱之上：

Metrics（指标）：数字化的度量数据，比如 QPS、错误率、响应时间
Logs（日志）：记录系统运行过程中发生了什么的文本记录
Traces（链路追踪）：一次请求跨服务的完整路径

ARMS：把这三块能力做成一个产品

ARMS（应用实时监控服务）是阿里云覆盖 Metrics、Logs、Traces 这三大支柱的一站式可观测产品，核心功能模块：

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

四个模块对应同一个问题在不同层面的答案：应用内部发生了什么（应用监控）、请求跨服务怎么流转（链路追踪）、用户实际体验如何（前端监控）、容器和基础设施是否健康（Prometheus 监控）。

日志采集和分析方面，阿里云还有一个独立产品 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。