# 616 页的微服务经典，FDE 只需精读五章

> 读对章节，就能学会追踪同步调用链、把 API 契约当硬约束，并诊断别人搭的系统为何变慢。

原文: https://fdetimes.net/zh/books-courses/building-microservices-five-chapters-for-fdes/

Sam Newman 的《Building Microservices》第二版共 16 章，约 616 页。一位前线部署工程师（FDE）即将把产品接入客户由几十个服务组成的系统，在启动会之前根本没时间读完全书。不过，要开始读懂别人的系统，精读五章就够了。

这本书大部分内容是写给*构建*微服务的人的。而 FDE 的工作通常是*读懂*并*对接*别人搭好的系统，有时还是搭得很糟的系统。读对章节，就能掌握相应的术语和几条规则，从驻场第一周起就能更快地定位问题。

## 第二版改了什么，可信度如何？

Newman 表示，第二版是一次彻底重写：第一版的每一页都重新审读过，需要改的地方都改写了。原有的观点保留下来，但大部分文字是新的。

他还用了更多篇幅讨论容器、Kubernetes 和 serverless 带来的影响。转售 O'Reilly Media 电子书的 Helion 在页面上也列出了新增内容：用户界面、容器编排和安全。

全书分三部分。第一部分“基础”涵盖第 1 至 4 章：什么是微服务、如何为服务建模、如何拆分单体应用，以及服务间的通信方式。

第二部分“实现”涵盖第 5 至 13 章：通信、工作流、构建、部署、测试、可观测性、安全、韧性和扩展。第三部分“人”讨论用户界面、组织结构，以及演进式架构师的角色，即帮助架构随时间逐步演变的人。

这本书也没有把微服务描绘得一片美好。一位从业者在书评中指出，书中说明了微服务并非银弹，它本身也有缺点。

早在 2015 年，Newman 就在博客中写道，服务边界划错的代价可能很高。这种审慎很适合 FDE，因为你会经常遇到边界划错的系统。

## 第 4 章和第 12 章：为什么慢服务比挂掉的服务更危险？

先读第 4 章。Dan Lebrero 对这一章的笔记提炼出一条规则：使用阻塞式同步通信时，要警惕过长的调用链。与之配套的规则是：把逻辑放在端点，而不是放在中间件里。

设想某零售客户的结算流程：结算服务调用库存服务，库存服务调用定价服务，定价服务调用支付服务，每次调用都是同步的。如果每个服务耗时 50 ms，整条链就是 200 ms。但如果定价服务卡住 3 秒，又没人设置超时，上游的每个请求都会占着连接等待。

第 12 章给这一现象下了定义。据 Lebrero 的笔记，响应极慢是你可能遇到的最糟糕的故障之一。挂掉的服务会立即报错；慢服务则会悄无声息地耗尽所有调用方的资源。

**要点:** 在多服务系统中，慢服务往往比挂掉的服务更危险。

到了客户现场，第一件事是把产品将要触及的那条流程的调用链重新画出来，然后问客户每一跳的超时设置是多少。

## 第 5 章：契约与重复消息

第 5 章是编写集成代码时最常用到的一章。Lebrero 的笔记总结了两条建议：用 schema 捕获结构性的破坏性变更；避免需要双方同时发布的部署。

对 FDE 来说，这意味着尽早向客户要 API 的 schema 文件，然后基于它运行自动化检查，而不是凭几个示例响应去猜数据结构。

下一条建议更不容易察觉：保证消息投递是个微妙的问题，最好假设会收到重复消息。设想你的某个 Agent 监听“订单已支付”事件，用来发送确认邮件。

如果消息代理把这个事件投递了两次，客户的顾客就会收到两封邮件；更糟的是，积分会被发放两次。解决办法是附上一个幂等键，执行操作前先检查它。

## 第 10 章和第 2 章：诊断不属于你的系统

第 10 章把监控改称为可观测性。据 Lebrero 对这一章的笔记，可观测性是指你能在多大程度上通过系统对外输出的信息来理解其内部状态。

调试别人的系统时，你不可能读完全部代码，手里只有日志、指标和链路追踪。所以在承诺修复期限之前，先问客户有没有分布式追踪。

第 2 章提供了一个简单的边界检验方法，Lebrero 的笔记显示这一观点在第 7 章再次出现：如果你总是要同时修改好几个服务，说明边界划错了。

在现场，可以问问最近一个功能改动涉及了多少个代码仓库。答案会告诉你，集成工作会在哪里遇到阻力。

## 对接客户系统时最容易犯的三个错误

第一，相信几个示例响应，而不是 schema。示例只能反映数据今天的样子；客户一旦修改某个字段，集成代码就会毫无预警地出错，而基于 schema 的检查本可以发现这一变更。

第二，假设每条消息恰好到达一次。第 5 章的笔记已经提醒过消息投递很微妙，所以每个接收事件或 webhook 的处理器，都应当按同一条消息会再来一次的前提来写。

第三，同步调用客户的服务却不设超时。就像上面的结算示例一样，你自己的调用可能成为等待链上的又一跳。

## 谁该读，按什么顺序读？

如果你写 API 已经得心应手，但还没调试过大型分布式系统，这五章是最短的入门路径。先读第 4 章，然后是第 5、12、10 章，最后读第 2 章。

第三部分可以等到你主导整个项目时再读。那位从业者认为第 2、6、9、10 章写得最好，因此读完上述五章后，接着读讲工作流的第 6 章和讲测试的第 9 章是合理的选择。

这位书评者也提醒，读完这本书并不意味着你已经完全具备在生产环境中构建和运行微服务的能力。所以读完之后，动手做点具体的事并记录下来。简历上不要只写“具备分布式系统经验”。

要写清楚：你重新梳理了客户系统的调用链，为调用设置了超时，并为一个事件驱动的集成加上了幂等处理。当 FDE 岗位描述提到集成或可观测性时，把这几条放在最前面。

这五章不会让你成为微服务架构师。它们能帮你做到客户在第一周最需要 FDE 做的事：在系统真正出故障之前，指出它可能在哪里出故障。

**本周动手试试:**

- 在你负责的系统中选一条业务流程，重新画出服务之间的每一次调用，标出同步调用接连发生的环节
- 找一个接收事件或 webhook 的地方，把同一条消息发送两次，检查数据是否被写入两次
- 先读第 4 章，再读第 12 章，写一页笔记：在那条流程中，哪个服务一旦变慢就会拖慢整条流程

## 信源

- [Building Microservices, 2nd Edition](https://samnewman.io/books/building_microservices_2nd_edition/)

- [Building Microservices. 2nd Edition](https://helion.pl/ksiazki/e_23tc.htm)

- [Book notes: Building Microservices - Second edition](https://danlebrero.com/2023/01/24/building-microservices-second-edition-designing-fine-grained-systems-summary)

- [Review: Building Microservices](https://rodion-blog.pp.ua/misc/review-building-microservices)

- [Microservices For Greenfield?](https://samnewman.io/blog/2015/04/07/microservices-for-greenfield/)