SCM基础设施架构转型趋势 - 超过60%的头部制造与零售企业正在将SCM从单体架构剥离，转向微服务化、中台化的新架构范式[1] - SCM基础设施分为三层：接入层（BFF+API网关）、通信层（消息队列）、治理层（注册中心、配置中心、缓存）[2] - 架构转型的核心是将业务特性、团队能力和成本约束三者对齐，找到平衡点[11] BFF层选型策略 - BFF核心价值在于多端适配，仓库PDA与总部PC仪表盘对库存视图需求差异极大[2] - 三种落地模式：前端自维护（适合10人以上前端团队）、统一BFF网关（适合中小组）、轻量级编排层（适合复杂流程）[3] - 若系统存在3种以上差异明显前端且接口字段差异超50%，建议引入独立BFF层[3][15] API网关选型方案 - API网关承担鉴权、限流、熔断、路由、日志采集等横切关注点[4] - 纯Java技术栈首选Spring Cloud Gateway，与Nacos/Sentinel无缝集成[4] - APISIX基于etcd热加载路由，单核QPS可达18000+，适合大促期间流量暴涨的SCM系统[4] - Envoy+Istio适合已有Kubernetes经验的团队，同时解决南北向和东西向流量治理[4] - APISIX性能更高（单核QPS高约50%），Kong插件生态更成熟[18] 消息队列场景化选型 - 核心交易链路（订单、库存、支付）推荐RocketMQ，事务消息机制解决分布式事务最终一致性[5] - 日志与数据分析（操作审计、IoT传感器数据）推荐Kafka，分区并行+顺序写入吞吐量无可匹敌[5] - 简单任务分发用RabbitMQ降低运维成本，多套并存是理性选择[5] - RocketMQ事务消息原理：半消息+本地事务执行+回查机制[16] 配套基础设施选型 - Nacos同时提供注册中心和配置中心能力，在Java生态中几乎成为事实标准[6] - 新项目建议优先选Nacos（Java栈）或Consul（多语言栈），Eureka正逐渐边缘化[6] - Redis集群承担热点数据缓存、分布式锁和会话存储，库存类数据应使用主动失效+版本号而非简单TTL过期[7] - Redis缓存穿透解决方案：缓存空值（短TTL）+布隆过滤器前置拦截无效Key，热点Key加互斥锁防击穿[17] 选型决策框架与反选原则 - 不选"银弹"：没有组件能完美覆盖所有场景，试图用一个网关解决全部流量治理是架构腐化的开始[8] - 不选团队不会运维的：技术选型的终极约束是团队能搞定的技术[9] - 不选过度超前的：日均5000单和500万单的架构完全不同，不要为未来可能需要而引入豪华套餐[10] - 小团队SCM微服务最小组件集：Nacos+Spring Cloud Gateway+RocketMQ+Redis，可满足日均十万级订单量[19] 未来技术展望 - API网关将从静态规则走向AI驱动的动态路由，头部电商平台已进入验证阶段[12] - SCM将从同步调用链逐步转向完全的事件驱动架构，消息队列升级为核心骨干[13] - 仓储IoT设备普及推动系统向云边端三级演进，边缘网关需承担实时计算与本地自治能力[14]