《Akka应用模式:分布式应用程序设计实践指南》读书笔记7

  1. 云栖社区>
  2. 博客>
  3. 正文

《Akka应用模式:分布式应用程序设计实践指南》读书笔记7

gabrywu 2018-06-12 17:35:00 浏览735
展开阅读全文

容错

  容错绝对是分布式系统最难搞定的事儿,至少我这样认为,因为意外总是会发生。

  处理故障在许多方面意味着要放弃全局一致性。Akka是基于不粗要调用方负责处理故障的想法而建立的。它主张由发生故障的actor负责处理问题,在actor不能处理的情况下,会向其“监督者”寻求帮助。由于Actor模型基于消息机制设计,就意味着系统的很多部分都是异步的,异步又进一步导致出现故障时解决问题的难度。而Akka有一套完整的机制,将故障尽量限制在对应的actor上,缩小出现故障的影响范围和降低解决故障的成本和时间。但·Akka只是提供了故障恢复的机制,具体怎么恢复还是需要我们自己设计。

故障类型

  在之前我也说过,分布式系统有很多不确定性,会出现各种意外,对意外分门别类总是有好处的。

异常

  不管是单机系统,还是分布式系统,系统故障中最常见的类型之一。其实自从学了Scala,觉得传统的异常机制不太完美。因为它以一种奇怪的方式改变了程序的流程。而且绝大部分你总是会发现没有处理的异常,也就是说,异常变成了程序异常退出的一个出口,而异常一旦有很多个,就意味着程序“千疮百孔”,各种漏洞。这样的结果很可能导致系统释放资源的代码没有资源,造成资源泄露或其他意想不到的问题。所以我更喜欢用一个Try来封装所有的异常。

JVM致命错误

  这就比较难办了,很多时候都是任期发生,然后找出问题再解决。需要注意的是,Try无法处理这种会使系统崩溃的严重错误,比如内存溢出。看看Try的源码就知道为啥了。

外部服务故障

  系统往往需要与外部系统进行交互,外部API出现问题也是比较头疼的。因为问题不可控,我们只能选择接受,而无法解决。但意识到这种问题的存在非常重要。

不符合服务等级协议(SLA)

  其实这就比较主观了,毕竟SLA还是可以定的比较宽松的,^_^。如果一个系统总是能返回一个正确的结果,但却不一定能保证在合理的时间内返回,这就比较尴尬了。最好的系统仍然可能成为高负载的情况下的受害者,因为它无法达到预定义的服务等级协议(SLA)。这其实还挺尴尬的,有时候SLA还会变化,就更麻烦了。

操作系统和硬件级故障

  这个吧,只能买好一点的机器。。。不过还是可以指定适当的预防措施的。

故障隔离

  我觉得这是处理故障的最正确的一个设计理念。那就是不要试图去消除全部的故障,而是承认其存在,将其限定在合理的范围内,隔离其影响范围。幸运的是,Akka提供了相关的工具。

舱壁模式

  这种模式对于我来说还是比较新颖的,因为我一直以为船舶一旦触礁,就会有大量的水流到船体内,然后就挂了。Akka提供了以actor层次结构形式实现的舱壁模式工具。也就是actor内部的错误不会蔓延,只影响其自身的功能。如果需要,还可以进一步分解,让特定actor只处理特定时间段内的请求,这样可以将请求中的故障隔离在请求发生的时间段内。

  这种设计理念我还是很喜欢的,毕竟很多时候,导致出现故障的原因,也许只是遇到了某个异常的请求,忽略这个请求,简单的重启继续后续消息的处理也许是非常合理的。

优雅降级

  这在互联网的架构博客中经常会被提及。其实刚开始我对它的理解比较粗浅,什么优雅降级,不就是let it go吗?所谓的优雅降级,就是牺牲一部分系统功能,使当前最重要的业务功能可用。优雅降级可以避免使这鞥个站点发生故障,只让其中一部分不可用,其他功能不受故障影响。这种降级,有时候是系统自动发生的,有时候是人工启动的。比如在业务高峰期,系统资源不足,可以选择性的将部分功能下线,以确保最核心的业务功能可用,就是所谓的丢车保帅。

使用Akka集群隔离故障

  Akka内置了舱壁模式,使其更加透明。集群分片某种意义上来说,就是对actor进行故障隔离。另外一个好处就是它可以自动将失败的节点上的actor重新分配给其他节点。

使用熔断器控制故障

  熔断器通常用来解决高负载情况下系统的故障隔离的。简单点来说,就是当系统处于高负载时,为了避免后续的消息使情况进一步恶化,成为压死骆驼的最后一根稻草,自动的使所有调用失败,甚至不会尝试处理调用请求。也就是尽快的通知调用方,调用失败了。故障恢复或者负载变低时,调用恢复正常。熔断器提供 一个让发生故障的系统在一段时间内恢复原有功能的方法。

  在预先设置好的时间段过去之后,熔断器进入“半开”状态。此时,进入熔断器的第一个调用将被处理,如果调用成功,则熔断器进入关闭状态,系统恢复正常运行。如果第一个调用还是失败,则熔断器返回到“打开”状态,继续使所有的调用快速失败。如果回到“打开”状态,则在接下来的一段时间内都保持打开状态。

  幸运的是Akka内置了熔断器CircuitBreader,使用还是比较方便的。

 故障处理

  前面已经对故障的类型做了分类,也对故障隔离和故障控制做了介绍,但没有说如何解决故障。Akka是设计理念是“let it crash”。从崩溃中恢复才是弹性系统应该具备的能力。首先认识的故障的发生,才能正面的解决和规避它。

异常处理

  异常一般分为非致命异常和致命异常。当然了是否致命是对整个系统来说的,不是对某个代码、函数或者actor来说的。

  在单个actor中,可以简单的处理可预测的故障,比如用try catch快封装;当异常不能被它的actor处理时,就会把异常发送给上层的监督者,由监督者决定如何处理。幸运的是Akka内置了几种常见的恢复策略。OneForOneStrategy提示监督者将恢复逻辑应用于发生故障的actor,其他actor不受影响;AllForOneStrategy告诉监督者将恢复逻辑应用于所有的子actor。恢复逻辑一般就是重启,actor重启的代价比较小,只需要做好相关的业务初始化代码即可。Decider是一个partial函数,它根据异常类型决定采取的应对方式。Decider将异常类型映射到以下执行。

  Resume。告诉发生故障的actor继续处理消息,即忽略发生故障的消息。

  Restart。告诉发生故障的actor应该重启。

  Stop。告诉发生故障的actor应该被停止。比如临时、一次性的actor,失败后不再需要,就可以停止。

  Escalate。将故障升级。其实就是把异常向上汇报,由监督者的监督者处理。

  其实选择合适的异常处理策略还是比较难的,因为异常就是意外,很难预测。我们所能做的就是对已知的故障进行应对,无法预见的就只能交给后期版本迭代了。

  JVM致命错误怎么办呢?Akka自身没有现成的工具可以做到这一点。但可以引入第三方工具,比如ConductR或者supervisor。当检测到对应JVM退出时,简单的重启。但还可以优化一下,比如在应用程序中设置一个回退点。在Akka中,我们可以选择将消息持久化,从某个时间点开始,回放消息。当然了这需要系统具备至少一次的交付机制。

外部服务的故障处理

  其实外部服务的故障我们往往没法解决,只能将其隔离,限制影响范围。可以将外部服务系统是为一个有界的上下文,为它创建一个包装器包装它。简单情况下,用一个actor封装对应的操作就好了。不过还可以用AtLeastOnceDelivery机制来确保外部服务恢复时,消息被重新发送处理。

  作者提到过渡使用AtLeastOnceDelivery机制表明我们正在尝试实现全局一致性,这一点对我的启发挺大的。其实我们在使用某个技术细节的时候,往往只考虑它带来的好处,而看不到隐藏的弊端。再加上程序员都是分流派的,互相怼来怼去,就更加夸大某个技术的好处,而选择性忽略其问题。技术要合理的使用。AtLeastOnceDelivery机制最适合调用流水线的两端,不要在管道的中间阶段使用它。

结论

  基于actor的分布式系统发生系统故障的可能性非常低,同事比其他类型的系统更容易从故障中恢复。这一点我深信不疑,看看我开源的代码就知道原因了。不过在分布式系统中,对于故障处理是一件非常麻烦的事情,因为它有可能占用系统设计、开发总时间的50%,甚至更多。

网友评论

登录后评论
0/500
评论
gabrywu
+ 关注