做企业管理软件这行十几年，最怕听到客户说"先按小团队做，以后不够再扩"。架构这东西，改起来伤筋动骨。业务规模决定了技术选型的边界，选错方向，后期每加一个功能都是填坑。

业务规模如何倒逼架构决策

20人以下的团队，一套单体Spring Boot加MySQL，两周就能跑通核心流程。但到了200人规模，部门墙出现，审批流、权限模型、数据隔离需求暴涨，还硬扛单体就是在给自己埋雷。**微服务不是万能药，但服务拆分的临界点通常出现在团队规模超过50人、日均请求破10万次的时候。**

三个维度判断你的架构拐点

• 并发量：日活低于5000，单体足够；超过2万，考虑读写分离和缓存层
• 业务耦合度：如果订单和库存逻辑改一处动全身，说明该拆了
• 部署频率：每周发版超过3次且互相阻塞，微服务或模块化架构更合适

实操中的技术组合策略

中小型企业做系统定制，推荐"模块化单体+API网关"过渡方案。数据库按业务域分库，应用层保持单体部署，既降低运维成本，又为后续拆分留好接口。大型企业则适合领域驱动设计，配合容器化部署，把软件开发的迭代周期从月压到周。

我们给一家制造企业做过测算：单体架构下每次发版平均耗时4.2小时，拆成6个微服务后降到38分钟，但运维复杂度上升了约3倍。这个账要算清楚。

数据对比：不同规模的技术选型参考

• 50人以下：单体+关系型数据库，年运维成本约3-5万
• 50-200人：模块化单体或粗粒度微服务，成本8-15万
• 200人以上：完整微服务+DevOps体系，成本20万起步

无论选哪种架构，网站开发和企业管理软件的边界正在模糊。前端统一用Vue或React，后端按规模分层，这套思路目前最稳。技术服务的价值不在于堆技术栈，而在于帮企业找到那个"刚好够用、留有余地"的平衡点。