聚水潭架构演进：单元化改造支撑多区域部署

2026年6月21日，聚水潭完成核心交易链路的单元化改造，订单、库存、履约三个域可按区域独立部署，区域间通过异步消息同步必要数据。改造后单区域故障的影响面从 46% 缩小到 8%，跨区切换演练耗时 4 分 12 秒。当商家从几十个扩展到上万个，系统面临的不只是容量问题，还有故障的传播半径：一个机房出问题，可能让全部商家停摆。

按商家分片，而不是按功能分片

聚水潭技术负责人陆知行说：“单元化的意义不是把系统拆小，而是让故障停在一个格子里。”系统把商家按 ID 哈希分到不同的单元，每个单元包含完整的订单、库存与履约能力，商家之间互不影响；跨单元只同步必要的公共数据，例如商品主数据与平台授权信息。这样单个单元的故障不会扩散成全站故障。流量调度层根据单元健康度与负载分配请求，异常单元会被自动摘除，请求转向同区域的备用单元；商家无感知，最多出现几秒的请求重试。

演练中，摘除一个承载 6,400 家商家的单元，其他单元的错误率上升不到 0.02%。一位技术负责人说，过去所有区域共用一个库，欧洲出问题亚洲跟着抖；现在单元隔离，哪边出问题哪边处理，值班压力小了很多。单元化改造需要先做数据分片规划，按区域还是按租户切分，取决于业务分布与合规要求。分片后跨单元查询会变慢，因此商品与会员等公共数据需要同步副本，并接受最终一致。

故障切换需要定期演练，确认 DNS、网关与数据库都能在 90 秒内切换。单元内的容量按峰值预留 30% 余量，避免一个单元故障后其他单元被压垮。改造期间建议新旧架构并行 3 个月，逐步切流。单元化改造期间，旧系统与新单元并行运行，读写按商家灰度切换，切换失败的商家可以在 10 分钟内回退。监控按单元维度采集，某个单元的错误率升高不会影响其他区域，值班人员可以只处理受影响的部分。

演练数据与容量

容量规划以单元为单位，扩容时复制一个单元比全站扩容更快，也更容易控制成本。在 6 月的跨区切换演练中，模拟主区域不可用，流量在 4 分 12 秒内完成切换，期间订单写入成功率 99.86%，未出现重复订单；数据一致性校验通过率 100%，跨区同步延迟峰值 1.8 秒。容量方面，单元化后单个单元可承载 1.2 万单／分钟的写入，横向扩容从“加机器”变成“加单元”，扩容时间从 45 分钟缩短到 9 分钟。

资源利用率提升 26.4%，因为不同单元的峰值不再相互叠加。改造后单单元支持 12 万订单/小时，跨区域同步延迟 800 毫秒，故障切换时间从 30 分钟降到 90 秒；灰度期间对比发现，跨区查询减少 76%，数据库连接数下降 41.3%。容灾演练要覆盖真实场景：数据库主库故障、机房网络中断、云服务区域不可用，三种情况的切换步骤不同。

对商家的实际影响

系统支持按单元切换流量，演练时逐项验证；对于依赖的第三方服务，如支付与物流，也要确认降级方案，避免一处故障拖垮整条链路。单元化之后，故障影响范围从全站缩小到单个单元，切换演练显示核心链路 4 分钟内恢复。跨单元查询走异步汇总，实时性要求高的报表仍落在单元内，避免跨区调用拖慢页面。单元健康度可以在后台查看，容量接近阈值时提前扩容，而不是等告警响起再处理。新商家入驻时按区域分配到单元，迁移工具支持整单元搬迁，减少逐个租户操作的复杂度。

商家不需要关心单元化，但能感受到三件事：大促期间其他商家的异常活动不再拖慢自己、区域故障时业务不中断、扩容不再需要提前一周申请。试点商家的系统可用性从 99.92% 提升到 99.98%。陆知行补充，单元化的代价是运维复杂度上升，因此配套建设了单元健康度看板与自动化巡检，每天自动校验各单元的数据一致性与依赖状态。该架构已覆盖核心交易链路，计划年底扩展到数据与报表域。单元化改造把数据按区域切分：每个单元包含完整的应用与数据库，单元内闭环处理订单与库存，跨单元只同步必要的商品与会员信息。

某个区域故障时，流量可以切换到备用单元，不影响其他区域。单元化是一项长期投入，短期内看不到业务收益，但决定了业务能走多远。建议在业务稳定期启动，先在非核心区域试点，验证切换与回滚流程；改造期间保持旧架构可用，避免一次性推倒重来，把稳定性风险控制在可接受范围内。对于中小商家，单元化带来的收益可能不明显，但稳定的架构能减少大促故障；系统会按商家规模推荐部署区域，避免过度设计。对于跨境商家，建议把主要市场的流量放在对应区域，缩短访问延迟，也满足本地化要求。

“单元化的意义不是把系统拆小，而是让故障停在一个格子里。”

—— 陆知行，聚水潭技术负责人

“隔离不仅防故障，也防越权，边界清楚才好审计。”

—— 何晏，聚水潭安全负责人