What even are microservices?

到底什么是微服务？

2026-07-26 It’s almost impossible to have a conversation about software architecture without someone bringing up microservices. Just look at the discussion over my last post. They have become the default example of both “good architecture” and “over-engineering,” depending on who you ask. 2026-07-26 在讨论软件架构时，几乎不可能不提到微服务。看看我上一篇文章的讨论就知道了。根据询问对象的不同，微服务已经成为“优秀架构”和“过度设计”的默认代名词。

What’s interesting is that everyone seems to recognize a microservice when they see one, yet almost nobody can explain what actually makes something a microservice. 有趣的是，每个人似乎在看到微服务时都能认出它，但几乎没有人能解释清楚到底是什么让一个东西成为了“微服务”。

The impossible definition

无法定义的定义

How small is micro? Should a service do exactly one thing? Two? Is there a maximum number of lines of code? A thousand? Ten thousand? Nobody has convincing answers, because there aren’t any. The industry has spent years trying to define microservices by technical characteristics, but those characteristics are surprisingly vague and fuzzy. The boundaries aren’t measured in responsibilities or number of deployments per day. They’re measured somewhere else entirely. And that’s the important realization: microservices aren’t primarily a technical abstraction. “微”到底有多小？一个服务应该只做一件事吗？两件？代码行数有上限吗？一千行？一万行？没有人能给出令人信服的答案，因为根本就没有标准答案。业界花了多年时间试图通过技术特征来定义微服务，但这些特征却出奇地模糊。边界不是通过职责范围或每天的部署次数来衡量的，而是由其他因素决定的。这是一个重要的认知：微服务本质上并不是一种技术抽象。

The problem they’re actually solving

它们真正解决的问题

Listen to the reasons people usually give for moving away from a monolith: deployments are slow, tests take too long, builds are painful. These are real problems, but none of them require microservices. Every single one can be improved while staying inside a monolith. So why do organizations migrate anyway? Because the bottleneck usually isn’t technical. It’s organizational. As companies grow, dozens or hundreds of engineers need to work independently. Teams need ownership. They need to release on their own schedules without constantly coordinating with everyone else. Microservices create boundaries that mirror organizational boundaries. That’s their real value. 听听人们通常给出的放弃单体架构的理由：部署缓慢、测试耗时太长、构建过程痛苦。这些都是真实存在的问题，但没有一个问题非得靠微服务才能解决。每一个问题都可以在保持单体架构的同时得到改善。那么，为什么组织还要进行迁移呢？因为瓶颈通常不在技术层面，而在组织层面。随着公司规模的扩大，几十甚至几百名工程师需要独立工作。团队需要所有权，他们需要按照自己的节奏发布，而无需不断地与其他人协调。微服务创建了映射组织边界的边界，这才是它们真正的价值所在。

Every benefit comes with a bill

每个收益都伴随着代价

Engineering is the art of managing trade-offs. Microservices are no exception. You gain autonomy, but you lose centralization. Inside a monolith it’s easy to answer questions like “Which dependencies are we shipping?”; or “Is this piece of code still used?” Static analysis can often tell you. Once the code is spread across dozens of independent services, those answers become much harder to obtain. The same pattern repeats everywhere. Communication between functions becomes communication over the network. A method call becomes an HTTP request. A compiler error becomes a runtime failure. Every distributed system problem — latency, retries, partial failures, serialization, consistency — suddenly becomes part of your application. None of these costs are surprising. They’re simply the price you pay for the flexibility that distributed systems provide. 工程学是一门管理权衡的艺术，微服务也不例外。你获得了自主权，却失去了集中化。在单体架构中，回答诸如“我们发布了哪些依赖项？”或“这段代码还在使用吗？”之类的问题很容易，静态分析通常就能告诉你答案。一旦代码分散在几十个独立的服务中，这些答案就变得难以获取。同样的模式在各处重复：函数间的通信变成了网络通信，方法调用变成了 HTTP 请求，编译器错误变成了运行时故障。每一个分布式系统的问题——延迟、重试、部分故障、序列化、一致性——突然间都成了你应用程序的一部分。这些代价并不令人意外，它们只是你为分布式系统所提供的灵活性而支付的费用。

The hidden communication cost

隐藏的沟通成本

When people talk about communication overhead, they usually think about APIs talking to each other. That’s only half the story. The teams now have to communicate too. Changing an API is no longer a refactor. It’s a negotiation. Consumers need advance notice. Versioning becomes necessary. Old versions have to remain alive while everyone migrates. Database changes become coordinated efforts instead of straightforward commits. The software isn’t the only thing that’s distributed anymore. The decision making is as well. 当人们谈论通信开销时，通常想到的是 API 之间的交互。但这只是一半的情况，团队现在也必须进行沟通。更改 API 不再仅仅是重构，而是一场谈判。消费者需要提前通知，版本控制变得必不可少。在所有人完成迁移之前，旧版本必须保持运行。数据库变更变成了需要协调的工作，而不是简单的提交。现在，不仅软件是分布式的，决策过程也是如此。

Choose them for the right reason

为了正确的理由选择它们

None of this is an argument against microservices. They’re an excellent architectural choice in the right environment. Many successful companies simply couldn’t operate without them. But it’s worth being honest about why they work. If your primary problem is organizational scaling, microservices might be exactly the right answer. If your problem is purely technical, you should first ask whether you’re reaching for a solution that’s far larger than the problem itself. Architectures become much easier to reason about once we stop pretending microservices are magic technical tools. They’re organizational tools with technical consequences. 以上这些并不是反对微服务的论点。在合适的环境下，它们是极佳的架构选择。许多成功的公司如果没有微服务根本无法运作。但我们有必要诚实地看待它们为何有效。如果你的主要问题是组织规模化，微服务可能正是正确的答案。如果你的问题纯粹是技术性的，你应该先问问自己，是否在追求一个远超问题本身的解决方案。一旦我们不再假装微服务是某种神奇的技术工具，架构就变得容易理解多了。它们是具有技术后果的组织工具。

I made a video version of this argument, if you’d rather watch it: What even are microservices? Thanks for reading. 如果你更喜欢看视频，我制作了这个观点的视频版本：到底什么是微服务？感谢阅读。