系統設計黃金法則：簡單之美

　　最近多次看到系統設計與實現的文章與討論，再加上以前讀過的其他資料以及自己的一些實踐教訓，讓我覺得應該把這些資料匯總整理一下。如果要從討論不同系統的眾多資料中總結一條黃金法則的話，那只有一個詞——“簡單”;如果用一個英語單詞來表達的話，那就是——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點教訓：

　　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有個報告【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有豐富的創業經驗。

原文轉自：http://www.anti-gravitydesign.com