Principles of Software Engineering, Part 1

这篇文章是读 Principles of Software Engineering, Part 1
)，摘录了部分内容

对抗软件中不确定的手段

作者在原文中总结了以下手段

最小化依赖

让软件更加健壮的一种技术手段是尽量让软件的依赖少。出错的组件越少，那么软件也就更少的出错。相对于依赖系统X或Y，依赖包含的内容会更多，比如你使用系统的的特性也是一种依赖。
Storm使用的zookeeper是一个很好的例子。集群中所有workers的位置信息是存储在zookeeper中的。当一个worker被重新分配后，其他的worker一定要尽快的发现这个worker的位置信息，这样它们就能发送数据到正确的位置。为了发现worker位置，有两种方式，分别是pull方法和push方法。在pull方式中，workers周期性的从zk中获取到最新的worker位置。而在push方式中，zk提供了“watches”特性用来当位置信息有变化时就发送最新的workers信息。push发送信息要比pull更加快速，但是push依赖zk的特性。
Storm使用了两种方式来传播worker位置信息。每个几秒，storm就会poll最新的worker信息。除了这个，storm还利用了zk的watches特性来加快worker信息获取的速度。这个设计保证了即使zk的watch特性失败了，那么worker仍然能够获取到准确的位置信息，虽然有些延迟。所以storm能够利用watch特性但是又没有完全依赖这个特性。大部分时间，watch特性都能够正确工作从而信息能够快速传播，同时这也避免了watch失败后导致storm不能工作的问题。这种设计正确是有远见的，因为zk中的watch出现过严重的bug。
在最小化依赖项和为了实现应用最小化代码数量(因为减少依赖项，可能为了达成应用功能需要付出一定的代码数量)之间存在一种平衡。在上面这个例子中，同时采用两个方式来传播位置信息是一种很好的方式，这是因为pull方式仅仅只是增加了少量的代码。另一方面，完全移除zk并不是一个好主意。因为要实现watcher功能需要大量的工作，同时自己实现相对于zk(广泛使用的开源项目)会有更少的稳定性。

减少级联失败的概率

级联失败是生产环境中一种很严重的失败。级联失败感觉像是世界都奔溃了。在我的经验中，造成级联失败的一种常见原因是服务的拒绝攻击。最底层的原因是因为并没有遵守系统中组件的输入范围。让组件之间的交付满足输入限制，为了避免DOS攻击，可以采用限流器。
另外一项技术是尽可能的隔离组件，同时减少组件之间互相的影响。说起来容易做起来难，但是如果发生级联失败时，这是一种非常有用的技术。

测量和监视

在生产环境中发生意外事件时，进行彻底的监控是非常关键的，这样就可以弄清楚发生了什么。随着软件逐渐稳定下来，意外变的越来越少，而且再现这些事件将变得越来越困难。因此，当发生意外事件时，您希望尽可能获取有关该事件的数据。
软件应从一开始就设计为可监控的。我认为软件的监控方面与软件本身的功能一样重要。而且应该对一切进行测量 - 延迟、吞吐量统计、缓冲区大小以及与应用程序相关的任何其他内容。监控是对软件固有不确定性的最重要的防御手段。
同样，对所有组件进行测量是重要的，以了解它们的功能输入范围。每个组件可以处理什么样的吞吐量？更多流量会如何影响延迟？如何破坏这些组件？进行这种测量工作可能不够光鲜，但对于可靠的工程来说是必不可少的。

总结

软件工程是与不确定性的持续斗争 - 不确定规范，不确定实现，不确定依赖项，以及不确定输入。认识到并为这些不确定性做好规划将使您的软件更可靠，也会让您成为一名更好的工程师。