英文原文：Application Resilience in a Service-oriented Architecture

故障隔离和Hystrix操作(Hystrix是Netflix发布的一个旨在通过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力的库，译注)

像Netflix（一家在线影片租赁提供商，译注）这类网络级别的应用使用成千上万个跨多个数据中心的服务器为数百万用户提供服务。系统故障无疑将会影响到用户体验、产品形象以及公司品牌和潜在收入。(Netflix)这些面向服务的架构由于太过于复杂而无法完全被理解和控制并且需要慎重对待。节点之间的关系不断变化并且作为系统中的成员独立演化。这些关系中的故障以错误和延迟的形式表现出来,弹性系统很容易就进入脆弱状态。 单个基础设施不要指望能够获得弹性。作为一个复杂系统组件的应用实例必须要隔离故障并不断对变化进行审计。

在Netflix（工作中），我们已经在系统的快速恢复能力工程上花费了大量时间和精力。我们已经建立的工具之一是Hystrix，它特别侧重于故障隔离和优雅降级。它是从一系列生产事故（比如饱和连接、与/或线程池、级联故障、池配置错误、队列、超时和其他类似导致影响主要用户的小错误）中演化而来的。

该开源库在不可避免发生新的失败时遵循以下原则来保护我们系统：

• 使用舱壁和断路器模式隔离客户端网络交互。
• 当有可能的时候（对系统）进行还原和优雅降级。
• 当（系统）还原不可用或不能快速还原时快速失败。
• 监控，提醒并且促使系统更改使用低延迟（秒）的配置。

限制对一个特定后端服务的并发访问已被证明是一种形式有效的隔离层，因为它限制了资源并发请求，使其小于应用实例的总的可用资源。我们使用两种技术：线程池和信号灯。它们都提供了限制并发访问的必要保证，同时线程提供了超时这样额外的机制，如果潜在的有一些基础工作，调用者就可以“离开”。

隔离功能相较传输层是有价值的，因为它不仅将隔离扩展到网络故障与延迟，同时也扩展到那些客户端代码所引起的问题。例子有请求验证逻辑，条件路由到不同的或多个后端，请求序列化，响应反序列化，响应的校验，和装饰。网络响应可以延迟，损坏，或在任何时候有不恰当的改变，这反过来又可以导致该应用程序意外逻辑故障。

混合的环境也会有几种客户端，对应于许多不同类型的后端。每一个都有不同的配置，而且在生产环境中，大多数客户端不会轻易暴露自己给审计或修改。令人遗憾的是，尽管尽了最大努力，通常默认配置也不是最佳的，这些都渗透到系统中（特别是通过依赖传递），只要有一个配置错误的客户端暴露出一个漏洞，结果就是系统的中断。

隔离层包裹于所有这一切之外——传输层，网络客户端和客户端代码——它提供了可靠的保护，对那些不管来自何方的改变行为，错误配置，依赖传递的意外网络活动，响应处理失败，以及整体延迟。

在功能层使用隔离也能够在错误发生时为优雅降级提供回滚行为的附加业务逻辑。错误可能来自网络或者客户代码异常、超时、短路或过多的并发请求。所有的这些现在都可以通过同样的错误处理器提供的回滚操作来处理。有些功能也许不能进行优雅降级，因此将快速失败并卸除载荷直到恢复，但是许多其他功能则可以返回历史数据、使用备用系统、使用默认值或其他类似的模式。

操作与检视当前状态对于实际的隔离技术是同等重要的。其关键方面是低延迟的量度、低延迟的配置更改和无视网络传输实现方式的对所有服务之间关系的普遍检视。

我们使用低延迟(~1秒)的量度流，其整合了集群中所有应用实例的量度结果，用于警示和对系统流量、性能和隔离层健康情况可视化显示的控制板（如下面的视频片段和上面的图片所描述的那样）。接近于实时的量度使得在进行部署或处理生产事故时提供更短的平均故障检测时间(MTTD)和平均故障恢复时间(MTTR)。配置更改在几秒钟内以可视化的方式应用于集群中的服务器上，并且其影响也立刻能够被观察到。

YouTube: http://www.youtube.com/watch?v=zWM7oAbVL4g&feature=player_embedded

对于维护有韧性的系统，审计产品是必须的。我们在生产环境中使用 Latency Monkey向面向服务架构系统之间注入延迟。延迟对于分布式系统更具破坏性，且比机器或代码的快速失败更难定位。 当进行延迟模拟时，Hystrix实时监测使得我们可以快速地看到影响，并决定我们是否安全，是否需要结束测试。大部分情况，这些模拟在控制板上突显出一个Hystrix隔离层，显示出它正在完成它隔离延迟的工作，但有时我们会揭示出性能下降，并快速发现它们，结束测试，并加入一个解决方案在下一轮测试中进行验证。

我们使用的另一种形式的审计，是跟踪所有离开JVM的网络流量，并找到任何隔离层后非孤立的流量。我们使用这种方式就像谚语矿井中的金丝雀所说的那样，持续的运行，并从生产流量中拿出一小部分，从中找到非孤立的骤然增加的网络流量。这可以发生在最初用新的代码部署金丝雀时，也可能发生在当A/B测试打开时、意外的代码路径通过依赖传被启用，或者生产配置的修改及推送到现有服务器群。

(译注：矿井中的金丝雀 17世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”，以便在危险状况下紧急撤离。 )

优雅降级并不单纯是一个服务器端的考虑，在让用户体验优异和可优雅降级方面，我们的设备和用户界面团队发挥着同样重要的作用。例如，服务器可以使用隔离层隔离故障，并对请求的一部分选择失败时“无声”的响应，但用户界面必须正确的表现，否则在客户端试图响应渲染不存在的数据时，它可能会失败。通过Hystrix execution hooks(运行钩子)的故障注入,可以使设备团队以特定的用户界面，设备，和帐户为目标，以便测试失败，延迟，和回退场景下，客户端代码是否正常响应。

应用的工程弹性是实现故障和延迟耐受性的关键。操作的注意事项和客户端应用支持同等重要。这些原则的应用方式可以有很多不同方式或途径（因语言、技术特点、个人喜好（但愿来自经验）甚至开源软件而异），(我们)可以从中受到启发以改善我们系统的应变能力。

其它翻译版本 (1) 加载中 本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务