Sam Newman 谈如何构建弹性分布式系统与微服务

流媒体播放最新一期节目

现在就在 YouTube、Apple 和 Spotify 上收听和观看。 本页顶部可查看本期节目文字稿，底部可查看本期节目时间戳。

本期节目由以下赞助商支持

• turbopuffer – 基于对象存储构建的向量与全文搜索：快速、成本降低 10 倍，且极具可扩展性。在底层，团队正在重写 tpuf 存储引擎。关注进展，直到它投入生产：turbopuffer.com/v3

• 免费获取基于属性的测试入门介绍：由 Hillel Wayne（近期播客嘉宾！）主讲的在线直播网络研讨会，他是《Logic for Programmers》的作者，也是 Antithesis 的开发者教育者。如果你只需要一个测试就能加固你的系统，会怎样？在此报名。

• Entire – 为智能体时代重建的 Git 托管服务。Entire 在区域内托管你的代码，速度比其他任何竞争对手快至多 89 倍。从 GitHub 镜像迁移只需一键 – 我已经这么做了。

本期内容

Sam Newman 写了一本关于微服务的最畅销书之一（“Building Microservices”），但他称微服务是一种“最后手段”的架构。

在本期 Pragmatic Engineer 播客中，Sam 解释了他对此的思考，而他确实很有资格这样做；当“微服务”这个词被创造出来时，他就在现场。我们讨论了团队在采用微服务时做错了什么、为什么独立部署很重要，以及微服务如何帮助团队更自主地工作。

我们还一窥他的新书《Building Resilient Distributed Systems》，Sam 解释了他对分布式系统的三条规则、为什么可观测性至关重要，以及在决定出错时是故障开放还是故障关闭时，为什么考虑业务上下文至关重要。

Sam 的新书 Building Resilient Distributed Systems 将于 10 月 7 日出版纸质版

我们还探讨了 AI 如何改变软件开发，从规格与代码作为真相来源，到认知债务和认知投降。Sam 分享了模块化架构如何帮助团队在试验 AI 的同时，保持对所构建系统的理解。

与 Sam 对话的要点

1. “微服务”被创造时他就在现场。在 2010 年代初，James Lewis——Sam 在 Thoughtworks 的同事——不断遇到一些公司构建面向服务的架构，其中每个服务都可以被快速替换。在英格兰湖区的一次架构研讨会上，James 为这一趋势提出了一个名字：“微应用”，而在大约 10 人的房间里（包括 Sam），另一个人提出了“微服务”。Lewis 和 Martin Fowler 随后在 2014 年 3 月写了关于该主题的第一篇文章《Microservices: a definition of this new architectural term》，Sam 则在次年出版了《Building Microservices》一书。

2. Sam 花了 18 个月教 Google 员工如何编写优秀的自动化测试。2007 年，Sam 作为 ThoughtWorks 顾问派驻 Yahoo 和 Google，与来自 Pivotal Labs 的人共事。他们的工作是教工程师如何编写自动化测试，以及可测试的代码。他回忆说，一些 Google 开发者不相信可以为网站编写自动化功能测试，直到 Sam 和他的同事向他们展示了 Selenium 是如何工作的！

3. Sam 在一家大公司工作了 10 多年，在初创公司工作了三年，并且已经独立工作超过十年。在 ThoughtWorks 工作 13 年后，他辞职以避免变得“体制化”。他回忆说自己当时想，如果继续留在 ThoughtWorks，可能会变得愤懑。“所以我现在就离开。”随后他在三家不同的初创公司工作过，之后开始独立工作，至今已有 15 年。做自己的老板最大的挑战是什么？他说：“为自己工作的问题在于，老板经常是个混蛋。所以，现在的 Sam 经常咒骂过去的 Sam 做出的承诺！”

4. 那么，什么是“微服务”？Sam 给出了两个定义：一个清晰的定义，和一个较宽松的定义：

可独立部署的服务。“清晰”的定义：只要在对系统进行更改时，它可以被独立部署——不需要部署任何其他服务——你就可以称它为微服务。
围绕业务领域的清晰边界。“较宽松”的定义：按业务功能（而不是按技术层）拆分的服务也可以称为微服务。

5. 分布式系统的三条规则：Sam 有时难以记住分布式计算的八大谬误，因此他将其归纳为最容易造成问题的三条：

1. 信息传播需要时间。你无法将信息从 A 点瞬时发送到 B 点。这基本上是“光速”约束。

2. 有时，你想通信的对象并不在那里。也就是说，资源会而且确实会离线。

3. 资源不是无限的；你最终会耗尽 CPU、内存、存储和网络带宽等东西。

根据 Sam 的经验，大多数分布式系统故障是由第 3 条引起的；资源池耗尽。

6. 处理幂等性：键还是指纹？幂等性是指多次执行同一操作，其效果与只执行一次相同。例如，如果你反复按电梯的“下行”按钮，除了第一次按下时发生的事情之外，不会有更多变化：多次猛按按钮不会给你带来更多电梯。支付是需要幂等性的经典例子：当你重试或刷新支付页面时，你不应该被扣款两次。

处理幂等性有两种常见方式：

幂等键：客户端发送一个唯一标识符（通常是 UUID），即幂等键。服务器确保具有相同幂等键的操作只执行一次。这种方式构建起来很干净，但很难改造，因为需要同时更改客户端和服务器。
指纹：客户端不发送任何内容，但服务器通过对相关字段进行哈希来创建请求的“指纹”。这种方式后期改造很容易（只需修改服务器），但合法请求可能会被当作重复请求而拒绝，而且重复请求仍可能发生。Sam 描述了他参与开发的一个丹麦支付系统，该系统在进行指纹识别时，会拒绝 5 分钟内相同金额的购买。

7. 韧性的四个概念：Sam 经常引用军事系统的四种结果，由 David Woods 解释：

稳健性：系统继续按预期运行，例如，当 Kubernetes 替换故障的 pod 时。稳健性的一个缺点是它会增加复杂性，而更复杂的系统有更多失败的方式。
回弹：系统在出错时恢复的速度。
可扩展性：应对意外情况，并能够扩展系统的支持以应对新需求
适应性：系统改变以支持新功能。有韧性的系统即使在事件之间也会进行调整。

8. 如果代码是协作的副作用呢？当 Sam 在 Thoughtworks 时，一些客户拒绝将结对编程作为一种实践，因为他们只能看到一名开发人员在打字，而另一名什么也不做，这是一种浪费。Martin Fowler 的名言“编程不是打字”帮助 Sam 向客户解释，打出代码是一种输出，但不是结果。

Sam 将编程视为集体构建一个系统，而代码是交付系统的机制之一。现在有了 LLM，我们不再花大部分时间打出代码，我们将发现创建优秀软件的下一个瓶颈。会是延迟的反馈循环吗？

9. 在将 AI 集成到系统时，对冲供应商选项是明智的。很难判断哪些 AI 公司拥有长期、可持续的商业模式，哪些没有，因此在设计系统时对冲供应商是负责任的做法。力求在你的选择中做到多供应商、多模型，这样你就可以轻松更换供应商或模型层。此外，考虑是否可以将 LLM 驱动的功能替换为运行更快、更便宜的确定性代码。

10. 我们必须抵制对 AI 的“认知投降”。Sam 认为，更多使用 AI 会导致更少的批判性思维——还是我们可能用错了？他说：“AI 最初的宣传是它将使我们摆脱苦差事。我们将有更少的劳作，可以更专注于批判性思维和智慧。然而，我们目前对 AI 的许多使用并没有让我们从批判性思维中解放出来！它导致了更多的上下文切换，留给思考的时间更少。人们工作时间更长；我们有研究表明这一点。

但[更长的工作时间和更多的上下文切换]不一定是 AI 的错。这只是我们使用它的方式。”

投入努力通常会带来更好的结果。例如，在撰写《构建弹性分布式系统》时，Sam 使用 NotebookLM 进行研究，但他手动点击了它呈现的每个链接，并检查这是否是他想要引用的信息。

11. 从模块开始鼓励更好的软件架构。另外：生产是真理。我向 Sam 询问了如何更好地设计系统的建议：

首先要仔细思考模块边界以及它们之间的连接
当你使用 AI 时，让它自由漫游，但只能在你设计好的模块结构内部！

12. 科技界很多人可能仍然对什么是 LLM 抱有天真看法。正如 Sam 所说：

“我认为整个科技界对 AI 相当天真，并且从根本上误解了 LLM 是什么。例如：为什么 LLM 删除了我的数据库？嗯，因为它没有因果概念。它们没有‘如果我做了 A，B 就会发生’的概念。
LLM 不是世界模型。世界模型已经存在很长时间了。它们早于 LLM。所以如果你有合适的模型和合适的输入，世界模型至少能达到‘如果我做了 X，那么 Y 会发生，而且我被告知不要做 Y’的程度。
我认为我们期望 LLM 做到超出它们实际能力的事情，因为它们看起来太聪明了。这让我们有点过度高估了它们的能力。但 LLM 的本质正是为什么围绕 LLM 的所有护栏真的不会成为正确的长期解决方案。”

Sam 的评论感觉非常及时，因为 Opus 5.5 刚刚格式化了一位开发者的硬盘，这位开发者用 —dangerously-skip-permissions 标签运行了该模型，然后惊讶地发现他的所有数据都没了。

Opus 5.5 认为格式化 C: 盘是个好主意。Sam 曾警告过由于 LLM 的本质，这类结果可能发生。截图来源：X

最后，推荐阅读，以提升软件架构能力。Sam 的推荐：