轻松构建全栈观测,从容应对咖啡产业竞争

简介: 轻松构建全栈观测,从容应对咖啡产业竞争

1964 年,Tim Hortons 咖啡馆诞生于多伦多的宁静小镇汉密尔顿,由传奇冰球运动员 Tim Horton 先生创立。经过近 60 年的发展,Tim Hortons 已成为全球著名咖啡连锁品牌。在英国权威品牌评估机构 Brand Finance 发布的“全球最有价值的 25 个餐厅品牌”排行榜中,Tim Hortons 连续多年入围。


2019 年,Tim Hortons 来到中国上海开出首家门店,并于 2023 年宣布使用中文名“天好咖啡”。秉承着创始人的初心“欢迎任何人随时来到 Tims 咖啡馆,享受家一般的感觉”,Tims 天好咖啡坚持为顾客提供独特的价值:将新鲜、高质量的本地化食品和饮品相结合,以适宜的价格为顾客提供暖心的体验。


截至 2023 年 7 月,Tims 天好中国全国门店数达到 700+ 家,已经覆盖了 40+ 个城市, 并计划在年底前突破 1000 家门店。凭借“咖啡+暖食”的差异化竞争策略,Tims 天好咖啡将全球品牌力与本土创新加速融合,逐渐走通了一条独有的可持续增长路径。


为了进一步强化 Tims 天好咖啡差异化并支持中国市场的快速增长,自 2021 年起 Tims 天好咖啡全面加速推进数智战略。但由于 Tims 天好咖啡部分早期业务系统由外部服务商提供且架构老旧难以维护,无法满足 Tims 天好咖啡线上业务高速增长所带来的高并发、弹性扩展、敏捷性等要求。为了满足中国越发蓬勃的用户需求与业务增长需要,针对用户交易、门店管理、餐饮制作等核心链路服务,Tims 天好咖啡选择全面自研与云原生化,即全面容器化、微服务化。


01 云原生化带来的技术红利


2021 年,Tims 天好咖啡开始落地容器化,这为 Tims 天好咖啡带来了诸多运维红利。首先,应用部署变得更加高效,借助 K8s 的标准化能力使 CI/CD 变得便捷,整体发布效率大幅提升。其次,部署在容器上的应用天然具备弹性扩缩容能力,更加从容的应对每日餐食时段的流量洪峰。最后,采用容器化的服务按需使用资源,相比原先按照峰值长期固定保有大量冗余资源,有效压降服务器成本。相比过往繁琐的运维流程与人员技能门槛,阿里云容器服务 ACK 的标准化界面很好的解决了容器的高密部署以及系统运维问题,极大的降低了人工运维和资源成本。


为了更好的满足快速迭代、稳定发布诉求,2022 年 Tims 天好咖啡对已有业务系统开始尝试微服务化,采用了以 Dubbo 为核心的微服务技术架构。微服务架构将应用分解的同时,规避了原本复杂度无止境的积累。每个微服务模块专注于单一功能,保持高可维护性并提高了开发效率。与此同时,由于微服务具备独立运行进程,每个微服务模块都可以独立部署。当某个微服务发生变更时,无需编译、部署整个应用。使得发布更加高效,缩短应用交付周期。


02 云原生带来的可观测挑战


但随着容器化、微服务化逐渐深入,云原生化带来的运维挑战与痛点驱动 Tims 天好咖啡运维团队构建更加精细与完整的运维可观测能力:


1. 业务稳定性驱动:如何保障业务可用性?

作为拥有海量客户的餐饮品牌,Tims 天好咖啡的交易链路核心服务需要保证在营业时间内业务系统的连续性与可用性要求非常严苛。在面临每日高峰订餐时间、新品发布、营销活动、突发热点事件等情况时,系统需要在高并发大流量下保证服务可用和用户体验顺畅。但随着微服务数量逐步增多,链路越来越长,故障定位变得愈发漫长与困难。如果不能快速且精准的进行故障定位,那么故障定位效率低下带来的服务不可用造成的业务损失,可能大于微服务架构本身带来的架构红利。


虽然 Tims 天好咖啡针对不同的服务模块都有对应监控,构建相对完善的指标监控体系,但由于微服务化后的服务模块众多、依赖复杂。很有可能因为某个组件的异常或不可用导致整条链路产生大量冗余告警,形成告警风暴。造成运维团队疲于应付海量告警信息,并非常容易遗漏真正用于故障排查的重要消息。因此,针对海量持续告警信息,如何进行告警合并,在保证不错过核心告警消息的前提下抑制告警消息数量,成为 Tims 天好咖啡的急需解决的重要运维难题。与此同时,由于缺乏链路追踪能力,链路之间无法关联,多个告警可能关联的是同一条完整链路的上下游服务,运维团队对于告警或故障的判断可能被误导或反复排查。


2. 研发效能驱动:全面提升研发效能与代码质量

应用研发是一项由团队共同参与、需要兼顾多方需求的复杂工作。为了更快、更及时地交付符合生产环境质量要求的服务,过去 Tims 天好咖啡大多采用 Code review 形式对代码质量进行评估。但随着研发协作规模不断扩大,这种评估形式效率达到瓶颈,质量与效率难以有效保障。随着团队规模、业务规模不断提升,团队需要对研发过程进行回顾,从效率、质量、交付速度、稳定性、可预估性等多角度进行抽象,并进行量化评估及巡检。


3. 构建运维巡检机制:先于客户发现问题

随着业务规模愈发增大,为了提供更稳健的服务与更优质的用户体验,Tims 天好咖啡计划建立内部巡检机制,主动对IT运行风险的评估发现,并围绕业务连续性保障相关的重要系统性能 & 容量 & 质量管理展开,打造先于用户、业务发现问题、分析问题、定位问题的运维巡检闭环,做到技术驱动用户体验与业务优化。


在云原生改造开始前,由于各个服务系统相对简单,Tims 天好咖啡通过自建 Zabbix 来进行指标监控,但 Zabbix 更擅长硬件、系统、网络设备等基础监控。随着云原生化,Zabbix 无法再满足更加丰富的可观测需求。Tims 天好咖啡结合现有云原生架构与以上三个可观测核心痛点,清晰梳理出两个核心思路:


1. 围绕业务增长规划全链路可观测体系

针对运行态,从前台业务数据、用户体验,到后台应用服务性能,再到云服务及基础资源,即系统资源层、云服务应用层、业务监控层,构建全链路可观测体系,及时发现、定位、解决影响业务与用户体验的故障与瓶颈。避免“自下而上”产生的后台问题,浪费团队时间与精力。同时,借助链路、日志、指标等不同类型指标的融合,提升预警的及时性与准确性,并有效提升故障排查效率。


2. 可观测驱动研发效能提升

作为领先的技术团队,Tims 天好咖啡将 DevOps 理念与流程引入日常研发流程中,并希望将可观测应用于业务运行态与研发态,从而形成全研发生命周期的观测体系。尤其是系统经过云原生改造后,Tims 天好咖啡希望借助可观测工具更直观高效的评估代码质量,为提高研发效率、需求评估抽象出可衡量的目标。


03 解决方案落地


目前 Tims 天好咖啡的服务载体客户端主要是支付宝小程序、微信小程序,针对Tims天好咖啡业务形态,由于海量用户使用不同操作系统、不同屏幕分辨率的终端设备,分布在不同地域,又通过不同网络运营商进行接入,甚至存在复杂第三方依赖,包括 CDN、第三方统计脚本、页面嵌套等方面。当用户体验遇到问题时,如果仅拥有服务端监控手段,很难第一时间确认问题的根源到底在于前端还是后端。即便能够排除服务端的问题,前端用户体验也受到页面渲染、JavaScript 执行、网络质量、第三方接口服务质量等方面的影响,为进一步排查问题留下了非常多的挑战。


因此,Tims 天好咖啡采用应用实时监控服务 ARMS -前端监控,实时掌握 PV/UV、首次渲染耗时等基础性能指标的同时,及时了解 JS 错误数、API 请求错误等影响用户体验的异常数据。从页面打开速度、页面稳定性和外部服务调用成功率这三个方面监测小程序健康度,帮助使用者降低页面加载时间、减少 JS 错误,有效提升用户体验。



与此同时,利用应用实时监控服务 ARMS -应用监控,快速了解应用最关键的响应时间,吞吐量,错误率这黄金三指标,同时根据指标的异常利用调用链能力对整个微服务进行快速跟踪。结合 ARMS 前端监控与应用监控,Tims 天好咖啡轻松构建前后端全链路追踪能力,将前端 API 请求从前端发出到后端调用链路完整串联,真实还原代码执行的完整现场。运维团队在故障发现时能够更快速的进行故障定位与根因分析。




针对容器及中间件云服务,Tims 天好咖啡选择使用 Prometheus + Grafana 的方案进行构建指标监控体系,并形成统一的可观测大屏。通过阿里云可观测监控  Prometheus 版获取了 ARMS 应用监控、云产品监控等指标数据源,结合业务需求与对象赋予各类业务标签,通过可观测可视化 Grafana 版为各个应用搭建完整可观测视图。



在建立可观测体系过程中,能够更早发现问题并提示的告警体系是非常重要的环节,Tims 天好咖啡采用「静态阈值」 + 「ARMS Insight」结合的方案进行日常告警配置。ARMS Insight 借助 ARMS 算法自动判断异常产生故障告警,并基于阿里云多年诊断经验与方案为这些告警故障生成相关诊断报告,目前已覆盖响应时间飙升、错误飙升等 6 大类不同场景,能自动判别、归因近百种不同问题根因,大幅提升常见问题诊断效率,缩短业务恢复时长。同时,对于 Tims 天好咖啡的核心业务场景和服务接口,Tims 天好咖啡根据业务实践设置各类静态阈值进行兜底,保证告警完整性和及时性。


“如果监控解决的是及时知晓服务故障,那么可观测的落地最终目的是挖掘故障或异常的本质,分析根因并反哺业务增长与技术体系迭代。”整个咖啡行业都在尝试数字化,可以看到作为其中优秀代表的 Tims 天好咖啡,正以惊人速度在中国市场扩张。借助以可观测为代表的阿里云云原生产品解决方案,Tims 天好咖啡更加从容的面对门店、交易数量、会员数量的急速增长,在愈发激烈的市场竞争中始终保持竞争优势。

相关实践学习
通过轻量消息队列(原MNS)主题HTTP订阅+ARMS实现自定义数据多渠道告警
本场景将自定义告警信息同时分发至多个通知渠道的需求,例如短信、电子邮件及钉钉群组等。通过采用轻量消息队列(原 MNS)的主题模型的HTTP订阅方式,并结合应用实时监控服务提供的自定义集成能力,使得您能够以简便的配置方式实现上述多渠道同步通知的功能。
相关文章
|
Cloud Native 网络安全 数据安全/隐私保护
【云原生】Docker网络Overlay搭建Consul实现跨主机通信
【云原生】Docker网络Overlay搭建Consul实现跨主机通信
1254 0
|
10月前
|
人工智能 缓存 供应链
森马如何用阿里云 AI 网关,轻松实现“AI+业务”高效落地
森马快速实现 AI 转型,通过阿里云 AI 网关(即 Higress 企业版)及注册配置中心 Nacos3.0 实现了多模型多 MCP server 统一接入统一管理统一配置,将存量服务一键转换为 MCP server,使 AI 与生产业务相结合,综合提效 30%。
1342 77
|
消息中间件 人工智能 运维
左手医生:医疗 AI 企业的云原生提效降本之路
通过使用阿里云云原生等产品,左手医生项目的上线时间缩短了 67%,运维效率提升 70% 左右,消息处理的效率也提升了 80% 左右。
1120 113
|
存储 人工智能 监控
从代码生成到自主决策:打造一个Coding驱动的“自我编程”Agent
本文介绍了一种基于LLM的“自我编程”Agent系统,通过代码驱动实现复杂逻辑。该Agent以Python为执行引擎,结合Py4j实现Java与Python交互,支持多工具调用、记忆分层与上下文工程,具备感知、认知、表达、自我评估等能力模块,目标是打造可进化的“1.5线”智能助手。
2763 62
|
运维 监控 Cloud Native
茶百道全链路可观测实战
茶百道全链路可观测实战
2490 124
|
10月前
|
人工智能 JSON API
MCP与Function Calling的区别是什么?它们与AI Agent有何关联?
本文解析了MCP与Function Calling的区别及联系。MCP通过条件化提示优化模型输出质量,Function Calling则让模型能直接调用外部函数执行操作。两者共同构成AI Agent的核心能力:MCP负责决策优化,Function Calling实现具体执行。文章还指出了实际应用中的常见问题与解决方案。
|
机器学习/深度学习 数据采集 人工智能
微调之后还能做什么?大模型后训练全链路技术解析
本文探讨了后训练的重要性、方法以及最新进展。文章将包含理论分析与实际操作指南,适合希望深入了解并应用这些技术的开发者。
3244 19
微调之后还能做什么?大模型后训练全链路技术解析
|
监控 Kubernetes Python
Python 应用可观测重磅上线:解决 LLM 应用落地的“最后一公里”问题
为增强对 Python 应用,特别是 Python LLM 应用的可观测性,阿里云推出了 Python 探针,旨在解决 LLM 应用落地难、难落地等问题。助力企业落地 LLM。本文将从阿里云 Python 探针的接入步骤、产品能力、兼容性等方面展开介绍。并提供一个简单的 LLM 应用例子,方便测试。
757 125
|
存储 监控 安全
得物 ZooKeeper SLA 也可以 99.99%丨最佳实践
在本文中,作者探讨了ZooKeeper(ZK)的一个内存占用问题,特别是当有大量的Watcher和ZNode时,导致的内存消耗。
44835 131
|
存储 人工智能 监控
2025 年可观测 10 大趋势预测
下述报告主要整理自各大网站发布的对 2025 年可观测趋势的预测,作者合并同类项汇总 10 个共性的趋势,欢迎大家一起讨论。

热门文章

最新文章