武汉燎原火信息技术B2B门户系统架构设计与高并发实践
从单体到分布式：B2B门户的架构演进之路
在服务制造业客户的过程中，武汉燎原火信息技术有限公司发现传统B2B门户的瓶颈往往不在业务逻辑，而在IO模型与数据一致性策略。早期我们为某汽配客户搭建的单体应用，在300并发下就出现连接池耗尽，这促使团队彻底重构了系统底层。
核心架构分层与关键参数
当前我们采用的架构分为四层：接入层（Nginx+Lua）→ 应用层（Spring Cloud Gateway集群）→ 服务层（Dubbo + 自定义线程池）→ 存储层（MySQL分片 + Redis Cluster）。其中线程池参数经过压测调整为核心数×2+1，队列长度设定为2048，拒绝策略采用CallerRunsPolicy以牺牲部分吞吐保障关键订单不丢失。
针对商品检索这类高频接口，我们直接使用Redis的ZSET存储热数据，配合Caffeine本地缓存做二级缓存，命中率稳定在92%以上。而库存扣减则通过Lua脚本封装原子操作，避免超卖——这套方案在去年双十一期间支撑了单日870万次写请求，平均响应时间控制在47ms。
高并发下的三大实践细节
首先是连接池动态化。我们放弃了固定连接数，改为根据CPU使用率与活跃连接数比率动态调整Druid连接池大小，避免流量突刺时频繁建连。其次是异步化改造，所有非核心链路（如日志、短信通知）都走MQ异步削峰，使用RocketMQ的事务消息保证最终一致性。
另一个容易被忽略的点是GC调优。在8G堆内存的JVM参数中，我们采用G1收集器并设置-XX:MaxGCPauseMillis=50，同时将大对象直接分配至老年代，减少了Young GC的停顿频率。
注意事项：别让架构成为负担
很多团队容易陷入微服务拆分的误区。我们遇到过客户把十几个简单查询也拆成独立服务，导致调用链超过5层，故障排查成本剧增。建议按业务变更频率而非数据表来划分服务边界，且必须配套全链路压测环境。另外，分布式事务尽量用事务消息+状态机代替Seata之类的强一致方案，否则性能损耗会抵消架构优势。
对于中小型B2B平台，若日活低于5万，其实单体+读写分离往往比微服务更经济可靠。武汉燎原火信息技术有限公司在前期需求调研时，会优先帮客户计算峰值QPS和RT目标，而不是盲目堆砌技术栈。
常见问题与应对策略
- 缓存穿透：采用布隆过滤器预判无效key，并设置短过期时间（如30秒）兜底。
- 热点key打爆单节点：将热点key复制为多个带随机后缀的副本，分散到不同分片。
- 数据库主从延迟：对实时性要求高的读操作强制走主库，并利用canal监听binlog异步更新缓存。
架构没有银弹，只有契合业务场景的取舍。武汉燎原火信息技术有限公司始终坚持用压测数据说话，每季度都会针对客户系统进行容量评估与参数调优。如果您的门户正面临性能瓶颈，不妨从线程池参数和缓存策略入手自查——往往这几项调整就能解决80%的问题。我们乐于分享更多实战经验，也欢迎同行交流指正。