云原生十大经典案例解读2024版

更多内容， 进入阿里云云原生官方公众号了解 24 20/目录 01 茶百道奶茶上云，原生的更好喝04 作者：伯衡、望宸 ALIBABACLOUDNATIVE 02 Rokid当Rokid遇上函数计算14 作者：王彬、姚兰天、聂大鹏 03 极氪ARMS助力极氪提效服务应急响应，为安全出行保驾护航21 作者：比扬 04 创米数联支撑“千万设备日活”的创米数联7年微服务架构演进之路30 作者：金兆旭、十眠 05 美洽对比5个开源网关项目，这家SaaS企业如何统一网关架构36 作者：古建国 06 高德阿里云函数计算FC助力高德RTA广告投放系统架构升级42 作者：赵庆杰、林雪清、杜玲玲、王壁成 07 TimHortons轻松构建全栈观测，从容应对咖啡产业竞争50 作者：郭皛璠 08 杭州亚运高光回眸：阿里云容器服务如何全面助力精彩亚运56 作者：刘佳旭谢乘胜贤维 09 阿里影业容灾切换时间减少99%，“云边协同”如何提升影演服务效率与稳定性61 作者：神蚕、鹤劼 CASESTUDIES 10 TCLTCL拥抱云原生，实现IT成本治理优化69 作者：行疾 奶茶上云，原生的更好喝 01 —.数字化要能助力好茶鲜做 一年卖出8亿杯，考验的不仅是奶茶的品牌、口感和性价比，还得有一套打通线上和线下、连接上下游供应链、以保障丝滑购买体验的数字化系统。 茶百道成立于2008年，起初，茶百道坚持一步一个脚印，用了8年时间门店数量也只有 100家。转折点发生在2018年，在这一年，茶百道正式开放全国性加盟，准备用规模来换 市场。2020到2022三年期间，营收和净利润都增长了4倍有余。这三年，也是茶百道数字化系统成功云原生化的演进历程。 01茶百道早期的IT业务系统由外部SaaS服务商提供，在满足业务扩张过程出现的新的业务需求，显得捉襟见肘。例如： 需要在原有的会员、订单、营销三中心上，开发更多的业务功能，例如积分商城、外卖系统、加盟招募等； 需要新增移动端小程序，并且做到随时可以发布新版本、以持续提升线上购买体验； 需要应对不定期举办的线上和线下营销活动所带来的消费波峰，不出现线上故障。 02时间就是竞争力，在竞争激烈的茶饮市场，茶百道决定组建自己的软件开发团队，并借助阿里云的云原生产品和技术，全面升级包括店务、POS、用户交易、平台对接、门店管理、餐饮制作等业务单元在内的数字化体验，充分利用线上营销和下单、线下售卖和派送相结合的优势，迅速占领市场。茶百道为这场数字化战役定了个目标： 数字化要能助力好茶鲜做数字化要能支持加速拓客 数字化要能对企业的经营起到降本增效的作用 茶百道的愿景之一是以好茶为始，持续探索天然食材与茶的搭配，呈现茶饮更多可能。然而，新式茶饮强调手作与新鲜，其产品往往需要多重工序，导致制作流程变得更加复杂，人员成本也随之大幅上涨。 为此，茶百道投资建立了OMS、WMS和TMS一体的供应链信息化、自动化技术系统，实现了库存、订单、运输资源、到店服务等全链路数字化转型。在提高运送质量的同时，做到信息留存可追溯，完善品牌自检自查和监管部门监管渠道，数字化“护送”食材的出货、送货、到货全流程。 但是供应链信息化、自动化技术系统背后的基础架构，并不是茶百道所擅长的。为了提升整体竞争效率，茶百道希望通过云原生，对从上游原材料供应商到终端门店的整套供应链体系进行再升级。 升级前，茶百道面向B端的供应链中心和面向C端的运营中心，均部署在自建的K8s集群上，存在不小的局限性，例如在运维复杂度、稳定性、成本控制等方面，已不能满足日益增长的业务发展需求。茶百道决定将自建K8s集群迁移到ACK+ECI，ACK具备强大的集群管理，包括集群创建、集群升级、多集群管理、授权管理等能力，提升了集群管理效率；ECI可根据业务需求，实现自动扩容，30s即可扩容3000Pod，提升闲置资源利用率，算力成本下降50%；通过ACK，茶百道有效降低了在节点、集群、应用上的日常维护、安全防护等方面的投入，全面提升供应链体系和运营中心的运营效率。 二.数字化要能支持加速拓客 茶百道目前的拓客资产包括：全国7000+线下加盟店，覆盖超过330个城市，小程序、美团、饿了么的线上外卖店，抖音&小红书&B站等社区的营销账号（近百万粉丝），以及高频的各类线上和线下营销活动。但在进行数字化升级前，茶百道的拓客渠道非常有限，主要是线下加盟店为主，流量成为营收增长的最主要瓶颈。 为此，茶百道重新设计了运营中心的业务架构，以线上支持业务的快速增长。新增了订单中心中的外卖、配送功能，会员中心的促销、用户、调度、账单、门店、商品功能，营销中心的券功能等，并对三大中心的原有功能进行了全面升级。 为此，茶百道借助阿里云微服务引擎MSE和应用实时监控服务ARMS建立了业务连续性管理体系和可观测体系。在业务连续性管理体系中，构建了故障预防、快速发现、系统防护3道标准流程。 降低发版过程中的风险 升级改造前，茶百道因为软件变更带来的线上事故占比一度超过60%，每次发版，都需要避开高峰，在凌晨发版。升级改造后，通过MSE微服务治理建立灰度环境，控制应用发布时出现问题的爆炸半径，以小流量来验证发版质量，逐步覆盖到全部业务节点；加强无损上下线能力，降低应用发布时的流量损失，从而加大了软件的发布频次，提升了对业务的响应诉求，随时可发版，无惧高峰。 茶百道目前日活订单超百万，很多店面是24小时营业。技术团队核心目标就是提升拓客效率、 线上0故障，因此运营中心的稳定性运行成为工作的重中之重。从运营中心架构和依赖关系图可以看到，茶百道的运营一体化系统架构应用繁多，存在以下稳定性挑战： 频繁的迭代和发布，三方服务依赖多，线上故障风险增高； 服务间调用关系复杂，线上出现问题后，较难快速发现和定位故障； 全渠道接入全覆盖的营销场景，难以预期的突发流量，导致保障难度加大。 这个过程中，MSE打通了Readiness，确保Pod与应用两者同步就绪，保障发布时业务的连续性；同时，新Pod通过小流量预热，确保流量的稳定增长，避免由于应用初始化，代码冷加载高流量冲击引起应用雪崩的现象；缩容时，MSE通过主动通知、客户端刷新等增强能力，解决无损下线问题。并且，通过动态、静态流量染色技术，从网关、应用、消息到数据库，按门店等多种方式进行流量分流隔离，确保灰度环境得到全链路的验证。此外，茶百道使用MSE云原生网关替代了原有的Traefikingress，整体性能提升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发布、环境等。在新环境部署业务系统，并进行业务验证及压测。 第二步，测试验证通过后，开始生产系统流量迁移： 为了保证平滑过度，此时只迁移系统的接入层和应用层，数据层和中间件选择复