2025年表现不佳的软件架构决策

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家 

四项在当初做出时合情合理、如今却大规模产生技术债务的架构选择。

软件架构本质上是对未来的一系列押注——押注系统将来需要做什么、以何种规模运行、在哪些约束条件下运作，以及由什么样的团队来维护。

其中一些押注经受住了时间的考验，另一些则不然。

以下四项架构决策，在各自的时代都是可以理解的——甚至常常被热情地奉为最佳实践。然而如今，它们正为其采用组织带来显著的运维成本。而那些能够及早识别并着手解决这些问题的组织，正在重新夺回多年来被悄然吞噬的交付速度。

1. 在错误的规模上采用微服务

微服务运动确实为那些在特定规模下运营的组织带来了实质性改进——当分布式、可独立部署的服务能够真正缓解实际运维约束时。对于拥有数百名工程师、技术需求复杂且多样化的大型组织而言，微服务架构确实实现了团队的独立扩展、隔离部署以及有意义的技术多样性。

但对于规模较小的组织，以及处于早期阶段的大型组织来说，许多微服务的采用都属于过早优化。分布式系统的复杂性、服务间通信的开销、运维数十个独立部署服务所带来的负担，以及原本是函数调用、如今却变成网络调用所引入的延迟，这些成本只有在组织达到一定规模后才值得承担，而当时这些组织尚未达到该规模。

如今在整个行业中显而易见的后果是：大量工程团队正在运维所谓的“分布式单体”——这类系统具备微服务的运维复杂性，却不具备足以支撑这种复杂性的团队规模或技术异构性。

这些团队如今面临的决策并不简单。架构已然成型，各服务已积累大量运维历史，彼此之间的依赖关系也使得整合工作变得棘手。但那些能够诚实地根据自身实际规模和运维现实重新评估微服务架构的团队，一致发现：将紧密耦合的服务进行整合，可以在不显著牺牲架构本应提供的灵活性的前提下，有效降低运维开销。

2. 万事皆用 MongoDB

2010 年代初期兴起的 NoSQL 热潮催生了一代基于文档数据库（尤其是 MongoDB）构建的应用程序。这些数据库因其灵活性和对开发者的友好性而被选用——在产品开发初期，模式的流动性确实至关重要。

十年之后，许多此类应用程序已经演进到模式实际上趋于固定、数据关系变得复杂且清晰明确的阶段，此时文档模型的灵活性已不再是首要关注点。这些应用现在真正需要的是事务一致性、复杂的查询能力，以及文档数据库刻意回避的关系型数据模型。

迁移成本是真实存在的——并非因为文档数据库在技术上劣于关系型数据库，而是因为多年积累在文档模型中的数据无法干净利落地转换为关系型模式，且围绕文档语义构建的应用逻辑也需要重构。

最有效地应对这一问题的团队，并非试图一次性完成整个数据库的迁移。他们采取渐进策略，针对数据模型中关系语义最为关键的部分引入关系型存储，同时继续保留文档模型用于其他部分。