1、2024ALIBABA CLOUD NATIVECASE STUDIES更多内容，进入阿里云云原生官方公众号了解/目录01茶百道奶茶上云，原生的更好喝作者：伯衡、望宸0402Rokid当 Rokid 遇上函数计算作者：王彬、姚兰天、聂大鹏1403极氪ARMS 助力极氪提效服务应急响应，为安全出行保驾护航作者：比扬2104创米数联支撑“千万设备日活”的创米数联 7 年微服务架构演进之路作者：金兆旭、十眠3005美洽对比 5 个开源网关项目，这家 SaaS 企业如何统一网关架构作者：古建国3606高德阿里云函数计算 FC 助力高德 RTA 广告投放系统架构升级作者：赵庆杰、林雪清、杜玲玲、王壁成4

2、207Tim Hortons轻松构建全栈观测，从容应对咖啡产业竞争作者：郭皛璠5008杭州亚运高光回眸：阿里云容器服务如何全面助力精彩亚运作者：刘佳旭 谢乘胜 贤维5609阿里影业容灾切换时间减少 99%，“云边协同”如何提升影演服务效率与稳定性作者：神蚕、鹤劼6110TCLTCL 拥抱云原生，实现 IT 成本治理优化作者：行疾6954茶百道云原生十大经典案例奶茶上云，原生的更好喝一年卖出 8 亿杯，考验的不仅是奶茶的品牌、口感和性价比，还得有一套打通线上和线下、连接上下游供应链、以保障丝滑购买体验的数字化系统。茶百道成立于 2008 年，起初，茶百道坚持一步一个脚印，用了 8 年时间门店数量

3、也只有 100 家。转折点发生在 2018 年，在这一年，茶百道正式开放全国性加盟，准备用规模来换市场。2020 到 2022 三年期间，营收和净利润都增长了 4 倍有余。这三年，也是茶百道数字化系统成功云原生化的演进历程。茶百道的愿景之一是以好茶为始，持续探索天然食材与茶的搭配，呈现茶饮更多可能。然而，新式茶饮强调手作与新鲜，其产品往往需要多重工序，导致制作流程变得更加复杂，人员成本也随之大幅上涨。为此，茶百道投资建立了 OMS、WMS 和 TMS 一体的供应链信息化、自动化技术系统，实现了库存、订单、运输资源、到店服务等全链路数字化转型。在提高运送质量的同时，做到信息留存可追溯，完善品牌自

4、检自查和监管部门监管渠道，数字化“护送”食材的出货、送货、到货全流程。但是供应链信息化、自动化技术系统背后的基础架构，并不是茶百道所擅长的。为了提升整体竞争效率，茶百道希望通过云原生，对从上游原材料供应商到终端门店的整套供应链体系进行再升级。升级前，茶百道面向 B 端的供应链中心和面向 C 端的运营中心，均部署在自建的 K8s 集群上，存在不小的局限性，例如在运维复杂度、稳定性、成本控制等方面，已不能满足日益增长的业务发展需求。茶百道决定将自建 K8s 集群迁移到 ACK+ECI，ACK 具备强大的集群管理，包括集群创建、集群升级、多集群管理、授权管理等能力，提升了集群管理效率；ECI 可根据

5、业务需求，实现自动扩容，30s 即可扩容 3000 Pod，提升闲置资源利用率，算力成本下降 50%；通过 ACK，茶百道有效降低了在节点、集群、应用上的日常维护、安全防护等方面的投入，全面提升供应链体系和运营中心的运营效率。01茶百道早期的 IT 业务系统由外部 SaaS 服务商提供，在满足业务扩张过程出现的新的业务需求，显得捉襟见肘。例如：需要在原有的会员、订单、营销三中心上，开发更多的业务功能，例如积分商城、外卖系统、加盟招募等；需要新增移动端小程序，并且做到随时可以发布新版本、以持续提升线上购买体验；需要应对不定期举办的线上和线下营销活动所带来的消费波峰，不出现线上故障。02时间就是竞

6、争力，在竞争激烈的茶饮市场，茶百道决定组建自己的软件开发团队，并借助阿里云的云原生产品和技术，全面升级包括店务、POS、用户交易、平台对接、门店管理、餐饮制作等业务单元在内的数字化体验，充分利用线上营销和下单、线下售卖和派送相结合的优势，迅速占领市场。茶百道为这场数字化战役定了个目标：数字化要能助力好茶鲜做数字化要能支持加速拓客数字化要能对企业的经营起到降本增效的作用一.数字化要能助力好茶鲜做0176茶百道云原生十大经典案例二.数字化要能支持加速拓客茶百道目前的拓客资产包括：全国 7000+线下加盟店，覆盖超过 330 个城市，小程序、美团、饿了么的线上外卖店，抖音&小红书&B 站等社区的营销

7、账号（近百万粉丝），以及高频的各类线上和线下营销活动。但在进行数字化升级前，茶百道的拓客渠道非常有限，主要是线下加盟店为主，流量成为营收增长的最主要瓶颈。为此，茶百道重新设计了运营中心的业务架构，以线上支持业务的快速增长。新增了订单中心中的外卖、配送功能，会员中心的促销、用户、调度、账单、门店、商品功能，营销中心的券功能等，并对三大中心的原有功能进行了全面升级。茶百道目前日活订单超百万，很多店面是 24 小时营业。技术团队核心目标就是提升拓客效率、线上 0 故障，因此运营中心的稳定性运行成为工作的重中之重。从运营中心架构和依赖关系图可以看到，茶百道的运营一体化系统架构应用繁多，存在以下稳定性挑

8、战：为此，茶百道借助阿里云微服务引擎 MSE 和应用实时监控服务 ARMS 建立了业务连续性管理体系和可观测体系。在业务连续性管理体系中，构建了故障预防、快速发现、系统防护 3 道标准流程。频繁的迭代和发布，三方服务依赖多，线上故障风险增高；服务间调用关系复杂，线上出现问题后，较难快速发现和定位故障；全渠道接入全覆盖的营销场景，难以预期的突发流量，导致保障难度加大。升级改造前，茶百道因为软件变更带来的线上事故占比一度超过 60%，每次发版，都需要避开高峰，在凌晨发版。升级改造后，通过 MSE 微服务治理建立灰度环境，控制应用发布时出现问题的爆炸半径，以小流量来验证发版质量，逐步覆盖到全部业务节

9、点；加强无损上下线能力，降低应用发布时的流量损失，从而加大了软件的发布频次，提升了对业务的响应诉求，随时可发版，无惧高峰。降低发版过程中的风险98茶百道云原生十大经典案例这个过程中，MSE 打通了 Readiness，确保 Pod 与应用两者同步就绪，保障发布时业务的连续性；同时，新Pod 通过小流量预热，确保流量的稳定增长，避免由于应用初始化，代码冷加载高流量冲击引起应用雪崩的现象；缩容时，MSE 通过主动通知、客户端刷新等增强能力，解决无损下线问题。并且，通过动态、静态流量染色技术，从网关、应用、消息到数据库，按门店等多种方式进行流量分流隔离，确保灰度环境得到全链路的验证。此外，茶百道使用

10、 MSE 云原生网关替代了原有的 Traefik ingress，整体性能提升 1 倍，并且做到了 ingress 通用规则的平滑迁移。经过以上的改造，茶百道实现了应用发布效率提升了 60%，因发版引起的线上故障较少了 90%以上。目前正在直播场景开始实施全链路压测，前端已完成改造。通过 ARMS 构建多层次全链路的监控体系，包括从最底层的系统和云监控，再到业务层监控，指标采样率百分百覆盖，链路全采集，监控数据准确率大幅提升，能够快速实现业务故障的自动发现，有效的配合敏态业务发展。总体来看，故障恢复效率提升 50%以上，故障恢复耗时缩短 50%。作为业务高速发展的新兴餐饮品牌，茶百道每天都有着

11、海量的在线订单，这对于业务系统的连续性与可用性有着非常严苛的要求，以确保交易链路核心服务稳定运行。为了让用户有顺畅的使用体验，整个微服务系统每个环节都需保证在高并发大流量下服务质量，但这一过程中，构建可观测体系存在诸多问题：快读定位线上故障运维：从需求承接到参与研发流程规则制定在业务高峰期或受到某些营销活动带来的突发流量，订单服务等核心应用会承压，为了保护核心应用履约流程不受影响，茶百道通过 ACK+ECI 配置了多种弹性指标，同时借助 MSE 的限流降级功能设置了熔断保护能力，双管齐下。例如，对部分非关键服务消费者配置一个规则，即当一段时间内的慢调用比例或错误比例达到一定条件时自动触发熔断，

12、后续一段时间服务调用直接返回 Mock 的结果。这样既可以保障调用端不会被不稳定服务拖垮，又可以给不稳定的下游服务一些喘息时间，从而保障整个业务链路的正常运转。系统防护，应对突发流量指标数据准确度与采样率难以平衡。适当的采样策略是解决链路追踪工具成本与性能的重要手段。在茶百道的庞大微服务系统规模下，100%链路采集会造成可观测平台存储成本超出预期，而且在业务高峰期还会对微服务应用本身的性能带来一定影响。但开源工具在设定采样策略的情况下，又会影响指标数据准确度，使错误率、P99 响应时间等重要可观测指标失去观测与告警价值。茶百道的应用数量有上百个规模，但是在茶百道的研发成员构成上,运维占比较少，

13、大多数是开发，而开发并不熟悉代码构建发布的技术细节。如何让运维能够低成本地定义规则和策略，并落地到应用的研发过程中，是落地过程中的问题点之一。为了解决该问题，茶百道结合云效应用交付中的研发流程模板、资源编排模板能力，通过模板实现应用配置的快速初始化。在这其中，运维更多的是作为应用研发流程规范的制定者，定义好应用的研发流程模板、资源编排模板、各阶段的代码分支模式以及集群资源，后续的应用特性发布都可以依据定义好的研发流程，在相应的阶段按照规定的发布策略发布到对应的集群资源中。缺少高阶告警能力。开源工具在告警方面实现比较简单，用户需要自行分别搭建告警处理及告警分派平台，才能实现告警信息发送到 IM

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

15、SRE 经验的工程师，才能快速准确的定位故障根源。三.数字化要能支持加速拓客如果说助力好茶鲜做是面向供应链的升级，加速拓客是面向市场和销售端的升级，那么降本增效则是对技术团队自身的升级了。1110茶百道云原生十大经典案例四.迁移和实施过程研发：保持定制和灵活，并自助完成构建和发布其次，对于实际要去执行代码构建发布的开发一线员工，如何能让他们无需关注 Dockerfile、Yaml 等细节，就能自助地完成构建和发布，并且同时又能保持足够的定制化和灵活性，是茶百道一站式 DevOps 工作流程落地的另一问题点。为了解决这一问题，茶百道结合云效应用交付中的变更研发流程模式，在运维人员把研发流程规范制

16、定好后，开发人员只需要去依据云效项目中的需求或开发任务，在应用下创建变更，从应用关联的云效代码库中拉取对应的 feature 分支并进行特性的开发，开发完成提交代码后就按照已设定好的研发流程，基于云效流水线进行各阶段的代码分支构建发布，依据提前设定好的分支模式做分支构建发布，构建过程中，从云效制品仓库中拉取相应的依赖包，并且把构建产物放在制品仓库中进行制品版本管理。通过这一模式，一方面可以实现对一线员工应用构建发布细节的隐藏，另一方面也可以随着业务更迭去定制修改构建发布细节。经过几个月的实践，基于云效，茶百道实现了一站式 DevOps 工作流程方案的成功落地，建立了产研数字化模型，提升了业务响

17、应能力，从而较好的提升了茶百道的企业研发效能。整体方案设计完成产品选型后，结合业务上云需求，我们明确了整体系统架构和切换方案。第一步，优先迁移业务层应用：即将自建 K8s 迁移到阿里云 ACK 集群，并采用云效应用交付，以应用为中心，集中管理企业的研发资产，包括应用的配置、代码、CI/CD 发布、环境等。在新环境部署业务系统，并进行业务验证及压测。第二步，测试验证通过后，开始生产系统流量迁移：为了保证平滑过度，此时只迁移系统的接入层和应用层，数据层和中间件选择复用，通过 DNS 切流及 MSE 灰度能力逐步进行业务割接。第三步：分批完成业务切流，最终通过数据同步方式完成数据库、中间件等产品全量

18、切换，原自建集群下线。业务架构设计实施过程-架构统计为了实现既定目标，项目组确定了项目实施关键里程碑，现场调研、方案设计、POC 验证、生产部署及验证、业务割接切流、回归测试、正式上线切流等。1312茶百道云原生十大经典案例迁移计划实施过程-PoC 测试PoC 环境搭建完成后，项目组通过 PTS 进行全链路压测，模拟复杂的业务场景，并快速精准地调度不同规模的流量，通过多维度的监控指标和日志记录，全方位地验证业务系统的性能、容量和稳定性。实施过程-生产系统切换通过 POC 及全链路压测以后，可以确保新环境具备接管能力，并提前准备好回滚方案。切换过程中，利用 ARMS 密切监控系统的性能和稳定性，

19、在迁移结束后进行充分的验证和测试，以确保系统在新环境中正常运行。生产系统的切换是一个复杂的过程，需要考虑到系统的稳定性和可靠性，为此我们选择分批切流，将原有生产系统的流量逐步切换到新系统中，有效降低了系统压力，减少切换过程中的风险和不确定性。同时，每一个批次都要具备门店灰度能力，在分批切流的同时，新环境的发布通过门店 ID 的方式，在部分门店进行灰度测试，利用生产环境真实流量验证新系统的可用性和性能表现，以确保其能够满足实际业务需求。五.总结数字化是传统企业突破原有市场天花板的核心竞争力，行业竞争越是激烈，数字化升级越是迫切。茶百道预判到行业的加速发展，果断、及时、全面的进行数字化升级，并选择

20、阿里云保障 IT 基础设施的先进性和稳定性，并以此助力好茶鲜做、支持加速拓客、帮助企业降本增效，为企业未来的进一步发展打下坚实的基础。在技术架构上，业务系统外部流量渠道很多，其中有五个主要渠道,包括门店,POS，美团/饿了么，小程序，抖音/支付宝等三方渠道。系统接入层，由 DNS 进行解析，SLB 进行负载均衡，自建 Nginx 集群进行流量分发，由 treafix ingress 作为 NG 和业务网关桥梁，使反向代理和负载均衡更加高效。业务层，除了鉴权的业务网关外，通过 ECS 搭建了 K8s 集群，K8s 由第三方厂商做了很多定制化改造。数据层，用到了 RDS，Redis，TiDB 等数

21、据库及缓存。中间件使用了 RabbitMQ 和 Kafka 等。为了保证方案的研究性及可行性，除此之外，项目组还详细统计了现有部署资源、内外部域名及调用关系、定时任务使用情况等详细情况，为方案设计及实施落地提供有力的支撑。1514Rokid云原生十大经典案例当 Rokid 遇上函数计算Rokid 创立于 2014 年，是一家专注于人机交互技术的产品平台公司。Rokid 通过语音识别、自然语言处理、计算机视觉、光学显示、芯片平台、硬件设计等多领域研究，将前沿的 Al 和 AR 技术与行业应用相结合，为不同垂直领域的客户提供全栈式解决方案，有效提升用户体验、助力企业增效、赋能公共安全，其 Al、A

22、R 产品已在全球八十余个国家和地区投入使用。Rokid Air Pro 这款AR眼镜产品，为旅游景点，大型企业，国内科研机构都提供了服务支持。目前 Rokid 已和全国百余家博物馆和景区达成合作，给游客穿越时空，身临其境的非凡参观体验。三维建图，场景创作，场景体验三个场景都涉及到了的图像处理，需要大量的 GPU 资源。其中三维建图属于离线任务，在构建展陈模型时，需要将整个展陈场所的视频内容进行预处理，是三个场景中消耗算力最大的部分；场景创作需要配合创作软件，GPU 资源主要来自开发机器；场景体验在设备真实运行时提供实时服务，主要功能是定位服务，对服务的实时性要求很高。为了支撑 GPU 算力的需

23、求，Rokid 在开发的初期就决定尽可能的使用云资源承载，充分利用云计算的红利。最初是购买了 ECS 的 GPU 机型，用于业务的开发和测试。这里很大的问题是在三维建图时，一般都会一次性采集展陈环境的所有场景资料，视频量巨大，通过 ECS 串行处理需要时间很长，一个 1 小时的视频资料，通过一台 ECS GPU 机器需要处理 3 小时左右。Rokid 做的第一步是并行化，通过拆分 CPU 和 GPU 处理逻辑和优化任务编排方式，尽可能的让可以并发处理的部分拉起更多的资源加大并发量，通过这一系列的优化，视频的处理时间得到了不错的提升。在并发资源方面，Rokid 选择的 GPU 计算资源是 ECI

24、，相对 ECS，ECI 可选的资源粒度更加多样，特别是在小规格的选择上，对于切分的小块视频，通过并发的使用小规格 ECI 实例并行处理，大大缩短了整体视频的处理时间。为此，Rokid 内部平台还开发了一套针对阿里云 ECI 资源的调度模块，方便内部快速的申请和归还 ECI 资源。通过对 ECI 资源的灵活使用，在保证高峰期任务处理并发度的同时，也保证了算力成本的可控，使用流程上得到了初步的优化。但是通过一段时间的使用，发现还是有很多的不足之处，主要问题总结如下：一.架构革新的必要性Rokid 在 AR 的研究可以追溯到公司创立之初，在 2012 年 Google Glass 横空出世，其广阔的

25、想象空间深深震撼了 Rokid 创始团队。后面虽然因为使用的场景和高额的价格原因，Google Glass 并没有持续的火爆普及。但可以预计在不久的将来，随着基础设施，生态应用的成熟，和人们持续提升的对娱乐，办公的体验要求，AR 技术一定会得到更广泛的应用。Rokid 在数字文化领域，围绕展陈导览解决方案，主要形成了三维建图，场景创作，场景体验三个业务模块，每个模块都有不同的后台平台支撑。三维建图：制作展陈导览的第一步是取景，通过设备获取场地的真实布景，然后通过算法处理，进行三维建模，之后可以经过创作器进行下一步的内容创作。场景创作：在三维建模生成的视频流上创作，通过 Web3D 渲染引擎，将

26、创作内容与场景紧密结合，结合硬件设备，在 AR 设备使用时，形成一体化的体验效果。场景体验：AR 设备在使用时，根据定位服务，锚定在场景中的位置，根据位置的不同会显示不同的空间内容，达到扩展现实场景的效果。010203ECI 资源的申请和释放都依靠使用人员主动操作，有时在使用完毕后会忘记及时释放资源，导致资源闲置浪费。且开发和维护 ECI 的调度程序也需要占据对应同学一定的精力，带来了一些额外的运维工作。01021716Rokid云原生十大经典案例底层依托阿里云的大计算池，提供近乎无限的计算资源，通过阿里云的 cGPU 技术，可将单卡 GPU 资源切分成多种更小粒度的资源规格。客户在函数计算选

27、择 GPU 规格创建函数，在有请求时，函数计算会实时从预热资源池获取资源，配合对应的镜像程序，启动客户函数，启动完毕后对外提供服务。函数计算在第一次运行实例时会涉及到资源的拉起，弹性交付时间在 1s（热启动）20s（冷启动）。Rokid 的三维建图场景是离线任务，单个视频的处理时间也在分钟级，对于秒级别的启动时延完全可以接受。在三维建图任务接入函数计算后，Rokid 不再需要手动申请 ECI 资源，在使用结束之后也不需要在手动释放。函数计算会根据请求流量，动态的拉起与请求量匹配的后端 GPU 算力资源，在请求处理结束后，一段时间没有新请求的情况下，自动释放资源；整个三维建模在拆分后涉及好几个步

28、骤，每个步骤都是异步执行，通过函数计算的异步系统，在一个步骤的任务完成后，可以自动触发下一个任务；函数计算控制台内置了指标监控，异常告警，链路追踪，调用日志，异步配置的功能，可以满足 Rokid 从开发，运行监控到运维全函数生命周期的功能需求；函数计算底层依托阿里云大计算池，加上预热和资源评估的后端算法，可以最大程度的保证资源供给；这几点正是 Rokid 之前遇到的痛点问题，通过接入函数计算单一的产品，就解决了 Rokid 近乎全部的主要问题。为了解决上面问题，Rokid 内部架构组寻求优化已有的架构，针对第 2 点，Rokid 自行维护了一个总的调度系统，进行任务编排；针对第 3 点，通过阿

29、里云 ARMS Tracing，Prometheus，Grafana 等组件的引入，结合 ECI 硬件指标，统一收集到 SLS，形成统一的监控报表，再配以监控指标的告警，也能够初步的满足 Rokid 使用需求。但第 1 点和第 4 点，很难通过增加云产品或者内部应用程序解决。为此 Rokid 架构组开始寻找云上新的产品，以求彻底的解决使用过程中的痛点问题。此时，Serverless 架构的函数计算出现在了 Rokid 架构师的视野，经过一段时间的调研使用，函数计算的各项能力都能够很好的满足 Rokid 使用场景。三维建模的任务经过拆分后，分成了好几个步骤，每个步骤的任务都需要异步执行，需要一个

30、系统维持任务的调用关系，在上一个步骤完成后，拉起下一个步骤的任务继续运行。在运行过程中，会存在异常情况，排查下来，有时是因为申请的计算资源规格过小导致计算负载较高，有时是存储异常或存储空间写满，还有些情况是程序本身性能瓶颈。对于程序的整体监控缺乏，使得出现问题时不能第一时间发现，发现有异常排查过程不够直观，需要通过多种工具获取运行指标分析。GPU 算力在云上规模有限，在高峰期会偶尔存在 ECI 资源弹不出的情况，影响开发效率。020304函数计算是事件驱动的全托管计算服务。使用函数计算，客户无需采购与管理服务器等基础设施，只需编写并上传代码或镜像。函数计算会准备好计算资源，弹性地、可靠地运行任

31、务，并提供日志查询、性能监控和报警等功能。函数计算提供 CPU，GPU 的算力，秒级计费，客户只需要为实际资源使用付费。资源弹性可根据定时，请求量等指标自动伸缩，无需维护调度，负载，重试，异步回调等组件，提供了开箱即用，用完即走，按量付费的极致 Serverless 能力。函数计算 GPU 架构如下：二.函数计算的出现恰逢其时1918接入函数计算后，Rokid 的云产品技术架构如下：函数计算资源利用率监控图如下，从监控图可以看出，在有任务进入时，GPU 计算利用率可以达到 60%甚至接近 100%。三.体验与架构的妥协Serverless 理念的函数计算确实给 Rokid 带了很多的便利，在高

32、峰期资源的扩展性和成本节约方面都做到了当前云产品的极致，但函数计算也并非万能，对于 Rokid 的场景体验功能，也就是需要实时提供定位服务的模块，函数计算还是存在了一定的问题。函数计算在第一次拉起实例资源时，会存在 1s（热启动）20s（冷启动）的启动时间，这个时间对于实时定位服务模块是不可接受的，实时定位是在使用者身处展陈场地时，AR 设备通过实时定位，获取空间位置的 AR 拓展信息，接口响应的时间对客户的体验非常重要，定位请求需要在 1s 以内返回。在成本和服务质量之间，Rokid 选择了服务质量优先，场景体验模块采用 ECI 部署，通过每天的定时任务，在高峰期提前弹出更多的 ECI 实例

33、，在低峰期时，保留少量的 ECI 实例，以此达到体验和成本的平衡。另一方面，函数计算在实时的场景也并非完全没有解决方案。目前 GPU 的模型一般都很大，镜像都在 G 级别，所以对于第一次资源拉起，在接下来一段时间内还看不到跟 CPU 资源一样 100ms 级别的拉起速度。针对实时场景，函数计算 GPU 实例在做的是预留实例，该功能可以在资源闲置时，释放计算资源的同时，保留程序的内存运行镜像，在有新的请求进来时，只需要供给算力资源，函数就能提供服务，免去了中间硬件资源拉起，函数镜像拉取和启动的时间，可以提供实时的服务。预留实例已经在 CPU 实例上线，闲置时 CPU 价格是运行态的 1/10，在

34、保证实时能力的情况下，大大降低了资源成本。GPU 版本的预留能力预计年底上线。场景体验采用 ECI 后，Rokid 的业务架构图如下：Rokid云原生十大经典案例2120四.出色的效果和进一步的期待一.客户介绍与项目背景通过一系列的云架构改造，当前 Rokid 三维建图模块运行在函数计算的 GPU 资源上，场景体验模块运行在 ECI 资源，在成本和性能上，都做到了兼顾，且给整个系统强大的可拓展性，达到了系统设计时设定的架构目标，从 2023/2 上线提供服务以来，达到了不错的效果。其中三维建图模块降本明显，相比最初的 ECS 架构，算力成本降低了 40%，更为重要的是，通过实时的并发处理，大大

35、减少了子任务的排队时间，加快了整个任务的完成时间。下一步，Rokid 对于函数计算的 GPU 预留实例还是非常期待，期待函数计算能够尽快上线，这样 Rokid 内部可以将整个的 GPU 算力都迁移到函数计算，达到架构的统一。经过展陈展览项目的实践，Rokid 相信以函数计算为代表的 Serverless 一定是云计算的未来，通过 Serverless，云计算的使用者不再需要关注底层的 Iaas 层运维和调度，在保证成本最优的情况下能够得到最大限度的拓展能力，且在整服务的生命周期，都能使用云产品提供的原生能力，简单，快速的定位，解决问题。Rokid 在 3d 模型处理，音视频后处理方面正在大规模

36、尝试函数计算，Rokid 相信以函数计算为代表的 Serverless 架构也一定会在越来越多的云产品上得到应用。Rokid极氪云原生十大经典案例ARMS 助力极氪提效服务应急响应，为安全出行保驾护航浙江极氪智能科技有限公司于 2021 年 3 月成立，2021 年 4 月发布极氪品牌及旗下首款产品极氪 001。极氪是一家以智能化、数字化、数据驱动的智能出行科技公司，秉承用户型企业理念，聚焦智能电动出行前瞻技术的研发，构建科技生态圈与用户生态圈，以“共创极致体验的出行生活”为使命，从产品创新、用户体验创新到商业模式创新，致力于为用户带来极致的出行体验。截止 2023 年 4 月，极氪量产车交付

37、已经突破 10 万辆，从 0 到 10 万辆，极氪用时仅两年，快于其他新势力品牌至少四年以上的时间，持续刷新新势力品牌交付记录，这不仅是对“极氪速度”的展现，也是对“中国速度”最好的诠释。为了保障好极氪汽车业务的快速发展和用户体验，技术团队除了保持高效的功能迭代的同时，也在不断的夯实其系统稳定性和应急响应能力。自 2023 年开始，大数据团队正试点推行面向极数 BI 业务的数字化稳定性治理建设。032322极氪云原生十大经典案例极数 BI 是一款面向极氪经营管理全体系的可视化数据分析系统，已覆盖多个核心业务场景。极数 BI 不仅仅是一个报表工具，还提供了全域数据互联互通、智能化数据分析和全景数

38、据可视化的功能，可以为其他业务“发生了什么、为什么发生、将要发生什么、如何应对”提供完善的数据支撑和辅助决策能力。打破数字鸿沟，创造数据价值，逐步实现全业务域的经营过程观测与经营结果呈现是极数 BI 的发展目标。为保障极数 BI 的数字化稳定性治理建设落地，极氪通过建设端到端的全链路可观测体系、企业级应急响应机制和跨部门团队的人员协同机制，以业务连续性保障为目标，实现了极数 BI 业务的“X 分钟的故障发现与通报”、“X 分钟的应急响应与故障定位”、“X 分钟的故障恢复”核心稳定性指标的达成。如何构建统一的报警体系、通报机制和跨团队应急协同机制 系统资源层、云服务应用层、业务监控层，为了监控这

39、些复杂的 IT 环境，由于各层资源分属不同的团队进行管理，导致采用了多种监控系统，例如 Prometheus、Grafana、Skywalking、阿里云云监控、阿里云 ARMS 等，以获取更全面的监控数据和更好的了解运行状态和性能表现。然而多种监控系统的并存带来的其中一个显著问题是告警信息的分散，不同的监控系统产生不同的告警信息，通过不一致的方式通报给告警处理人，而告警的排查通常需要多个团队共同合作进行处理，纵横交错的告警处理增加了人员响应的复杂性和工作量，疲于应付的程度往往远超出了告警处理人员的日常负荷。02如何规范故障等级定义、应急处置流程和故障管理体系 业务可用率是一套业务系统可靠性、

40、维修性和维修保障性的综合反映。Availability=MTBF/(MTBF+MTTR)，通常业界习惯用 N 个 9 来表 征 系 统 可 用 性，比 如 99.9%（3-9 availability），99.999%（5-9 availability），系统出现故障的停机时间直接反映了业务可用率。如何定义一套适用于极氪自身业务的故障等级定义、应急处置流程和故障管理体系将是保障极氪对外承诺的业务可用率的重要支撑手段。通过建立一个可遵循的规范、全流程闭环的故障管理体系，配合技术手段的提升，可以有效降低故障发生的几率，缩短故障的 MTTR，最终使故障造成的破坏性趋近于 0。03如何有效度量业务稳定

41、性指标和应急响应 SLA 如何查看过去一段时间系统发生了哪些告警，哪类告警占比较高；制定了值班机制，但无法衡量值班人员告警处理的效率，如何确保值班机制的执行效果；一个服务在多个系统中配置了多个告警，无法从服务的维度来查看告警的处理效率，查看服务的 SLA；在针对性的系统优化后告警占比是否降低，告警的持续时间占比是否得到改善。这些都是在日常运维过程中衡量告警的处理效率和服务的稳定性面临的典型问题。这些重要数据都需要完善的数据报表和统一的大盘来呈现。04疲于应付海量告警信息，并且非常容易遗漏真正用于故障排查的重要消息。因此，针对海量持续告警信息，如何进行告警合并，在保证不错过核心告警消息的前提下抑

42、制告警消息数量，成为了面临的重要运维难题。二.项目落地时面临的挑战和需求云原生浪潮下，Serverless 因其全托管免运维、成本降低和弹性伸缩等特性正逐步在引领下一代的应用架构。极数 BI 业务从立项之初就确定了 Serverless 化的方向，并基于阿里云 Serverless 应用引擎（SAE）成功落地。应用 Serverless 化最大化限度减轻了运维工作，但是在自身业务的数字化稳定性治理方面依然面临较大挑战：如何覆盖和收敛从基础设施到业务应用监控的全链路告警事件 从前台业务数据、用户体验，到后台应用服务性能，再到云服务及基础资源，即系统资源层、云服务应用层、业务监控层，虽然针对不同的

43、服务模块都有对应监控，构建了相对完善的指标监控体系，但由于微服务化后的服务模块众多、依赖复杂，很有可能因为某个组件的异常或不可用导致整条链路产生大量冗余告警，形成告警风暴，从而造成运维团队012524极氪云原生十大经典案例三.基于 ARMS 的企业级应急响应解决方案针对上述面临的问题和挑战，阿里云云原生可观测团队与大数据团队经过多轮沟通对焦，通力合作共同输出了基于 ARMS 构建企业级应急响应体系的最佳实践，并成功在极数 BI 业务中落地，实现了全业务、全场景的监控和告警。同时全面提升了监控的覆盖率和告警有效率，其中按照极氪现行推广的应急响应机制，全团队事件接手率显著提升，告警平均认领耗时（M

44、TTA）大幅降低，告警平均恢复耗时（MTTR）明显缩短，跨团队协同效率得到有效提升。采用 ARMS 智能告警建设统一的告警事件管理中心 极氪技术团队根据自身业务属性使用了多种监控系统，例如阿里云应用监控 ARMS、阿里云日志服务 SLS、Zabbix、Prometheus、Grafana 和自定义告警集成等，为了简化联系人、通知方式、值班等运维配置；统一告警信息格式、告警等级定义和告警事件的统一管理，极氪采用了 ARMS 智能告警作为多告警源统一管理的事件管理中心。ARMS 智能告警设计的集成、事件处理流、通知策略等功能专门针对告警统一管理的场景，解决了统一管理过程中遇到的诸多问题。以下重点介

45、绍下整体方案中围绕“告警、接手”两项落地的“以事件为中心的告警全生命周期管理”解决方案。接入不同格式的告警。ARMS 智能告警参考开源 Prometheus 告警定义，使用一个半结构化的数据结构来描述告警。通过高度可扩展的键值对来描述告警，这样就可以非常灵活的对告警内容进行扩展从而接入不同的数据源产生的告警。通过告警集成的字段映射能力，即可将自定义的告警内容中的关键信息映射到 ARMS 告警数据结构中。同时也提供了多种监控工具的快捷接入能力，像极氪这边使用的阿里云应用监控 ARMS、阿里云日志服务 SLS、Zabbix、Prometheus、Grafana 等均已覆盖。告警等级统一定义。根据影

46、响面的不同、业务受损程度的不同,一般需要定义不同的告警等级，告警处理人员需要根据不同的告警等级执行不同的应急处理过程。按照极氪的故障等级规范,配置告警时根据业务情况将告警归一到 P0、P1、P2、P3 四个等级。01022726极氪云原生十大经典案例事件和告警的归一化管理。多告警事件源通过集成的方式统一到 ARMS 智能告警，通过统一的事件处理流、通知策略、通知对象、升级策略等对告警事件进行归一化管理。一份通知对象、一套通知策略、一致的告警管理模式，满足极氪统一的告警事件中心需求。通过认领告警的消息广播可以让群成员之间明确的知道当前告警是谁在处理。01认领告警有些告警触发属于预期内的行为，且不

47、会造成业务影响，但是又不能直接关闭告警。这种情况下可以通过屏蔽告警来降低告警通知的打扰。02屏蔽告警关注告警后，会将被关注告警的状态变更以短信的形式推送给关注人。对于重大故障的情况下，团队负责人可以通过关注告警的能力实时订阅关注告警处理的进展，从而为指挥决策提供数据支撑。03关注告警关闭告警并在群聊中发送一个告警关闭的通知，被关闭的告警状态会变成已恢复。04解决告警03基于极氪使用的企业微信建设便捷高效的 ChatOps 掌上运维能力 ChatOps 是一种集成了聊天和自动化工具的协作方法和文化，旨在提高团队的协作效率和可见性。ChatOps 的目标是提高工作流程的效率和可见性，并促进团队成员

48、之间的协作和沟通。极氪内部使用企业微信作为办公协同工具，ARMS 智能告警支持对接企业微信，通过创建企业微信机器人，即可在通知策略中指定对应的企业微信群用于接收告警，相关告警信息仅在企业微信的极氪内部企业组织内流转。当通知策略的匹配规则被触发时，系统会自动向指定的企业微信群发送告警通知。企业微信群收到通知后，便可以随时随地在企业微信群中对告警进行管理。源于 ITIL 理念且适用于极氪组织架构和业务属性的事件管理体系 大数据团队目前正在极数 BI 业务推广的数字化稳定性治理机制最核心的部分就是构建一套标准规范的事件管理流程。流程上包含告警发现、告警通报、告警响应/接手、告警定位、指挥决策、告警恢

49、复、故障复盘和持续改进。从人员组织上包括运维团队、告警值班人员、告警处置技术人员、应急指挥人员等。当告警触发接收到通报后，告警值班人员需要迅速建立针对告警关联团队的高效协同渠道，故障应急启动后。技术同学需要尽快完成签到，同时同步进行故障快速止血、根因定位排查、信息同步，如果在预期时间内未接手签到，告警通知将逐步升级。运维团队和应急指挥人员要负责统筹收集相关数据并同步影响面、处理进展和恢复进展，定时播报，更新告警处理情况。当告警以卡片的形式发送到 IM 群聊中，可以通过订正卡片的样式来添加一组操作进行告警的处理。通过 IM 的告警卡片即可便捷进行告警的全生命周期管理：同时为了方便极氪告警值班人员

50、快速知悉告警通告情况，防止群消息过多被忽略，告警通知支持在告警通知群中 指定处理人。通过将告警处理人添加为 ARMS 联系人、通知策略中配置的通知对象和绑定处理人手机号相同即可实现告警通知时根据排班情况 值班人员。2928极氪云原生十大经典案例ARMS 智能管理提供排班管理功能，告警通知可以按照运维人员的值班时间设置告警发送的排班表，再通过通知策略将告警通知以电话、短信、邮件或企微消息的方式发送至对应的值班人员，而不会打扰到非值班时间的运维人员。告警值班人员再根据事件管理标准流程进行告警接手和处置。01排班管理对于长期未解决的告警，可以选择升级通知来提醒值班人员及时解决。在通知策略中添加升级策

51、略后，系统会以指定的通知方式向处理人发送告警信息，以提醒处理人采取必要的问题解决措施。极氪的事件管理流程规定长期未处置的告警需要进行两层升级，一层到业务部门主管，再一层到应急指挥主管。通过这种方式也是为了尽可能提高告警接手率，降低告警处理和恢复时长。03升级策略通过设置通知策略，可以制定针对告警事件的匹配规则。当匹配规则被触发时，系统会以指定的通知方式向通知对象发送告警信息，以提醒通知对象采取必要的问题解决措施。通知策略中可以选择排班表，匹配到通知策略的事件将会按照排班表中的人员进行告警通报。为了保障告警的接手率，防止值班人员遗漏告警，还可以在配置重复通知策略，当告警未恢复时，告警会以设置的重

52、复频率循环发送告警信息直至告警恢复。另外极氪的事件管理流程规定告警必须值班人员干预和接手，哪怕告警已经自动恢复。ARMS 智能告警提供了告警手动恢复的能力，当告警事件在告警集成中设置的自动恢复时间内都没有再触发，告警不会自动恢复，必须人工干预调整状态。满足极氪对值班人员接手率考核和度量的要求。02通知策略灵活、自定义的 ARMS Grafana 应急响应数据大盘 如果没有数据报告和持续运营，那么对现状的了解就会充满了模糊和不确定性，事件管理对整体业务的提升就没法落到实处。客观的数据虽然不能替代沟通和观察，但是通过数据共享和信息的可视化，能够有效的促进共识的达成，大家都能够共同的看到和了解数据变

53、化和现状，促进相互协作。ARMS 智能告警默认提供历史告警总览和告警处理效率两张数据大盘，大盘提供了告警统计、告警趋势、MTTx 指标、人员效率等一系列告警度量数据，这些数据存储在默认的 Prometheus 实例中。极氪则根据自身运维诉求基于原始数据在 ARMS Grafana 服务中配置了自定义的应急响应度量大盘，包括值班状态、告警概览、告警接手情况和 MTTx 指标等，帮助运维团队能够实时了解业务告警状态及应急处置情况，大幅提升了应急响应效率。测试数据大盘示意图四.后续合作的方向和规划极氪全业务推行的数字化稳定性治理正在如火如荼的进行着，整体应急响应效率得到大幅提升的同时，也挖掘了更多的

54、能够进一步提升效率的需求点，阿里云云原生可观测团队将继续跟大数据团队在提升告警规则配置效率和进一步缩短告警恢复时间上深度合作共建。近期 ARMS 智能告警新发布的静态阈值推荐、告警数预测、区间检测和告警规则测试等能力将借助智能化的手段帮助极氪进一步提升告警规则配置效率。同时 ARMS 智能告警新增支持行动集成，提供函数计算 FC 和自定义 Webhook 的行动集成能力，基于行动集成提供的可执行的任务能够作为告警快速止血的预案，对于具有确定性特征的告警，能够提供快速的止血恢复手段，可以有效缩短实际的告警恢复时长。业务系统的稳定性和应急响应效率，是品牌口碑和用户体验的基石，阿里云将坚定不移的为客

55、户提供极致“稳定、安全、性能、成本”的产品和方案，助力客户业务再攀高峰。3130创米数联云原生十大经典案例支撑“千万设备日活”的创米数联 7 年微服务架构演进之路创米数联是小米生态链首批亿元俱乐部成员，主营业务为智能家居产品的研发、设计、生产和销售，致力于成为以居家安全为核心的产品和服务提供商，提供多品类的全屋智能家居产品及服务。公司以居家安全为核心，洞察用户在居住环境下的智能化需求，建立物理安全、环境安全、系统安全三类场景及服务体系，主要产品包括智能摄像机、智慧门、智能猫眼、智能门铃、智能插座等。公司旨在实现“看得见的全屋智能”，以智能家庭安全为切入点，提供多品类覆盖的智能家居解决方案。截至

56、 2021 年 12 月 31 日，创米数联已经在全世界 150 多个国家，销售了超过 5500 万台设备，拥有了 1600 万设备和 500 万设备用户日活。作为小米生态链的一员，创米采用微服务架构支撑其千万日活的 IOT 设备。随着智能家居市场的快速迭代，创米面临着发布和迭代的稳定性挑战，同时需要解决多方 IOT 接入面临的性能和安全挑战。本文将为您一一道来创米是如何应对这些挑战的。从 2019 年伊始，创米数联提出了研发自有 APP 和适配自有 APP 的智能家居设备的发展战略。云服务部将研发重心转向自有 APP 云端业务，并逐步接入自有品牌设备。为了实现全球业务，创米云服务部将相关服务

57、部署在阿里云的 4 个 Region 的 ACK Pro 专有版 Kubernetes 集群上。阿里云 ACK 为创米云提供了可靠稳定的基础设施，向下封装好的数十款云产品，降低了云端运维人员的运维压力，快速对接其他云产品的能力也对开发人员十分友好，能够让创米云服务在极短的时间内搭建一套线上可用的环境。在自有业务研发开始阶段，我们选择了 Spring Cloud、Eureka 和 Apollo 等技术栈来搭建我们的微服务基础架构。然而，经过一年半的摸索，我们发现当前的混合架构存在着不稳定、上线部署风险大以及高人力维护成本等问题。因此，从 2021 年开始，创米云服务决定改变现有的微服务架构，逐步

58、拥抱云原生。我们的目标是在满足稳定性和低维护成本等需求的基础上，实现所有组件的可观测性、全链路的流量治理以及更加便捷高效的 DevOps 流程。首先我们将当前的 Spring Cloud 体系全面转向 Spring Cloud Alibaba，使用 Nacos 替换 Eureka，以解决 Eureka 服务端压力过大的问题，并满足单注册中心多环境分组的需求。由于 Apollo 在某些情况下存在容器磁盘压力大的问题，我们逐步将配置中心从 Apollo 替换为 Nacos。针对之前定制化的 Apollo 配置同步和本地特殊配置缓存，同样我们也对 Nacos 客户端进行了部分定制化改造。初版上线时，

59、考虑到注册中心和配置中心的高可用性、热升级、成本、可观测配套等因素，我们没有选择自建有状态的开源 Nacos 服务，而是直接使用了阿里云 MSE Nacos 专业版服务。至今，该服务一直稳定运行，没有出现可用性问题。云计算时代的蹒跚学步创米云服务从 2016 年创始之初就选择了云计算+微服务的技术路线，以应对面临的大量线上用户和设备带来的流量挑战。构建微服务之初，市面上可选用的解决方案并不多，我们自主实现了一些微服务组件，如 frontend 业务网关和配置中心，并在小米生态云上部署容器服务来处理设备消息、设备插件 API 和微信公众号等相关业务，并利用 HPA 及 CronHPA 等容器弹性

60、伸缩策略来应对动态的海量线上流量。自此创米数联在云计算时代踏上了探索服务容器化的第一步。新业务及新挑战云原生体系探索043332针对全链路的流量治理，由于创米云服务所处的 AIoT 行业不同于传统互联网行业，我们在南北向流量时不仅需要治理下游用户手机端 APP 及 Web 端的 HTTP 请求，还需要处理来自设备端的 MQTT、第三方 AMQP 和 HTTP 2 长连接 Push 消息的流量治理。这些消息通常经由统一的上游消息网关（消息总线）监听，经过多级过滤器，如消息来源、消息限流和产品或特定设备级别的白名单等，对消息进行分类和打标签，然后对消息 Topic 正则路由并进行 HTTP 异步或

61、 rpc 请求。只有经过这些请求后，我们才能对其进行流量治理。因此，创米云服务的流量治理整体较为复杂。我们曾考虑过采用侵入式代码和自定义负载均衡器，并开发控制台来实现高度自定义的流量方案。我们还考虑过使用 Istio Service Mesh 的方案治理流量。然而，前者在当前百万级别设备消息的情况下性能严重受限，后者由于设备消息链路较长、打标较多，导致实现全链路灰度时配置文件实现较为复杂，而且 Envoy 代理无法完整拦截消息总线请求等问题，因此我们否定了这两种方案。之后在选型过程中，我们采用了 MSE 微服务治理。我们传统的 API 业务流量治理选用了多域名、多租户环境、节点隔离加多业务网关

62、的方案配合 MSE 微服务治理来实现多个环境服务的测试开发及线上灰度部署。我们使用多域名加 DNS 流量划分的方式对服务重构后的业务网关新路由进行测试，保证服务重构后的安全上线。我们利用多个 K8s 集群、K8s namespace 以及多个 namespace 的注册配置中心的隔离构建了不同的线上环境，分别用来线上开发、线上测试、灰度以及基线环境部署。对于同一集群不同 namespace 的应用 pod 使用多集群隔离、应用节点亲和性、反亲和性以及节点污点等集群调度手段保证环境的安全性，避免不同环境间出现的资源异常导致基线环境不可用的情况。基线环境和灰度环境同属不同命名空间的相同节点池内，测

63、试和开发环境应用 pod 部署在不同的 K8s 集群或节点池中。我们的整体流程通常是在 feature 及 bug 修复后涉及的服务在开发环境联调完毕，在每次测试流程前将 feature 服务部署至测试环境，通过蓝绿测试将测试人员的流量导向测试环境，在多轮的覆盖及回归测试完成后，将服务部署至灰度环境，再将测试人员及 Beta 测试用户的流量导向灰度环境，经过一定时间的检验后，逐步将线上基线流量导向灰度环境，灰度环境流量完成 100%灰度后，替换基线环境镜像，最后逐步将灰度流量倒流至基线环境。在核心业务接入 MSE 微服务治理之后，创米云服务对部分多云部署及老项目通过 DNS 流量切分+全链路灰

64、度的方式进行灰度，逐渐将自有 APP 及自有设备的所有业务重构迁移至新项目中并全部接入 MSE 微服务，实现了云上 API 业务的 100%安全发布。在设备消息业务的流量治理的推进过程中，为了解决无法拦截消息请求的问题，我们首先将消息总线拆分为控制器和路由器两部分。控制器监听各个通道的消息后仅对消息进行打标签和分类，然后通过异步 HTTP 请求经由统一的路由器转发到各个服务中。我们将路由器服务定义为流量治理的入口，从而解决了消息无法治理的问题。然后，我们使用统一的全链路灰度对打标签后的 HTTP 请求进行蓝绿和灰度的流量治理，并将其分发到指定的命名空间的指定服务中进行消息处理。MSE 微服务治

65、理接入非常简单，只需要在 Helm 或组件中心安装 ack-onepilot 组件，重启服务便可自动注入服务，除此之外 MSE 提供了较为友好的全链路灰度配置界面，较 Istio 方案更加易于配置和上手。通过这样的流程，创米云服务成功实现了设备服务的更新、云云设备的对接以及固件 OTA 版本的迭代过程中的安全发布。创米数联云原生十大经典案例全链路流量治理3534在之前的服务发版部署或 pod 弹性伸缩过程中经常会有部分请求出现超时或不可用的情况，由于创米云服务承载了大量的用户设备请求，这些流量损失轻则导致设备消息重试，严重时会影响部分用户设备的可用性，后续我们了解了 MSE 微服务治理提供了无

66、损上下线及服务预热功能，决定将相关服务全部接入了 MSE 微服务治理的无损上下线，并调整对应服务的就绪检查，在后续的服务上下线过程中经观察再未出现因为流量损失导致的请求不可用的情况，一定程度上避免了由部署发布和服务缩容引起的线上流量损失问题。为了实现可观测性，我们早期就将阿里云 SLS 日志服务集成到自有业务框架中。然而，我们遇到了业务索引不规范、唯一 RequestId 索引异步丢失以及 Spring Cloud Gateway 等 Reactive 框架应用日志异步写入 Location 导致 CPU 占用过高等问题。因此，我们对当前的日志规范进行了改进，并在多个链路追踪方案中选择了 Sk

67、ywalking。我们将 Skywalking 的 TraceId 写入 SLS 日志索引中，并通过对 ThreadLocal 无损上下线解决发布扩缩容流量损失问题无损下线逻辑图新启动 Pod 的预热流量分布可观测体系早些时候由于多云部署的问题，我们并没有统一的全自动 CI/CD 解决方案，为了解决云端 DevOps 构建部署和上线安全性等问题，我们将所有的 Devops 流程开始全面转向阿里云云效。首先，我们将云服务代码从自建的 Gitlab 完全同步到阿里云 CodeUp 代码库中，并将之前的 Gitlab CI/CD 和 Jenkins 的 CI/CD 方案全部迁移到阿里云云效流水线。我

68、们建立了单 Region、多 Region、多云项目的多条流水线，实现了从代码提交、手动或自动触发构建，到自动部署到指定的 K8s 集群和命名空间的全流程。每次构建和部署完成后，我们会发送飞书通知并调用 Newman 自动化测试脚本的 WebHook，根据自动化测试结果报告，评估每次服务版本发布是否满足安全规范。CI/CD 提效对于线上环境稳定性评估，创米云服务选用了混沌工程的方式来检验服务的可用性，创米云服务根据自身业务对 Java 应用 OOM、缓存击穿、网络延迟、K8s Pod 资源、K8s 系统组件、关键云服务等多个维度对自身环境的服务进行全方位的演练排查，并检验可观测性中告警配置的灵

69、敏度。我们在没有造成线上损失的情况下发现并修复了部分漏洞、完善了多 AZ 的云服务资源的建设、调整了未触发告警的配置，使自身架构更加健壮。在一定程度上帮助创米云服务在及时弥补了在 HA 方面不足，并在后续的架构设计中提出了高可用优先的原则。稳定性评估与演练的改造实现了异步线程的日志索引信息传递。我们的服务挂载了 Skywalking Agent，并自定义了可选插件，然后接入了阿里云链路追踪服务。相比自建 ElasticSearch 集群，阿里云链路追踪服务更经济实惠且免维护，链路追踪服务可以直接将项目关联到指定的 SLS logstore 中，更方便进行链路问题排查。在上线的第一个月里，链路追

70、踪服务帮助我们解决了多个项目中的接口性能问题。创米云服务的指标信息的观测主要依赖于 ARMS ACK、ARMS ACK Pro、ARMS 云服务等多个开箱可用的 Grafana Dashboard，它们提供了相当完善的集群、Node、Pod 等多个维度的指标信息，除此之外我们依然会使用阿里云云监控或自定义一些 Grafana Dashboard 用来关注其他部分指标。创米云服务为了快速预警，设置了云产品、SLS 日志、K8s 事件等多个维度的告警配置，对报警进行降噪调优，根据告警等级设置了电话、短信、邮件和飞书群多个通道的报警通知，建立了相当全面的服务告警体系，以便相关人员及时发现问题，避免线

71、上损失。创米数联云原生十大经典案例未来创米云服务将业务网关逐渐转型为云原生网关+WASM 插件方案，代替繁重的 Spring Cloud Gateway 业务网关，进一步提升网关性能、灵活性和可扩展性，并接入现有可观测体系。我们将继续致力于创新和技术升级，为用户提供更优质的产品体验。未来展望3736美洽云原生十大经典案例对比 5 个开源网关项目，这家 SaaS 企业如何统一网关架构美洽作为全球智能云客服服务商，10 年来深耕智能客服领域，旗下拥有在线客服、呼叫中心、客服机器人、工单系统、语音机器人等智能客服系列产品矩阵，覆盖不同行业客户服务场景，致力于帮助企业获客、销售和服务场景的效率提升。目

72、前，美洽全链路产品已经服务超过 40 万家企业客户，覆盖互联网软件、教育培训、医疗、电子商务、金融、生活服务和房地产等行业领域。01需求背景多条业务线使用了了不同编程语言，在微服务化演进的路上困难重重；历史架构使用多个流量转发中间件导致流量路径冗长、复杂且故障排查困难（LB+OpenResty+Nginx+Caddy+SpringCloud-Gateway）；WebSocket 长连接服务在多重路由层上不支持热更新，维护成本高。历史架构的流量拓扑图通过对目前市面上流行的网关产品进行详细的横向对比，再结合美洽对统一网关的需求目标，我们从对比的表格当中，看到了 Higress 所带来的最佳对比结果

73、。同时美洽重点关注的几个点：K8S Ingress 支持、WebSocket 支持、Nacos 服务发现、路由配置热更新、WASM 插件都得到了很好的支持。02需求目标找到一个统一网关，能够一次性解决流量网关和业务网关的路由转发需求；支持路由规则热更新，解决 WebSocket 连接在路由更新或网络抖动时产生的重连风暴；前置 API 请求权限校验、签名校验、WAF 拦截、CC 拦截；可视化统一网关的后台操作，让普通员工也能上手；多云架构下私有化部署支持。方案横向对比 053938美洽云原生十大经典案例简化了流量路径，公网流量通过 SLB 直接到达网关，网关路由直达容器 Pod；释放了使用 EC

74、S 自建的 Nginx、OpenResty、Caddy 服务，降低了大量服务器成本；服务发现和服务治理，以及各个服务当前的健康状态都以可视化的 Dashborad 呈现出来；为什么选择 HigressHigress 在阿里云上有成熟的企业版产品：MSE 云原生网关，我们从 2021 年开始使用这款产品，这是一款全托管，完全免运维的 SaaS 网关产品，并且具备强劲的性能和丰富的功能，相比自建同吞吐的网关，整体成本是更低的，因此我们在阿里云上直接使用了这款产品。美洽除了阿里云，在其他云上也有部署业务，我们希望能统一多云的统一网关技术架构，开源版 Higress 正好符合我们的需求，相比商业版，在

75、控制台功能上，开源版目前的能力相对较少，但大部分功能也都可以通过自己定义 K8s CRD 配置的方式来实现，完全满足我们的需求。面向多云架构友好 01控制面和数据面解耦的架构03美洽从 2021 年便已经全面迁移到 Kubernetes 进行资源调度，遇到最大的困难是历史的网关中间件，在容器化的架构里面，各种水土不服，要么需要借助 Nginx-Ingress-Controller，要么需要外部的 SLB 进行服务之间的负载均衡与网络通信。这导致了比容器化之前更加复杂的流量路径，一度让我们下定决心，必须、必须、必须要解决统一网关的问题，还必须云原生的。2021 年底开始，我们开始尝试使用阿里云

76、MSE 网关 SaaS 产品，开始将部分服务从 Nginx 路由迁移到 MSE 网关上，很快解决了Ngxin Configuration 配置维护复杂，故障频发的问题，尝到甜头后，我们便开始计划进一步扩大 MSE 网关的使用，结合 Nacos 和 K8S 的服务发现，将 80%大部分容器化服务路由转发全部迁移到了云原生网关上。这带来的收益就包括：原生支持 K8s Ingress02Console 负责管理 和 Gateway 负责处理请求,灵活可扩展,互不干扰；整个系统的性能和可用性可以得到很好的保障；即使控制面出现问题，数据面仍然可以继续处理请求，反之亦然。控制面和数据面解耦是一种很好的设计

77、模式，把管理控制逻辑和运行处理逻辑分开，这样可以更好地管理和扩展系统。在美洽客服自己的产品中，也大量使用了控制面和数据面分离的这种架构设计模式，在选择 Higress 统一网关的落地实践中，也更好的可以和美洽产品的架构进行配合，例如控制台采用微前端技术统一美洽运维控制台，Higress 控制台，Nacos 控制台。在早期，美洽在 2021 年开始使用阿里云 MSE 云原生网关时，就已经对网关的控制台使用有了很多的经验基础，团队中 QA 同学也能熟练使用了。目前在其他云上的项目，私有化部署的开源版 Higress，在控制台方面功能与操作和阿里云 MSE 产品的交互保持一致，团队使用很快便上手了。

78、插件方面，美洽使用了 JWT Auth 鉴权，Key Rate Limit 限流，HMAC Auth 请求签名，Bot Detect 和 WAF 功能有涉及。容易上手的后台 Dashboard044140美洽云原生十大经典案例美洽的落地实践美洽的智能客服产品侧使用了 WebSocket 进行长连接保持和消息通信，所以非常依赖网络的稳定，以及更新网关配置所带来的副作用。在使用 Nginx+OpenResty 方案的期间，每一次的配置变更都会带来极大的代价，断线重连风暴时常发生。一次配置变更 Pendding 或者变更失败带来的瞬时断联是极其痛苦的。在迁移到 Higress 上之后，路由配置热更新

79、特性，不再需要像 Nginx 一样需要 Reload Gateway，解决配置更新 reload 带来的断线重连风暴问题。另外，在 WebSocket Server 服务升级过程中，通过给 Pod 打上 stage 标签，在 Higress 侧通过标签路由进行新老版本无损流量切换，给产品快速迭代升级带了巨大的杠杆效应。彻底解决 WebSocket 断线重连问题采用 Helm 在 K8s node 上 一键部署1.helm repo add higress.io 2.helm install higress higress.io/higress-n higress-system-create-n

80、amespace完全替代了 Nginx、OpenResty、Caddy、SLB-Intranet在面向 2B 的 SaaS 产品业务场景中，经常会发生某一个客户突发海量流量，占据大量带宽，影响其他客户正常使用的情况，这时我们需要针对客户规模对单个客户的 API 并发上限做灵活的动态限流，使用 Higress 的插件 Key Rate Limit 就很好的解决了这个问题，根据流量大盘随时调整限流水位红线，做到精准，灵活的限流。熔断限流经验总结统一流量网关+业务网关能力，实现了给企业降本，为研发增效；为云原生架构提供很好的基座，在异构语言服务化层面排除了网络通信难题；路由热更新、无损升级、可视化

81、Console、开放的插件、基于 Kubernetes 和 Istio，给技术演进带来了更多的可能性。Higress 网关的落地，给企业全面落地云原生微服务架构提供强有力的支持，对我们技术人员来说，这绝对是一个杠杆级别的开源产品，另外，在阿里云上又有对等的 SaaS 产品，这样的配合，将公有云和私有化部署的统一网关一次性全部解决，对企业来说是绝对的利好。最后，我们祝愿 Higress 在云原生的道路上越走越远，大家一起用开源、开放、分享的心态将 Higress 建设地越来越好。4342高德云原生十大经典案例阿里云函数计算 FC 助力高德 RTA 广告投放系统架构升级2023 年春节，经历了三年

82、的疫情后，我们终于在春天迎来了曙光。国人的出行热情空前高涨：回家看看父母亲；心心念念的旅行终于可以成行了。按照高德的估计，2023 年春节出行的峰值流量将比 2022 年同期和 2022 年十一都有相当大比例的增长。然而，就在不久前，受疫情的影响，系统的流量还在相对低位运行。如何在短时间内快速完成春节出行的备战准备工作，保障系统在春节流量高峰下平稳运行，让民众出行所必需的导航等信息服务访问可以丝般顺滑，成为了摆在技术人员眼前的迫切事情。要在流量变化很大的情况下保障系统平稳运行，同时做到降本增效，怎么做到呢？过去几年，高德一直在坚定、持续地推进应用的 Serverless 化。经过深入的研究和选

83、型，最终选择阿里云函数计算 FC 作为其应用的 Serverless 计算平台。过去的一年，更是取得了长足的进展。高德在 Serverless 上的远见帮助他们以更加敏捷、经济的方式应对不确定性以及强劲复苏的春节出行：不用费心考虑流量变化带来的资源变化，无需提前按照峰值流量准备大量的计算资源，不用担心资源是否足够，经济成本大幅下降、研发和运维效率明显提升。基于之前的 Serverless 成果，高德相关业务快速完成了春节出行备战准备工作，春节保障顺畅完成。我们一起来看一个典型的案例：在 2022 年阿里云函数计算 FC 是如何助力高德 RTA 广告投放系统实现架构升级的。RTA 是一种实时的广

84、告程序接口，通过发挥媒体与广告主双方的数据、模型能力，实现实时的广告优选；RTA 是一种接口技术，更是一种策略导向的投放能力。广告媒体通过高德的 RTA 接口，来询问是否要投广告，RTA 的服务通过查询高德自己的人群信息，返回投放结果。这样媒体投放广告可以更精准。什么是 RTA一.业务背景原系统服务器占用较多，依赖链路较长，每次扩容，依赖服务也需相应扩容，造成资源占用较多。原系统的架构&问题人群命中功能，本质可以归结为检索某个元素是否在一个集合中的问题。这类问题，业界常用 bloom filter 进行解决。bloom filter 的本质是一组 hash 算法和 bitmap 的组合。优点是

85、查询效率高，占用空间小。Redis 扩展版提供了 bf(bloom filter)功能。由于读取是用 golang，写入是用 Java 的写入，为了避免跨语言带来的库不一致，可能存在的 bloom filter 不同实现导致的命中不一致的问题，可以采用 Redis 扩展版的 bf(bloom filter)功能，在 Redis 服务端实现 bf 功能，保证不同语言调用的数据一致性。借助 Redis 来实现人群命中功能，就可以去掉算法网关，数据中台侧的很多资源也可以因此节省下来。人群命中功能目前圈人平台的数据更新有 4 种类型：在线、实时、离线单次、离线周期。目前的圈人策略都是基于离线人群进行圈

86、定。后续虽然有可能使用在线和实时的情况，不过由于 RTA 广告圈定的人群一般较大，实时人群的变化的比例较低，且媒体端均有缓存，实数据同步二.技术选型0102064544高德云原生十大经典案例时性要求不高。使用实时，在线人群和离线人群的效果区别不大，所以目前建议只使用离线人群作为主要圈人手段，如果对实时性要求较高，可以考虑离线周期为小时维度的更新(本质上实时性取决于 UDF 更新频率和触发方式)。综合考虑离线周期更新 Redis 的方式。通过重新划分应用和平台的界面，Serverless 使得业务可以专注自身业务逻辑，人人都可以快速开发出一个稳定、安全、弹性、可扩展的分布式应用成为可能。新的技术

87、选型里，引擎服务需要访问 Redis。这是一个有着高频存储访问的系统如何 Serverless 化的问题。一般认为 Serverless 就是 FaaS+BaaS。FaaS：Function as a Service，函数即服务，一般是各种后端微服务。BaaS：Backend as a Service，就是不适合以 FaaS 形态存在的后端服务，比如存储服务。Serverless 化的系统架构对云存储提出很高的要求，在可扩展性、延迟和 IOPS 方面，云存储需要能够实现与应用同等/接近的自动扩缩容能力。阿里云提供 Redis 企业版服务，集群架构版本提供多种实例规格，支持最高 2G 总带宽，6

88、000 万的 QPS。支持调整实例的架构、规格等，以满足不同的性能和容量需求。可实现无感扩缩容。可以满足引擎服务 Serverless 化之后对存储的要求。而 FaaS 是目前后端微服务 Serverless 化最常见的技术选型。阿里云函数计算 FC 是 Forrester 测评认定的全球领先的函数计算产品，在公有云和集团内都积累了丰富的应用 Serverless 化经验，是合适的选择。Serverless 化为什么要 Serverless 化如何实现 Serverless 化03RTA 广告投放系统作为为外部媒体提供相关服务的系统，具有大流量，延迟要求高的特点，是典型的高性能要求场景。这样的

89、场景里，客户端设置的超时时间一般都很短，一旦超时，接口调用就会失败。采用 Serverless 的架构之后，请求的流量会先打入阿里云函数计算 FC 的系统，然后转发到函数实例进行处理。在这个场景里，要求函数计算 FC 的多租户、大流量的情况下，将请求处理的系统耗时（不包括函数自身执行时间）的平均值、P99 值控制在很低的水平，才能保证请求成功率 SLA 的要求。高性能要求新架构里，中台生成人群后，调用 Redis 的 BF.INSERT 等指令，生成 bf。引擎侧拿到设备 ID 后，通过 Redis 的 BF.EXISTS 指令，判断是否在对应的人群中。系统架构特点：前面我们提到高德 RTA

90、广告投放系统具有流量大，延迟要求高的特点，是典型的高性能要求场景。而阿里云函数计算 FC 是一个典型的多租系统，一个集群内不单单有高德 RTA 广告投放函数，还有非常多其它业务的函数。对函数计算 FC 的请求调度提出非常高要求：请求调度三.落地方案040102去除网关，减少链路长度设置缓存，离线系统和在线系统解耦，提升性能数据压缩，减少内存占用系统 Serverless 化，实现实时弹性和免运维，加快应用迭代速度单函数 QPS 无上限，大量长尾函数不消耗资源调度服务要保证高可用，单点故障对服务无影响请求处理所需的系统耗时要控制在平均值小于 2ms，P99 值小于 10ms4746高德云原生十大

91、经典案例我们来看看函数计算 FC 是怎么做到的。为了实现实时弹性，当函数的请求到达函数计算 FC 的前端机之后，前端机会找调度节点（Partitionworker）要一个处理请求的实例，并将请求转发给它。调度节点接收到请求之后，如果有实例可用，则根据负载均衡策略获取一个实例并返回给前端机；如果没有，则实时创建一个，并返回给前端机。实例的创建时间可以达到百毫秒级别。我们看到一个请求需要通过前端机和调度节点的处理之后，才转发给具体的函数实例。因此请求处理的系统耗时包括前端机的处理时间、调度节点的处理时间、前端机和调度节点的通信时间以及前端机和函数实例的通信时间，过去一年，我们对函数计算 FC 的前

92、端机、调度系统针对性的做了很多的优化，保证了系统在超大流量的情况下，请求处理的请求处理所需的系统耗时要控制在平均值小于 2ms，P99 值小于 10ms。为了保证高可用和横向可扩展，调度节点采用分区架构同一个用户/函数的请求映射在连续的分片区域内单函数请求可跨越多个分片，横向扩展调度节点（Partitionworker）通过心跳向分片管理器（Partitionmaster）汇报分片和节点状态Partition master 通过移动/分裂/合并分片进行负载均衡调度 100 万函数，单函数最大峰值 20 万 TPS，调度延时小于 1ms任何节点故障，请求会被路由到其他 Partitionwork

93、er 上，对可用性无影响Serverless 的场景下，业务不再需要关心资源的管理了，平台负责资源的管理和调度。业务流量上涨了，平台需要有能力快速刚性交付业务需要的计算资源；而当流量下降之后，平台需要将空闲的资源自动释放掉。为了保证包括高德 RTA 广告投放函数在内的函数的资源刚性交付，阿里云函数计算 FC 持续优化了资源管理的实现。资源交付03一开始，阿里云函数计算 FC 采用 Docker 容器的形式来交付函数计算实例。因为 Docker 存在容器逃逸存等这样的安全问题，为了保证安全性，一台宿主机只会部署一个租户的函数。由于函数计算 FC 存在大量的长尾函数，函数实例的规格也往往比较小，比

94、如只有 128M/0.1 核，这限制了资源利用率的提升。为了解决这个问题，阿里云函数计算 FC 和相关团队合作，将资源底座全面升级到神龙裸金属+安全容器，借助神龙裸金属软硬一体化技术带来的虚拟化效率提升和安全容器安全性保障后实现的多租户高密混部，大幅提升了资源的利用率。Serverless 新底座：神龙裸金属+安全容器由于 K8s 集群的 Pod 产出效率很难满足 Serverless 每分钟几万个实例的创建需求，所以函数计算 FC 与相关团队合作，实现了 Pod 内的计算资源的进一步细分，由函数计算 FC 直接对 Pod 里面的容器进行管控，从而实现了高密部署，以及高频创建的能力。独立的资源

95、管控相比较 K8s 分钟级以上的资源交付速度要求，Serverless 的场景需要将资源的交付速度提升到秒级、毫秒级。为了解决 K8s 基础设施启动耗时和函数计算 FC 对极致弹性强烈诉求之间的矛盾，阿里云函数计算 FC 实现了 Pod 资源池化、镜像加速、镜像预热、计算实例 Recycle 等等技术，保证了极速的资源交付速度。毫秒级资源交付速度为了实现高可用，阿里云函数计算 FC 的资源在每个 region 不止分布在一个 K8s 集群，而是多个 K8s 集群，做到了任何一个 K8s 集群出现问题，会自动地切换到正常集群的能力。每个集群都有多种资源池类型：独占资源池、混跑资源池和可抢占资源池

96、。函数计算 FC 根据业务的特点，进行统一调度，从而把成本进一步的降低。高可用4948高德云原生十大经典案例下图展示了在一个调用量快速增长的场景下函数计算 FC 的流控行为：以上参数为可调整。突增实例数：可立即创建的实例数（默认 300）；实例增长速度：超过突增实例数后每分钟可增加的实例数（默认每分钟 300）。在资源的交付总量方面，目前阿里云函数计算 FC 已经有了单函数交付几万个实例的案例，由于函数计算 FC 有资源池池化动态补充的能力，理论上，函数计算 FC 单函数可以交付的实例数远不止几万个实例。在资源的交付速度方面，函数计算 FC 可以做到百毫秒级别的实例创建速度。遇到 burst

97、的情况，函数计算 FC 从以下两个维度来控制资源交付速度：交付 SLA系统采用三单元部署，保证外部媒体都可以就近访问，降低网络时延。多机房部署04系统架构升级后，节省了几千核的机器资源，实现了全面 Serverless 化，调用链路变短了，系统变得更加弹性、健壮和易于维护，取得了很好的业务效果。四.业务效果在过去的 2022 年，高德在 Serverless 领域中已经取得了长足的进展，然而这不是终点，而只是刚刚开始，后续阿里云函数计算 FC 会和高德一起推进应用的全面 Serverless 化，期望帮助高德在更多的场景去使用 Serverless，吃透 Serverless 给带来的技术红利

98、！五.展望5150Tim Hortons云原生十大经典案例轻松构建全栈观测，从容应对咖啡产业竞争1964 年，Tim Hortons 咖啡馆诞生于多伦多的宁静小镇汉密尔顿，由传奇冰球运动员 Tim Horton 先生创立。经过近 60 年的发展，Tim Hortons 已成为全球著名咖啡连锁品牌。在英国权威品牌评估机构 Brand Finance 发布的“全球最有价值的 25 个餐厅品牌”排行榜中，Tim Hortons 连续多年入围。2019 年，Tim Hortons 来到中国上海开出首家门店，并于 2023 年宣布使用中文名“天好咖啡”。秉承着创始人的初心“欢迎任何人随时来到 Tims

99、咖啡馆，享受家一般的感觉”，Tims 天好咖啡坚持为顾客提供独特的价值：将新鲜、高质量的本地化食品和饮品相结合，以适宜的价格为顾客提供暖心的体验。截至 2023 年 7 月，Tims 天好中国全国门店数达到 700+家，已经覆盖了 40+个城市,并计划在年底前突破 1000 家门店。凭借“咖啡+暖食”的差异化竞争策略，Tims 天好咖啡将全球品牌力与本土创新加速融合，逐渐走通了一条独有的可持续增长路径。为了进一步强化 Tims 天好咖啡差异化并支持中国市场的快速增长，自 2021 年起 Tims 天好咖啡全面加速推进数智战略。但由于 Tims 天好咖啡部分早期业务系统由外部服务商提供且架构老旧

100、难以维护，无法满足 Tims 天好咖啡线上业务高速增长所带来的高并发、弹性扩展、敏捷性等要求。为了满足中国越发蓬勃的用户需求与业务增长需要，针对用户交易、门店管理、餐饮制作等核心链路服务，Tims 天好咖啡选择全面自研与云原生化，即全面容器化、微服务化。2021 年，Tims 天好咖啡开始落地容器化，这为 Tims 天好咖啡带来了诸多运维红利。首先，应用部署变得更加高效，借助 K8s 的标准化能力使 CI/CD 变得便捷，整体发布效率大幅提升。其次，部署在容器上的应用天然具备弹性扩缩容能力，更加从容的应对每日餐食时段的流量洪峰。最后，采用容器化的服务按需使用资源，相比原先按照峰值长期固定保有大

101、量冗余资源，有效压降服务器成本。相比过往繁琐的运维流程与人员技能门槛，阿里云容器服务 ACK 的标准化界面很好的解决了容器的高密部署以及系统运维问题，极大的降低了人工运维和资源成本。为了更好的满足快速迭代、稳定发布诉求，2022 年 Tims 天好咖啡对已有业务系统开始尝一.云原生化带来的技术红利但随着容器化、微服务化逐渐深入，云原生化带来的运维挑战与痛点驱动 Tims 天好咖啡运维团队构建更加精细与完整的运维可观测能力：二.云原生带来的可观测挑战试微服务化，采用了以 Dubbo 为核心的微服务技术架构。微服务架构将应用分解的同时，规避了原本复杂度无止境的积累。每个微服务模块专注于单一功能，保

102、持高可维护性并提高了开发效率。与此同时，由于微服务具备独立运行进程，每个微服务模块都可以独立部署。当某个微服务发生变更时，无需编译、部署整个应用。使得发布更加高效，缩短应用交付周期。作为拥有海量客户的餐饮品牌，Tims 天好咖啡的交易链路核心服务需要保证在营业时间内业务系统的连续性与可用性要求非常严苛。在面临每日高峰订餐时间、新品发布、营销活动、突发热点事件等情况时，系统需要在高并发大流量下保证服务可用和用户体验顺畅。但随着微服务数量逐步增多，链路越来越长，故障定位变得愈发漫长与困难。如果不能快速且精准的进行故障定位，那么故障定位效率低下带来的服务不可用造成的业务损失，可能大于微服务架构本身带

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

104、动：如何保障业务可用性？01075352Tim Hortons云原生十大经典案例应用研发是一项由团队共同参与、需要兼顾多方需求的复杂工作。为了更快、更及时地交付符合生产环境质量要求的服务，过去 Tims 天好咖啡大多采用 Code review 形式对代码质量进行评估。但随着研发协作规模不断扩大，这种评估形式效率达到瓶颈，质量与效率难以有效保障。随着团队规模、业务规模不断提升，团队需要对研发过程进行回顾，从效率、质量、交付速度、稳定性、可预估性等多角度进行抽象，并进行量化评估及巡检。研发效能驱动：全面提升研发效能与代码质量02随着业务规模愈发增大，为了提供更稳健的服务与更优质的用户体验，Tim

105、s 天好咖啡计划建立内部巡检机制，主动对 IT 运行风险的评估发现，并围绕业务连续性保障相关的重要系统性能&容量&质量管理展开，打造先于用户、业务发现问题、分析问题、定位问题的运维巡检闭环，做到技术驱动用户体验与业务优化。构建运维巡检机制：先于客户发现问题03在云原生改造开始前，由于各个服务系统相对简单，Tims 天好咖啡通过自建 Zabbix 来进行指标监控，但 Zabbix 更擅长硬件、系统、网络设备等基础监控。随着云原生化，Zabbix 无法再满足更加丰富的可观测需求。Tims 天好咖啡结合现有云原生架构与以上三个可观测核心痛点，清晰梳理出两个核心思路：针对运行态，从前台业务数据、用户体

106、验，到后台应用服务性能，再到云服务及基础资源，即系统资源层、云服务应用层、业务监控层，构建全链路可观测体系，及时发现、定位、解决影响业务与用户体验的故障与瓶颈。避免“自下而上”产生的后台问题，浪费团队时间与精力。同时，借助链路、日志、指标等不同类型指标的融合，提升预警的及时性与准确性，并有效提升故障排查效率。围绕业务增长规划全链路可观测体系01作为领先的技术团队，Tims 天好咖啡将 DevOps 理念与流程引入日常研发流程中，并希望将可观测应用于业务运行态与研发态，从而形成全研发生命周期的观测体系。尤其是系统经过云原生改造后，Tims 天好咖啡希望借助可观测工具更直观高效的评估代码质量，为提

107、高研发效率、需求评估抽象出可衡量的目标。可观测驱动研发效能提升02三.解决方案落地目前 Tims 天好咖啡的服务载体客户端主要是支付宝小程序、微信小程序，针对 Tims 天好咖啡业务形态，由于海量用户使用不同操作系统、不同屏幕分辨率的终端设备，分布在不同地域，又通过不同网络运营商进行接入，甚至存在复杂第三方依赖，包括 CDN、第三方统计脚本、页面嵌套等方面。当用户体验遇到问题时，如果仅拥有服务端监控手段，很难第一时间确认问题的根源到底在于前端还是后端。即便能够排除服务端的问题，前端用户体验也受到页面渲染、JavaScript 执行、网络质量、第三方接口服务质量等方面的影响，为进一步排查问题留下

108、了非常多的挑战。因此，Tims 天好咖啡采用应用实时监控服务 ARMS-前端监控，实时掌握 PV/UV、首次渲染耗时等基础性能指标的同时，及时了解 JS 错误数、API 请求错误等影响用户体验的异常数据。从页面打开速度、页面稳定性和外部服务调用成功率这三个方面监测小程序健康度，帮助使用者降低页面加载时间、减少 JS 错误，有效提升用户体验。5554Tim Hortons云原生十大经典案例与此同时，利用应用实时监控服务 ARMS-应用监控，快速了解应用最关键的响应时间，吞吐量，错误率这黄金三指标，同时根据指标的异常利用调用链能力对整个微服务进行快速跟踪。结合 ARMS 前端监控与应用监控，Tim

109、s 天好咖啡轻松构建前后端全链路追踪能力，将前端 API 请求从前端发出到后端调用链路完整串联，真实还原代码执行的完整现场。运维团队在故障发现时能够更快速的进行故障定位与根因分析。针对容器及中间件云服务，Tims 天好咖啡选择使用 Prometheus+Grafana 的方案进行构建指标监控体系，并形成统一的可观测大屏。通过阿里云可观测监控 Prometheus 版获取了 ARMS 应用监控、云产品监控等指标数据源，结合业务需求与对象赋予各类业务标签，通过可观测可视化 Grafana 版为各个应用搭建完整可观测视图。在建立可观测体系过程中，能够更早发现问题并提示的告警体系是非常重要的环节，Ti

110、ms 天好咖啡采用静态阈值+ARMS Insight结合的方案进行日常告警配置。ARMS Insight 借助 ARMS 算法自动判断异常产生故障告警，并基于阿里云多年诊断经验与方案为这些告警故障生成相关诊断报告，目前已覆盖响应时间飙升、错误飙升等 6 大类不同场景，能自动判别、归因近百种不同问题根因，大幅提升常见问题诊断效率，缩短业务恢复时长。同时，对于 Tims 天好咖啡的核心业务场景和服务接口，Tims 天好咖啡根据业务实践设置各类静态阈值进行兜底，保证告警完整性和及时性。“如果监控解决的是及时知晓服务故障，那么可观测的落地最终目的是挖掘故障或异常的本质，分析根因并反哺业务增长与技术体系

111、迭代。”整个咖啡行业都在尝试数字化，可以看到作为其中优秀代表的 Tims 天好咖啡，正以惊人速度在中国市场扩张。借助以可观测为代表的阿里云云原生产品解决方案，Tims 天好咖啡更加从容的面对门店、交易数量、会员数量的急速增长，在愈发激烈的市场竞争中始终保持竞争优势。5756杭州亚运云原生十大经典案例高光回眸：阿里云容器服务如何全面助力精彩亚运2023 年，第 19 届杭州亚运会在杭州成功举办。在亚运之光和科技之光的交相辉映下，这届亚运会成为亚运史上首届“云上亚运”，用云计算创造了历史，赛事核心系统和转播全面上云，为大型赛事的数字化普及奠定了坚实基础，杭州亚运会乘着科技的翅膀取得圆满成功。在这次

112、赛事的多个核心项目中，阿里云原生技术发挥了重要的支撑作用，如容器服务 Kubernetes 版 ACK、容器镜像服务 ACR 等通过高效稳定、极致弹性、安全智能等能力的输出，再次推动国际体育赛事以云原生的方式加速向数字化演进发展。容器服务 Kubernetes 版 ACK 整合了阿里云的虚拟化、存储、网络和安全能力，提供高性能且可伸缩的容器应用管理能力，支持企业级容器化应用的全生命周期管理，助力企业高效运行云端 Kubernetes 容器化应用。阿里云容器服务 ACK 在 2023 年成为 Gartner 容器管理魔力象限报告中亚洲唯一的全球领导者，2022 年成为国内唯一进入 Forrest

113、er 领导者象限的产品。容器镜像服务 ACR 作为云原生领域重要的制品资产管理平台，为企业提供云原生制品安全托管与高效分发能力，加速企业的云原生化迭代创新。正如体育精神体现出的进步与超越一样，阿里云容器服务也在不断向极致的能力发起挑战。在这次亚洲瞩目的体育盛会服务保障中，容器服务专业版 ACK Pro，容器镜像服务企业版 ACR EE，都凭借出色的发挥，为更多上层的项目应用构建和运行提供强大的能力基座，更向世界证明了来自中国的云原生基石能力。下面让我们一起回顾阿里云云原生容器服务 ACK 和 ACR 是如何助力精彩亚运的。赛会期间，杭州亚运会赛事信息系统 AGIS 扮演了非常核心的作用，具体包

114、括赛事管理系统（GMS）、成绩发布系统（RDS）和赛事支持系统（GSS），支撑 56 个竞赛场馆及信息技术指挥中心、主媒体中心及亚运村等重要设施的全天候运营，服务超过 10 万名注册用户，包括来自全球 45 个国家和地区的运动员、转播商、记者、工作人员及志愿者。以赛事成绩发布系统为例，它是亚运会赛事期间最重要的信息系统群之一。每一场赛事结束，在赛事成绩发布类系统群的调度下，比赛成绩从场馆的计时记分设备导入场馆成绩系统、向中央成绩系统汇集，以打印分发、信息发布、数据接口等不同模式向外界呈现。如此核心的系统需要系统具有极高的稳定性和高可用性，不容任何差错。凭借 ACK 稳如磐石的稳定性，赛事管理系

115、统和成绩发布系统，均以 ACK 为云原生底座，构建了跨 AZ 高可用的多个 ACK 集群，构建了 DMZ/Trusted 隔离的架构（DMZ/Trusted 架构是一种网络安全架构设计，用于保护企业内部网络与外部网络之间的通信）。ACR 稳定支持赛事信息系统、浙江政务云云平台在亚运期间提供应用部署丝滑体验。赛事期间在云原生领域报障数为 0。2023 年 7 月，ACK 成为首批通过中国信通院“云服务稳定运行能力-容器集群稳定性”评估的产品，并荣获“先进级”认证。这是对 ACK 稳定性的高度认可。一.稳如磐石，为赛事核心系统保驾护航ACK 稳定性源于大规模实践经验沉淀：ACK 全网管理了数万个

116、K8s 集群，对线上丰富的客户和业务场景提供全面的支持。ACK 与 ACR 作为底座承载了历届阿里双十一、618 等超大规模的电商业务，具有丰富的阿里电商场景的极限压力锤炼经验。对社区原生 K8s 做参数、性能、架构等优化，并形成产品能力和稳定性功能。ACR EE 产品集成全链路高可用、DevSecOps 安全交付链能力，稳定支撑月均镜像拉取数十亿次，服务数千家企业级客户在生产环境深度使用。085958杭州亚运云原生十大经典案例杭州第 19 届亚运会组委会推出的国际大型综合性运动会史上首个一站式数字观赛服务平台，通过运用区块链、大数据、人工智能等高新技术，对接数字城市各类资源，整合亚运城市各类

117、场景应用，杭州亚组委围绕“食、住、行、游、购、娱”六个方面需求，结合票务功能，为观众提供从购票、出行、观赛到住宿、用餐和旅游等一站式服务。亚运一站通累计用户 1.19 亿，日均访问人次超过 1 亿，累计访问人次超过 60 亿。部分关键应用包括：亚运一站通的后台服务正是基于 ACK 集群构建，在赛会全程安全、稳定、可靠，顺利完成保障亚运服务精彩、高效运行的任务。在高可用方面，亚运一站通依托于 ACK 云原生底座和高可用产品功能，实现了同城高可用、异地灾备、数据同步的高可用架构，真正实现两地多中心金融级容灾架构。亚运一站通基于 ACR EE 提供的异地容灾最佳实践，实现业务镜像跨地域高可用，进一步

118、提升容器镜像抵抗未知潜在风险的容灾能力。在快速弹性方面，亚运一站通是面向 C 端的应用，在开幕式/闭幕式/薪火相传/售票等场景，需要有高效稳定的快速弹性能力保障。亚运一站通采取集群内弹性和集群外弹性相结合的弹性策略：二.极致弹性、极致高可用，保障亚运一站通亚运 PASS集群内弹性：“亚运 PASS”整合景区入园、文博场馆预约、公共交通出行等各类应用场景，为游客提供“一码通行”的便捷服务。弹性技术手段依赖 HPA 方案，快速自适应扩容缩容 Pod。赛事查询线上火炬传递赛事查询整合赛事日程、竞赛项目、亚运场馆等信息，为用户提供比赛成绩展示、亚运奖牌榜、亚运场馆查询等赛事一体化服务。在杭州亚运会倒计

119、时 100 天之际，智能亚运一站通全新升级，开展“线上火炬传递”，全球网民身着亚运数字火炬手服装，手持亚运会数字火炬，聚力亚运取火，将亚运之火传遍亚洲 45 个国家与地区，深化亚洲多元文明交流互鉴。亚运一站通作为国际大型综合性运动会史上首个一站式数字观赛服务平台，为今后的赛事举办树立了标杆作用，ACK 与 ACR 有幸参加遇到这一历史活动中，并充分证明了高可用、弹性等灵活、丰富的产品能力。智能化底座支撑了亚运会的多种智能化服务，其中，“亚运钉”是杭州亚组委和钉钉联合打造的全球首个大型体育赛事一体化智能办赛平台，为十万赛事工作人员提供服务。三.Serverless，让“一部手机掌上办赛”成为现实

120、集群外弹性：集群内部资源弹性耗尽之后，将开始外部弹性，方案包括弹节点和弹 ECI 容器。利用阿里云资源快速弹性 ECI Pod，可实现分钟级创建万量级 Pod 的能力。通过配置 ECI Pod 拉取 ACR 镜像缓存，实现 ECI Pod 秒级启动。集群通过安装 ACR EE 按需加载、P2P 分发套件，解决集群大规模应用部署时出现的流量洪峰问题，享受极致的弹性体验。6160杭州亚运阿里影业云原生十大经典案例在本次杭州亚运前，阿里云容器服务产品家族已积累了丰富的大型体育赛事应用场景和案例沉淀，例如在 2020 年东京夏季奥运会、2022 年北京冬季奥运会等均为核心系统的云原生底座。本次亚运会中

121、，阿里云 ACK 和 ACR 再次深度参与到赛事项目和活动中，稳如磐石地承担了亚运信息系统 AGIS、亚运一站通、亚运钉等核心项目，为体育赛会带来了业界领先的云原生技术、产品和服务，与阿里云各个产品线通力协作顺利完成了亚运会的支持和保障工作。未来，阿里云 ACK 和 ACR 也会在即将举办的巴黎奥运会中提供服务保障，我们将持续构建安全、稳定、性能、成本持续优化的云原生技术能力和稳如磐石的服务品质，促进阿里云的科技之光与五环之光交相辉映，帮助全球更多行业、企业加化数字化转型进程。四.展望亚运钉接入了行政审批、气象服务、会议服务、医疗服务等各业务领域的 293 个应用，并接入阿里云上的多种亚运核心

122、系统应用，包括竞赛视频系统、IT 事件跟踪与管理系统、志愿者管理系统等等；工作人员和志愿者近 10 万人使用，每日消息量超过 25 万条，每日视频会议数超过 5000 次。亚运期间，近十万工作人员通过亚运钉实现了在线扁平化沟通协同。此外，亚运钉还能支持汉英日泰等 13 种语言的实时翻译，方便不同国家工作人员的相互交流。作为统一的业务协同平台，亚运钉接入了行政审批、气象服务、会议服务、医疗服务等各业务领域的 293 个应用，并接入阿里云上的多种亚运核心系统应用，包括竞赛视频系统、IT 事件跟踪与管理系统、志愿者管理系统等等。同时，亚运钉采用宜搭低代码开发新应用，高效便捷地满足亚运在筹办和运行阶段

123、所出现的新业务流程。不仅如此，亚运钉还解决了亚运会的知识资产沉淀问题，为解决赛事文件收集、厘清繁多的数字资产、实现数字资产沉淀提供支持，既能保障赛事的顺利举办，也能为后续举办亚运、奥运等大型体育赛事提供经验参考。如此丰富的功能，均依托于 ACK Serverless 形态部署。对 Serverless Container 的支持是 K8s 演进的重要方向，基于弹性容器实例 ECI 的 ACK Serverless 在客户场景中得到了广泛的应用，如在微博热搜、钉钉会议等大家熟悉的在线应用中发挥极致弹性伸缩能力，更在助力越来越多 AI 和大数据客户降本增效。在亚运钉系统应用发布方面，ACR EE

124、全球同步能力助力亚运钉高质量、高效率地交付业务应用，实现全链路云原生应用发布。通过将 ACR EE 全球同步能力与亚运钉自建 CI/CD 工具深度结合，亚运钉平台实现了本地一次构建，全球多个地域应用镜像自动分发，进而打通全球各业务地域发布系统的发版流程，极大地提升了亚运钉系统应用交付速率。容灾切换时间减少 99%，“云边协同”如何提升影演服务效率与稳定性沉寂三年后，线下演出市场正在迎来“报复性”复苏。对于一场期待已久的演唱会，验票环节是否流畅、能否快速入场，直接影响着每一位观众对整场演出服务的体验和评价，相信不少朋友都有着切身的感受。阿里巴巴影业集团是以互联网为核心驱动的影视实业公司，拥有内容

125、生产制作、互联网宣传发行、衍生品授权及综合开发、院线票务管理及数据服务的全产业链娱乐平台，是阿里巴巴文化娱乐集团重要的垂直业务纵队。阿里影业一直在通过技术与架构的创新，引领行业全链路向数字化和智慧化变革。行业流量爆发增长的同时，影演场景也在不断得到延伸和丰富。在此背景下，为了应对演出现场服务效率、系统稳定性、高可用性压力带来的严苛考验，阿里影业基于阿里云边缘容器服务 ACKEdge 实现了一套面向影演现场服务场景的云边端一体混合云架构，通过对海量异构设备接入的支持，以及高可用、高稳定性、可扩展等性能提升，来满足未来高时延敏感实操消息上下行和业务快速发展需求。值得一提的是，这是演出行业首例实现云

126、边端一体、云端服务与边缘集群云原生协同的落地实践，并于 2023 年 6 月获得中国信通院“可信边缘最佳实践案例”。096362阿里影业云原生十大经典案例云边协同便捷：随着云计算、边缘计算和物联网等技术的快速发展，对于协同工作的需求也在不断增长。云边协同可以充分利用这些先进技术，为用户提供更高效、便捷的协同体验。高效数据处理：低时延：大幅降本：数据已成为企业和组织最重要的资产之一。伴随电影演出数据量呈现爆炸式增长，这使得对数据的存储、处理和分析需求也随之增。云边协同可以帮助用户更好地管理和利用这些数据资源，云边协同可以跨越地域和时区的限制，提高工作效率。在电影演出现场，对数据处理和反馈的实时性

127、要求非常高。云边协同可以通过边缘计算技术，实现数据在本地设备的快速处理，降低延迟，满足实时性需求。云边协同可以在本地设备上进行部分数据处理，减少数据在网络中的传输量，从而降低网络带宽需求和通信成本，同时更合理地利用机器资源，降低硬件投入成本以及硬件运输成本。阿里影业线下演出场景的服务人群主要分为三类，消费者、主办方以及监管方。对于监管方要满足安全、稳定的要求；对于消费者要保证核验准确、进场快速；对于主办方，除了以上几点，还需要尽量降低成本。服务系统管理平台作为阿里影业的核心业务系统，在不同演出场地的基础网络设施参差不齐的条件下，结合现场人流量呈现短时并发增长的特性，业务系统对高度敏感的网络资源

128、需求依赖较大，导致业务健壮性无法保证。在演出现场服务规模高速发展的现状下，已经出现严重的边端业务发展瓶颈，如多边端项目规则无法协同配置，多演出现场无法统一监控管理，海量异构设备无法统一运维调度，传统云到端以及端到端架构现状无法继续满足实际边端场景需求，需要面向海量异构设备接入的高可用、高稳定性、可扩展的云边端一体的混合云架构，解决现有瓶颈与未来扩展问题：一.人流大、环境复杂，影演现场服务挑战催生云边协同诉求二.阿里影业基于 ACKEdge 的云边协同 IoT 架构实践阿里影业边缘 IoT 服务系统使用云边端协同的架构，是针对现场换验业务场景的一种解决方案。整体思路主要以云控边、边自治、端智能为

129、核心思想，以实现云边协同、多元化的方式为现场提供高可用、高性能、高扩展的现场服务。ACKEdge 是阿里云容器服务针对边缘计算场景推出的云边一体化协同托管方案.面向大规模边缘计算场景，ACKEdge 拥有经中国信通院认证的“卓越级节点管理”产品能力，采用原生 Kubernetes 非侵入方式增强方式支持边缘计算场景下的应用统一生命周期管理和统一资源调度，帮助企业专注于容器化应用的开发与管理。图 1：阿里云边缘容器服务 ACK在整体架构上采用云边端一体化协同托管方案，将云计算的能力下沉到边缘侧、设备侧，重点提供存储、网络、安全、监控、日志等能力；在集群管理方面，APIserver 和调度器内置了

130、大量性能优化；在云边网络方面，通过对网络插件 Flannel 优化大幅度降低云边流量开销；此外，考虑到边缘资源的异构性、地域性以及网络的复杂性等特点，ACKEdge 提供了异构资源管理、边缘自治、边缘单元化、边缘流量管理、轻量化、原生运维 API 支持等，以原生方式支持边缘计算场景下的应用统一生命周期管理和统一资源调度，保障边缘业务稳定性。ACKEdge 目前已经广泛应用于 CDN、实时音视频云服务、在线教育、交通、智慧城市、智慧工业、IoT、物流、水利、能源、农业等场景。6564阿里影业云原生十大经典案例图 2：阿里影业云边协同解决方案整体架构阿里影业的现场换验云边端协同架构使用 ACKEd

131、ge 作为底层云原生边缘基础设施调度的托管底座，利用 ACKEdge 提供的边缘自治、边缘管理、服务运维等能力来支撑云控边、边自治的设计原则。在实际业务场景中，现场的边缘服务器是分散在各个现场的并且是不固定的，通常需要在边缘服务器出厂时，便将边缘节点添加到 ACK&Edge 的 master 节点上，再通过云上自建设备监控平台进行业务部署、运维管控等操作。利用 ACK&Edge 的边缘自治能力保证现场节点在极端弱网、无网的情况下服务正常启动，提供现场需要的换票、验票等能力，以便现场能够保证正常地进行验票、换票等操作，此外，通过 ACK&Edge 的可观测能力，对现场服务节点进行监控、告警等以提

132、升现场服务问题的自我发现能力和保证现场服务的可用性。边缘容器服务 ACKEdge 提供的功能，通过更上层次的抽象，对多个 Deployment 进行统一管理，比如创建、更新和删除等操作。提供一个模板来定义应用，将多个 Workload 部署到不同的区域，每个区域定义为一个节点池。目前单元化部署支持两种类型的 Workload，StatefulSet 和 Deployment。控制高效的边缘服务定制管理01图 3：边缘服务编排大型和超大型演出现场验票系统可靠性要高其他类型现场,对设备可靠性提出更高的要求，并且设备故障平均故障时间也要满足全天候验票要求，同时针对现场容灾，可自动感知和服务切换，减少

133、现场运维人员排除故障时间。针对现场验票服务设备可靠性要达到 0.999 及其以上，并具备服务容灾能力，实现多机运行,云端一体的服务容灾。边缘自治，节点任务无缝自动切换02器会根据单元化部署中节点池的配置创建子的 Workload 资源对象，每个资源对象都有一个期望的 Replicas Pod 数量。通过一个单元化部署实例就可以自动维护多个 Deployment 或者 Statefulset 资源，同时还能实现 Name、NodeSelectors 和 Replicas 等的差异化配置。现场运维管理平台提供边缘设备服务发现、边缘服务差异化配置服务，根据现场业务动态调整 Deployment 配置

134、，依托 ACKEdge 实现高效的边缘服务定制、管理。6766阿里影业云原生十大经典案例图 4：现场规则一致边缘节点可以自主协商、决策和执行任务的能力；自治能力可以使边缘节点更加智能化，能够自动适应环境变化，保证系统的稳定性和可靠性。无缝自动切换是指在边缘计算中，当某个节点故障或不可用时，系统可以自动将任务转移到其他节点上，实现无缝的任务切换和容错能力。通过边缘自治和无缝自动切换的技术，边缘计算可以更加灵活、高效地进行任务调度和资源利用，同时也能够提高系统的可靠性和容错性。设备端连接边缘和云端提供换验能力，设备通过自动决策 SDK，判断网络状态、智能监测服务行为自动进行决策，确定连接边缘还是连

135、接云端服务。边缘通过数据同步服务与云端进行多通道数据交互，以确保云端和边缘数据一致性。云边协同将云计算和边缘计算相结合，通过协同工作，实现更加高效、灵活和可靠的计算模式。现场规则一致多开是指在边缘计算环境中，可以快速复制、部署和管理相同的应用程序和服务，以满足现场多个节点的需求。通过云边协同和现场规则一致多开的技术，可以将计算资源和应用程序更好地分布到边缘节点上，提高系统的响应速度和性能，同时也能够满足现场多样化的需求。具体来说，云控制整体中心云与边缘云部署，主动协同边缘，推送边缘数据实时协同，云端项目与边缘项目共享现场规则，云边配置整体协同与回流，现场规则云边一体一致多开协同，云端管控高速触

136、达边缘，做到“云控端，边回云，一致协同”。云边协同，确保现场规则一致03图 5：智能体检服务安全边缘计算环境下，需要保护数据和服务不受攻击和滥用的技术和策略。边缘计算场景下，由于数据传输路径较长、网络拓扑结构复杂，安全风险较高，因此保障服务安全显得尤为重要。同时，智能体检是对边缘设备、网络环境和服务进行全面的安全体检和分析，及时发现和排查安全隐患，保证系统的安全性和稳定性。通过服务安全和智能体检的技术，可以提高边缘计算系统的安全性和可靠性，保障数据和服务的安全和可用性。阿里影业 IoT 云边端充分考虑服务安全和智能体检，以保障系统的安全性和可靠性。边缘服务自动智能检测边缘服务各个系统指标，自动

137、上传系统体检指标数据，自动化检测、修复、引导等进行现场系统告警修复，并将检测数据实时上传云端，以便对现场所有边缘服务器进行早知道、早修复、早处理。服务安全，智能体检046968阿里影业TCL云原生十大经典案例通过将 ACKEdge 平台作为 IoT 云边端架构整体基座，阿里影业在影演现场服务场景打通了现有云上 Paas 平台与边缘端服务配置管理能力，将云原生的能力扩展到了边缘侧,能够满足边端的高响应、低时延、大连接的强诉求的云管边的整体协同能力。目前，该架构已经很好的应用于现场服务中，在超过 200 场次的各类项目中验票总数近十万张，带来业务结果在诸多方面的提升：通过落地基于 ACKEdge

138、的云边一体协同架构，阿里影业拓展了更多的演出行业场景，整体服务稳定性与高可用度得到提升，并且大幅提升主办方对阿里影业信任与消费者满意度，形成了帮助阿里影业在现场服务领域处于领先的重要支撑。未来，阿里影业将继续秉持“内容+科技”的双轮驱动发展战略，加速上游内容布局，加长科技板块优势，不断优化运营效能，推动业务多元化发展。阿里云容器服务也将始终与客户业务同行，助力阿里影业为广大用户、市场和行业提供丰富、满意的文娱消费体验。三.ACKEdge 助力阿里影业 IoT 云边协同、增效降本将服务置于容器中，解决了原始资源不隔离带来的稳定性差的问题，统一设备操作系统与配置环境，降低现场 98%的设备兼容问题

139、，现场人员部署速度提升 45%以上，降低活动人员成本；利用边缘容灾完成局域集群负载均衡，无需人工监控与操纵，减少 99%的切换时间，实现主机与备用机的平滑无感切换，大大增强现场服务容灾能力，在保证服务稳定性的同时，提升了验票环节的用户体验，1 秒完成验票，人均验票时间减少 70%；机器资源合理利用，实现多节点一台机器，使硬件的投入和部署成本整低降低 50%。边缘设备管理实现了边缘设备镜像发布、回滚以及升级，监控数据以及服务发现，实现远程对所有节点的统一管控，同步所有节点版本发布，减少因版本不一致或版本未更新造成的入场问题。01020304一.客户简介TCL 拥抱云原生，实现 IT 成本治理优化

140、TCL 工程师团队基于阿里云企业云原生 IT 成本治理方案沉淀了一套成熟的 IT 企业成本治理流程与系统，通过阿里云容器服务提供的开箱即用的成本洞察、资源智能画像等功能，进行业务成本拆分、闲置资源可视化发现，并制定弹性伸缩与混部等优化策略，为集团优化了 10%闲置的资源，各类业务降低了 30%的配额，每年节省近百万的 IT 成本投入。TCL 创立于 1981 年，总部设于中国广东省惠州市，目前已形成 TCL 实业和 TCL 科技两大主体，布局智能终端、半导体显示、新能源光伏三大核心产业，成长为一家具有全球竞争力的智能科技产业集团。TCL 目前拥有 13 万名员工，在全球布局 43 个研发中心和

141、 32 个制造基地，业务遍及 160 多个国家和地区，全球累计服务用户超 9.6 亿。整体资源利用率较低，成本洞察粒度不足，无法驱动策略优化。在早期上云的过程中，TCL 通过给不同的事业部分配独立云账号的方式，实现成本单元的规划与核算。但是当工程师团队希望去洞察整体的资源使用、浪费情况的时候，单纯从服务器等云资源的利用率情况来衡量业务的容量规划浪费情况是不够合理的。因为从单个业务的视角，容量规划需要根据业务的峰值情况来规划。业务高速发展，传统容量规划的周期无法满足，影响业务使用。TCL 上云的过程经历了上云迁移期、业务增长期、业务稳定期等多个阶段，在上云迁移期和业务增长期中，发现传统按照月度、

142、季度甚至是年度的 IT 成本治理的周期，无法跟上业务增长的速度，造成很多业务处于无资源可用 或者超预算使用的情况。临时作业/突发任务等短周期作业较多，对容量规划带来巨大挑战。TCL 压测平台是一个被重点关注的业务，因为压测任务具有短时间、大规模、低成本的的要求，是传统企业 IT 成本管理中最难以处理和解决的资源类型，但也是上云按需使用的最佳场景。客户痛点107170TCL云原生十大经典案例业务容量、成本预估困难，缺少数字化指标支撑降本增效。在 TCL 工程师团队定下降本增效的目标后，如何数字化衡量和评估应用的容量和成本情况，成为了最大的挑战。只有当一个应用的资源成本画像可以被准确绘制的时候，才

143、能够有针对性的建立优化策略。洞察资源使用量，调控周期性业务成本，提高集群利用率。先根据应用的具体类型进行分类，选择合适的机型、CPU/内存的配置；与业务团队协商业务容量上限，并对业务进行全链路压测确定容量的画像和水位的情况。在压测的过程中，通过阿里云容器服务提供的成本洞察功能，可以查看应用在当前容量规划的方案下的真实利用率；对于存在明显的周期性业务，采用定时伸缩的模型，降低在波谷时的资源成本；调整生产环境和测试环境的超卖比配置，将测试环境的超卖比调整为 300%，提高集群利用率。精细化成本管理，合理规划容量，应对突发业务。定时查看、巡检集群中应用的利用率、资源水位的情况，汇总成本报表；通过云原

144、生企业 IT 成本治理方案中，阿里云容器服务成本洞察功能，对业务进行集群-部门-应用维度的成本实时预估，让部门可以时刻关注自身成本的趋势变化；开启 HPA 等自动伸缩策略与报警，保障业务在流量突增的场景的鲁棒性。快速预估成本，基于数字化指标精准绘制资源成本画像。通过阿里云云原生企业 IT 成本治理方案中提供的费用分摊等功能，定期将拆分后的成本分析数据推送给事业部 IT 负责人、部门负责人、业务负责人等不同角色，并建立复盘机制，协同技术、财务、业务团队迭代优化成本画像的合理性。方案亮点图 1：阿里云云原生企业 IT 成本治理方案通过阿里云云原生企业 IT 成本治理方案，TCL 工程师团队可以非常便捷地提供 Kubernetes 集群中的业务、组织等维度的成本数据，大大提升了部门之间的成本通晒的效率，配合技术、业务、财务“战略同频”的云原生 IT 成本治理流程，为集团优化了 10%闲置的资源，各类业务降低了 30%的配额，每年节省近百万的 IT 成本投入。建设成果图 2：通过成本洞察，形成资源成本画像后，最终制定了兼具稳定性、成本优化的 HPA 自动扩缩策略