《Release It! Second Edition》阅读笔记（一）

Case Study: The Exception That Grounded an Airline¶

举了一个航空公司的系统故障的例子，在这个例子中因为一个未捕获的 SQLException 异常导致整个航空系统瘫痪了数小时。

讲了一下用到的方法：

• 通过 jvm 的 thread dumps 找到各个服务 block 的地方
• 通过反编译的方式拿到了关键问题的 java 代码，从而最终确定了 bug 是哪段代码导致的

bug 总是不可避免的，谁也不能保证再也不会出现 bug。这个例子中最糟糕的问题不是这个 bug 本身，而是这个 bug 瘫痪了整个系统： 一个系统中的 bug 所产生的影响传递到了所有相关的系统。我们要解决的问题是：如何阻止一个系统中的 bug 影响其他所有的系统。 后面的章节会讲如何组织这类问题的一些设计模式。

Stabilize Your System¶

Integration Points¶

现在大部分系统的结构已经从之前的单体架构变成了集成多个服务的类似网状的结构，网状结构中的各个依赖链路是摧毁你系统的一个关键点， 下面看看这些依赖链路是怎么在各种场景下成为毁灭者的，以及你可以如何应对。

Socket-Based Protocols¶

大多数高级协议都是基于 socket 实现的。虽然这些高级协议都有自己的故障模型，但是它们都会受 socket 层故障的影响。

• connection refused 是最容易处理、一般也不会被忽略的一种异常情况

• TCP 三次握手（SYN、SYN/ACK、ACK）期间的异常情况： * 如果远程服务没有监听指定的端口，客户端会收到 RST 报，这个过程的响应特别快，调用方会得到一个异常/错误返回码 * 远程服务监听了指定端口，监控端口的同时会有一个 listen queue（在队列内的连接处于发送了 SYN，但是还没收到 SYN/ACK 回复的 pending 状态）:

  • 队列满了：新进来的连接会被拒绝（不放到 listen queue 中，不回复 SYN/ACK），客户端会反复重传 SYN 包
  • 队列没满，但是没有 accept 回复 SYN/ACK 的话，客户端会反复重传 SYN 包
  • open() 调用在三次握手没完成的时候都会阻塞在那里，直到连接成功或超时（connection timeout）。 连接超时的阻塞时间一般都是分钟级别的，甚至十几分钟。

• 客户端连接成功了并且发送了一个请求，但是服务端可能会花很长时间才会完成读取请求并返回一个响应的操作。 在服务端返回响应前， read() 调用会一直阻塞在那里，通常这个阻塞是没有时间限制的，如果你想唤醒这个阻塞调用的话，必须得设置 socket 超时时间。

网络故障通常有两种方式：快速或者缓慢。类似 connection refused 的快速故障调用者可以在几毫秒内就获知这个结果， 类似 ACK 包被丢弃的缓慢故障会导致分钟级别的线程阻塞问题，阻塞的线程无法处理其他事物，如果所有线程都阻塞的话，可能会导致整个系统宕机。

所以，缓慢的响应比没有响应（快速得到结果）更糟。

The 5 A.M. Problem¶

可以通过抓包工具（tcpdump、Wireshark）来调查 socket 相关的问题。

作者讲了一个因为链路中的一个防火墙频繁丢弃了 ACK 包导致服务 hang 住最终导致整条链路都挂了的案例 （有个连接池，连接池中每个空闲连接的超时时间是一个小时，因为丢包问题导致无法及时剔除有问题的连接，然后使用连接的时候用了有问题的连接出现服务 block）。

一般需要二十分钟 socket 库才能感知到重传导致的超时问题（tcp_retries2），上面案例中他们用的系统需要三十分钟才能感知到超时， 也就是说他们服务中的 write socket 操作会出现长达三十分钟的 block 问题，read socket 操作会 block forever!

这个例子想说的是，有时候故障不一定是应用层面导致的问题，有时可能是上层或下层导致的问题，你需要知道如何深挖至少两层来找到真正的问题所在。

HTTP Protocols¶

HTTP 协议也是基于 socket 的，所以它有上面提到 socket 相关的所有问题，同时它也有自己特殊的问题：

• 服务端可能接受了 TCP 连接，但是不响应 HTTP 请求
• 服务端可能接受连接，但是不读取请求。如果请求的 body 特别大的话，可能会超出服务的的 TCP 窗口大小，这会导致 调用方的 TCP buffer 被填满，这将导致 write socket 操作 block 住。这种情况下正在发送的请求永远都不会完成
• 服务端可能会返回一个调用方无法处理的响应，比如 "418 I’m a teapot." 或者 "451 Resource censored."
• 服务端可能会返回一个调用方非预期的或者无法处理的内容类型，比如，返回一个 404 的 Html 页面而不是预期的 JSON 响应。（比如，有些 ISP 在 dns 查询失败的时候会返回一个 html 的错误页面）
• 服务端声明会返回一个 JSON 数据，但是实际上是个普通的纯文本数据或者二进制数据

推荐使用那种可以详细控制超时（包括连接超时和读取超时）以及如何处理响应的客户端库，不要用那种直接把响应映射为对象的库，应该在确认获取到了预期的数据后再把响应作为合法数据进行处理。

Vendor API Libraries¶

供应商提供的 API 库通常意味着：代码质量差、bug 多、bug 修复周期长、有些甚至看不到源代码无法自助修复 bug。

供应商 API 库主要的稳定性杀手是其中的 block 操作：内部连接池/资源池、socket read 调用、HTTP 连接或者是不安全的序列化操作。 供应商 API 库布满了大量不安全的代码实践。

Countering Integration Point Problems¶

如何防范集成链路中各个依赖的问题，下面有一些建议：

• 警惕必然会出现的问题：链路上的每个依赖必然会出现某种故障，你需要为这些故障做预案和准备。
• 为多种形式的故障准备预案。
• 故障会快速传递：远程系统中的故障会快速成为你的系统中的问题，如果你的代码防御性不够的话，这个问题通常会演变成瀑布式故障（故障风暴）。
• 应用一些模式来抵御链路中的问题：通过熔断（Circuit Breaker）、超时（ Timeouts）、解耦中间件 （Decoupling Middleware）、握手（Handshaking）这些防御式编程方法来帮助你抵御链路上的危险问题。

Chain Reactions¶

目前的架构风格一般分为水平扩展和垂直扩展，然后大部分服务都是水平扩展架构的。

水平扩展的模式一下，一般都有类似负载均衡或集群的模式。 水平扩展虽然不容易受单点故障问题的影响，但是仍旧有负载相关的失败模式。 比如，有一个节点因为内存泄露导致服务异常了，此时这个节点上的流量通过负载均衡器会分摊到剩下的健康节点上， 但是剩下的节点可能也会因为这些新的流量也导致出现异常（因为这些节点也有内存泄露问题，只是暂时还未达到临界点）。 解决这种连锁反（chain reaction）应的唯一办法是修复导致问题的 bug。

把一层分隔为多个池的舱壁模式（Bulkhead）可以减轻连锁反应说带来的影响。

连锁反应有时是因为一些阻塞的线程而导致的问题，比如一个节点中所有处理请求的线程都阻塞了，这会导致服务无法响应请求， 新进来的连接会分散到同一层的其他节点上，加大其他节点出现问题的几率。

Remember This:

• 意识到，有时一个服务宕机会危及剩下的服务，导致它们也出现宕机的问题。连锁反应可能会导致整个层的服务都宕机， 其他依赖这层的服务必须保护自己，否则它们可能会因为失败风暴导致宕机。
• 追杀资源泄露问题。大部分连锁反应都是内存泄露导致的问题。
• 追杀令人费解的时间相关的 bug。如果一个节点出现死锁问题，很有可能会导致其他节点也出现死锁问题。
• 使用自动扩容功能。随着时间的推移，自动扩容的速度将超过连锁反应的传递速度，最终终止连锁反应。
• 使用舱壁(Bulkheads)模式进行防御：在服务端使用舱壁模式阻止连锁反应危及整个服务， 在客户端使用熔断器（Circuit Breaker）模式来处理一部分服务宕机的情况。

Cascading Failures¶

瀑布式故障，故障雪崩，指的是某一层的服务的故障导致调用方那一层也出现故障。

瀑布式故障通常是低层次的故障导致资源池异常的结果，比如请求依赖的外部服务时没有设置超时。

下游服务的故障会导致上游服务触发重试逻辑，然后随着下游服务故障的加重最后触发了重试风暴，最终打挂下游服务。 针对这种重试风暴的情况，调用方需要应用熔断器（Circuit Breaker）模式。

最高效的对付瀑布式故障的模式是熔断器（Circuit Breaker）和超时。

Remember This:

• 确保你的服务在外部依赖异常时不会受牵连导致宕机。
• 仔细检查各种资源池。资源池异常通常会导致瀑布式故障。比如，长时间无法获取到需要的资源的连接池，获取连接的线程会一直阻塞，其他等待连接的线程也会阻塞。 安全的资源池应该限制一个线程获取资源的等待时间。
• 通过超时和熔断器（Circuit Breaker）模式来防御瀑布式故障问题。

Users¶

用户太少是个问题，用户太多其实也会成为问题。比如未准备好的促销活动或者网红转发导致的用户量暴增，这些个的用户增长可能都会打垮服务。

Blocked Threads¶

很多时候服务故障的时候并不会崩溃而是所有线程都阻塞在那等待着一些不能完成的事情。

所以建议不只是要有内部监控（日志抓取、进程监控、端口监控等）也可以有个外部监控，比如一个模拟真实用户操作的客户端，如果这个客户端无法得到预期的结果的话，肯定是哪里有问题了，即便服务还在运行。

metric 监控同样也可以帮助快速发现问题，比如登录成功数、支付失败数等计数类 metric 监控。

线程阻塞可能发生在任何时候：从连接池中获取一个连接、处理缓存或对象登记、或者是进行一次外部调用。

不安全的多线程代码通常有四种情况：

• 错误情况和异常的组合数太多了，导致测试无法完全覆盖
• 非预期的交互会把问题引入到前面安全的代码中
• 时间非常重要，应用可能会同时 hang 住多个并发请求
• 开发者从来没测试过应用处理 1 万个并发请求的情况

在开发环境很难发现 hang 住的情况。不要总想着自己实现连接池，实现一个可靠、安全、高性能的连接池比你想象的要更困难。

尽量不要在同步方法里修改共享对象，建议是把这些共享对象实现为不可变的或者在同步方法里使用一个原对象的副本。

Self-Denial Attacks¶

市场部门的营销活动可能会导致自我拒绝的攻击，一些全局共享的资源也会导致类似的问题，比如分布式全局锁服务。

Scaling Effects¶

任何时候你有一个多对一或多对少关系，当一端增长时候，你都可能会遇到尺度效应（scaling effects）的问题。

比如，一个数据库服务在只有 10 台机器作为调用方的时候可以正常工作，但是当你又新加了 50 台机器的时候，这个数据服务就崩溃了。

开发环境和测试环境中因为使用的机器数量太少，基本上很难发现尺度效应相关的问题。

Unbalanced Capacities¶

链路中各个系统的容量不一样，尤其是前端部分一般容量都比后端部分大，在突然出现的流量高峰的时候容量不够的部分就会成为瓶颈， 但是让所有系统的容量都预留的特别足只为了应对某一天的突发流量也不是特别现实。

但是也还是要应对偶然的突发流量的，调用方可以在下游异常时应用熔断器模式来减轻下游服务的压力， 服务提供方可以使用 Handshaking 和 Backpressure 来告诉调用方请求限流了，同时也可以考虑使用 Bulkheads 模式来为高优先级的调用方保留容量。

Dogpile¶

当一群服务同时施加这种瞬时负载的时候，这种情况就叫做叠罗汉（Dogpile）。 dogpile 可能发生的场景：

• 多个服务启动的时候，比如代码升级或服务重启
• 在半夜触发的定时任务（或者每小时触发）
• 配置管理系统推送一个变更

有些配置管理工具允许配置一个随机因子（这样推送事件就不会集中在某一点）来打散短时间内的 dogpile 问题。

dogpile 也可能会发生在因为外部因素导致出现了同步触发的流量。 需要小心那些多个线程等待一个线程完成的情况，当那个线程完成的时候，那些等待的线程就会对下游服务产生 dogpile 现象。

Remember This

• Dogpile 需要你花费更多的容量来处理它产生的波峰问题。
• 使用随机时钟来打散波峰，不要把所有定时任务都放在半夜执行或者每小时执行，混合使用来打散负载。
• 通过增加 backoff 次数来规避脉冲现象。固定周期的重试间隔会产生周期性的脉冲，应该使用 backoff 算法这样不同的调用者会因为不同的周期而产生不同的流量点。

Force Multiplier¶

自动化赋予了管理员以少量工作完成大规模迁移的能力，这个就是 Force Multiplier

Slow Responses¶

通常一个慢响应要比一个拒绝连接或返回错误要更糟糕。

Remember This

• 慢响应会触发级联故障。
• 对于网站来说，慢响应会导致更多的流量。
• 考虑快速失败。
• 查找内存泄露和资源竞争。

Unbounded Result Sets¶

设计的时候要对外部系统持怀疑态度，时常考虑：系统 X 的啥操作会影响我系统的稳定性。

无限的结果集在某天可能会对你的系统找出特别大的伤害， 比如一个查询操作，因为没有限制返回的结果，平时数据量少看不出影响，突然有一天返回了上百万行的数据，此时可能就好影响你的系统的稳定性。

Wrapping Up¶