最近多次看到系統(tǒng)設(shè)計與實現(xiàn)的文章與討論，再加上以前讀過的其他資料以及自己的一些實踐教訓(xùn)，讓我覺得應(yīng)該把這些資料匯總整理一下。如果要從討論不同系統(tǒng)的眾多資料中總結(jié)一條黃金法則的話，那只有一個詞——“簡單”；如果用一個英語單詞來表達(dá)的話，那就是——KISS (Keep It Simple, Stupid!)。
麻省理工方法與新澤西方法(MIT Approach vs. New Jersey Approach)
這個觀點來自一篇很經(jīng)典的文章，Richard Gabriel 在 1989 年寫的文章中的一節(jié)“The Rise of ‘Worse is Better’”。說來慚愧，我是直到 2011 年 5 月在 IBM T.J. Watson 實驗室聽報告才第一次聽說，當(dāng)時便印象深刻。后來上普林斯頓的高級系統(tǒng)設(shè)計課程，發(fā)現(xiàn)這篇文章也在 Reading List 中，要求所有學(xué)生閱讀然后在課上討論。
“The Rise of ‘Worse is Better”對比了以 LISP 系統(tǒng)為代表的麻省理工方法和以 Unix/C為代表的新澤西(貝爾實驗室)方法。Gabriel 發(fā)現(xiàn)相比于 LISP/CLOS 系統(tǒng)完美的設(shè)計，Unix/C只是一味追求實現(xiàn)簡單，但事實卻證明 Unix/C 像終極計算機(jī)病毒那樣快速蔓延，奠定了今天計算機(jī)系統(tǒng)的基礎(chǔ)。
讓我們來看看這兩種不同的設(shè)計哲學(xué)。
1）MIT Approach
簡單性：設(shè)計必須簡單，這既是對實現(xiàn)的要求，也是對接口的要求。接口的簡單要比實現(xiàn)的簡單更加重要。
正確性：設(shè)計在任何值得注意的方面都要保證正確。不正確是絕對不允許的。
一致性：設(shè)計必須保持一致兼容。設(shè)計可以允許輕微少量的不簡單和不完整，來避免不一致。一致性和正確性同等重要。
完整性：設(shè)計必須覆蓋到實際應(yīng)用的各種重要場景。所有可預(yù)料到的情況都必須覆蓋到。簡單性不能過度的損害完整性。
2）New Jersey Approach
簡單性：設(shè)計必須簡單，這既是對實現(xiàn)的要求，也是對接口的要求。實現(xiàn)的簡單要比接口的簡單更加重要。簡單是設(shè)計中需要第一重視的因素。
正確性：設(shè)計在任何值得注意的方面都要求正確。為了簡單性，正確性可以做輕微的讓步。
一致性：設(shè)計不能過度不兼容一致。為了簡單，一致性可以在某些方面做些犧牲，但與其允許設(shè)計中的這些處理不常見情況的部分去增加實現(xiàn)的復(fù)雜性和不一致性，不如丟掉它們。
完整性：設(shè)計必須覆蓋到實際應(yīng)用的各種重要場景。所有可預(yù)料到的情況都應(yīng)該覆蓋到。為了保證其它幾種特征的品質(zhì)，完整性可以作出犧牲。事實上，一旦簡單性受到危害，完整性必須做出犧牲。一致性可以為實現(xiàn)的完整性作出犧牲；最不重要的是接口上的一致性。
如果覺得這種哲學(xué)描述太抽象的話，原文中有一個關(guān)于 Unix 中斷處理的例子，非常生動。一位 MIT 的教授一直困惱于 Syscall 處理時間過長出現(xiàn)中斷時如何保護(hù)用戶進(jìn)程某些狀態(tài)，從而讓用戶進(jìn)程能繼續(xù)執(zhí)行。他問新澤西人，Unix 是怎么處理這個問題。新澤西人說，Unix 只支持大多數(shù) Syscall 處理時間較短的情況，如果時間太長出現(xiàn)中斷 Syscall 不能完成，那就會返回一個錯誤碼，讓用戶重新調(diào)用 Syscall。但 MIT 人不喜歡這個解決方案，因為這不是“正確的做法”。
Unix/C開發(fā)于 1970 年前后，那時離 1964 年剛推出的 IBM System/360 沒幾年，軟件剛擺脫硬件束縛，能移植到不同的機(jī)器上，從而變成了一種可單獨出售的產(chǎn)品。就是這樣的一個軟件產(chǎn)業(yè)的萌芽期，這種“實現(xiàn)簡單”的理念被證明是更有效的。那么在今天的互聯(lián)網(wǎng)時代，這種理念還有效嗎？我們再來看下一篇文章。
來自互聯(lián)網(wǎng)巨頭們的教訓(xùn)
這是最近看到的一篇文章，作者從 High Scalability Blog 上總結(jié)了幾大互聯(lián)網(wǎng)在設(shè)計后臺數(shù)據(jù)中心所遇到的教訓(xùn)（這篇文章總結(jié)的非常好，強(qiáng)烈推薦大家讀一下）。文章開頭就總結(jié)了七個互聯(lián)網(wǎng)公司（Google, YouTube, Twitter, Amazon, eBay， Facebook and Instagram）都提到的 6 點教訓(xùn)：
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 for the job, but don’t be afraid to roll your own solution.
Use caching, where appropriate.
Know when to favor data consistency over data availability, and vice versa.
第一點就是“簡單”，但和 New Jersey Approach 的原因和內(nèi)涵有所不同。不同于 Unix 時代相對簡單的單機(jī)系統(tǒng)，互聯(lián)網(wǎng)時代的大公司的系統(tǒng)往往都是成千上萬臺機(jī)器，在這樣的系統(tǒng)上部署、管理服務(wù)（軟件）是一項非常有挑戰(zhàn)的任務(wù)。而為大規(guī)模用戶提供的一項服務(wù)往往會涉及到眾多模塊、若干步驟。此時“簡單”就是要求每個階段、每個步驟、每個子任務(wù)盡量采用最簡單的解決方案，這是由于大規(guī)模系統(tǒng)內(nèi)在的不確定性導(dǎo)致的復(fù)雜性決定的。
即使做到了每個環(huán)節(jié)最簡單，但由于不確定性的存在，整個系統(tǒng)還是會出現(xiàn)不可控的復(fù)雜性。比如，Google 的 Jeff Dean 最近在 UC Berkeley 有個報告介紹他們努力緩解大規(guī)模數(shù)據(jù)中心中的 Long-Tail Latency 難題。問題簡單描述如下：假設(shè)一臺機(jī)器處理請求的平均響應(yīng)時間為 1ms，只有1% 的請求處理時間會大于 1s (99th-Percentile)。如果一個請求需要由 100 個這樣的節(jié)點一起處理，那么就會出現(xiàn) 63% 的請求響應(yīng)時間大于 1s，這樣的系統(tǒng)完全是不可接受的。面對這個復(fù)雜的不確定性問題，Google 他們做了很多工作，權(quán)衡各種 Tradeoff，具體請看這個報告。
大規(guī)模數(shù)據(jù)中心，看起來似乎和我們普通的開發(fā)人員離得比較遠(yuǎn)。但最近看 Paul Graham 寫的《Hackers and Painters》這本介紹硅谷創(chuàng)業(yè)公司的書，發(fā)現(xiàn) Graham 也在多處強(qiáng)調(diào)“簡單”。
Paul Graham 的《Hackers and Painters（黑客與畫家）》
Paul Graham 被稱為“硅谷創(chuàng)業(yè)之父”。他在 1995 年和 MIT 的 Robert Morris 教授創(chuàng)辦了 Viaweb，于 1998 年被 Yahoo!以 4900 萬美元收購。2005年，他又創(chuàng)辦了Y Combinator 創(chuàng)業(yè)孵化器公司，幫助 80 多家創(chuàng)業(yè)公司成長起來，其中包括 Dropbox (市值大于 40 億美元)、Airbnb (市值大于 13 億美元)等。顯然，Graham 有豐富的創(chuàng)業(yè)經(jīng)驗。
Graham 在“設(shè)計者的品味”一章中寫到，“好的設(shè)計是簡單的”、“簡單就是美，正如漂亮的數(shù)學(xué)證明往往是簡短而巧妙的那種”。他提到，有些創(chuàng)業(yè)者希望第一版就能推出功能齊全的產(chǎn)品，滿足所有的用戶需求，但這種想法是致命的。在硅谷創(chuàng)業(yè)最忌諱的就是“Premature Optimization”。因為一方面用戶需求是多樣的，不同人群都有不同的需求；另一方面開發(fā)者想象的需求往往和真實的用戶需求有偏差。所以，Graham 推崇那種有用戶參與反饋的迭代優(yōu)化的方式。
無獨有偶，最近至少聽到兩個報告提到了 Facebook 的開發(fā)模式。當(dāng) Facebook 開發(fā)一個新的服務(wù)，會先讓一個小用戶群使用，根據(jù)用戶的反饋來修改功能，同時可以調(diào)試程序中的 bug。然后下一版讓更大一些的用戶群使用，收集用戶反饋繼續(xù)修改程序。如此反饋幾次，最后再推向所有用戶。這種模式要求再最初設(shè)計時盡量簡單，從而只需幾個月的時間就能推出一個新的功能，然后再不斷地優(yōu)化完善。
到目前為止，談的工業(yè)界偏多一些，但其實在系統(tǒng)領(lǐng)域的學(xué)術(shù)研究，“簡單”法則同樣適用。
李凱教授：KISS 原則
普林斯頓大學(xué)計算機(jī)系的李凱教授是“KISS”原則的堅決貫徹者。幾乎每次和李凱老師討論，他都會強(qiáng)調(diào)“Keep it Simple”。李凱老師的做事方式是——只抓住大方向，其他問題盡量簡化。
但真正要做到 KISS 原則其實并不容易。我在遇到問題時，往往會從各個方面去考慮問題，其中難免包含了各種細(xì)枝末節(jié)，這種方式導(dǎo)致問題經(jīng)常會變得非常復(fù)雜。之前講過這個例子，在移植 TCP/IP 協(xié)議棧到用戶態(tài)時，我覺得有約 10 個功能需要考慮。和李老師討論，他讓我把那些功能分成兩類：“必須有(Must Have)”和“可以有(Nice-to-Have)”。當(dāng)我試了這種方法，發(fā)現(xiàn)原來 Must-Have 的功能其實也不過2~3個而已。而最近的例子則是在要設(shè)計一個功能讓 TCP/IP 連接的 Server 在模擬器中、Client 在真實機(jī)器。我考慮是盡量減少模擬器上 OS 的開銷，所以打算采用自己寫一個設(shè)備、然后讓用戶態(tài)程序 Bypass Kernel 直接訪問該設(shè)備的方案。但李凱老師在了解 OS 開銷以后，認(rèn)為容忍開銷、盡量直接使用模擬器自己帶的功能，讓開發(fā)更簡單。
這些教訓(xùn)也讓我不斷地去思考為什么要用 KISS 原則。慢慢地我體會到，KISS 原則目的其實是——“快速推進(jìn)、逐步優(yōu)化”。我們設(shè)計一個算法，往往可以在大腦中預(yù)先思考好，然后直接編程寫出來。但是，我們設(shè)計實現(xiàn)一個系統(tǒng)，當(dāng)系統(tǒng)的復(fù)雜度超出我們大腦的工作記憶容量時，就無法在大腦中去“模擬”每一個細(xì)節(jié)。此時，我們應(yīng)該用最快的速度去把系統(tǒng)建起了，然后再對各個環(huán)節(jié)進(jìn)行優(yōu)化。
這個 KISS 理念并不是計算機(jī)系統(tǒng)領(lǐng)域特有的，最早是來源于研制飛機(jī)時提出的設(shè)計理念。而在其他領(lǐng)域，如果一個任務(wù)涉及多個步驟，也同樣有效，比如生物研究。我去年前曾看過施一公教授寫的一篇文章中也提到了這一點。
施一公教授：”耗費時間的完美主義阻礙創(chuàng)新進(jìn)取 “
2011年 9 月清華大學(xué)施一公教授在科學(xué)網(wǎng)上發(fā)布了一篇博客《如何做一名優(yōu)秀的博士生：（二）方法論的轉(zhuǎn)變》，其中介紹到完美主義的危害，其實是從另一個角度來強(qiáng)調(diào)“簡單”。
施教授講了他博士后期間的一個故事。一次他的任務(wù)是純化一個蛋白。兩天下來，雖然純化了，但是產(chǎn)量只有 20%。
他不好意思地對導(dǎo)師說，“產(chǎn)率很低，我計劃繼續(xù)優(yōu)化蛋白的純化方法，提高產(chǎn)率”。
但導(dǎo)師反問：“你為什么想提高產(chǎn)率？已有的蛋白不夠你做初步的結(jié)晶實驗嗎？”
他回敬：“我有足夠的蛋白做結(jié)晶篩選，但我需要優(yōu)化產(chǎn)率以得到更多的蛋白。”
導(dǎo)師不客氣地打斷：“不對。產(chǎn)率夠高了，你的時間比產(chǎn)率重要。請盡快開始結(jié)晶。”
實踐最后證明他導(dǎo)師的建議是對的。
對于這個故事，施一公教授總結(jié)如下：
“在大刀闊斧進(jìn)行創(chuàng)新實驗的初期階段，對每一步實驗的設(shè)計當(dāng)然要盡量仔細(xì)，但一旦按計劃開始后對其中間步驟的實驗結(jié)果不必追求完美，而是應(yīng)該義無反顧地把實驗一步步推到終點，看看可否得到大致與假設(shè)相符的總體結(jié)果。如果大體上相符，你才應(yīng)該回過頭去仔細(xì)地再改進(jìn)每一步的實驗設(shè)計。如果大體不符，而總體實驗設(shè)計和操作都沒有錯誤，那你的假設(shè)（或總體方向）很可能是有大問題的。
這個方法論在每一天的實驗中都會用到。比如，結(jié)構(gòu)生物學(xué)中，第一次嘗試純化一種新的蛋白不應(yīng)該追求每一步的產(chǎn)率，而應(yīng)該盡量把所有純化步驟進(jìn)行到底，看看能否拿到適于結(jié)晶的蛋白。第一次嘗試 limited proteolysis，不應(yīng)該刻意確定 protease 濃度或追求蛋白純度，而是要關(guān)注結(jié)果中是否有 protease-resistant core domain。從 1998 年開始自己的獨立實驗室到現(xiàn)在，我告訴所有學(xué)生：切忌一味追求完美主義。
我把這個方法論推到極限：只要一個實驗還能往前走，一定要做到終點，盡量看到每一步的結(jié)果，之后需要時再回頭看，逐一解決中間遇到的問題。 ”
結(jié)語
我想從各個角度去闡釋“簡單之美”，但到最后感覺這篇文章就是一個大雜燴。既然如此，那我就再加一點料。
Elon Musk 是現(xiàn)實世界中的鋼鐵俠，他先后創(chuàng)辦了網(wǎng)絡(luò)支付公司 PayPal、電動汽車公司 Tesla 以及空間探索公司 Space X。目前 Space X 研制的“獵鷹”火箭已成功試飛，并得到 NASA 16 億美元的合同。為了減低成本和提供可靠性，Space X 設(shè)計的火箭也到處滲透著“簡單”：“在他們的獵鷹 1 號運載火箭上，并沒有很多專利，科學(xué)家們不在乎，只要火箭能飛就行。火箭用的主發(fā)動機(jī)也不是 21 世紀(jì)的最新設(shè)計，而是 1960 年代的老古董，只有一個燃料噴射器。它很老，但很可靠。”
參考資料
1、The Rise of ‘Worse is Better’
2、“差點的更好”設(shè)計理念的興起
3、Scalability Lessens from Google, YouTube, Twitter, Amazon, eBay， Facebook and Instagram
4、Achieving Rapid Response Times in Large Online Services, Jeff Dean, Google.
5、“如何做一名優(yōu)秀的博士生：（二）方法論的轉(zhuǎn)變”，施一公，科學(xué)網(wǎng)博客
6、硅谷企業(yè)家開設(shè)私人火箭工廠目標(biāo)直指火星