Let It Crash的原理及其作用

约定不等于承诺〃 2022-10-10 12:48 138阅读 0赞

[参考此文章，请点击此处][Link 1]  
 一、是的，你没看错，就是Let It Crash(任其崩溃)。  
   为什么能（甚至是要）这么做呢？为什么SQL语句执行异常就要使整个程序崩溃退出呢？常规做法不应该是捕捉到异常之后进行重试等操作来尝试解决异常吗？这样说崩溃就崩溃的代码难度不会让人耻笑？  
事实上，我们不应该忙着耻笑，因为这其中其实隐含着一个对于复杂系统稳定性提升极端重要的思想： Let it crash！  
   在日趋复杂的互联网分布式系统中，如何提高系统的稳定性、容忍局部致命错误、保障不出现全局性的系统故障，是一个颇有挑战的问题，也是一个开放性的问题。关于此问题，有无数的先贤智者提出过诸多具有远见卓识的编程思想或者解决方案。而这其中，由Joe Armstrong倡导，并在Erlang这门编程语言中完美实施的“let it crash”编程思想无疑是其翘楚之一。

作为一种编程思想范式，对于什么是“Let It Crash”，业界并没有一个标准的定义。与其对立的编程思想是“Defensive Programming（防御性编程）”，而与其含义相近的则有“fail-fast（速错）”、“crash-only（直接崩溃）”等几种不同名称的概念。

我们也可以认为“Let It Crash”是系统设计中“KISS（Keep It Simple & Stupid）”原则的直接应用。Let It Crash原则使程序代码足够简洁，以至于简洁到难以出错的地步，这也就从另一个角度提高系统的可靠性。  
 二、定义  
   另外一个广为流传的、来自于Erlang之父Joe Armstrong的定义（更准确的说应该是描述）是：“Only program the happy case, what the specification says the task is supposed to do”。  
   这句话指出在Erlang中let it crash的核心在于处理好happy的case，不happy的case任其崩溃。很显然，这是一个简洁优雅（但略显生硬？）的描述，一个更为详细的描述则来自于实践中Erlang编程环境程序的几点指导原则：  
  1）只为良好定义的逻辑路径编程（Code for the happy path） Focus on what your code should do in the successful case. Code that first and only if necessary deal with some of the unhappy paths. You write software to DO something. Most of the code you write should be for doing that thing, not handling faults when they occur.  
  2）不要捕捉你不能适当处理的异常（Don’t catch exceptions you can’t handle properly） Never catch exceptions when you don’t know how to remedy them in the current context. Trying to work around something you can’t remedy can often lead to other problems and make things worse at inopportune times. Catching exceptions at higher levels is always possible. It is harder to re-throw an exception without losing information. Catch-all expressions that trap exceptions you didn’t anticipate are usually bad.  
  3）不得已失败时应该尽量喧嚣的失败（Software should fail noisily） The worst thing software can do when encountering a fault is to continue silently. Unexpected faults should result in verbose exceptions that get logged and reported to an error tracking system.

我们可以进一步的看到，Let it crash的核心在于对待不你能正确把控的错误的态度：你应该喧嚣的爆出错误，而不是默默的吃掉她。  
   在Erlang中，通过轻量级process（可以理解成协程）、消息队列message、精心设计过的OTP框架等语言级基础设施的支持，Let it crash原则极易的使用和实施，这也使得“Let it crash”在Erlang项目中被广泛的应用于各式各样的生产实践之中。基于Erlang的分布式系统的超强稳定性，事实上反过来证明了这种思想原则的有效性。

三、壮大（无处不在的Let It Crash）  
   那么Let it crash是否是Erlang的专属呢？ 排除掉一些毫无意义的抬杆式的争论（例如某乎上某天的评论文章），绝大部分主流的观点都认为Let it crash作为编程思想范式，并非Erlang专属，而是一个可以在系统设计或者代码编写过程中加以广泛使用的编程原则。

事实上，如果从广义的角度出发，我们可以看到Let it crash其实无处不在。例如，分布于linux操作系统内核各个角落的panic调用、早期windows平台鬼魅般不时出现的蓝屏死机、C/C++语言中广泛使用的assert断言函数和exception机制、Java语言中java.util等 系统类库中广泛使用的ConcurrentModificationException 异常等等， 都可以认为是let it crash的某种实践应用。  
四、 反思（猛药更需良医）  
   现实中的各种实践告诉我们，正确的使用Let it crash可以快速的暴露和恢复问题，提升系统的可靠性，是一剂良药。同时，我们也必须看到Let it crash也绝非可以随意使用的包治百病的灵丹妙药，更不能成为程序编写人员偷懒的借口。  
猛药需要良医号脉开方才不至于误人性命，“Let it crash”发挥其应有的功效也一样需要广大工程师同学精准的把握系统的特性，在限定的条件下合理使用。一般来说，Let it crash在满足如下条件时，才能使用。  
   1）状态一致性能够恢复 崩溃的时候系统的状态必须是可以自动恢复的， Crash不影响系统数据的一致性。例如订单系统中，通过数据库事务保证了一致性，任意时刻崩溃都可回滚恢复，可以使用Let it crash；支付系统中，通过补单等操作在崩溃后修复数据库数据，也可以在一定阶段使用；对于“无状态”的应用，此条件自动满足，也是较好适用场景。  
   2）奔溃状态能有效隔离 崩溃状态隔离是指奔溃的处理器(协程/线程/进程等)必须尽量不波及到崩溃上下文不相关的业务流程，把自身奔溃的状态与不相关业务隔离，避免殃及无辜。例如在Erlang中，轻量级的process可以在不影响其他无关process的情况下随时奔溃退出；在Golang中，goroutine与process相似，可以做到随时创建和panic奔溃而不影响不相关goroutine；多线程模型可以做到线程退出不影响无关线程；多进程模型则可以隔离奔溃状态到自身进程而不影响其他进程。  
   3）监控及自愈手段到位 任其崩溃的每一层实体都必须监控子实体的状态，确保在子实体出现crash时能执行必要的告警和拉起动作。重新拉起后恢复至初始状态，初始状态必定是一致性的状态，进而可以继续提供服务。公司持续推广的zabbix端口监控、supervisord进程监控、cloudha云主机高可用、prometheus业务流量监控等等工具或项目，在不同的层级对公司的系统进行了监控告警和自愈保障。项目中使用Let it crash时，务必保证对上下级的监控及自愈手段进行了设计。  
   4）能容忍局部短时失效 崩溃必然导致系统在某种维度下出现极短时的失效问题，任其崩溃要求系统有高可用特性，能够容忍局部的短时失效。像具有极高可靠性和实时性要求的航天类系统，Let it crash就需要谨慎使用。不过可以放心的是，互联网公司层面的绝大多数（如果不是所有的话）业务服务对于局部短时失效，都是可以接受和容忍的。

五、 总结（欢迎一起探讨）  
   总结本文内容，我们可以得出以下结论：（Maybe此处得出的是争论，欢迎大家线上线下进一步探讨）  
   原则1：永远不要去处理你不知道如何处理的问题，Let it crash（任其崩溃），反馈给你的上级处理。  
   原则2：当你必须失败的时候，尽可能快的吵闹地失败，Fail fast（速错），以便快速定位并解决问题。  
   原则3：系统设计必须要考虑容错性设计，Fault tolerance（容错），在各种层级上监控并恢复有能力恢复的crash。  
   原则4：管理上和心理上容忍试错，不苛责和畏惧系统的crash，甚至对于遵循了Let it crash相关原则并且快速定位到问题点的事故，可以适当降低（或免于）责任等级认定。

[Link 1]: https://zhuanlan.zhihu.com/p/25070432