|||
【注:本文已发表在2012年第5期《中国计算机学会通讯》。】
最近多次看到系统设计与实现的文章与讨论,再加上以前读过的其他资料以及自己的一些实践教训,让我觉得应该把这些资料汇总整理一下。如果要从讨论不同系统的众多资料中总结一条黄金法则的话,那只有一个词——“简单”;如果用一个英语单词来表达的话,那就是——KISS (Keep It Simple, Stupid!)。
麻省理工方法与新泽西方法(MIT Approach vs. New Jersey Approach)【1】【2】
这个观点来自一篇很经典的文章,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没几年,软件刚摆脱硬件束缚,能移植到不同的机器上,从而变成了一种可单独出售的产品。就是这样的一个软件产业的萌芽期,这种“实现简单”的理念被证明是更有效的。那么在今天的互联网时代,这种理念还有效吗?我们再来看下一篇文章。
来自互联网巨头们的教训【3】
这是最近看到的一篇文章,作者从High Scalability Blog上总结了几大互联网在设计后台数据中心所遇到的教训(这篇文章总结的非常好,强烈推荐大家读一下)。文章开头就总结了七个互联网公司(Google, YouTube, Twitter, Amazon, eBay, Facebook and Instagram)都提到的6点教训:
第一点就是“简单”,但和New Jersey Approach的原因和内涵有所不同。不同于Unix时代相对简单的单机系统,互联网时代的大公司的系统往往都是成千上万台机器,在这样的系统上部署、管理服务(软件)是一项非常有挑战的任务。而为大规模用户提供的一项服务往往会涉及到众多模块、若干步骤。此时“简单”就是要求每个阶段、每个步骤、每个子任务尽量采用最简单的解决方案,这是由于大规模系统内在的不确定性导致的复杂性决定的。
即使做到了每个环节最简单,但由于不确定性的存在,整个系统还是会出现不可控的复杂性。比如,Google Fellow、美国工程院院士Jeff Dean最近在UC Berkeley有个报告【4】介绍他们努力缓解大规模数据中心中的Long-Tail Latency难题。问题简单描述如下:假设一台机器处理请求的平均响应时间为1ms,只有1%的请求处理时间会大于1s (99th-Percentile)。如果一个请求需要由100个这样的节点一起处理,那么就会出现63%的请求响应时间大于1s,这样的系统完全是不可接受的。面对这个复杂的不确定性问题,Google他们做了很多工作,权衡各种Tradeoff,具体请看这个报告【4】。
大规模数据中心,看起来似乎和我们普通的开发人员离得比较远。但最近看Paul Graham写的《Hackers and Painters》这本介绍硅谷创业公司的书,发现Graham也在多处强调“简单”。
Paul Graham的《Hackers and Painters(黑客与画家)》
Paul Graham被称为“硅谷创业之父”。他在1995年和MIT的Robert Morris教授创办了Viaweb,于1998年被Yahoo!以4900万美元收购。2005年,他又创办了Y Combinator创业孵化器公司,帮助80多家创业公司成长起来,其中包括Dropbox(市值大于40亿美元)、Airbnb(市值大于13亿美元)等。显然,Graham有丰富的创业经验。
Graham在“设计者的品味”一章中写到,“好的设计是简单的”、“简单就是美,正如漂亮的数学证明往往是简短而巧妙的那种”。他提到,有些创业者希望第一版就能推出功能齐全的产品,满足所有的用户需求,但这种想法是致命的。在硅谷创业最忌讳的就是“Premature Optimization”。因为一方面用户需求是多样的,不同人群都有不同的需求;另一方面开发者想象的需求往往和真实的用户需求有偏差。所以,Graham推崇那种有用户参与反馈的迭代优化的方式。
无独有偶,最近至少听到两个报告提到了Facebook的开发模式。当Facebook开发一个新的服务,会先让一个小用户群使用,根据用户的反馈来修改功能,同时可以调试程序中的bug。然后下一版让更大一些的用户群使用,收集用户反馈继续修改程序。如此反馈几次,最后再推向所有用户。这种模式要求再最初设计时尽量简单,从而只需几个月的时间就能推出一个新的功能,然后再不断地优化完善。
到目前为止,谈的工业界偏多一些,但其实在系统领域的学术研究,“简单”法则同样适用。
李凯教授:KISS原则
美国工程院院士、普林斯顿大学计算机系李凯教授是“KISS”原则的坚决贯彻者。几乎每次和李凯老师讨论,他都会强调“Keep it Simple”。李凯老师的做事方式是——只抓住大方向,其他问题尽量简化。
但真正要做到KISS原则其实并不容易。我在遇到问题时,往往会从各个方面去考虑问题,其中难免包含了各种细枝末节,这种方式导致问题经常会变得非常复杂。之前讲过这个例子,在移植TCP/IP协议栈到用户态时,我觉得有约10个功能需要考虑。和李老师讨论,他让我把那些功能分成两类:“必须有(Must Have)”和“可以有(Nice-to-Have)”。当我试了这种方法,发现原来Must-Have的功能其实也不过2~3个而已。而最近的例子则是在要设计一个功能让TCP/IP连接的Server在模拟器中、Client在真实机器。我考虑是尽量减少模拟器上OS的开销,所以打算采用自己写一个设备、然后让用户态程序Bypass Kernel直接访问该设备的方案。但李凯老师在了解OS开销以后,认为容忍开销、尽量直接使用模拟器自己带的功能,让开发更简单。
这些教训也让我不断地去思考为什么要用KISS原则。慢慢地我体会到,KISS原则目的其实是——“快速推进、逐步优化”。我们设计一个算法,往往可以在大脑中预先思考好,然后直接编程写出来。但是,我们设计实现一个系统,当系统的复杂度超出我们大脑的工作记忆容量时,就无法在大脑中去“模拟”每一个细节。此时,我们应该用最快的速度去把系统建起了,然后再对各个环节进行优化。
这个KISS理念并不是计算机系统领域特有的,最早是来源于研制飞机时提出的设计理念。而在其他领域,如果一个任务涉及多个步骤,也同样有效,比如生物研究。我去年前曾看过施一公教授写的一篇文章中也提到了这一点。
施一公教授:"耗费时间的完美主义阻碍创新进取 "【5】
2011年9月清华大学施一公教授在科学网上发布了一篇博客《如何做一名优秀的博士生:(二)方法论的转变》,其中介绍到完美主义的危害,其实是从另一个角度来强调“简单”。
施教授讲了他博士后期间的一个故事。一次他的任务是纯化一个蛋白。两天下来,虽然纯化了,但是产量只有20%。
他不好意思地对导师说,“产率很低,我计划继续优化蛋白的纯化方法,提高产率”。
但导师反问:“你为什么想提高产率?已有的蛋白不够你做初步的结晶实验吗?”
他回敬:“我有足够的蛋白做结晶筛选,但我需要优化产率以得到更多的蛋白。”
导师不客气地打断:“不对。产率够高了,你的时间比产率重要。请尽快开始结晶。”
实践最后证明他导师的建议是对的。
对于这个故事,施一公教授总结如下:
结语
我想从各个角度去阐释“简单之美”,但到最后感觉这篇文章就是一个大杂烩。既然如此,那我就再加一点料。
Elon Musk是现实世界中的钢铁侠,他先后创办了网络支付公司PayPal、电动汽车公司Tesla以及空间探索公司Space X。目前Space X研制的“猎鹰”火箭已成功试飞,并得到NASA 16亿美元的合同。为了减低成本和提供可靠性,Space X设计的火箭也到处渗透着“简单”【6】:“在他们的猎鹰1号运载火箭上,并没有很多专利,科学家们不在乎,只要火箭能飞就行。火箭用的主发动机也不是21世纪的最新设计,而是1960年代的老古董,只有一个燃料喷射器。它很老,但很可靠。”
参考资料
【1】“The Rise of 'Worse is Better'”, http://www.jwz.org/doc/worse-is-better.html
【2】“"差点的更好"设计理念的兴起”, http://www.aqee.net/the-rise-of-worse-is-better/
【3】“Scalability Lessens from Google, YouTube, Twitter, Amazon, eBay, Facebook and Instagram”
http://www.dodgycoder.net/2012/04/scalability-lessons-from-google-youtube.html
【4】“Achieving Rapid Response Times in Large Online Services”, Jeff Dean, Google.
http://research.google.com/people/jeff/latency.html
【5】“如何做一名优秀的博士生:(二)方法论的转变”,施一公,科学网博客
http://blog.sciencenet.cn/home.php?mod=space&uid=46212&do=blog&id=486270
【6】“硅谷企业家开设私人火箭工厂 目标直指火星”,新浪科技,http://tech.sina.com.cn/d/2012-02-09/16086703213.shtml
Archiver|手机版|科学网 ( 京ICP备07017567号-12 )
GMT+8, 2024-10-15 08:37
Powered by ScienceNet.cn
Copyright © 2007- 中国科学报社