一年卖出 8 亿杯，考验的不仅是奶茶的品牌、口感和性价比，还得有一套打通线上和线下、连接上下游供应链、以保障丝滑购买体验的数字化系统。

茶百道成立于 2008 年，起初，茶百道坚持一步一个脚印，用了 8 年时间门店数量也只有 100 家。转折点发生在 2018 年，在这一年，茶百道正式开放全国性加盟，准备用规模来换市场。2020 到 2022 三年期间，营收和净利润都增长了 4 倍有余。这三年，也是茶百道数字化系统成功云原生化的演进历程。

茶百道的小程序页面

茶百道早期的 IT 业务系统由外部 SaaS 服务商提供，在满足业务扩张过程出现的新的业务需求，显得捉襟见肘。例如：

• 需要在原有的会员、订单、营销三中心上，开发更多的业务功能，例如积分商城、外卖系统、加盟招募等；
• 需要新增移动端小程序，并且做到随时可以发布新版本、以持续提升线上购买体验；
• 需要应对不定期举办的线上和线下营销活动所带来的消费波峰，不出现线上故障。

时间就是竞争力，在竞争激烈的茶饮市场，茶百道决定组建自己的软件开发团队，并借助阿里云的云原生产品和技术，全面升级包括店务、POS、用户交易、平台对接、门店管理、餐饮制作等业务单元在内的数字化体验，充分利用线上营销和下单、线下售卖和派送相结合的优势，迅速占领市场。茶百道为这场数字化战役定了个目标：

• 数字化要能助力好茶鲜做
• 数字化要能支持加速拓客
• 数字化要能对企业的经营起到降本增效的作用

数字化要能助力好茶鲜做

茶百道的愿景之一是以好茶为始，持续探索天然食材与茶的搭配，呈现茶饮更多可能。然而，新式茶饮强调手作与新鲜，其产品往往需要多重工序，导致制作流程变得更加复杂，人员成本也随之大幅上涨。

为此，茶百道投资建立了 OMS、WMS 和 TMS 一体的供应链信息化、自动化技术系统，实现了库存、订单、运输资源、到店服务等全链路数字化转型。在提高运送质量的同时，做到信息留存可追溯，完善品牌自检自查和监管部门监管渠道，数字化“护送”食材的出货、送货、到货全流程。

但是供应链信息化、自动化技术系统背后的基础架构，并不是茶百道所擅长的。为了提升整体竞争效率，茶百道希望通过云原生，对从上游原材料供应商到终端门店的整套供应链体系进行再升级。

升级前，茶百道面向 B 端的供应链中心和面向 C 端的运营中心，均部署在自建的 K8s 集群上，存在不小的局限性，例如在运维复杂度、稳定性、成本控制等方面，已不能满足日益增长的业务发展需求。茶百道决定将自建 K8s 集群迁移到 ACK + ECI，ACK 具备强大的集群管理，包括集群创建、集群升级、多集群管理、授权管理等能力，提升了集群管理效率；ECI 可根据业务需求，实现自动扩容，30s 即可扩容 3000 Pod，提升闲置资源利用率，算力成本下降50%；通过 ACK，茶百道有效降低了在节点、集群、应用上的日常维护、安全防护等方面的投入，全面提升供应链体系和运营中心的运营效率。

数字化要能支持加速拓客

茶百道目前的拓客资产包括：全国 7000+ 线下加盟店，覆盖超过 330 个城市，小程序、美团、饿了么的线上外卖店，抖音 & 小红书 & B 站等社区的营销账号（近百万粉丝），以及高频的各类线上和线下营销活动。但在进行数字化升级前，茶百道的拓客渠道非常有限，主要是线下加盟店为主，流量成为营收增长的最主要瓶颈。

为此，茶百道重新设计了运营中心的业务架构，以线上支持业务的快速增长。新增了订单中心中的外卖、配送功能，会员中心的促销、用户、调度、账单、门店、商品功能，营销中心的券功能等，并对三大中心的原有功能进行了全面升级。

茶百道目前日活订单超百万，很多店面是 24 小时营业。技术团队核心目标就是提升拓客效率、线上 0 故障，因此运营中心的稳定性运行成为工作的重中之重。从运营中心架构和依赖关系图可以看到，茶百道的运营一体化系统架构应用繁多，存在以下稳定性挑战：

• 频繁的迭代和发布，三方服务依赖多，线上故障风险增高；
• 服务间调用关系复杂，线上出现问题后，较难快速发现和定位故障；
• 全渠道接入全覆盖的营销场景，难以预期的突发流量，导致保障难度加大。

为此，茶百道借助阿里云微服务引擎 MSE 和应用实时监控服务 ARMS 建立了业务连续性管理体系和可观测体系。在业务连续性管理体系中，构建了故障预防、快速发现、系统防护 3 道标准流程。

降低发版过程中的风险

升级改造前，茶百道因为软件变更带来的线上事故占比一度超过 60%，每次发版，都需要避开高峰，在凌晨发版。升级改造后，通过 MSE 微服务治理建立灰度环境，控制应用发布时出现问题的爆炸半径，以小流量来验证发版质量，逐步覆盖到全部业务节点；加强无损上下线能力，降低应用发布时的流量损失，从而加大了软件的发布频次，提升了对业务的响应诉求，随时可发版，无惧高峰。

这个过程中，MSE 打通了 Readiness，确保 Pod 与应用两者同步就绪，保障发布时业务的连续性；同时，新Pod 通过小流量预热，确保流量的稳定增长，避免由于应用初始化，代码冷加载高流量冲击引起应用雪崩的现象；缩容时，MSE 通过主动通知、客户端刷新等增强能力，解决无损下线问题。并且，通过动态、静态流量染色技术，从网关、应用、消息到数据库，按门店等多种方式进行流量分流隔离，确保灰度环境得到全链路的验证。此外，茶百道使用 MSE 云原生网关替代了原有的 Traefik ingress，整体性能提升 1 倍，并且做到了 ingress 通用规则的平滑迁移。

经过以上的改造，茶百道实现了应用发布效率提升了 60%，因发版引起的线上故障较少了 90% 以上。目前正在直播场景开始实施全链路压测，前端已完成改造。

快读定位线上故障

作为业务高速发展的新兴餐饮品牌，茶百道每天都有着海量的在线订单，这对于业务系统的连续性与可用性有着非常严苛的要求，以确保交易链路核心服务稳定运行。为了让用户有顺畅的使用体验，整个微服务系统每个环节都需保证在高并发大流量下服务质量，但这一过程中，构建可观测体系存在诸多问题：

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

通过 ARMS 构建多层次全链路的监控体系，包括从最底层的系统和云监控，再到业务层监控，指标采样率百分百覆盖，链路全采集，监控数据准确率大幅提升，能够快速实现业务故障的自动发现，有效的配合敏态业务发展。总体来看，故障恢复效率提升 50% 以上，故障恢复耗时缩短 50%。

系统防护，应对突发流量

在业务高峰期或受到某些营销活动带来的突发流量，订单服务等核心应用会承压，为了保护核心应用履约流程不受影响，茶百道通过 ACK +ECI 配置了多种弹性指标，同时借助 MSE 的限流降级功能设置了熔断保护能力，双管齐下。例如，对部分非关键服务消费者配置一个规则，即当一段时间内的慢调用比例或错误比例达到一定条件时自动触发熔断，后续一段时间服务调用直接返回 Mock 的结果。这样既可以保障调用端不会被不稳定服务拖垮，又可以给不稳定的下游服务一些喘息时间，从而保障整个业务链路的正常运转。

数字化要能对企业的经营起到降本增效的作用

如果说助力好茶鲜做是面向供应链的升级，加速拓客是面向市场和销售端的升级，那么降本增效则是对技术团队自身的升级了。

运维：从需求承接到参与研发流程规则制定

茶百道的应用数量有上百个规模，但是在茶百道的研发成员构成上，运维占比较少，大多数是开发，而开发并不熟悉代码构建发布的技术细节。如何让运维能够低成本地定义规则和策略，并落地到应用的研发过程中，是落地过程中的问题点之一。

为了解决该问题，茶百道结合云效应用交付中的研发流程模板、资源编排模板能力，通过模板实现应用配置的快速初始化。在这其中，运维更多的是作为应用研发流程规范的制定者，定义好应用的研发流程模板、资源编排模板、各阶段的代码分支模式以及集群资源，后续的应用特性发布都可以依据定义好的研发流程，在相应的阶段按照规定的发布策略发布到对应的集群资源中。

研发：保持定制和灵活，并自助完成构建和发布

其次，对于实际要去执行代码构建发布的开发一线员工，如何能让他们无需关注 Dockerfile、Yaml 等细节，就能自助地完成构建和发布，并且同时又能保持足够的定制化和灵活性，是茶百道一站式 DevOps 工作流程落地的另一问题点。

为了解决这一问题，茶百道结合云效应用交付中的变更研发流程模式，在运维人员把研发流程规范制定好后，开发人员只需要去依据云效项目中的需求或开发任务，在应用下创建变更，从应用关联的云效代码库中拉取对应的 feature 分支并进行特性的开发，开发完成提交代码后就按照已设定好的研发流程，基于云效流水线进行各阶段的代码分支构建发布，依据提前设定好的分支模式做分支构建发布，构建过程中，从云效制品仓库中拉取相应的依赖包，并且把构建产物放在制品仓库中进行制品版本管理。通过这一模式，一方面可以实现对一线员工应用构建发布细节的隐藏，另一方面也可以随着业务更迭去定制修改构建发布细节。

经过几个月的实践，基于云效，茶百道实现了一站式 DevOps 工作流程方案的成功落地，建立了产研数字化模型，提升了业务响应能力，从而较好的提升了茶百道的企业研发效能。

迁移和实施过程

整体方案设计

完成产品选型后，结合业务上云需求，我们明确了整体系统架构和切换方案。

业务架构设计

第一步，优先迁移业务层应用：即将自建 K8s 迁移到阿里云 ACK 集群，并采用云效应用交付，以应用为中心，集中管理企业的研发资产，包括应用的配置、代码、CI/CD 发布、环境等。在新环境部署业务系统，并进行业务验证及压测。

第二步，测试验证通过后，开始生产系统流量迁移：为了保证平滑过度，此时只迁移系统的接入层和应用层，数据层和中间件选择复用，通过 DNS 切流及 MSE 灰度能力逐步进行业务割接。

第三步，分批完成业务切流，最终通过数据同步方式完成数据库、中间件等产品全量切换，原自建集群下线。

迁移计划

实施过程 - 架构统计

为了实现既定目标，项目组确定了项目实施关键里程碑，现场调研、方案设计、 POC 验证、生产部署及验证、业务割接切流、回归测试、正式上线切流等。

在技术架构上，业务系统外部流量渠道很多，其中有五个主要渠道，包括门店，POS，美团/饿了么，小程序，抖音/支付宝等三方渠道。系统接入层，由 DNS 进行解析，SLB 进行负载均衡，自建 Nginx 集群进行流量分发，由 treafix ingress 作为 NG 和业务网关桥梁，使反向代理和负载均衡更加高效。业务层，除了鉴权的业务网关外，通过 ECS 搭建了 K8s 集群，K8s 由第三方厂商做了很多定制化改造。数据层，用到了 RDS，Redis，TiDB 等数据库及缓存。中间件使用了 RabbitMQ 和 Kafka 等。为了保证方案的研究性及可行性，除此之外，项目组还详细统计了现有部署资源、内外部域名及调用关系、定时任务使用情况等详细情况，为方案设计及实施落地提供有力的支撑。

实施过程 - PoC 测试

PoC 环境搭建完成后，项目组通过 PTS 进行全链路压测，模拟复杂的业务场景，并快速精准地调度不同规模的流量，通过多维度的监控指标和日志记录，全方位地验证业务系统的性能、容量和稳定性。

实施过程 - 生产系统切换

通过 POC 及全链路压测以后，可以确保新环境具备接管能力，并提前准备好回滚方案。切换过程中，利用 ARMS 密切监控系统的性能和稳定性，在迁移结束后进行充分的验证和测试，以确保系统在新环境中正常运行。

生产系统的切换是一个复杂的过程，需要考虑到系统的稳定性和可靠性，为此我们选择分批切流，将原有生产系统的流量逐步切换到新系统中，有效降低了系统压力，减少切换过程中的风险和不确定性。同时，每一个批次都要具备门店灰度能力，在分批切流的同时，新环境的发布通过门店 ID 的方式，在部分门店进行灰度测试，利用生产环境真实流量验证新系统的可用性和性能表现，以确保其能够满足实际业务需求。

总结

数字化是传统企业突破原有市场天花板的核心竞争力，行业竞争越是激烈，数字化升级越是迫切。茶百道预判到行业的加速发展，果断、及时、全面的进行数字化升级，并选择阿里云保障 IT 基础设施的先进性和稳定性，并以此助力好茶鲜做、支持加速拓客、帮助企业降本增效，为企业未来的进一步发展打下坚实的基础。

作者：伯衡、望宸

原文链接

本文为阿里云原创内容，未经允许不得转载。