聚水潭ERP架构升级：云原生改造让扩容快至6分钟

2026年10月24日，聚水潭ERP完成云原生架构升级，核心服务容器化率达到92%，扩容时间从42分钟缩短到6分钟，服务器资源成本下降27%，跨可用区故障切换30秒完成。升级覆盖订单、库存、仓储三条核心链路，灰度期间未发生商家侧中断。改造按链路分批推进，先迁订单查询，再迁库存扣减，最后迁仓储作业；每条链路上线前都做了流量切换演练，切换失败可在两分钟内回退。迁移遵循先读后写的原则：先迁查询类流量，观察两周无异常后再迁写入链路；每次切换保留旧集群一周，出现异常可切回，切换脚本可重复执行。灰度按商家分批切换，每批观察四十八小时，重点看接口成功率与页面首屏时间；异常批次自动回退到旧集群，回退过程对商家无感，只是短暂出现两次页面刷新。

ERP系统跑得久，历史包袱就重。聚水潭基础架构负责人赵启明说：“老系统扩容要申请机器、配环境、改配置，一圈下来四十分钟，大促根本来不及。”云原生改造把部署单位从虚拟机换成容器，把配置从文件搬到配置中心。老系统的配置散落在几十台机器的文件里，一次扩容要改七八处；改造后配置集中到配置中心，变更可回滚，配置漂移问题基本消失，排障时也能看到每次变更的操作人。排障方式也随之改变：过去靠登录机器看日志，现在按请求ID串联各服务调用链，一次查询失败的路径能直接看到卡在哪个服务、耗时多少，定位时间从40分钟降到6分钟。容器化之后，发布方式从停机更新改为滚动更新，单实例下线前先摘除流量并等待在途请求结束；一次常规发布的影响时间从十几分钟降到不足一分钟。

容器化92%：扩容6分钟

核心服务拆分为37个微服务，容器化率92%，剩余8%为依赖特定运行环境的旧模块，采用容器内嵌虚拟机方式过渡。扩容由监控指标自动触发，从检测到新实例就绪平均6分钟，最快2分40秒。

资源调度按实际负载动态分配，夜间低谷自动缩容，白天高峰扩容。改造后月度服务器成本下降27%，CPU平均利用率从19%提升到46%。

37个微服务按领域拆分，服务间调用设置超时与熔断，单服务故障不影响主链路；服务注册与发现由平台统一管理，新实例上线自动接入流量，无需人工改配置，也不再依赖运维手工登记。

“云原生不是换个部署方式，而是让扩容、发布、容灾都变成按一下就能完成的事。”

—— 商悦，聚水潭云平台架构师

跨可用区容灾：30秒切换

核心服务在三个可用区部署，数据库采用主备加只读副本架构，主库故障时自动切换，切换时间30秒，切换期间写请求排队最长12秒，读请求不受影响。升级后共演练故障切换6次，全部成功。

对象存储与消息队列采用跨区复制，RPO控制在5秒内。灰度期间发生过一次机房网络抖动，系统在28秒内完成切换，商家侧仅感知到一次页面重试。

数据库按读写分离加分库分表，订单表按店铺哈希分片，单表数据量控制在2000万行以内；跨分片查询走异步汇总，页面先出首屏再补齐统计，深翻页也能在可接受时间内返回。

成本与效率：27%的账单差额

改造成本不只是服务器，还包括人力与工具。团队统计，改造后发布频率从每周1次提升到每周4次，单次发布耗时从52分钟降到9分钟；因环境不一致导致的故障从每月4.2次降到0.3次。

资源成本方面，同等业务量下月度支出下降27%，按当前规模测算每年可节省约420万元；这部分节省被投入到压测与容灾演练中。

成本优化不是简单缩容：团队把夜间批处理迁到低峰时段，把冷数据迁到低频存储，把镜像体积压缩了六成，三项合计贡献了成本下降的一半，剩余部分来自调度策略调整。 云原生架构升级已完成，商家侧无需操作，接口与功能保持不变。下一阶段将把报表与大数据链路迁入同一平台，并开放资源用量看板。需要稳定可扩展的ERP底座，可下载聚水潭ERP。资源用量看板正在内测，商家可查看自己账户的CPU、存储与接口调用趋势，为容量规划与活动备货提供依据，也能提前发现异常的调用突增。容量评审改为按月进行，依据调用量、存储增速与活动计划给出扩容建议；对增长较快的商家账户，团队会提前预留资源池，避免活动当天临时申请。监控指标从机器维度转向服务维度，按接口、依赖与错误类型拆分，告警阈值随历史波动自动调整；同一类告警重复出现时自动合并，避免值班人员被大量重复消息淹没。