多大的并发才需要微服务?别再被架构焦虑绑架了

「你们这个架构能撑多少并发?要不要上微服务?」这是做项目时最常被问的问题之一。很多老板和技术人都被架构焦虑绑架:一谈性能就想到微服务,一聊高并发就担心单体撑不住。这篇把并发量级和架构选择讲透,帮你省下不必要的复杂度。

先给一个直觉:大多数业务到底有多少并发?一个日活 10 万的商城,高峰期也就几百 QPS(每秒请求数);一个服务几千家门店的进销存系统,日常并发可能只有几十。而一台配置普通的服务器,单体应用轻松能扛几千 QPS——也就是说,绝大部分业务从并发角度看,单体架构绰绰有余。

单体能扛多少,取决于语言和优化程度。PHP-FPM 传统模型受进程开销限制,单机几百到一千 QPS 就吃力了;Java、Go、Rust 这类语言单机几千 QPS 是常态,配合连接池、异步 IO 还能更高。再加三件套——Redis 缓存、数据库读写分离、静态资源走 CDN——单机单体的天花板还能再翻几倍。瓶颈通常不在应用代码,而在数据库:先把慢查询和索引优化好,比拆服务有用得多。

那微服务什么时候才需要?说句得罪人的实话:微服务解决的从来不是并发问题,而是组织和协作问题。真正的信号是:团队大到几十人,模块边界清晰、各自独立交付;不同模块发布节奏完全不同;某个模块流量特别大需要单独扩容;某个模块挂了不能拖垮全局。如果你的系统只有几个人维护、业务还在快速变化,微服务只会带来分布式事务、网络调用失败、链路追踪、部署编排一堆新麻烦——性能不升反降。

中间路线是模块化单体:代码里按业务模块清晰分层,但先部署成一个应用,等某个模块确实需要独立扩容或独立发布时,再把那一个模块拆出去。这也是很多从单体成长起来的公司的路径:不是规划出来的微服务,而是业务逼出来的。

最后给个务实的量级参考:几十 QPS,随便什么架构;几百 QPS,单体 + 缓存 + 数据库优化;几千 QPS,单体水平扩容(多实例 + 负载均衡)+ 读写分离,依然没问题;几万 QPS 且模块边界清晰,这时候再认真考虑拆服务、上消息队列、分库分表。记住:90% 的性能问题出在代码和数据库,不是架构。

对我们做中小企业的软件来说,绝大多数客户的需求,一台服务器 + 一个单体应用 + 好的工程习惯就够了。把省下来的复杂度,换成更快的交付和更稳的维护,才是对客户最负责的做法。