微服务何时值得拆？Sam Newman 解释服务边界与系统韧性

微服务能让团队分开发布软件，但也会把网络延迟、故障恢复和资源管理带进日常开发。Sam Newman 写过《Building Microservices》，却把微服务称作一种“最后手段”：只有当服务边界能让团队更独立地开发和部署时，拆分才值得承担额外复杂度。他还用三条规律解释分布式系统为什么会失效，以及 AI 编程工具怎样改变工程师理解系统的方式。

原始来源：Building resilient systems with Sam Newman。中文深度整理，非逐字翻译。本文依据 Sam Newman 与 The Pragmatic Engineer 发布的详细节目整理，不是 YouTube 字幕。

微服务先解决团队部署边界

Sam 给“微服务”提出一个比较明确的标准：修改一个服务时，团队能够独立部署它，不必同步部署系统里的其他服务。另一种更柔性的理解，是按业务功能划出清楚边界，而不是把系统简单拆成技术层。两种说法的重点都不是服务有多小，而是不同团队能不能负责自己的业务部分，并独立发布改动。

如果团队仍要同时改动多个服务、协调多次部署，拆分就没有获得预期的自主性。服务之间还要通过网络通信，团队需要维护监控、测试、部署和故障处置。因此 Sam 把微服务称为“最后手段”：只有单体系统或现有模块边界已妨碍团队独立工作时，才值得引入这份额外复杂度。

分布式系统的三种麻烦都不可消除

Sam 把分布式计算的常见问题归纳为三条：信息从一台机器传到另一台需要时间；你要联系的服务可能已经离线；CPU、内存、存储和带宽等资源不是无限的。他认为不少系统故障来自第三种情况——资源池耗尽。系统扩展时如果只盯住请求量，却没有监控连接数、队列、内存和带宽，最终可能在压力增大时突然失效。

系统韧性也不只是“故障时继续运行”。Sam 引用军事系统研究者总结的四个概念：稳健性是故障发生时仍按预期工作；恢复力关注出错后多久恢复；可扩展性是遇到意外需求时能否调整；适应性则是系统能否因新需求而改变。增加自动重启或副本可能提高稳健性，但每加一层机制也会增加系统复杂度。

重试要防止同一笔业务重复执行

幂等性意味着，同一个操作执行多次，最终效果仍像只执行过一次。支付是典型例子：用户刷新页面或网络断开后重试，系统不应该把同一笔款扣两遍。一个做法是让客户端发送唯一的幂等键，服务器识别重复请求后只执行一次；这种方式清楚，但要同时修改客户端和服务端，老系统改造成本更高。

另一个办法是由服务器根据请求内容生成“指纹”，识别看起来相同的交易。它更容易接入旧系统，却可能把两笔合法的同额交易误判为重复，也不能保证完全挡住重复操作。Sam 举例说，他参与过一个丹麦支付系统，系统在生成指纹的短时间窗口里，会拒绝金额相同的购买请求。这个例子说明，可靠性机制总要和业务规则一起设计：宁可多拦一次，还是冒着重复收费的风险，不能只靠技术抽象决定。

AI 写代码时，模块边界更重要

Sam 认为，软件开发不等于打字；协作、反馈和理解系统同样重要。过去，他曾遇到客户反对结对编程，因为他们只看到一个人在键盘前操作。现在模型能生成代码，开发工作的瓶颈可能会转向设计、反馈周期和验证结果。

他建议先由工程师设计模块边界，再允许 AI 在这些边界内探索实现。模块像是约定清楚的工作区：代理可以快速尝试，但不会在没有约束的情况下改动整个系统。Sam 也提醒人们，语言模型没有真正理解因果关系的世界模型；它看起来很聪明，不等于它知道一次操作会产生什么后果。因此，要求模型解释、核验生产行为和保留人工判断仍很重要。

自动化要看业务出错时应该怎样处理

遇到依赖服务出错，系统有时要“开放失败”，继续提供不完整但可用的服务；有时要“关闭失败”，直接停止操作以避免错误结果。具体选择取决于业务：暂时显示旧内容或许可以接受，支付金额错了则不能。Sam 因此强调观测能力和业务背景，不能只设一个全局重试或熔断规则。

他也担心过度依赖 AI 会造成“认知交还”：开发者把理解问题和验证资料的工作都交给模型。Sam 分享写书时使用 NotebookLM 查资料，但仍亲自打开模型找到的每个来源，判断是否值得引用。工具能节省找线索的时间，但系统负责人仍要理解证据和后果；否则，软件发布得更快，人却更难判断它为什么这样工作。