见过最冤的一笔技术投入：一家二十人的外贸公司，管理系统日活不到五十人，供应商给他上了微服务架构，八个服务加消息队列加容器集群，报价翻倍，运维复杂度直接拉满，改个小功能要动三个服务。后端系统开发的架构选择，先想清楚要不要那么大。
单体不是落后，是默认选项
绝大多数企业的第一个系统，单体架构就是正确答案。一个应用、一个数据库、部署在一两台服务器上，加个功能一天搞定，出问题日志一看就知道在哪。日活几千人以下、团队三五个人，单体的开发效率碾压微服务，这不是保守，是常识。那些成功的大系统，早期也多是单体，业务长出来才逐步拆分。
什么时候才值得拆
- 不同模块负载差异巨大，比如某个报表计算拖垮了整个系统；
- 团队规模上来了，十几个人挤在一个代码库里频繁互相踩；
- 某个模块需要独立扩容，比如促销期间订单量是平时的二十倍；
- 对可用性要求分层，核心下单链路不能被边缘功能拖累。
满足两三条以上再谈拆分，而且先从最容易出瓶颈的一块拆，别一口气切八个服务。架构是长出来的，不是设计出来的，这句话被说烂了但依然是对的。
另外提醒一句，架构选型也影响招人和外包价格：越新的架构，市场上懂的人越少，维护单价越高。团队将来谁来接手，这个问题想清楚了，选型自然就务实了。中小企业的系统，务实比先进重要，跑得稳、改得动，就是好架构，这句话值得贴在墙上。
更该早投入的三件小事
比起追架构潮流，这些事性价比高得多：数据库做好备份和慢查询监控，出事能恢复、慢了能发现；代码分层写清楚，业务逻辑别散落一地，为将来拆分留余地；日志和告警配好，系统挂了五分钟内有人知道。后端系统开发的稳定性，九成靠这些不起眼的基本功，跟用什么架构关系不大。
两条建议：供应商一开口就是微服务、分布式、中台的，让他先证明你的业务量配得上这套东西；把预算花在数据备份、监控和代码质量上，比花在架构名词上划算。比格网络给客户做系统评估时，第一件事就是看业务量和技术方案的匹配度，杀鸡用牛刀的钱我们不建议花。
