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

2024ALIBABA CLOUD NATIVECASE STUDIES/目录01茶百道奶茶上云，原生的更好喝作者：伯衡、望宸0402Rokid当 Rokid 遇上函数计算作者：王彬、姚兰天、聂大鹏1403极氪ARMS 助力极氪提效服务应急响应，为安全出行保驾护航作者：比扬2104创米数联支撑“千万设备日活”的创米数联 7 年微服务架构演进之路作者：金兆旭、十眠3005美洽对比 5 个开源网关项目，这家 SaaS 企业如何统一网关架构作者：古建国3606高德阿里云函数计算 FC 助力高德 RTA 广告投放系统架构升级作者：赵庆杰、林雪清、杜玲玲、王壁成4207Tim Hortons轻松构建全栈观测，从容应对咖啡产业竞争作者：郭皛璠5008杭州亚运高光回眸：阿里云容器服务如何全面助力精彩亚运作者：刘佳旭 谢乘胜 贤维5609阿里影业容灾切换时间减少 99%，“云边协同”如何提升影演服务效率与稳定性作者：神蚕、鹤劼6110TCLTCL 拥抱云原生，实现 IT 成本治理优化作者：行疾6954茶百道云原生十大经典案例奶茶上云，原生的更好喝一年卖出 8 亿杯，考验的不仅是奶茶的品牌、口感和性价比，还得有一套打通线上和线下、连接上下游供应链、以保障丝滑购买体验的数字化系统。茶百道成立于 2008 年，起初，茶百道坚持一步一个脚印，用了 8 年时间门店数量也只有 100 家。转折点发生在 2018 年，在这一年，茶百道正式开放全国性加盟，准备用规模来换市场。2020 到 2022 三年期间，营收和净利润都增长了 4 倍有余。这三年，也是茶百道数字化系统成功云原生化的演进历程。茶百道的愿景之一是以好茶为始，持续探索天然食材与茶的搭配，呈现茶饮更多可能。然而，新式茶饮强调手作与新鲜，其产品往往需要多重工序，导致制作流程变得更加复杂，人员成本也随之大幅上涨。为此，茶百道投资建立了 OMS、WMS 和 TMS 一体的供应链信息化、自动化技术系统，实现了库存、订单、运输资源、到店服务等全链路数字化转型。在提高运送质量的同时，做到信息留存可追溯，完善品牌自检自查和监管部门监管渠道，数字化“护送”食材的出货、送货、到货全流程。但是供应链信息化、自动化技术系统背后的基础架构，并不是茶百道所擅长的。为了提升整体竞争效率，茶百道希望通过云原生，对从上游原材料供应商到终端门店的整套供应链体系进行再升级。升级前，茶百道面向 B 端的供应链中心和面向 C 端的运营中心，均部署在自建的 K8s 集群上，存在不小的局限性，例如在运维复杂度、稳定性、成本控制等方面，已不能满足日益增长的业务发展需求。茶百道决定将自建 K8s 集群迁移到 ACK+ECI，ACK 具备强大的集群管理，包括集群创建、集群升级、多集群管理、授权管理等能力，提升了集群管理效率；ECI 可根据业务需求，实现自动扩容，30s 即可扩容 3000 Pod，提升闲置资源利用率，算力成本下降 50%；通过 ACK，茶百道有效降低了在节点、集群、应用上的日常维护、安全防护等方面的投入，全面提升供应链体系和运营中心的运营效率。01茶百道早期的 IT 业务系统由外部 SaaS 服务商提供，在满足业务扩张过程出现的新的业务需求，显得捉襟见肘。例如：需要在原有的会员、订单、营销三中心上，开发更多的业务功能，例如积分商城、外卖系统、加盟招募等；需要新增移动端小程序，并且做到随时可以发布新版本、以持续提升线上购买体验；需要应对不定期举办的线上和线下营销活动所带来的消费波峰，不出现线上故障。02时间就是竞争力，在竞争激烈的茶饮市场，茶百道决定组建自己的软件开发团队，并借助阿里云的云原生产品和技术，全面升级包括店务、POS、用户交易、平台对接、门店管理、餐饮制作等业务单元在内的数字化体验，充分利用线上营销和下单、线下售卖和派送相结合的优势，迅速占领市场。茶百道为这场数字化战役定了个目标：数字化要能助力好茶鲜做数字化要能支持加速拓客数字化要能对企业的经营起到降本增效的作用一.数字化要能助力好茶鲜做0176茶百道云原生十大经典案例二.数字化要能支持加速拓客茶百道目前的拓客资产包括：全国 7000+线下加盟店，覆盖超过 330 个城市，小程序、美团、饿了么的线上外卖店，抖音&小红书&B 站等社区的营销账号（近百万粉丝），以及高频的各类线上和线下营销活动。但在进行数字化升级前，茶百道的拓客渠道非常有限，主要是线下加盟店为主，流量成为营收增长的最主要瓶颈。为此，茶百道重新设计了运营中心的业务架构，以线上支持业务的快速增长。新增了订单中心中的外卖、配送功能，会员中心的促销、用户、调度、账单、门店、商品功能，营销中心的券功能等，并对三大中心的原有功能进行了全面升级。茶百道目前日活订单超百万，很多店面是 24 小时营业。技术团队核心目标就是提升拓客效率、线上 0 故障，因此运营中心的稳定性运行成为工作的重中之重。从运营中心架构和依赖关系图可以看到，茶百道的运营一体化系统架构应用繁多，存在以下稳定性挑战：为此，茶百道借助阿里云微服务引擎 MSE 和应用实时监控服务 ARMS 建立了业务连续性管理体系和可观测体系。在业务连续性管理体系中，构建了故障预防、快速发现、系统防护 3 道标准流程。频繁的迭代和发布，三方服务依赖多，线上故障风险增高；服务间调用关系复杂，线上出现问题后，较难快速发现和定位故障；全渠道接入全覆盖的营销场景，难以预期的突发流量，导致保障难度加大。升级改造前，茶百道因为软件变更带来的线上事故占比一度超过 60%，每次发版，都需要避开高峰，在凌晨发版。升级改造后，通过 MSE 微服务治理建立灰度环境，控制应用发布时出现问题的爆炸半径，以小流量来验证发版质量，逐步覆盖到全部业务节点；加强无损上下线能力，降低应用发布时的流量损失，从而加大了软件的发布频次，提升了对业务的响应诉求，随时可发版，无惧高峰。降低发版过程中的风险98茶百道云原生十大经典案例这个过程中，MSE 打通了 Readiness，确保 Pod 与应用两者同步就绪，保障发布时业务的连续性；同时，新Pod 通过小流量预热，确保流量的稳定增长，避免由于应用初始化，代码冷加载高流量冲击引起应用雪崩的现象；缩容时，MSE 通过主动通知、客户端刷新等增强能力，解决无损下线问题。并且，通过动态、静态流量染色技术，从网关、应用、消息到数据库，按门店等多种方式进行流量分流隔离，确保灰度环境得到全链路的验证。此外，茶百道使用 MSE 云原生网关替代了原有的 Traefik ingress，整体性能提升 1 倍，并且做到了 ingress 通用规则的平滑迁移。经过以上的改造，茶百道实现了应用发布效率提升了 60%，因发版引起的线上故障较少了 90%以上。目前正在直播场景开始实施全链路压测，前端已完成改造。通过 ARMS 构建多层次全链路的监控体系，包括从最底层的系统和云监控，再到业务层监控，指标采样率百分百覆盖，链路全采集，监控数据准确率大幅提升，能够快速实现业务故障的自动发现，有效的配合敏态业务发展。总体来看，故障恢复效率提升 50%以上，故障恢复耗时缩短 50%。作为业务高速发展的新兴餐饮品牌，茶百道每天都有着海量的在线订单，这对于业务系统的连续性与可用性有着非常严苛的要求，以确保交易链路核心服务稳定运行。为了让用户有顺畅的使用体验，整个微服务系统每个环节都需保证在高并发大流量下服务质量，但这一过程中，构建可观测体系存在诸多问题：快读定位线上故障运维：从需求承接到参与研发流程规则制定在业务高峰期或受到某些营销活动带来的突发流量，订单服务等核心应用会承压，为了保护核心应用履约流程不受影响，茶百道通过 ACK+ECI 配置了多种弹性指标，同时借助 MSE 的限流降级功能设置了熔断保护能力，双管齐下。例如，对部分非关键服务消费者配置一个规则，即当一段时间内的慢调用比例或错误比例达到一定条件时自动触发熔断，后续一段时间服务调用直接返回 Mock 的结果。这样既可以保障调用端不会被不稳定服务拖垮，又可以给不稳定的下游服务一些喘息时间，从而保障整个业务链路的正常运转。系统防护，应对突发流量指标数据准确度与采样率难以平衡。适当的采样策略是解决链路追踪工具成本与性能的重要手段。在茶百道的庞大微服务系统规模下，100%链路采集会造成可观测平台存储成本超出预期，而且在业务高峰期还会对微服务应用本身的性能带来一定影响。但开源工具在设定采样策略的情况下，又会影响指标数据准确度，使错误率、P99 响应时间等重要可观测指标失去观测与告警价值。茶百道的应用数量有上百个规模，但是在茶百道的研发成员构成上,运维占比较少，大多数是开发，而开发并不熟悉代码构建发布的技术细节。如何让运维能够低成本地定义规则和策略，并落地到应用的研发过程中，是落地过程中的问题点之一。为了解决该问题，茶百道结合云效应用交付中的研发流程模板、资源编排模板能力，通过模板实现应用配置的快速初始化。在这其中，运维更多的是作为应用研发流程规范的制定者，定义好应用的研发流程模板、资源编排模板、各阶段的代码分支模式以及集群资源，后续的应用特性发布都可以依据定义好的研发流程，在相应的阶段按照规定的发布策略发布到对应的集群资源中。缺少高阶告警能力。开源工具在告警方面实现比较简单，用户需要自行分别搭建告警处理及告警分派平台，才能实现告警信息发送到 IM 群等基本功能。由于茶百道微服务化后的服务模块众多、依赖复杂。经常因为某个组件的异常或不可用导致整条链路产生大量冗余告警，形成告警风暴。造成的结果就是运维团队疲于应付五花八门且数量庞大的告警信息，非常容易遗漏真正用于故障排查的重要消息。故障排查手段单一。开源 APM 工具主要基于 Trace 链路信息帮助用户实现故障定位，对于简单的微服务系统性能问题，用户能够快速找到性能瓶颈点或故障源。但实际生产环境中的很多疑难杂症，根本没有办法通过简单的链路分析去解决，比如 N+1 问题，内存 OOM，CPU 占用率过高，线程池打满等。这样就对技术团队提出了极高要求，团队需要深入了解底层技术细节，并具备丰富 SRE 经验的工程师，才能快速准确的定位故障根源。三.数字化要能支持加速拓客如果说助力好茶鲜做是面向供应链的升级，加速拓客是面向市场和销售端的升级，那么降本增效则是对技术团队自身的升级了。1110茶百道云原生十大经典案例四.迁移和实施过程研发：保持定制和灵活，并自助完成构建和发布其次，对于实际要去执行代码构建发布的开发一线员工，如何能让他们无需关注 Dockerfile、Yaml 等细节，就能自助地完成构建和发布，并且同时又能保持足够的定制化和灵活性，是茶百道一站式 DevOps 工作流程落地的另一问题点。为了解决这一问题，茶百道结合云效应用交付中的变更研发流程模式，在运维人员把研发流程规范制定好后，开发人员只需要去依据云效项目中的需求或开发任务，在应用下创建变更，从应用关联的云效代码库中拉取对应的 feature 分支并进行特性的开发，开发完成提交代码后就按照已设定好的研发流程，基于云效流水线进行各阶段的代码分支构建发布，依据提前设定好的分支模式做分支构建发布，构建过程中，从云效制品仓库中拉取相应的依赖包，并且把构建产物放在制品仓库中进行制品版本管理。通过这一模式，一方面可以实现对一线员工应用构建发布细节的隐藏，另一方面也可以随着业务更迭去定制修改构建发布细节。经过几个月的实践，基于云效，茶百道实现了一站式 DevOps 工作流程方案的成功落地，建立了产研数字化模型，提升了业务响应能力，从而较好的提升了茶百道的企业研发效能。整体方案设计完成产品选型后，结合业务上云需求，我们明确了整体系统架构和切换方案。第一步，优先迁移业务层应用：即将自建 K8s 迁移到阿里云 ACK 集群，并采用云效应用交付，以应用为中心，集中管理企业的研发资产，包括应用的配置、代码、CI/CD 发布、环境等。在新环境部署业务系统，并进行业务验证及压测。第二步，测试验证通过后，开始生产系统流量迁移：为了保证平滑过度，此时只迁移系统的接入层和应用层，数据层和中间件选择复用，通过 DNS 切流及 MSE 灰度能力逐步进行业务割接。第三步：分批完成业务切流，最终通过数据同步方式完成数据库、中间件等产品全量切换，原自建集群下线。业务架构设计实施过程-架构统计为了实现既定目标，项目组确定了项目实施关键里程碑，现场调研、方案设计、POC 验证、生产部署及验证、业务割接切流、回归测试、正式上线切流等。1312茶百道云原生十大经典案例迁移计划实施过程-PoC 测试PoC 环境搭建完成后，项目组通过 PTS 进行全链路压测，模拟复杂的业务场景，并快速精准地调度不同规模的流量，通过多维度的监控指标和日志记录，全方位地验证业务系统的性能、容量和稳定性。实施过程-生产系统切换通过 POC 及全链路压测以后，可以确保新环境具备接管能力，并提前准备好回滚方案。切换过程中，利用 ARMS 密切监控系统的性能和稳定性，在迁移结束后进行充分的验证和测试，以确保系统在新环境中正常运行。生产系统的切换是一个复杂的过程，需要考虑到系统的稳定性和可靠性，为此我们选择分批切流，将原有生产系统的流量逐步切换到新系统中，有效降低了系统压力，减少切换过程中的风险和不确定性。同时，每一个批次都要具备门店灰度能力，在分批切流的同时，新环境的发布通过门店 ID 的方式，在部分门店进行灰度测试，利用生产环境真实流量验证新系统的可用性和性能表现，以确保其能够满足实际业务需求。五.总结数字化是传统企业突破原有市场天花板的核心竞争力，行业竞争越是激烈，数字化升级越是迫切。茶百道预判到行业的加速发展，果断、及时、全面的进行数字化升级，并选择阿里云保障 IT 基础设施的先进性和稳定性，并以此助力好茶鲜做、支持加速拓客、帮助企业降本增效，为企业未来的进一步发展打下坚实的基础。在技术架构上，业务系统外部流量渠道很多，其中有五个主要渠道,包括门店,POS，美团/饿了么，小程序，抖音/支付宝等三方渠道。系统接入层，由 DNS 进行解析，SLB 进行负载均衡，自建 Nginx 集群进行流量分发，由 treafix ingress 作为 NG 和业务网关桥梁，使反向代理和负载均衡更加高效。业务层，除了鉴权的业务网关外，通过 ECS 搭建了 K8s 集群，K8s 由第三方厂商做了很多定制化改造。数据层，用到了 RDS，Redis，TiDB 等数据库及缓存。中间件使用了 RabbitMQ 和 Kafka 等。为了保证方案的研究性及可行性，除此之外，项目组还详细统计了现有部署资源、内外部域名及调用关系、定时任务使用情况等详细情况，为方案设计及实施落地提供有力的支撑。1514Rokid云原生十大经典案例当 Rokid 遇上函数计算Rokid 创立于 2014 年，是一家专注于人机交互技术的产品平台公司。Rokid 通过语音识别、自然语言处理、计算机视觉、光学显示、芯片平台、硬件设计等多领域研究，将前沿的 Al 和 AR 技术与行业应用相结合，为不同垂直领域的客户提供全栈式解决方案，有效提升用户体验、助力企业增效、赋能公共安全，其 Al、AR 产品已在全球八十余个国家和地区投入使用。Rokid Air Pro 这款AR眼镜产品，为旅游景点，大型企业，国内科研机构都提供了服务支持。目前 Rokid 已和全国百余家博物馆和景区达成合作，给游客穿越时空，身临其境的非凡参观体验。三维建图，场景创作，场景体验三个场景都涉及到了的图像处理，需要大量的 GPU 资源。其中三维建图属于离线任务，在构建展陈模型时，需要将整个展陈场所的视频内容进行预处理，是三个场景中消耗算力最大的部分；场景创作需要配合创作软件，GPU 资源主要来自开发机器；场景体验在设备真实运行时提供实时服务，主要功能是定位服务，对服务的实时性要求很高。为了支撑 GPU 算力的需求，Rokid 在开发的初期就决定尽可能的使用云资源承载，充分利用云计算的红利。最初是购买了 ECS 的 GPU 机型，用于业务的开发和测试。这里很大的问题是在三维建图时，一般都会一次性采集展陈环境的所有场景资料，视频量巨大，通过 ECS 串行处理需要时间很长，一个 1 小时的视频资料，通过一台 ECS GPU 机器需要处理 3 小时左右。Rokid 做的第一步是并行化，通过拆分 CPU 和 GPU 处理逻辑和优化任务编排方式，尽可能的让可以并发处理的部分拉起更多的资源加大并发量，通过这一系列的优化，视频的处理时间得到了不错的提升。在并发资源方面，Rokid 选择的 GPU 计算资源是 ECI，相对 ECS，ECI 可选的资源粒度更加多样，特别是在小规格的选择上，对于切分的小块视频，通过并发的使用小规格 ECI 实例并行处理，大大缩短了整体视频的处理时间。为此，Rokid 内部平台还开发了一套针对阿里云 ECI 资源的调度模块，方便内部快速的申请和归还 ECI 资源。通过对 ECI 资源的灵活使用，在保证高峰期任务处理并发度的同时，也保证了算力成本的可控，使用流程上得到了初步的优化。但是通过一段时间的使用，发现还是有很多的不足之处，主要问题总结如下：一.架构革新的必要性Rokid 在 AR 的研究可以追溯到公司创立之初，在 2012 年 Google Glass 横空出世，其广阔的想象空间深深震撼了 Rokid 创始团队。后面虽然因为使用的场景和高额的价格原因，Google Glass 并没有持续的火爆普及。但可以预计在不久的将来，随着基础设施，生态应用的成熟，和人们持续提升的对娱乐，办公的体验要求，AR 技术一定会得到更广泛的应用。Rokid 在数字文化领域，围绕展陈导览解决方案，主要形成了三维建图，场景创作，场景体验三个业务模块，每个模块都有不同的后台平台支撑。三维建图：制作展陈导览的第一步是取景，通过设备获取场地的真实布景，然后通过算法处理，进行三维建模，之后可以经过创作器进行下一步的内容创作。场景创作：在三维建模生成的视频流上创作，通过 Web3D 渲染引擎，将创作内容与场景紧密结合，结合硬件设备，在 AR 设备使用时，形成一体化的体验效果。场景体验：AR 设备在使用时，根据定位服务，锚定在场景中的位置，根据位置的不同会显示不同的空间内容，达到扩展现实场景的效果。010203ECI 资源的申请和释放都依靠使用人员主动操作，有时在使用完毕后会忘记及时释放资源，导致资源闲置浪费。且开发和维护 ECI 的调度程序也需要占据对应同学一定的精力，带来了一些额外的运维工作。01021716Rokid云原生十大经典案例底层依托阿里云的大计算池，提供近乎无限的计算资源，通过阿里云的 cGPU 技术，可将单卡 GPU 资源切分成多种更小粒度的资源规格。客户在函数计算选择 GPU 规格创建函数，在有请求时，函数计算会实时从预热资源池获取资源，配合对应的镜像程序，启动客户函数，启动完毕后对外提供服务。函数计算在第一次运行实例时会涉及到资源的拉起，弹性交付时间在 1s（热启动）20s（冷启动）。Rokid 的三维建图场景是离线任务，单个视频的处理时间也在分钟级，对于秒级别的启动时延完全可以接受。在三维建图任务接入函数计算后，Rokid 不再需要手动申请 ECI 资源，在使用结束之后也不需要在手动释放。函数计算会根据请求流量，动态的拉起与请求量匹配的后端 GPU 算力资源，在请求处理结束后，一段时间没有新请求的情况下，自动释放资源；整个三维建模在拆分后涉及好几个步骤，每个步骤都是异步执行，通过函数计算的异步系统，在一个步骤的任务完成后，可以自动触发下一个任务；函数计算控制台内置了指标监控，异常告警，链路追踪，调用日志，异步配置的功能，可以满足 Rokid 从开发，运行监控到运维全函数生命周期的功能需求；函数计算底层依托阿里云大计算池，加上预热和资源评估的后端算法，可以最大程度的保证资源供给；这几点正是 Rokid 之前遇到的痛点问题，通过接入函数计算单一的产品，就解决了 Rokid 近乎全部的主要问题。为了解决上面问题，Rokid 内部架构组寻求优化已有的架构，针对第 2 点，Rokid 自行维护了一个总的调度系统，进行任务编排；针对第 3 点，通过阿里云 ARMS Tracing，Prometheus，Grafana 等组件的引入，结合 ECI 硬件指标，统一收集到 SLS，形成统一的监控报表，再配以监控指标的告警，也能够初步的满足 Rokid 使用需求。但第 1 点和第 4 点，很难通过增加云产品或者内部应用程序解决。为此 Rokid 架构组开始寻找云上新的产品，以求彻底的解决使用过程中的痛点问题。此时，Serverless 架构的函数计算出现在了 Rokid 架构师的视野，经过一段时间的调研使用，函数计算的各项能力都能够很好的满足 Rokid 使用场景。三维建模的任务经过拆分后，分成了好几个步骤，每个步骤的任务都需要异步执行，需要一个系统维持任务的调用关系，在上一个步骤完成后，拉起下一个步骤的任务继续运行。在运行过程中，会存在异常情况，排查下来，有时是因为申请的计算资源规格过小导致计算负载较高，有时是存储异常或存储空间写满，还有些情况是程序本身性能瓶颈。对于程序的整体监控缺乏，使得出现问题时不能第一时间发现，发现有异常排查过程不够直观，需要通过多种工具获取运行指标分析。GPU 算力在云上规模有限，在高峰期会偶尔存在 ECI 资源弹不出的情况，影响开发效率。020304函数计算是事件驱动的全托管计算服务。使用函数计算，客户无需采购与管理服务器等基础设施，只需编写并上传代码或镜像。函数计算会准备好计算资源，弹性地、可靠地运行任务，并提供日志查询、性能监控和报警等功能。函数计算提供 CPU，GPU 的算力，秒级计费，客户只需要为实际资源使用付费。资源弹性可根据定时，请求量等指标自动伸缩，无需维护调度，负载，重试，异步回调等组件，提供了开箱即用，用完即走，按量付费的极致 Serverless 能力。函数计算 GPU 架构如下：二.函数计算的出现恰逢其时1918接入函数计算后，Rokid 的云产品技术架构如下：函数计算资源利用率监控图如下，从监控图可以看出，在有任务进入时，GPU 计算利用率可以达到 60%甚至接近 100%。三.体验与架构的妥协Serverless 理念的函数计算确实给 Rokid 带了很多的便利，在高峰期资源的扩展性和成本节约方面都做到了当前云产品的极致，但函数计算也并非万能，对于 Rokid 的场景体验功能，也就是需要实时提供定位服务的模块，函数计算还是存在了一定的问题。函数计算在第一次拉起实例资源时，会存在 1s（热启动）20s（冷启动）的启动时间，这个时间对于实时定位服务模块是不可接受的，实时定位是在使用者身处展陈场地时，AR 设备通过实时定位，获取空间位置的 AR 拓展信息，接口响应的时间对客户的体验非常重要，定位请求需要在 1s 以内返回。在成本和服务质量之间，Rokid 选择了服务质量优先，场景体验模块采用 ECI 部署，通过每天的定时任务，在高峰期提前弹出更多的 ECI 实例，在低峰期时，保留少量的 ECI 实例，以此达到体验和成本的平衡。另一方面，函数计算在实时的场景也并非完全没有解决方案。目前 GPU 的模型一般都很大，镜像都在 G 级别，所以对于第一次资源拉起，在接下来一段时间内还看不到跟 CPU 资源一样 100ms 级别的拉起速度。针对实时场景，函数计算 GPU 实例在做的是预留实例，该功能可以在资源闲置时，释放计算资源的同时，保留程序的内存运行镜像，在有新的请求进来时，只需要供给算力资源，函数就能提供服务，免去了中间硬件资源拉起，函数镜像拉取和启动的时间，可以提供实时的服务。预留实例已经在 CPU 实例上线，闲置时 CPU 价格是运行态的 1/10，在保证实时能力的情况下，大大降低了资源成本。GPU 版本的预留能力预计年底上线。场景体验采用 ECI 后，Rokid 的业务架构图如下：Rokid云原生十大经典案例2120四.出色的效果和进一步的期待一.客户介绍与项目背景通过一系列的云架构改造，当前 Rokid 三维建图模块运行在函数计算的 GPU 资源上，场景体验模块运行在 ECI 资源，在成本和性能上，都做到了兼顾，且给整个系统强大的可拓展性，达到了系统设计时设定的架构目标，从 2023/2 上线提供服务以来，达到了不错的效果。其中三维建图模块降本明显，相比最初的 ECS 架构，算力成本降低了 40%，更为重要的是，通过实时的并发处理，大大减少了子任务的排队时间，加快了整个任务的完成时间。下一步，Rokid 对于函数计算的 GPU 预留实例还是非常期待，期待函数计算能够尽快上线，这样 Rokid 内部可以将整个的 GPU 算力都迁移到函数计算，达到架构的统一。经过展陈展览项目的实践，Rokid 相信以函数计算为代表的 Serverless 一定是云计算的未来，通过 Serverless，云计算的使用者不再需要关注底层的 Iaas 层运维和调度，在保证成本最优的情况下能够得到最大限度的拓展能力，且在整服务的生命周期，都能使用云产品提供的原生能力，简单，快速的定位，解决问题。Rokid 在 3d 模型处理，音视频后处理方面正在大规模尝试函数计算，Rokid 相信以函数计算为代表的 Serverless 架构也一定会在越来越多的云产品上得到应用。Rokid极氪云原生十大经典案例ARMS 助力极氪提效服务应急响应，为安全出行保驾护航浙江极氪智能科技有限公司于 2021 年 3 月成立，2021 年 4 月发布极氪品牌及旗下首款产品极氪 001。极氪是一家以智能化、数字化、数据驱动的智能出行科技公司，秉承用户型企业理念，聚焦智能电动出行前瞻技术的研发，构建科技生态圈与用户生态圈，以“共创极致体验的出行生活”为使命，从产品创新、用户体验创新到商业模式创新，致力于为用户带来极致的出行体验。截止 2023 年 4 月，极氪量产车交付已经突破 10 万辆，从 0 到 10 万辆，极氪用时仅两年，快于其他新势力品牌至少四年以上的时间，持续刷新新势力品牌交付记录，这不仅是对“极氪速度”的展现，也是对“中国速度”最好的诠释。为了保障好极氪汽车业务的快速发展和用户体验，技术团队除了保持高效的功能迭代的同时，也在不断的夯实其系统稳定性和应急响应能力。自 2023 年开始，大数据团队正试点推行面向极数 BI 业务的数字化稳定性治理建设。032322极氪云原生十大经典案例极数 BI 是一款面向极氪经营管理全体系的可视化数据分析系统，已覆盖多个核心业务场景。极数 BI 不仅仅是一个报表工具，还提供了全域数据互联互通、智能化数据分析和全景数据可视化的功能，可以为其他业务“发生了什么、为什么发生、将要发生什么、如何应对”提供完善的数据支撑和辅助决策能力。打破数字鸿沟，创造数据价值，逐步实现全业务域的经营过程观测与经营结果呈现是极数 BI 的发展目标。为保障极数 BI 的数字化稳定性治理建设落地，极氪通过建设端到端的全链路可观测体系、企业级应急响应机制和跨部门团队的人员协同机制，以业务连续性保障为目标，实现了极数 BI 业务的“X 分钟的故障发现与通报”、“X 分钟的应急响应与故障定位”、“X 分钟的故障恢复”核心稳定性指标的达成。如何构建统一的报警体系、通报机制和跨团队应急协同机制 系统资源层、云服务应用层、业务监控层，为了监控这些复杂的 IT 环境，由于各层资源分属不同的团队进行管理，导致采用了多种监控系统，例如 Prometheus、Grafana、Skywalking、阿里云云监控、阿里云 ARMS 等，以获取更全面的监控数据和更好的了解运行状态和性能表现。然而多种监控系统的并存带来的其中一个显著问题是告警信息的分散，不同的监控系统产生不同的告警信息，通过不一致的方式通报给告警处理人，而告警的排查通常需要多个团队共同合作进行处理，纵横交错的告警处理增加了人员响应的复杂性和工作量，疲于应付的程度往往远超出了告警处理人员的日常负荷。02如何规范故障等级定义、应急处置流程和故障管理体系 业务可用率是一套业务系统可靠性、维修性和维修保障性的综合反映。Availability=MTBF/(MTBF+MTTR)，通常业界习惯用 N 个 9 来表 征 系 统 可 用 性，比 如 99.9%（3-9 availability），99.999%（5-9 availability），系统出现故障的停机时间直接反映了业务可用率。如何定义一套适用于极氪自身业务的故障等级定义、应急处置流程和故障管理体系将是保障极氪对外承诺的业务可用率的重要支撑手段。通过建立一个可遵循的规范、全流程闭环的故障管理体系，配合技术手段的提升，可以有效降低故障发生的几率，缩短故障的 MTTR，最终使故障造成的破坏性趋近于 0。03如何有效度量业务稳定性指标和应急响应 SLA 如何查看过去一段时间系统发生了哪些告警，哪类告警占比较高；制定了值班机制，但无法衡量值班人员告警处理的效率，如何确保值班机制的执行效果；一个服务在多个系统中配置了多个告警，无法从服务的维度来查看告警的处理效率，查看服务的 SLA；在针对性的系统优化后告警占比是否降低，告警的持续时间占比是否得到改善。这些都是在日常运维过程中衡量告警的处理效率和服务的稳定性面临的典型问题。这些重要数据都需要完善的数据报表和统一的大盘来呈现。04疲于应付海量告警信息，并且非常容易遗漏真正用于故障排查的重要消息。因此，针对海量持续告警信息，如何进行告警合并，在保证不错过核心告警消息的前提下抑制告警消息数量，成为了面临的重要运维难题。二.项目落地时面临的挑战和需求云原生浪潮下，Serverless 因其全托管免运维、成本降低和弹性伸缩等特性正逐步在引领下一代的应用架构。极数 BI 业务从立项之初就确定了 Serverless 化的方向，并基于阿里云 Serverless 应用引擎（SAE）成功落地。应用 Serverless 化最大化限度减轻了运维工作，但是在自身业务的数字化稳定性治理方面依然面临较大挑战：如何覆盖和收敛从基础设施到业务应用监控的全链路告警事件 从前台业务数据、用户体验，到后台应用服务性能，再到云服务及基础资源，即系统资源层、云服务应用层、业务监控层，虽然针对不同的服务模块都有对应监控，构建了相对完善的指标监控体系，但由于微服务化后的服务模块众多、依赖复杂，很有可能因为某个组件的异常或不可用导致整条链路产生大量冗余告警，形成告警风暴，从而造成运维团队012524极氪云原生十大经典案例三.基于 ARMS 的企业级应急响应解决方案针对上述面临的问题和挑战，阿里云云原生可观测团队与大数据团队经过多轮沟通对焦，通力合作共同输出了基于 ARMS 构建企业级应急响应体系的最佳实践，并成功在极数 BI 业务中落地，实现了全业务、全场景的监控和告警。同时全面提升了监控的覆盖率和告警有效率，其中按照极氪现行推广的应急响应机制，全团队事件接手率显著提升，告警平均认领耗时（MTTA）大幅降低，告警平均恢复耗时（MTTR）明显缩短，跨团队协同效率得到有效提升。采用 ARMS 智能告警建设统一的告警事件管理中心 极氪技术团队根据自身业务属性使用了多种监控系统，例如阿里云应用监控 ARMS、阿里云日志服务 SLS、Zabbix、Prometheus、Grafana 和自定义告警集成等，为了简化联系人、通知方式、值班等运维配置；统一告警信息格式、告警等级定义和告警事件的统一管理，极氪采用了 ARMS 智能告警作为多告警源统一管理的事件管理中心。ARMS 智能告警设计的集成、事件处理流、通知策略等功能专门针对告警统一管理的场景，解决了统一管理过程中遇到的诸多问题。以下重点介绍下整体方案中围绕“告警、接手”两项落地的“以事件为中心的告警全生命周期管理”解决方案。接入不同格式的告警。ARMS 智能告警参考开源 Prometheus 告警定义，使用一个半结构化的数据结构来描述告警。通过高度可扩展的键值对来描述告警，这样就可以非常灵活的对告警内容进行扩展从而接入不同的数据源产生的告警。通过告警集成的字段映射能力，即可将自定义的告警内容中的关键信息映射到 ARMS 告警数据结构中。同时也提供了多种监控工具的快捷接入能力，像极氪这边使用的阿里云应用监控 ARMS、阿里云日志服务 SLS、Zabbix、Prometheus、Grafana 等均已覆盖。告警等级统一定义。根据影响面的不同、业务受损程度的不同,一般需要定义不同的告警等级，告警处理人员需要根据不同的告警等级执行不同的应急处理过程。按照极氪的故障等级规范,配置告警时根据业务情况将告警归一到 P0、P1、P2、P3 四个等级。01022726极氪云原生十大经典案例事件和告警的归一化管理。多告警事件源通过集成的方式统一到 ARMS 智能告警，通过统一的事件处理流、通知策略、通知对象、升级策略等对告警事件进行归一化管理。一份通知对象、一套通知策略、一致的告警管理模式，满足极氪统一的告警事件中心需求。通过认领告警的消息广播可以让群成员之间明确的知道当前告警是谁在处理。01认领告警有些告警触发属于预期内的行为，且不会造成业务影响，但是又不能直接关闭告警。这种情况下可以通过屏蔽告警来降低告警通知的打扰。02屏蔽告警关注告警后，会将被关注告警的状态变更以短信的形式推送给关注人。对于重大故障的情况下，团队负责人可以通过关注告警的能力实时订阅关注告警处理的进展，从而为指挥决策提供数据支撑。03关注告警关闭告警并在群聊中发送一个告警关闭的通知，被关闭的告警状态会变成已恢复。04解决告警03基于极氪使用的企业微信建设便捷高效的 ChatOps 掌上运维能力 ChatOps 是一种集成了聊天和自动化工具的协作方法和文化，旨在提高团队的协作效率和可见性。ChatOps 的目标是提高工作流程的效率和可见性，并促进团队成员之间的协作和沟通。极氪内部使用企业微信作为办公协同工具，ARMS 智能告警支持对接企业微信，通过创建企业微信机器人，即可在通知策略中指定对应的企业微信群用于接收告警，相关告警信息仅在企业微信的极氪内部企业组织内流转。当通知策略的匹配规则被触发时，系统会自动向指定的企业微信群发送告警通知。企业微信群收到通知后，便可以随时随地在企业微信群中对告警进行管理。源于 ITIL 理念且适用于极氪组织架构和业务属性的事件管理体系 大数据团队目前正在极数 BI 业务推广的数字化稳定性治理机制最核心的部分就是构建一套标准规范的事件管理流程。流程上包含告警发现、告警通报、告警响应/接手、告警定位、指挥决策、告警恢复、故障复盘和持续改进。从人员组织上包括运维团队、告警值班人员、告警处置技术人员、应急指挥人员等。当告警触发接收到通报后，告警值班人员需要迅速建立针对告警关联团队的高效协同渠道，故障应急启动后。技术同学需要尽快完成签到，同时同步进行故障快速止血、根因定位排查、信息同步，如果在预期时间内未接手签到，告警通知将逐步升级。运维团队和应急指挥人员要负责统筹收集相关数据并同步影响面、处理进展和恢复进展，定时播报，更新告警处理情况。当告警以卡片的形式发送到 IM 群聊中，可以通过订正卡片的样式来添加一组操作进行告警的处理。通过 IM 的告警卡片即可便捷进行告警的全生命周期管理：同时为了方便极氪告警值班人员快速知悉告警通告情况，防止群消息过多被忽略，告警通知支持在告警通知群中 指定处理人。通过将告警处理人添加为 ARMS 联系人、通知策略中配置的通知对象和绑定处理人手机号相同即可实现告警通知时根据排班情况 值班人员。2928极氪云原生十大经典案例ARMS 智能管理提供排班管理功能，告警通知可以按照运维人员的值班时间设置告警发送的排班表，再通过通知策略将告警通知以电话、短信、邮件或企微消息的方式发送至对应的值班人员，而不会打扰到非值班时间的运维人员。告警值班人员再根据事件管理标准流程进行告警接手和处置。01排班管理对于长期未解决的告警，可以选择升级通知来提醒值班人员及时解决。在通知策略中添加升级策略后，系统会以指定的通知方式向处理人发送