|
|
最近多次看到系統設計與實現的文章與討論，再加上以前讀過的其他資料以及自己的一些實踐教訓，讓我覺得應該把這些資料匯總整理一下。如果要從討論不同系統的眾多資料中總結一條黃金法則的話，那只有一個詞——“簡單”；如果用一個英語單詞來表達的話，那就是——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 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 的原因和內涵有所不同。不同于 Unix 時代相對簡單的單機系統，互聯網時代的大公司的系統往往都是成千上萬臺機器，在這樣的系統上部署、管理服務（軟件）是一項非常有挑戰的任務。而為大規模用戶提供的一項服務往往會涉及到眾多模塊、若干步驟。此時“簡單”就是要求每個階段、每個步驟、每個子任務盡量采用最簡單的解決方案，這是由于大規模系統內在的不確定性導致的復雜性決定的。
即使做到了每個環節最簡單，但由于不確定性的存在，整個系統還是會出現不可控的復雜性。比如，Google 的 Jeff Dean 最近在 UC Berkeley 有個報告介紹他們努力緩解大規模數據中心中的 Long-Tail Latency 難題。問題簡單描述如下：假設一臺機器處理請求的平均響應時間為 1ms，只有1% 的請求處理時間會大于 1s (99th-Percentile)。如果一個請求需要由 100 個這樣的節點一起處理，那么就會出現 63% 的請求響應時間大于 1s，這樣的系統完全是不可接受的。面對這個復雜的不確定性問題，Google 他們做了很多工作，權衡各種 Tradeoff，具體請看這個報告。
大規模數據中心，看起來似乎和我們普通的開發人員離得比較遠。但最近看 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 理念并不是計算機系統領域特有的，最早是來源于研制飛機時提出的設計理念。而在其他領域，如果一個任務涉及多個步驟，也同樣有效，比如生物研究。我去年前曾看過施一公教授寫的一篇文章中也提到了這一點。
施一公教授：”耗費時間的完美主義阻礙創新進取 “
2011年 9 月清華大學施一公教授在科學網上發布了一篇博客《如何做一名優秀的博士生：（二）方法論的轉變》，其中介紹到完美主義的危害，其實是從另一個角度來強調“簡單”。
施教授講了他博士后期間的一個故事。一次他的任務是純化一個蛋白。兩天下來，雖然純化了，但是產量只有 20%。
他不好意思地對導師說，“產率很低，我計劃繼續優化蛋白的純化方法，提高產率”。
但導師反問：“你為什么想提高產率？已有的蛋白不夠你做初步的結晶實驗嗎？”
他回敬：“我有足夠的蛋白做結晶篩選，但我需要優化產率以得到更多的蛋白。”
導師不客氣地打斷：“不對。產率夠高了，你的時間比產率重要。請盡快開始結晶。”
實踐最后證明他導師的建議是對的。
對于這個故事，施一公教授總結如下：
“在大刀闊斧進行創新實驗的初期階段，對每一步實驗的設計當然要盡量仔細，但一旦按計劃開始后對其中間步驟的實驗結果不必追求完美，而是應該義無反顧地把實驗一步步推到終點，看看可否得到大致與假設相符的總體結果。如果大體上相符，你才應該回過頭去仔細地再改進每一步的實驗設計。如果大體不符，而總體實驗設計和操作都沒有錯誤，那你的假設（或總體方向）很可能是有大問題的。
這個方法論在每一天的實驗中都會用到。比如，結構生物學中，第一次嘗試純化一種新的蛋白不應該追求每一步的產率，而應該盡量把所有純化步驟進行到底，看看能否拿到適于結晶的蛋白。第一次嘗試 limited proteolysis，不應該刻意確定 protease 濃度或追求蛋白純度，而是要關注結果中是否有 protease-resistant core domain。從 1998 年開始自己的獨立實驗室到現在，我告訴所有學生：切忌一味追求完美主義。
我把這個方法論推到極限：只要一個實驗還能往前走，一定要做到終點，盡量看到每一步的結果，之后需要時再回頭看，逐一解決中間遇到的問題。 ”
結語
我想從各個角度去闡釋“簡單之美”，但到最后感覺這篇文章就是一個大雜燴。既然如此，那我就再加一點料。
Elon Musk 是現實世界中的鋼鐵俠，他先后創辦了網絡支付公司 PayPal、電動汽車公司 Tesla 以及空間探索公司 Space X。目前 Space X 研制的“獵鷹”火箭已成功試飛，并得到 NASA 16 億美元的合同。為了減低成本和提供可靠性，Space X 設計的火箭也到處滲透著“簡單”：“在他們的獵鷹 1 號運載火箭上，并沒有很多專利，科學家們不在乎，只要火箭能飛就行。火箭用的主發動機也不是 21 世紀的最新設計，而是 1960 年代的老古董，只有一個燃料噴射器。它很老，但很可靠。”
參考資料
1、The Rise of ‘Worse is Better’
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、“如何做一名優秀的博士生：（二）方法論的轉變”，施一公，科學網博客
it知識庫：簡單之美——系統設計黃金法則，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
