"系统支持亿级流量"——这大概是企业商城选型时最容易被滥用的一句话。本文拆三个问题：谁在说？怎么定义的？你的商城真的需要吗？

作为做了十年企业商城的团队，我们看过太多被"亿级"两个字忽悠的客户——买了能扛亿级流量的系统，实际日PV不到10万，多余的服务器成本比软件授权费还高。本文不吹数字，讲真实的流量水平、隐藏的成本结构和架构的选择逻辑。

一、"亿级"的三种口径——不说口径的数字是营销

二、企业自建商城的真实流量——不是"能扛"，是"需要"

基于万米服务的中大型企业客户的实际运行数据：

绝大多数企业自建B2B商城的日PV在万到十万级别，峰值QPS在三位数。这不是SBC的能力上限——这是企业自建商城的客观流量现实。一个央企福利商城的用户就是它自己的员工——5万到20万人。人不会变多，流量不会诡异地暴涨。为不存在的"亿级峰值"采购大量服务器——ROI是负的。

三、真正的性能挑战——不是QPS

对于企业自建商城，影响用户体验的性能问题，按实际频次排序：

1. 购物车算价——B2B的定价引擎比B2C复杂10倍。B2C结算时：商品原价 - 促销价 = 最终价。B2B结算时：客户身份价 → 区域价 → 等级价 → 阶梯价 → 协议价 → 业务员折扣 → 促销满减——六到七层计算链路。一个购物车20件商品 = 20×7=140次定价查询。如果算价引擎不是预计算+缓存组合，用户体验的是"结算转圈10秒"——不是"QPS不够"。

2. 大促弹性伸缩——一年只有7天需要峰值。春节前3天、中秋前2天、双11当天——福利商城和集采商城的流量是平时的3-5倍。为这7天常年备3-5倍的服务器——年化ROI不到2%。正确的架构是支持弹性扩缩——平时跑在基础集群上，大促期间自动扩容，结束后自动缩回。

3. 报表实时性——千万级福点流水的聚合。集团运营要看"各子公司本月福利发放汇总""各员工年度台账""福点消费品类分布"。千万条福点流水+百万条订单——不做ES搜索集群和预聚合，一个查询SQL跑30秒。这不是QPS问题——是数据量大+多维度聚合的性能问题。

4. 多端一致性——同一商品在PC/H5/小程序三端的价格、库存和标签必须实时一致。加服务器不解决一致性问题——分布式事务和最终一致性方案才是核心。

四、SBC架构能不能扛大流量——能，但不是为了吹数字

SBC的架构设计确实具备扩展能力——微服务独立部署、BFF聚合层按端（PC/H5/小程序）隔离、Redis+Redisson分布式缓存、ShardingSphere分库分表、ES搜索和聚合独立集群、RocketMQ异步削峰。合理配置下可支撑千级QPS，全集群万级QPS——对任何企业自建商城场景都远超实际需求。

但SBC的选型思路不是"把QPS堆到最高"。而是"在中大型企业的实际并发和峰值需求下，保持架构的清晰度和可维护性，并为大促弹性扩缩做好预留"。我们的客户最关注的是三件事——平常促销日购物车算价不卡（影响成单率）、大促高峰期不崩（影响发放体验）、实时报表刷得快（影响管理决策）。这三件事的优先级远高于"理论上能扛多少QPS"。

五、隐藏成本——你不需要的东西最贵

最容易被忽略的是"为不需要的流量所支付的隐藏成本"：

• 服务器成本：为"亿级"准备的服务器集群，实际利用率不到20%。剩余80%的算力闲置——但又不能不用，因为合同里写了"支持亿级"
• 运维成本：集群越大，运维越重。监控、报警、日志、安全——每个环节都需要专业运维。自建团队？招人+培训+流失——年化成本不低于百万
• 复杂度成本：架构越复杂，出错概率越高。分库分表的分片键选错——迁移代价是重做大半业务逻辑。引入K8s但团队没有K8s经验——上线后天天在处理Pod重启
• 机会成本：把研发资源花在"扛亿级"上，不如投入到六层购物车算价优化、实时报表引擎和弹性伸缩策略——这些才是真实影响用户和管理者体验的能力

在2026年的中国，没有一个企业自建B2B商城需要"亿级流量"。需要的是：价格算得对、订单拆得准、报表出得快、大促扛得住。如果你看到友商的核心卖点是"亿级流量"——要么他们不懂你的业务，要么在用你不需要的参数忽悠你。万米SBC选择了更务实但也更难的路——不是吹QPS，而是把B2B购物车的七层算价引擎优化到毫秒级，把千万福点流水的实时聚合做到秒级，把弹性伸缩做成自动化而非概念。

万米商云 · 南京万米信息技术有限公司 · wanmi.com · 400-025-0992

SBC 技术真相系列
真实并发 · B2B算价引擎 · 弹性伸缩 · 架构务实 · 隐藏成本