茶百道全链路可观测实战

随着业务规模的急速扩展，茶百道全面加速推进数字化转型战略。但由于茶百道部分早期业务系统由外部 SaaS 服务商提供，无法满足线上业务高速增长所带来的大规模、高并发、弹性扩展、敏捷性、可观测等要求。为了满足线上线下门店客户需求与业务增长需要，针对店务、POS、用户交易、平台对接、门店管理、餐饮制作等核心链路服务，茶百道选择全面自研与阿里云云原生能力相结合，推动容器化、微服务化、可观测能力全面升级。

茶饮行业面临着市场竞争的压力和内部运营效率的提升需求。为了应对这些挑战，阿里云与茶百道一起完成云原生上云的转型，开启数字化的新征程。

云原生的上云转型不仅带来了更高的安全性、可用性和可伸缩性，也提升了企业的创新能力和竞争力。

茶百道作为业务高速发展的新兴餐饮品牌，每天都有海量的在线订单，这背后是与互联网技术的紧密结合，借助极高的数字化建设支撑茶百道庞大的销售量。因此，对于业务系统的连续性与可用性有着非常严苛的要求，以确保交易链路核心服务的稳定运行。特别是在每日高峰订餐时段、营销活动、突发热点事件期间，为了让用户有顺畅的使用体验，整个微服务系统的每个环节都需要保证在高并发大流量下的服务质量。

• 指标数据准确度与采样率之间的平衡难以取舍

  适当的采样策略是解决链路追踪工具成本与性能的重要手段，如果 APM 工具固定使用 100% 链路全采集，会带来大量重复链路信息被保存。在茶百道的庞大微服务系统规模下，100% 链路采集会造成可观测平台存储成本超出预期，而且在业务高峰期还会对微服务应用本身的性能带来一定影响。但开源工具在设定采样策略的情况下，又会影响指标数据准确度，使错误率、P99 响应时间等重要可观测指标失去观测与告警价值。

• 缺少高阶告警能力
  开源工具在告警方面实现比较简单，用户需要自行分别搭建告警处理及告警分派平台，才能实现告警信息发送到 IM 群等基本功能。由于茶百道微服务化后的服务模块众多、依赖复杂。经常因为某个组件的异常或不可用导致整条链路产生大量冗余告警，形成告警风暴。造成的结果就是运维团队疲于应付五花八门且数量庞大的告警信息，非常容易遗漏真正用于故障排查的重要消息。
• 故障排查手段单一
  开源 APM 工具主要基于 Trace 链路信息帮助用户实现故障定位，对于简单的微服务系统性能问题，用户能够快速找到性能瓶颈点或故障源。但实际生产环境中的很多疑难杂症，根本没有办法通过简单的链路分析去解决，比如 N+1 问题，内存 OOM，CPU 占用率过高，线程池打满等。这样就对技术团队提出了极高要求，团队需要深入了解底层技术细节，并具备丰富 SRE 经验的工程师，才能快速准确的定位故障根源。

在茶百道系统架构全面云原生化的过程中，茶百道技术团队与阿里云的工程师深入探讨了全链路可观测更好的落地方式。

ARMS 应用监控作为阿里云云原生可观测产品家族的重要成员，提供线程剖析、智能洞察、CPU & 内存诊断、告警集成等开源 APM 产品不具备的能力。在阿里云的建议下，茶百道技术团队尝试着将一个业务模块接入 ARMS 应用监控。

由于 ARMS 提供了容器服务 ACK 环境下的应用自动接入，只需要对每个应用的 YAML 文件增加 2 行代码就自动注入探针，完成整个接入流程。经过一段时间试用，ARMS 应用监控提供的实战价值被茶百道的工程师不断挖掘出来。茶百道同时使用了阿里云性能测试产品 PTS，来实现日常态和大促态的容量规划。因为ARMS和 PTS 的引入，茶百道日常运维与稳定性保障体系也发生了众多升级。

由于之前基于开源产品搭建告警平台时，经常遇到告警风暴的问题，茶百道对于告警规则的配置是非常谨慎的，尽可能将告警目标收敛到最严重的业务故障上，这样虽然可以避免告警风暴对 SRE 团队的频繁骚扰，但也会让很多有价值的信息被忽略，比如接口响应时间的突增等。

其实对于告警风暴问题，业界是有一整套标准解法的，其中涉及到去重、压缩、降噪、静默等关键技术，只是这些技术与可观测产品集成上存在一定复杂度，很多开源产品并没有在这个领域提供完善方案。

灵活开放的告警事件处置策略满足了不同时效、场景的需求。茶百道在此基础上参考阿里巴巴安全生产最佳实践，开始构建企业级应急响应体系。将业务视角的应急场景作为事件应急处置的核心模型，通过不同告警级别，识别与流转对应的故障处理过程。这些都是茶百道在全面云原生化后摸索出的经验，并显著提升生产环境服务质量。

从链路信息中提取指标数据，是所有 APM 工具的必备功能。不同于开源产品简单粗暴的指标提取方式，ARMS 应用监控使用端侧预聚合能力，捕捉每一次真实请求，先聚合，后采样，再上报，提供精准的指标监控。确保在采样策略开启的情况下，指标数据依然与真实情况保持一致。

为了降低 APM 工具带来的应用性能损耗，茶百道对大部分应用采取 10% 采样率，对于 TPS 非常高的应用则采取自适应采样策略，进一步降低高峰期应用性能损耗。通过实测，在业务高峰期，ARMS 应用监控造成的应用性能损耗比开源产品低 30% 以上且指标数据准确性可信赖，比如接口级别的平均响应时间、错误数等指标都可以满足生产级业务需求。

在 Java 领域存在异步线程池技术，以及众多开源异步框架，比如 RxJava、Reactor Netty、Vert.x 等。相较于同步链路，异步链路的自动埋点与上下文透传的技术难度更大。开源产品对主流异步框架的覆盖度不全，在特定场景下存在埋点失败问题，一旦出现这样的问题，APM 工具最重要的链路分析能力就难以发挥作用。

在这种情况下，需要开发者自行通过 SDK 手工埋点，以保证异步链路的上下文透传。这就会造成巨大的工作量且难以在团队内部大面积、快速推广。

图：异步调用的链路上下文

在埋点覆盖度足够高的情况下，传统 APM 工具和链路跟踪工具能够帮助用户快速确定链路的哪一个环节（也就是Span）存在性能瓶颈，但需要更进一步排查问题根源时，就无法提供更有效的帮助了。

举一个例子，当系统 CPU 占用率显著提升时，是否因某个业务方法疯狂的消耗 CPU 资源所导致？这个问题对于大多数的 APM 产品而言，都是难以办法解决的。因为单从链路视图无法知晓每个环节的资源消耗情况。茶百道的工程师在使用开源工具时，曾多次遇到类似问题，当时只能凭借经验去猜测，再去测试环境反复对比来彻底解决，虽然也试过一些 Profiling 工具，但使用门槛比较高，效果不是很好。

图：通过火焰图分析 CPU 时间

经过 2 个月时间的调研与对比，茶百道决定全面从开源可观测平台转向 ARMS，从开源压测平台转向 PTS，并在团队内部进行推广。随着使用的不断深入，ARMS 所提供的智能洞察、线程池分析等高阶可观测能力也逐步被茶百道的技术团队应用于日常运维中，线上问题排查效率相比之前也有了数倍提升。