茶百道全链路可观测实战

作者：山猎

茶百道是四川成都的本土茶饮连锁品牌，创立于 2008 年 。经过 15 年的发展，茶百道已成为餐饮标杆品牌，全国门店超 7000 家，遍布全国 31 个省市，实现中国大陆所有省份及各线级城市的全覆盖。2021 年 3 月 31 日，在成渝餐·饮峰会中，茶百道斩获“2021 成渝餐·饮标杆品牌奖”。2021 年 8 月，入选艾媒金榜（iiMedia Ranking）最新发布《2021 年上半年中国新式茶饮品牌排行 Top15》。2023 年 6 月 9 日，新茶饮品牌“茶百道”获得新一轮融资，由兰馨亚洲领投，多家知名投资机构跟投，估值飙升至 180 亿元。

今年 4 月，茶百道在成都总部举行了品牌升级发布会，宣布门店数突破 7000 家。根据中国连锁经营协会的数据，截至 2020 年、2021 年以及 2022 年 12 月 31 日，茶百道门店数量分别为 2,240 间、5,070 间以及 6,532 间，疫情并没有拖慢其扩张步伐。

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

云原生化的业务价值

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

采用容器和微服务技术实现了应用的轻量化和高可移植性。让企业可以更灵活地部署、扩展应用，快速响应市场需求，使得企业能够实现应用的高可用性和弹性扩展能力，无论面对突发的高峰访问量还是系统故障，都能保持业务的稳定运行。

引入了持续交付和持续集成的开发方式，帮助企业实现了快速迭代和部署。通过自动化的流程，企业能够更快地推出新功能和产品，与市场保持同步，抢占先机。

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

云原生带来的可观测挑战

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

完善的全链路可观测平台以及 APM  ( Application Performance Management )工具，是保障业务连续性与可用性的前提。在可观测技术体系建设上，茶百道技术团队经历过比较多探索。全面实现容器化之前，茶百道在部分微服务系统上接入了开源 APM 工具，并进行超过一年时间的验证，但最终没有能够推广到整个微服务架构中，主要有这几个方面的原因：

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

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

• 缺少高阶告警能力

  开源工具在告警方面实现比较简单，用户需要自行分别搭建告警处理及告警分派平台，才能实现告警信息发送到 IM 群等基本功能。由于茶百道微服务化后的服务模块众多、依赖复杂。经常因为某个组件的异常或不可用导致整条链路产生大量冗余告警，形成告警风暴。造成的结果就是运维团队疲于应付五花八门且数量庞大的告警信息，非常容易遗漏真正用于故障排查的重要消息。

• 故障排查手段单一

  开源 APM 工具主要基于 Trace 链路信息帮助用户实现故障定位，对于简单的微服务系统性能问题，用户能够快速找到性能瓶颈点或故障源。但实际生产环境中的很多疑难杂症，根本没有办法通过简单的链路分析去解决，比如 N+1 问题，内存 OOM，CPU 占用率过高，线程池打满等。这样就对技术团队提出了极高要求，团队需要深入了解底层技术细节，并具备丰富 SRE 经验的工程师，才能快速准确的定位故障根源。

接入阿里云应用实时监控服务 ARMS

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

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

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

围绕 ARMS 告警平台构建应急响应体系

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

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

这些告警领域的关键技术，在 ARMS 告警平台上都有完整功能。以事件压缩举例，ARMS 提供基于标签压缩和基于时间压缩两种压缩方式。满足条件的多条事件会被自动压缩成为一条告警进行通知（如下图所示）。

图: 基于标签压缩

图：基于时间压缩

配合 ARMS 告警平台所提供的多种技术手段，可以非常有效的解决告警风暴的问题，因此茶百道技术团队开始重视告警的使用，逐步丰富更多的告警规则，覆盖应用接口、主机指标、JVM 参数、数据库访问等不同层面。

通过企业微信群进行对接，使告警通知实现 ISTM 流程的互动，当值班人员收到告警通知后，可以直接通过 IM 工具进行告警关闭、事件升级等能力，快速实现告警处理。（如下图所示）

图：监控告警事件的智能化收敛与通告

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

引入采样策略

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

图：ARMS 端侧预聚合能力

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

图：接口级别指标数据

异步链路自动埋点*

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

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

ARMS 对主流的异步框架都实现了支持，无需任何业务代码上的侵入就能够异步链路上下文透传，即使对一些异步框架的特定版本没有及时支持，只要用户侧提出需求，ARMS 团队就能在新版本的探针中补齐。使用 ARMS 应用监控之后，茶百道技术团队直接将此前异步框架手工埋点代码进行了清理，大幅度减少维护工作量。

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

更高阶应用诊断技术的运用

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

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

ARMS 应用监控提供了 CPU & 内存诊断能力，可以有效发现 Java 程序中因为 CPU、内存和 I/O 导致的瓶颈问题，并按照方法名称、类名称、行号进行细分统计，最终协助开发者优化程序、降低延迟、增加吞吐、节约成本。CPU & 内存诊断可以在需要排查特定问题时临时开启，并通过火焰图帮助用户直接找到问题根源。在一次生产环境某应用 CPU 飙升场景中，茶百道的工程师通过 CPU & 内存诊断一步定位到问题是由一个特定业务算法所导致。

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

此外，对于线上的业务问题，还可以通过 ARMS 提供的 Arthas 诊断能力在线排查。Arthas 作为诊断 Java 领域线上问题诊断利器，利用字节码增强技术，可以在不重启 JVM 进程的情况下，查看程序运行情况。

虽然 Arthas 使用有一定门槛，需要投入比较多精力进行学习，但茶百道的工程师非常喜欢使用这个工具。针对“到底符合哪种特殊的数据导致某业务异常”此类问题，没有比 Arthas 更方便的排查工具了。

阶段性成果

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

在可观测产品本身的使用成本上，虽然表面上 ARMS 相比开源产品有所提高，但这是建立在开源方案数据单写，以及存在单点故障的情况下。其实茶百道的技术团队也非常清楚，之前的开源方案是存在高可用性隐患的，某个组件的故障会导致整个可观测方案不可用。只是大家对于开源方案提供的可观测能力并没有重度使用，所以才没有足够重视。所以综合来看，ARMS 整体成本并不会高于开源方案。

利用 ARMS 能力，茶百道实现了可观测指标采样率百分百覆盖，链路全采集，监控数据准确率大幅提供，能够快速实现业务故障的自动发现，有效的配合敏态业务发展。

故障发生后，监控系统需要第一时间通知相关人员，做初步定位，ARMS 告警告警能力实现了 ChatOps 能力，基于 IM 工具，快速触达相关人员，并且提供初步定位能力，是故障的响应能力大幅提升。

故障的快速恢复，对于控制业务影响至关重要，ARMS 利用全链路 Trace 能力，快速定位具体应用、接口、方法、慢sql等，是故障快速恢复的关键助手。茶百道技术团队负责人表示： “在与开源方案成本持平的前提下，ARMS 丰富且全面的全栈观测与告警能力，使茶百道快速建立运维观测与响应能力，故障恢复效率提升 50% 以上，故障恢复耗时缩短 50%，真正做到用可观测为业务迅猛发展保驾护航。”

故障的预防收敛，在稳定性体系建设中是投入产出比极高的，PTS 利用全国流量施压的能力，和秒级监控能力，验证站点容量并定位性能瓶颈。茶百道在业务上线前，充分对单应用和全链路做压测，累计压测 800 余次，在上线前做到了性能问题的收敛，避免演进为线上故障。

下阶段目标

在可观测领域，Prometheus + Grafana 是指标数据存储、计算、查询、展示的事实标准，ARMS 产品家族提供托管加强的 Prometheus 和 Grafana 服务。ARMS 应用监控生成的指标数据也会自动保存到托管版 Prometheus 中，并预置数张 Grafana 大盘。茶百道的工程师们正在基于 Prometheus 和 Grafana，将应用层指标、关键业务指标、云服务指标进行结合，开发多维度可观测大盘。

在不久的将来，茶百道就会建立覆盖业务层、用户体验层、应用服务层、基础设置层、云服务层的统一可观测技术体系，为千万级用户同时在线的大规模微服务系统实现稳定性保障。