Why I'm No Longer Talking to Architects About Microservices

Ian Miell March 11, 2025 10 minutes Read

上周再次发生了。我在一个架构评审会议上，一位架构师同事兴致勃勃地开始了另一场关于 microservices 的辩论。几分钟之内，大家眼神呆滞，陷入了一场荒谬的讨论，讨论的内容本应是实现目标的手段，却演变成了目标本身。那一刻，我意识到：我受够了。我终于发誓不再和架构师谈论 microservices 了。为什么？因为这些对话通常毫无结果。

我将我的挫败感归结为三个问题：

1. 没有人对 "microservice" 的含义达成一致。
2. 关于 microservices 的对话是抽象的，与真正的业务目标几乎没有联系
3. 在不改变组织结构的情况下采用 microservices 是毫无意义的。

Problem One: No One Knows What a Microservice Is

这是最明显的问题。对于什么是 microservice，没有正式的定义，所以当人们谈论它们时，最终往往各说各话。

以下是一些现有的定义：

• 代码行数少的服务：
  • "它们非常非常小。我的意思是，现在 100 行代码可能就是一个大型服务了。" Fred George，Barcelona Ruby Conference
• The ‘two-pizza’ team
  • 严格来说，这不是 microservices 的定义，但经常被用作所需团队规模的经验法则，并且暗示一个 microservice 需要它自己的团队。
• 只需要一个程序员来构建和维护：
  • "如果需要超过一个程序员来开发、设计和维护它，那就不是一个 microservice。" Fred George，GOTO 2016
• Autonomous, self-contained and unique processes
  • "每个服务都是自主的、独立的，并且运行一个独特的进程。"
• A container/pod
  • "每个 microservice 都被打包成一个 Docker container，以便部署到 Kubernetes 集群进行应用程序编排。"
• 拥有自己的数据存储的服务
  • 这曾经是我个人长期坚持的经验法则，并且也隐含在 这里
• “Independently replaceable and upgradeable”
  • Ian Cooper, after Yourdon, Edward; Constantine, Larry Structured Design , 1975
• A 'little computer' that operates on a model of the business concepts that are relevant to its operation. Daniel Terhorst-North

虽然其中一些定义彼此之间有很大的重叠，但重点的差异，加上我们讨论它们的松散方式，最终导致了 "盲人摸象" 的情况：每个人都在正确地描述略有不同的东西，所以没有人是 "错的"，但我们肯定没有达成一致。

（在谈到 Amazon Video 所谓的 microservices 到 monolith 的迁移时，我 在这里 讨论了关于什么是 microservice 的这种困惑。）

在经历了足够多的此类辩论后，我发现完全禁止使用 "microservices" 这个词更简单。如果一个术语引起如此多的混乱，也许它已经失去了它的作用。

我们可以讨论具体的挑战，或特定的权衡，而不是争论如何称呼我们的架构：如何更快地部署新功能，如何减少耦合，如何扩展系统的某些部分。换句话说，microservices（无论你决定它们是什么）本身不是目的，而是实现其他目标的副产品。

Problem One (b): The Lack of Discipline in Software Terminology

这不仅仅是一个 microservices 问题：这是我们行业中一个更广泛的问题。我们抛出听起来令人印象深刻的大词，但对不同的人来说，它们意味着截然不同的东西。考虑一下这些术语，以及它们的历史：

• DevOps
  • 最初是对开发和运营团队标准分离的拒绝，但后来完全正常地谈论围绕部署工具的独立和集中的 "DevOps 团队"
• Agile
  • 最初是对软件方法和行为的拒绝，这些方法和行为通常与瀑布软件开发相关，并拥抱动态和特定于上下文的方法和行为，但该术语与高度官僚化和仪式化的行为相关联
• SRE
  • 最初是 Google 引入的一种学科，旨在将软件工程实践引入运营，强调可靠性、自动化和服务级别目标 (SLO)，但它演变成了一个重新命名的运营职能，通常没有向自动化和共享所有权转变的文化转变，而这正是它最初提倡的
• Observability
  • 最初是控制理论中应用于软件系统的概念，专注于从外部输出来理解内部状态的能力，它被现代基础设施团队所接受，以超越传统的监控。然而，随着供应商推出商业可观测性解决方案，它变得越来越等同于昂贵的仪表板、指标超载和工具蔓延，通常会掩盖而不是澄清系统健康

每个术语都以明确的意图开始，但随着时间的推移，它们被拉伸和扭曲，以意味着说话者想要倡导或批评的任何东西。有了如此草率的定义，我们的对话绕圈子也就不足为奇了？

（顺便说一句，我想赞扬 GitOps。这个术语的使用相对稳定，这主要归功于一个清晰的原始定义（现在，可悲的是，它已经从互联网上消失了，与该术语的创建者 Weaveworks 一起），这个定义不容易被用于商业目的而歪曲。）

Problem Two: Microservices Conversations Are Abstract and Unrelated from Business Goals

与第一个问题密切相关的是，关于 microservices 的讨论通常与任何有形的业务目标脱节。如果你问 "我们实际上要解决什么业务问题？" 你经常会得到模糊的回应，例如：

• Microservices 提高了可扩展性。（什么的可扩展性？当前瓶颈在哪里？）
• Microservices 使团队更敏捷。（如何？部署速度慢是因为架构，还是因为流程限制？）
• Microservices 允许独立部署。（这实际上是你的团队的要求，还是只是一个锦上添花？）
• Microservices 减少了认知负荷。（对于谁？它们真的减少了吗，或者我们只是在转移复杂性？）

如果你仔细听，关于 microservices 的许多对话实际上不是关于架构，而是关于想要为一家不同的公司工作，在那里技术是最前沿的，问题在理论上很有趣，而不是遗留问题缠身并受到现实世界权衡的约束。

可悲的现实是，许多开始进行 microservices 迁移的团队最好还是坚持使用结构良好的 monolith，直到他们的扩展需求真正需要不同的方法。Building Microservices 的作者 Sam Newman 经常警告说，除非有令人信服的理由，否则大多数组织不应从 microservices 开始。

再说一遍，最好停止谈论 microservices。开始谈论缩短周期时间、提高可靠性和解决具体的业务瓶颈。如果将系统分解为更小的服务是实现这些结果的最佳方式，那很好，但架构师之间关于 microservices 的钻牛角尖的讨论并不是实现目标的方式。

Problem Three: Microservices Without Organizational Change Is Pointless

工程师在脱离业务背景的情况下讨论 microservices 的另一个关键后果是，他们通常会忽略使 microservices 工作所需的组织变革。

Microservices 不是在真空中工作的。它们要求团队以支持它们的方式进行组织。这意味着：

• 拥有端到端服务的跨职能、自主团队。如果团队仍然依赖于集中的瓶颈（例如，单个 DBA 团队），microservices 将无法实现承诺的好处
• 分散决策，以避免协调开销。如果发布仍然需要漫长的审批流程，那么服务的独立性就是一种幻觉
• 成熟的 DevOps 文化，拥有 CI/CD、监控和事件管理实践，可以处理分布式系统的复杂性

如果你的组织不愿意做出这些改变，microservices 只会使事情变得更糟。增加技术复杂性，同时保留所有旧的组织效率低下。简而言之，技术应该遵循业务需求，而不是相反。

大多数讨论 microservices 的人要么不欣赏这一点，要么不欣赏这有多么困难。当你的业务规模超过微不足道的规模时，改变你的组织结构比改变你的软件架构_困难得多_。这就是为什么小型创业公司可以 "pivot"，并如此迅速地改变他们的软件架构：只要每个人都同意架构更改，他们的组织结构就可以更改。

The Next Time Someone Mentions Microservices…

我很清楚这里的讽刺意味：我已经谈到了我不再谈论 microservices 了。有了这些，我就闭嘴，再也不提这件事了。