devops方法论_3种处理DevOps瞬态故障的方法

最新推荐文章于 2022-06-25 17:45:25 发布

cumo3681

最新推荐文章于 2022-06-25 17:45:25 发布

阅读量635

点赞数

文章标签： java 数据库分布式大数据人工智能

原文链接：https://opensource.com/article/19/9/transient-faults-devops

版权

devops方法论

在电气工程中， 瞬态故障定义为在断开电源并恢复电源后消失的错误状态。当我们强制关闭物理设备的电源，然后在充满乱码的蓝色崩溃屏幕上强制关闭或打开物理设备的电源时，这也是我们许多人不自觉使用的解决方法。

在云计算中，我们将面对越来越多的复杂性，未知的未知因素，或更糟糕的是，我们将永远无法接触的未知未知的基础设施，以及以指数级速度发展的技术和连接不断扩展的数字世界的不同解决方案。如今，虚拟用户对无响应，不可靠和性能不佳的产品的容忍度为零-每个人都希望24x7全天候正常运行时间以及不断发展并融入其生活方式的解决方案。

让我们快速看一下两个令人沮丧的事件，这些事件提醒我们，当今的瞬时故障可能发生在心跳中，难以识别和解决，并且对利益相关者产生深远的影响。

一个粗糙的补丁 ： “ 过去半个星期我们在服务方面遇到了一些问题。我对此感到非常恐惧，对此我深表歉意。这是自我们的不稳定性以来我们遇到的最大事件。服务重构”，微软公司云开发服务副总裁Brian Harry在博客中写道。经过数周的不眠之夜，根本原因被确定为对访问控制服务（ACS）的请求风暴，该请求耗尽了源网络地址转换（SNAT）端口，阻止了身份验证并影响了利益相关方。
503错误： “在Azure实施过程的开始就设置监视，这证实了在DevOps流程中进行监视的重要性，” Cellenza的Mikael Krief在ALM DevOps Rangers博客上报道。同样，我们花了整夜不眠的夜晚，找到了我们重构后的扩展为何引发连接和线程风暴，破坏了我们的Azure服务以及使利益相关者感到“ 503服务不可用”错误的根本原因。

我们可以为我们的云应用程序设置故障和灾难恢复，以帮助最大程度地减少（而不是消除）由资源故障或自然灾害引起的中断的影响。但是，对于使用远程资源或与远程服务通信的解决方案，我们需要增加对瞬态故障的敏感性。经过精心设计的解决方案可以在发出警报之前检测并尝试对瞬态故障进行自我纠正，甚至更糟的是，它们会变得无响应和失败。

有几种瞬态故障处理模式，包括以下白板上显示的三种：重试，节流和断路器 。

重试模式

重试模式是三种瞬态故障处理模式中最简单的一种，我们在日常生活中自然会做一些事情。在跨分布式网络进行通信以解决由网络延迟，服务过载和断电等问题引起的瞬态故障的解决方案中，它可能是有效的。

伪码

设置failure_count = 0
致电 [微]服务
如果（失败）failure_count ++
如果（failure_count> retry_limit）或（非暂时性失败）失败
延迟时间 （delay_time）
将delay_time增加为failure_count的倍数
重试步骤2

该模式可确保在不理想的情况下，用户的请求最终成功，在这种情况下，瞬态失败会导致立即失败和频繁失败。有关详细信息，请参见开源实现，例如java-design-patterns和transient-fault-handling-application-block 。

节流模式

我们需要保护我们的服务免受过度使用我们的解决方案或由于系统或逻辑故障而变得无聊的客户的侵害。就像为六车道高速公路服务的四车道隧道一样，我们必须管理超过最大吞吐量（隧道）的请求（汽车）和节流端点（车道）的流量。

伪码

增加request_count
//限制–一个间隔内的最大请求数
//降级–因“减速”错误或暂停操作而失败
如果（request_count>限制）降级服务
致电 [微]服务

该模式有助于我们满足服务水平协议，防止单个用户过度使用系统，优化请求流以及处理突发的请求。我们需要增加先前模式中重试之间的延迟的原因之一是，确保我们不会无意中超过系统的吞吐量并触发服务质量下降。有关更多详细信息，请参见WebApiThrottle和Core.Throttling等开源实现。

断路器模式

像您家中的断路器一样，断路器模式是您的最后防御。重试模式有助于自动纠正短暂的瞬态故障，但此模式更适合需要较长时间才能解决的瞬态故障。在处理网络或服务中断（例如“ 粗糙补丁”事件）时，重试失败的服务操作可能会使情况恶化，导致级联故障，并最终触发解决方案崩溃。断路器模式的假设是，失败的服务呼叫很可能在（且仅当）在重大延迟后自动重试时才成功。

就像您在黑暗中交错进入地下室以找到断路器柜一样，您可以在翻转开关之前让电气系统和潜在的静电荷恢复。

伪码

//断路器没有跳闸
如果（circuit_state ==打开）

致电 [微]服务
如果（失败）fail_count ++
如果（失败计数>限制）circuit_state = 已关闭

//断路器跳闸
其他

如果（circuit_state ==闭合）启动计时器

//调用计时器事件
定时器超时

致电 [微]服务
如果（成功）circuit_state == 打开

有关更多详细信息，请参见开源实现，例如Hystrix ， circuit-breaker和Polly 。

不要担心缺点

切记包括所有已知故障和已实施处理模式的单元测试和集成测试。触发故障处理逻辑时，单元测试必须验证您的解决方案能够正确响应。另一方面，集成测试必须模拟弹性故障，以验证您的集体服务解决方案可以有效地处理故障。您可以通过使用服务虚拟化（例如Hoverfly）来模拟服务，瞬态故障和降级服务。如果您的解决方案和相关的故障处理模式未能实现自我修复和避免灾难性崩溃的希望，那么您的利益相关者将不会感到高兴。

因此，故障就像故障一样，是无可指责的DevOps的功能，我们不应该担心它们。为了保持竞争力，我们必须提高基础架构，解决方案和问责制的质量标准，以进行根本原因级别的检测，修复，并进行自我纠正以维持可接受的服务级别。

例如，在下图中，微服务＃7已爆裂，触发断路器和流量节流，并在继续为用户提供服务的同时允许系统恢复。从这个简单的说明中可以明显看出，故障的组合和处理故障的复杂性在特征标记切换时会变得复杂。