近两年，丽江本地不少文旅、零售类企业在推进软件定制项目时，常遇到一个尴尬局面：系统上线三个月，业务量一涨，单体应用就开始卡顿，改一处代码牵动全身。这背后，往往是架构选型阶段埋下的隐患。

微服务不是万能药，但有些场景非它不可

当订单、库存、结算等模块耦合在一个WAR包里，每次发布都得全量重启。我们复盘过三个失败案例，共同点是：业务边界模糊时就急于拆分服务，结果分布式事务拖垮了开发效率。

落地时真正要算的三笔账

• 运维成本账：服务数量超过15个后，没有统一日志和链路追踪，技术运维团队70%时间耗在排查问题上。
• 数据一致性账：强一致场景建议保留单体，最终一致场景再引入消息队列。
• 团队能力账：缺乏容器化经验的团队，先从模块化单体过渡更稳妥。

在给丽江某景区做票务系统开发时，我们只拆了检票、库存两个核心服务，其余保持模块化，上线半年零故障。这才是务实的信息化解决方案——不追新，只求稳。

选型建议：从业务反推架构

如果日订单不过万，网站搭建阶段用Spring Modulith做模块隔离足矣。真要上微服务，先确认有没有持续交付流水线和专职SRE。架构是长出来的，不是画出来的。