2026-07-26 几乎不可能进行软件架构的讨论而不提到微服务。看看我上一篇文章中的讨论就知道了。根据你问的对象，微服务已成为“良好架构”和“过度工程”的默认示例。有趣的是，似乎每个人在见到微服务时都会认出它，但几乎没有人能解释什么实际上构成了微服务。 不可思议的定义 微服务究竟有多小？一个服务是否应该只做一件事？两件？是否有代码行数的上限？一千？一万？没有人能给出令人信服的答案，因为并不存在。行业已经花了多年时间试图通过技术特征来定义微服务，但这些特征意外地模糊和模糊。它们的边界不是通过责任或每日部署数量来衡量的，而是在完全不同的地方衡量的。这就是重要的认识：微服务并不是主要的技术抽象。 真正解决的问题 听听人们通常给出的为什么要摆脱单体的原因：部署速度慢，测试时间太长，构建过程痛苦。这些都是实际问题，但它们并不需要微服务。每一个问题都可以在保持单体的情况下得到改善。那么，组织为何仍然选择迁移？因为瓶颈通常不是技术上的，而是组织上的。随着公司的成长，数十或数百名工程师需要独立工作。团队需要拥有权。他们需要在不不断与其他人协调的情况下，按自己的时间表发布。微服务创建的边界反映了组织的边界。这才是它们真正的价值所在。 每个好处都需要付出代价 工程是管理权衡的艺术。微服务也不例外。你获得了自主性，但失去了集中化。在单体内部，很容易回答类似“我们正在交付哪些依赖？”或“这段代码还在使用吗？”这样的问题。静态分析通常可以告诉你。一旦代码分散到数十个独立服务中，这些答案就变得难以获得。这样的模式到处都在重演。函数之间的通信变成了通过网络的通信。方法调用变成了HTTP请求。编译错误变成了运行时失败。每个分布式系统问题——延迟、重试、部分失败、序列化、一致性——突然成为了你应用程序的一部分。这些成本并不令人惊讶。它们只是你为分布式系统提供的灵活性所支付的代价。 隐藏的通信成本 当人们谈论通信开销时，他们通常会想到API之间的交互。这只是部分故事。团队现在也必须进行沟通。更改API不再是一个重构，而是一次谈判。消费者需要提前通知。版本控制变得必要。在每个人迁移期间，旧版本必须保持活跃。数据库更改变成了协调工作的努力，而不是简单的提交。软件不再是唯一分布式的东西。决策也是。 基于正确的理由选择它们 以上这些并不是反对微服务的论据。在合适的环境中，它们是极好的架构选择。许多成功的公司根本无法在没有它们的情况下运作。但值得诚实地谈论它们为何有效。如果你的主要问题是组织扩展，微服务可能正是正确的答案。如果你的问题纯粹是技术性的，则应首先问自己是否正在寻求一个远远超出问题本身的解决方案。一旦我们停止假装微服务是魔法技术工具，架构就变得更容易推理。它们是具有技术后果的组织工具。我制作了这个论点的视频版本，如果你更喜欢观看：微服务到底是什么？感谢阅读。