微服务究竟是什么？

# 微服务到底是什么？ — var0.xyz 来源：https://var0.xyz/posts/what-even-are-microservices.html 2026-07-26 如今谈论软件架构，几乎不可能不提到微服务。看看我上篇文章（https://news.ycombinator.com/item?id=48979120）下面的讨论就知道了。微服务已经成为了“优秀架构”和“过度设计”的双重代名词——具体取决于你问的是谁。 有趣的是，每个人看到微服务时似乎都能认出来，但几乎没人能说清楚到底是什么东西让一个服务称得上是“微服务”。 ## 那个不可能的定义 “微”到底要多小？一个服务应该只做一件事？两件？有没有最大代码行数？一千行？一万行？没人能给出令人信服的答案，因为本来就没有。 整个行业花了多年时间试图用技术特征来定义微服务，但这些特征出奇地模糊和含混。边界不是用职责数量或每日部署次数来衡量的。衡量标准完全在别处。 而这正是最重要的认识：微服务首先不是一种技术抽象。 ## 它们真正要解决的问题 听听人们通常给出的脱离单体应用的理由：部署慢、测试时间长、构建痛苦。这些都是真实的问题，但哪一个都不需要微服务来解决。每一个问题都可以在单体内部得到改善。 那为什么组织还是选择迁移呢？ 因为瓶颈通常不是技术性的，而是组织性的。 随着公司规模扩大，几十甚至上百名工程师需要独立工作。团队需要拥有所有权。他们需要按照自己的节奏发布，而不必时刻与其他团队协调。微服务创建的边界正好对应组织边界。这才是它们真正的价值所在。 ## 每一项好处都附带着代价 工程学就是管理权衡的艺术。微服务也不例外。 你获得了自主性，但失去了集中性。在单体应用里，很容易回答像“我们在交付哪些依赖？”或“这段代码还在使用吗？”这样的问题。静态分析往往能告诉你答案。一旦代码分散到几十个独立服务中，这些答案就变得难以获取。 同样的模式随处可见。函数之间的通信变成了网络通信。方法调用变成了 HTTP 请求。编译错误变成了运行时故障。所有分布式系统的问题——延迟、重试、部分失败、序列化、一致性——突然都变成了你应用的一部分。 这些代价没有一个是意外的。它们只是你为分布式系统提供的灵活性所付出的代价。 ## 隐藏的沟通成本 人们谈论沟通开销时，通常想到的是 API 之间的交互。这只是故事的一半。 团队之间现在也得沟通了。 修改一个 API 不再是一次重构，而是一场谈判。消费者需要提前通知。版本管理变得必不可少。旧版本必须在所有人迁移完成之前保持存活。数据库变更变成了需要协调的工作，而不是简单的提交。 如今，被分布式的不仅仅是软件。决策过程也同样被分布了。 ## 为了正确的理由选择它们 这些都不是反对微服务的理由。在合适的环境中，它们是极好的架构选择。许多成功的公司没有它们根本无法运作。 但值得诚实面对它们为什么有效。 如果你的主要问题是组织规模化，微服务可能正是正确的答案。如果你的问题纯粹是技术性的，你首先应该问问自己是否在拿一个远大于问题本身的解决方案。 一旦我们不再假装微服务是神奇的技术工具，架构就变得容易理解得多了。它们是带有技术后果的组织工具。 --- 我也做了一个视频版本，如果你想看的话： 微服务到底是什么？（https://youtu.be/aacClo78H-8） 感谢阅读。