量贩零食上云,原生的最划算

本文涉及的产品
可观测可视化 Grafana 版,10个用户账号 1个月
应用实时监控服务-应用监控,每月50GB免费额度
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 鸣鸣很忙集团作为中国最大的休闲食品饮料连锁零售商,旗下“零食很忙”和“赵一鸣零食”两大品牌已覆盖全国28个省份,门店数量超14000家。通过数字化转型,集团在4年内完成了传统企业10多年的数字化进程,实现了人、货、场的全面数字化管理。借助阿里云的全栈云原生方案,集团构建了弹性计算、大数据分析及智能监控体系,保障日均超430万级交易数据的一致性与稳定性,同时优化IT成本并提升运营效率。

1.gif


继现制茶饮、咖啡、餐饮等行业后,量贩零食成为消费领域又一个跑出万店的赛道,这些线下零售起家的连锁企业,正以另一种范式诠释着什么是后互联网时代的新零售。本文整理自鸣鸣很忙集团数字化中心总经理孙浩和运维服务部经理黄奖的视频采访稿。


鸣鸣很忙集团是中国最大的休闲食品饮料连锁零售商,亦是中国食品饮料量贩模式的引领者,旗下现有“零食很忙”、“赵一鸣零食”两大品牌。截至 2024 年 12 月 31 日,鸣鸣很忙全国门店数量 14394 家,覆盖中国 28 个省份和各线城市,是中国零食连锁行业首个达到万店规模的企业,并稳居行业第一。


一、鸣鸣很忙数字化:4 年多时间走完其他企业 10 多年的路程


鸣鸣很忙的数字化建设,要从零食很忙说起。


零食很忙的数字化建设是从 2021 年开始的,到目前为止,鸣鸣很忙集团已经搭建起一整套业务数字化体系,我们在 4 年多的时间差不多走过了很多企业 10 多年的数字化进程。


我们一方面做加盟商和门店相关的数字化,让加盟商、门店的管理简单化和傻瓜化,完成前端的人、货、场的数字化管理。另一方面做企业内部的数字化,让人、财、物的管理在线化和一体化。这两大方面的数字化建设,是鸣鸣零食规模化的坚实基础。

特别需要说一下的,是关于人货场"这三个零售命脉。


首先,在的方向。去年,集团代言人发布活动期间,订单流量呈现爆炸式增长。若采用传统系统模式,这种突如其来的大量订单将难以应对。幸运的是,我们采用了阿里云的弹性计算技术,配合负载均衡和弹性容器实例,就像给收银台开了 1000 个临时窗口,系统自动扩容扛住流量洪峰,并在活动结束后自动回收包装袋,避免了资源的浪费。


接下来是的智能化问题。过去,补货完全依赖店长的经验判断,薯片怕压、巧克力怕热、坚果怕过期,每个仓库都像布满了定时炸弹。因此,我们开始利用大数据计算平台,分析天气、节庆甚至社交媒体的热门话题,结合供应能力、仓储条件和销售预测,自动生成补货清单。


还有就是在的转型上。我们内部常说,如今开设新店必须做到复制粘贴。通过企业级分布式应用服务,我们将开店流程模块化,从而大幅缩短了新店从签约到开业的周期。一些超级加盟商能够同时开设多家店铺,仅需携带 12 名运营督导,其余事宜均可在云端完成。


二、云原生是企业数字化建设的最短路径


在数字化建设的道路中,鸣鸣很忙凭借阿里云的全栈云原生方案,成功实现了从 传统单体架构敏捷云原生架构的华丽转身。这一转型有力地支撑了其在促销活动期间应对流量洪峰,以及快速迭代业务功能的需求。


我们的核心业务使用了阿里云的诸多云原生产品,包括微服务引擎 MSE、消息队列 RocketMQ、应用实时监控 ARMS、日志服务 SLS、容器服务 ACK、云原生数据库 PolarDB/PolarDB-X,还有一些云安全产品等。


选择阿里云的云产品,主要基于以下的考量:


  • 全栈的技术整合能力,从容器、微服务到监控,提供了一站式方案,极大地避免了多平台集成的复杂性,有效降低了技术栈碎片化的风险。
  • 从可靠性、成本效益性以及安全合规性等多维度出发,阿里云的产品组合为我们全面打造了一个坚实可靠的基础设施服务平台,助力我们在数字化道路上稳步前行。


在应对业务快速增长过程中,我们通过容器化和微服务化实现技术架构升级,其中,整体资源利用率提升 40%,研发迭代效率提高 30% 以上。通过 MSE 云原生网关统一多层网关架构(原流量/微服务/安全网关),实现 QPS Nginx 提升 40% 以上,HTTPS 性能提升 80%,故障排查效率提升 50%。


由于业务全面容器化和微服务化过程中,给业务带来了更多的运维复杂度,为了更及时、高效的观测整个 IT 系统,鸣鸣零食借助阿里云应用实时监控服务 ARMS、日志服务 SLS、云监控 CMS 的全栈可观测方案,构建完整了的端到端可观测体系,实现四层监控覆盖:用户体验层应用服务层中间件层资源层;实现了分钟分故障定位能力,告警准确率提升至 98%


除了日常运营,我们还有大量的营销活动,比如我们去年举办的「周杰伦代言」的营销活动中,全网曝光超过 25 亿次。百万级 QPS 的情况下,整体平稳运行抗住流量峰值,这个过程我们获得了阿里云的大力支持。


在活动筹备初期,我们借助 PTS 模拟千万级用户行为,提前发现 12 处性能瓶颈且提前验证服务可用性与资源容量预估。在活动过程中,Grafana 驾驶舱实时监控 200+ 核心指标。完整的可视化大盘和驾驶舱,以及 MSE 网关的自动弹性扩容等技术,为活动的顺利落地保驾护航,让业务稳定性看得见摸得到


三、上万家门店的数据同步和一致性,如何保障


鸣鸣很忙为了实现总部管理万家门店的经营模式,采用"中心化管控+分布式业务"混合架构的数字化体系。其中,会员、订单、商品、库存等核心业务系统,通过阿里云的保障,可以支撑日均 500 万级的交易数据。


我们的关键事务场景有订单支付、库存扣减、积分变更等强一致性业务,鸣鸣很忙采用了云消息队列 RocketMQ 事务消息实现跨服务最终一致性。基于数据强一致性的要求,我们做了 3 层保障体系:


  • 业务层:本地事务+消息表机制。
  • 消息层:自动重试/死信队列/消息轨迹追踪。
  • 监控层:基于云消息队列 RocketMQ 的实时追踪消息积压与消费延迟监控能力。


从而进一步提升了整个系统的稳定性和性能。


四、日均 >430 万级交易数据下的消费者体验,如何保障


在大数据与智能化的背景下,鸣鸣很忙通过以下 3 个方式提升消费者体验:


  • 数字化门店管理:借助数字化系统,实现门店从品类分析到营运管理的标准化,缩短开店周期,简化陈列流程,量化采购规模,降低运营成本。数字化门店管理采用微服务架构,并托管在阿里云微服务引擎 MSE 上,提升性能和稳定性。
  • 数图可视化品类管理系统:利用大数据分析优化陈列,结合门店资源与销售能力生成陈列图,经门店执行后反馈总部核验。面对大规模数据处理需求,采用阿里云的云消息队列 Kafka 版与 Spark 流计算引擎,实现数据实时捕捉与处理,提升系统响应速度与灵活性。
  • 终端应用监控优化:通过阿里云应用实时监控服务 ARMS - 用户体验监控,实时掌握 WebH5、小程序的 PV/UV、首次渲染耗时等性能指标,及时发现并解决 JS 错误、API 请求错误等问题,从页面打开速度、稳定性和外部服务调用成功率三个方面提升用户体验。


五、规模越大,越关注 IT 成本和运营效率


IT 成本优化上,主要基于 Kubernetes 的智能弹性(如 AHPA 预测扩缩容)弹性资源管理降低冗余成本 30% 以上,并结合 ECI 的弹性容器实例,实现秒级资源响应,资源利用率提升 30%-50%。基于阿里云智能化成本治理工具,实现资源水位分析和多维度成本洞察和优化实现成本趋势预测,给出优化建议降低成本。


运营效率上,基于云原生的开发范式(如容器化、DevOps 流水线),标准化应用交付流程提升研发效率提升达 30% 以上、业务连续性保障我们系统可用性达到 99.95 以上。


此外,我们在技研发团队全面启用通义灵码。研发团队使用覆盖率超过 60% 以上了,代码生成占比超过 30% 以上,智能补全采纳率超过 40% 以上。核心的场景主要在:单元测试场景、代码注释、代码优化、研发智能问答文档生产等场景;


  • 提升编码效率:通过代码大模型辅助编程,大幅提升研发人员的工作效率,实现人效提升。
  • 代码质量增强:借助单元测试AI自动生成技术,将质量管控左移,显著提高代码质量。
  • 盘活研发资产:激活数字化转型过程中沉淀的规范文档和代码样例库,提高代码规范性,减少重复开发,进一步提升研发效率。


六、AI 时代,鸣鸣很忙数字化的未来规划


产研发团队但需求分析、设计、编码环节,会逐步提升智能化的覆盖率,通过阿里云通义系列模型来协助数字化产品和研发来理解需求、更高效的设计产品方案,甚至自动生成部分代码片段,提高研发效率。我们还会将智能化的技术应用于终端门店,例如通过 AI 智能称实现商品的快速识别与称重,整合运营平台,实现商品的批量及大小码管理,门店运营和收银效率。其他技术规划还包括:


  • 深化 AI 应用:鸣鸣零食已经在门店收银结算、收货、远程巡店等环节应用了 AI 技术,如智能秤、AI 视频巡检等,未来将继续深化 AI 在业务中的应用,提升运营效率。例如,智能秤可以识别散称商品的 SKU,无需手动输入编码,大幅提高收银效率。
  • 智能化供应链:利用 AI 技术实现供应链的智能化决策和精细化管理,如智能订货功能,通过对门店销售情况的预测,智能规划采购时间和数量,优化库存周转和商品满足率。
  • 技术融合:强调 ITDT AI 的融合,推动技术与业务的深度融合,实现从数字化到智能化的转型升级。
相关文章
|
存储 运维 开发工具
警惕日志采集失败的 6 大经典雷区:从本地管理反模式到 LoongCollector 标准实践
本文探讨了日志管理中的常见反模式及其潜在问题,强调科学的日志管理策略对系统可观测性的重要性。文中分析了6种反模式:copy truncate轮转导致的日志丢失或重复、NAS/OSS存储引发的采集不一致、多进程写入造成的日志混乱、创建文件空洞释放空间的风险、频繁覆盖写带来的数据完整性问题,以及使用vim编辑日志文件导致的重复采集。针对这些问题,文章提供了最佳实践建议,如使用create模式轮转日志、本地磁盘存储、单线程追加写入等方法,以降低日志采集风险,提升系统可靠性。最后总结指出,遵循这些实践可显著提高故障排查效率和系统性能。
209 20
|
28天前
|
弹性计算 运维 监控
资源利用率提升50%:Serverless 驱动国诚投顾打造智能投顾新范式
通过与阿里云深度合作,国诚投顾完成了从传统 ECS 架构向云原生 Serverless 架构的全面转型。新的技术架构不仅解决了原有系统在稳定性、弹性、运维效率等方面的痛点,还在成本控制、API 治理、可观测性、DevOps 自动化等方面实现了全方位升级。
249 20
|
19天前
|
安全 druid Nacos
0 代码改造实现应用运行时数据库密码无损轮转
本文探讨了敏感数据的安全风险及降低账密泄漏风险的策略。国家颁布的《网络安全二级等保2.0标准》强调了企业数据安全的重要性。文章介绍了Nacos作为配置中心在提升数据库访问安全性方面的应用,并结合阿里云KMS、Druid连接池和Spring Cloud Alibaba社区推出的数据源动态轮转方案。该方案实现了加密配置统一托管、帐密全托管、双层权限管控等功能,将帐密切换时间从数小时优化到一秒,显著提升了安全性和效率。未来,MSE Nacos和KMS将扩展至更多组件如NoSQL、MQ等,提供一站式安全服务,助力AI时代的应用安全。
125 14
|
17天前
|
人工智能 JSON 自然语言处理
Function AI 工作流发布:以 AI 重塑企业流程自动化
本文介绍了基于函数计算 FC 打造的全新 Function AI 工作流服务,该服务结合 AI 技术与流程自动化,实现从传统流程自动化到智能流程自动化的跨越。文章通过内容营销素材生成、内容安全审核和泛企业 VOC 挖掘三个具体场景,展示了 Function AI 工作流的设计、配置及调试过程,并对比了其与传统流程的优势。Function AI 工作流具备可视化、智能性和可扩展性,成为企业智能化转型的重要基础设施,助力企业提升效率、降低成本并增强敏捷响应能力。
350 28
|
13天前
|
传感器 人工智能 IDE
通义灵码用户说 | 编程智能体+MCP加持,秒查附近蜜雪冰城
通义灵码现已全面支持Qwen3,新增智能体模式,具备自主决策、环境感知、工具使用等能力,可端到端完成编码任务。支持问答、文件编辑、智能体多模式自由切换,结合MCP工具与记忆功能,提升开发效率。AI IDE重构编程流程,让开发更智能高效。
208 20
|
2月前
|
人工智能 Java Nacos
开启报名|Nacos3.0 开源开发者沙龙 Agent&MCP 专场
Nacos3.0 开源开发者沙龙 Agent&MCP 专场,本次活动是 Nacos 社区成员今年首次线下分享最新的能力和实践,并邀请了 Spring AI Alibaba 和 Higress 一起分享一站式的开源解决方案。欢迎大家来现场交流。
112 16
|
14天前
|
人工智能 数据库 决策智能
《Data+AI驱动的全栈智能实践开放日》线上直播来了!
阿里云瑶池数据库生态工具全新发布,首次推出Data Agent系列产品,助力数据在AI时代“活起来”。活动聚焦Data+AI创新实践,涵盖数据治理到智能决策全链路解决方案。连续3天直播,研发专家分享如何用AI优化数据库性能、实现分钟级洞察及构建智能分析平台。
|
20天前
|
SQL 人工智能 Java
阿里云百炼开源面向 Java 开发者的 NL2SQL 智能体框架
Spring-ai-alibaba-nl2sql 是析言 GBI 产品在数据问答领域的一次重要开源尝试,专注于 NL2SQL 场景下的核心能力开放。
387 48
|
19天前
|
人工智能 安全 Java
AI Agent 的工程化被低估了
本文探讨了AI应用工程化的关键作用与实现路径,将其分为产品工程和技术工程两大部分。产品工程关注用户体验与交互设计,包括需求建模、UI/UX设计、系统提示词优化及反馈闭环构建,确保AI“能用、好用”。技术工程则聚焦系统稳定性与扩展性,涵盖架构模块化、工具调用机制、流量控制、数据管理及可观测性建设,保障AI应用“快、稳、强”。两者协同决定了AI Agent的实用性与规模化潜力,为行业提供了落地参考。
374 30
AI Agent 的工程化被低估了