新技术负责人一开口就是微服务、分布式、中台，客户听得云里雾里，预算却实打实往上涨。给中小客户做小程序定制这些年，我的经验很朴素：架构够用就好，超过业务规模半代的架构都是浪费。
九成的小程序，单体架构足够
日均订单千单以内、用户量十万以内的项目，一台四核八G的服务器加一套单体后端完全撑得住，MySQL加Redis的组合跑了多少年没出过大问题。这种架构的好处肉眼可见：开发快，一个后端工程师两周能搭出主体；部署简单，出问题十分钟内能定位；维护便宜，一年服务器费用三四千块。日营业额几十万的门店、客单价百元的电商、预约制的服务行业，全在这个范围里。说到底，小程序定制的架构选型要跟着业务量走，不是跟着技术潮流走。
什么时候才需要拆
真正的分界线不是感觉，是数据。当单台服务器扛不住高峰并发，比如秒杀、直播带场景，或者团队超过十个人要并行开发，微服务的拆分才开始划算。到那个阶段，也不是全面推翻重来，常见的做法是把订单、支付这类高压力模块单独拆出去，其余照旧。架构演进是长跑，不是起跑就冲刺。
见过一个教训：某客户听信供应商推销，八十人天的预算里二十人天花在搭建分布式框架上，上线半年日活不到一千，那些架构能力一次没用上。省下的十五个人天，够他把会员体系打磨得细致一倍。
还有一个判断角度容易被忽略：团队水平。三个熟练工程师的单体架构，往往比五个人现拼的微服务稳定，架构复杂度每升一级，对人的要求就不是线性增长。小团队硬上复杂架构，出了问题连排查的人都凑不齐，这是比费用更现实的风险。
签约前问三个问题
判断服务商给的架构方案靠不靠谱，问三个问题就够。第一，预计的并发峰值是多少，依据是什么数据。第二，这个架构支撑到什么量级需要升级，升级的路径是什么。第三，架构相关的人天占了多少，能不能砍。答不上来或者含糊其辞的，方案八成是照模板抄的。这三个问题不需要标准答案，要的是推导过程，有数据、有路径、有取舍，说明对方是真想过的。
比格网络做架构选型有个习惯，先看客户未来一年的业务数据预测，再定方案，从不为了炫技上重架构。给你的建议两条：让方案里出现具体数字，出现不了就退回去重做；把架构升级的触发条件写进合同，到量了再升级，钱一步一步花。
