系统设计的黄金法则.docVIP

系统设计黄金法则最近多次看到系统设计与实现的文章与讨论，再加上以前读过的其他资料以及自己的一些实践教训，让我觉得应该把这些资料汇总整理一下。如果要从讨论不同系统的众多资料中总结一条黄金法则的话，那只有一个词——“简单”；如果用一个英语单词来表达的话，那就是——KISS (Keep It Simple, Stupid!)。 　　麻省理工方法与新泽西方法(MIT Approach vs. New Jersey Approach) 　　这个观点来自一篇很经典的文章，Richard Gabriel 在 1989 年写的文章中的一节“The Rise of ‘Worse is Better’”。说来惭愧，我是直到 2011 年 5 月在 IBM T.J. Watson 实验室听报告才第一次听说，当时便印象深刻。后来上普林斯顿的高级系统设计课程，发现这篇文章也在 Reading List 中，要求所有学生阅读然后在课上讨论。 　　“The Rise of ‘Worse is Better”对比了以 LISP 系统为代表的麻省理工方法和以 Unix/C为代表的新泽西(贝尔实验室)方法。Gabriel 发现相比于 LISP/CLOS 系统完美的设计，Unix/C只是一味追求实现简单，但事实却证明 Unix/C 像终极计算机病毒那样快速蔓延，奠定了今天计算机系统的基础。 　　让我们来看看这两种不同的设计哲学。 　　1）MIT Approach 　　简单性：设计必须简单，这既是对实现的要求，也是对接口的要求。接口的简单要比实现的简单更加重要。 　　正确性：设计在任何值得注意的方面都要保证正确。不正确是绝对不允许的。 　　一致性：设计必须保持一致兼容。设计可以允许轻微少量的不简单和不完整，来避免不一致。一致性和正确性同等重要。 　　完整性：设计必须覆盖到实际应用的各种重要场景。所有可预料到的情况都必须覆盖到。简单性不能过度的损害完整性。 　　2）New Jersey Approach 　　简单性：设计必须简单，这既是对实现的要求，也是对接口的要求。实现的简单要比接口的简单更加重要。简单是设计中需要第一重视的因素。 　　正确性：设计在任何值得注意的方面都要求正确。为了简单性，正确性可以做轻微的让步。 　　一致性：设计不能过度不兼容一致。为了简单，一致性可以在某些方面做些牺牲，但与其允许设计中的这些处理不常见情况的部分去增加实现的复杂性和不一致性，不如丢掉它们。 　　完整性：设计必须覆盖到实际应用的各种重要场景。所有可预料到的情况都应该覆盖到。为了保证其它几种特征的品质，完整性可以作出牺牲。事实上，一旦简单性受到危害，完整性必须做出牺牲。一致性可以为实现的完整性作出牺牲；最不重要的是接口上的一致性。 　　如果觉得这种哲学描述太抽象的话，原文中有一个关于 Unix 中断处理的例子，非常生动。一位 MIT 的教授一直困恼于 Syscall 处理时间过长出现中断时如何保护用户进程某些状态，从而让用户进程能继续执行。他问新泽西人，Unix 是怎么处理这个问题。新泽西人说，Unix 只支持大多数 Syscall 处理时间较短的情况，如果时间太长出现中断 Syscall 不能完成，那就会返回一个错误码，让用户重新调用 Syscall。但 MIT 人不喜欢这个解决方案，因为这不是“正确的做法”。 　　Unix/C开发于 1970 年前后，那时离 1964 年刚推出的 IBM System/360 没几年，软件刚摆脱硬件束缚，能移植到不同的机器上，从而变成了一种可单独出售的产品。就是这样的一个软件产业的萌芽期，这种“实现简单”的理念被证明是更有效的。那么在今天的互联网时代，这种理念还有效吗？我们再来看下一篇文章。 　　来自互联网巨头们的教训 　　这是最近看到，作者从 High Scalability Blog 上总结了几大互联网在设计后台数据中心所遇到的教训（这篇文章总结的非常好，强烈推荐大家读一下）。文章开头就总结了七个互联网公司（Google, YouTube, Twitter, Amazon, eBay， Facebook and Instagram）都提到的 6 点教训： Keep it simple – complexity will come naturally over time. Automate everything, including failure recovery. Iterate your solutions – be prepared to throw away a working component when you want to scale it up to the next level. Use the right tool fo