先說你看到的頁面上，最重要的幾個：
【搜索商品】——這個功能，如果你有幾千條商品，完全可以用select * from tableXX where title like %XX%這樣的操作來搞定。但是——當你有10000000000（一百億）條商品的時候，任何一個數(shù)據(jù)庫都無法存放了，請問你怎么搜索？這里需要用到分布式的數(shù)據(jù)存儲方案，另外這個搜索也不可能直接從數(shù)據(jù)庫里來取數(shù)據(jù)，必然要用到搜索引擎（簡單來說搜索引擎更快）。好，能搜出商品了，是否大功告成可以啵一個了呢？早著呢，誰家的商品出現(xiàn)在第一頁？這里需要用到巨復雜的排序算法。要是再根據(jù)你的購買行為做一些個性化的推薦——這夠一幫牛叉的算法工程師奮斗終生了。

【商品詳情】——就是搜索完畢，看到你感興趣的，點擊查看商品的頁面，這個頁面有商品的屬性、詳細描述、評價、賣家信息等等，這個頁面的每天展示次數(shù)在30億以上，同樣的道理，如果你做一個網(wǎng)站每天有10個人訪問，你絲毫感覺不到服務器的壓力，但是30億，要解決的問題就多了去了。首先，這些請求不能直接壓到數(shù)據(jù)庫上，任何單機或分布式的數(shù)據(jù)庫，承受30億每天的壓力，都將崩潰到完全沒有幸福感，這種情況下要用到的技術就是大規(guī)模的分布式緩存，所有的賣家信息、評價信息、商品描述都是從緩存里面來取到的，甚至更加極致的一點“商品的瀏覽量”這個信息，每打開頁面一次都要刷新，你猜能夠從緩存里面來取嗎？淘寶做到了，整個商品的詳情都在緩存里面。

【商品圖片】——一個商品有5個圖片，商品描述里面有更多圖片，你猜淘寶有多少張圖片要存儲？100億以上。這么多圖片要是在你的硬盤里面，你怎么去查找其中的一張？要是你的同學想拷貝你的圖片，你需要他準備多少塊硬盤？你需要配置多少大的帶寬？你們的網(wǎng)卡是否能夠承受？你需要多長時間拷貝給他？這樣的規(guī)模，很不幸市面上已經(jīng)沒有任何商業(yè)的解決方案，最終我們必須自己來開發(fā)一套存儲系統(tǒng)，如果你聽說過google的GFS，我們跟他類似，叫TFS。順便說一下，騰訊也有這樣的一套，也叫TFS。

【廣告系統(tǒng)】——淘寶上有很多廣告，什么，你不知道？那說明我們的廣告做的還不錯，居然很多人不認為它是廣告，賣家怎么出價去買淘寶的廣告位？廣告怎么展示？怎么查看廣告效果？這又是一套算法精奇的系統(tǒng)。

【BOSS系統(tǒng)】——淘寶的工作人員怎么去管理這么龐大的一個系統(tǒng)，例如某時刻突然宣布某位作家的作品全部從淘寶消失，從數(shù)據(jù)庫到搜索引擎到廣告系統(tǒng)，里面的相關數(shù)據(jù)在幾分鐘內(nèi)全部消失，這又需要一個牛叉的后臺支撐系統(tǒng)。

【運維體系】——支持這么龐大的一個網(wǎng)站，你猜需要多少臺服務器？幾千臺？那是零頭。這么多服務器，上面部署什么操作系統(tǒng)，操作系統(tǒng)的內(nèi)核能否優(yōu)化？Java虛擬機能否優(yōu)化？通信模塊有沒有榨取性能的空間？軟件怎么部署上去？出了問題怎么回滾？你裝過操作系統(tǒng)吧，優(yōu)化過吧，被360坑過沒，崩潰過沒？這里面又有很多門道。

不再多寫了，除了上面提到的這些，還有很多很多需要做的技術，當然并不是這些東西有多么高不可攀，任何復雜的龐大的東西都是從小到大做起來的，里面需要牛叉到不行的大犇，也需要充滿好奇心的菜鳥，最后這一句，你當我是別有用心好了。

===============================華麗的分割線====================================

?

不單局限于網(wǎng)站，對于所有的軟件來說，從軟件工程學的角度來說，其需求大體可以分為功能性需求（functional Requirements）和非功能性需求（nonfunctional Requirements）兩個大的部分。

功能性需求，一般是我們顯性易見的，就是一般實現(xiàn)了什么功能，提供了什么服務，大體我認為問題中提到，或者我們?nèi)粘Ｋf的：“看起來復雜不復雜”，基本上都會是針對功能性需求而言的。如果拿google的搜索服務舉例來說，那就是：
提供一個輸入框， 提供一個按鈕，用戶在輸入框里輸入關鍵字，按了按鈕以后，可以搜索出相應結果。
功能性需求，會因為不同的網(wǎng)站，不同的軟件，不同的業(yè)務和使用目的，大相徑庭，五花八門，不一而論。

非功能性需求，以下應用維基百科的定義（雖然有些晦澀和繞口，但是我認為是比較精到和準確的）

在系統(tǒng)工程及需求工程中，非功能性需求（Non-functional requirement）是指依一些條件判斷系統(tǒng)運作情形或其特性，而不是針對系統(tǒng)特定行為的需求。和非功能性需求相對的是功能需求，后者會定義系統(tǒng)特定的行為或功能。非功能性需求也可以視為為了滿足客戶業(yè)務需求而需要符合，但又不在功能需求以外的特性。
一般會在系統(tǒng)設計（英語：Systems design）中詳細列出實現(xiàn)功能需求的計劃，而會在系統(tǒng)架構（英語：Systems architecture）中詳細列出實現(xiàn)非功能性需求的計劃。一般而言，功能需求會定義系統(tǒng)的行為，而非功能性需求會定義系統(tǒng)的特性。
非功能性需求一般會稱為系統(tǒng)的“品質”，有時也會稱為“限制”、“品質屬性”、“品質目標”、“品質屬性”、“品質服務需求”或“非行為性的需求”。有許多非功能性需求的英文都是以“ilitiy”結尾，例如穩(wěn)定性（stability）及可移植性（portability），因此非功能性需求有時也稱為“ilities”。
非功能性需求可以分為以下的二類：
運行品質（Execution qualities），可以在系統(tǒng)運作時觀察到的品質，例如保安性及易用性等。
發(fā)展品質（Evolution qualities），和軟件系統(tǒng)結構及開發(fā)過程有關的品質，例如軟件可測試性（英語：software testability）、可維護性、可擴展性、可伸縮性（scalability）等

非功能性需求一般是隱性的，容易被菜鳥程序員，設計師們忽略。非功能性需求不同于功能性需求，它在不同的網(wǎng)站，軟件上，擁有一定的共性，就例如@子柳 提到的海量文件存儲的問題上，淘寶，騰訊，google都遇到了一樣的問題，研發(fā)了類似的解決方案（TFS,TFS和GFS）。
非功能性需求的分類方法較多，并沒有業(yè)界通行和一致的標準，但是大多數(shù)殊途同歸，名稱/叫法以及分類方法上可能略有差異，但是其含義和指向一般是趨向一致的，我簡單介紹一下我一般較多采用的分類：

性能/容量：性能和容量比較利于理解，包括像需要支持的用戶的數(shù)量啊（尤其是峰值的并發(fā)用戶數(shù)量），用戶能夠接受的響應時間啊，數(shù)據(jù)規(guī)模啊（例如@子柳 提到的百萬級的驚人數(shù)據(jù)規(guī)模，上億的文件存儲啦等等。這里小小糾正一下@子柳 的一個觀點，百萬級的數(shù)據(jù)支撐，還是有一些商業(yè)數(shù)據(jù)庫產(chǎn)品可以支持的，TPC-C/TPC-D以及新一代的業(yè)界性能測試標準中還有千萬級數(shù)據(jù)規(guī)模的測試項目，也有數(shù)據(jù)庫廠商報名參加的，當然，對于淘寶這樣的業(yè)務模式和實際情況/要求來說，性價比和實用性可能確實就比較低了）

可靠性/可用性/可復原性： 可靠性之與在規(guī)定的一段時間和條件下軟件維持其功能服務以及性能水平的能力有關的一組屬性（可用性是另外一種說法）。例如說我們要求系統(tǒng)7x24小時運行，全年持續(xù)運行故障停運時間累計不能超過10小時等等，都屬于這方面的要求。 可復原性與在是發(fā)生錯誤和故障后重建其性能水平并恢復直接受影響數(shù)據(jù)的能力。例如支付寶需要保證如果在交易提交失敗以后，需要保證回滾，不能這頭銀行的錢沒有付成功，那頭卻顯示付款成功或者反之這頭銀行扣款了，那頭在改變交易狀態(tài)的時候缺因為冗塞或者其他原因導致交易還是未付款狀態(tài)。

可維護性/可管理性：包括系統(tǒng)在無人工干預條件下的穩(wěn)定性，自排錯能力，可測試性都屬于這個范疇。故障的可排查能力，系統(tǒng)的修正，升級，備份，恢復機制以及方便與否，都屬于這個范疇。這通常會極大決定系統(tǒng)的運行維護成本及維護難度。

安全：包括傳輸加密，存儲加密，可破解性，以及各種未被授權的用戶行為如何防范和控制，都是安全范疇，這里的安全不單針對外部普通用戶，也針對內(nèi)部不同級別的權限用戶的的控制。小到如何防范和處理用戶在輸入框里輸入特殊字符來獲得設計者未曾預料的結果，大到防范外部黑客和內(nèi)部內(nèi)鬼。安全很多時候不單依賴技術實現(xiàn)，同時非常依賴相應的制度和審計。

易用性：好吧，這個話題現(xiàn)在最熱了，這可能是非功能性需求中現(xiàn)在唯一被高亮出來，被各種人等都關注，都拿出來說事的一個領域了。易用性設計現(xiàn)在已經(jīng)上升到了一個新的高度，叫做人機體驗，UE設計，雖然現(xiàn)在UE到底是劃分在功能性需求還是非功能性需求上，尚有一些爭議，但是主流觀點（包括我自己）都認為，這是非功能性需求的一個典型部分。

數(shù)據(jù)一致性：包括數(shù)據(jù)的編碼和語言，冗余數(shù)據(jù)的一致性要求（含時間要求）等等。例如為了性能的考慮，數(shù)據(jù)庫整體設計未采用巴斯克范式，而采用了第二或者第三范式的要求來設計，一些信息（例如用戶注冊信息），可能同時存在于系統(tǒng)的多個地方（例如多個表中），當發(fā)生注冊信息變更時，如何保證多處地方記錄的信息都被修改，以及這個全部修改的時限要求是多少等等都是這個范疇的內(nèi)容。

系統(tǒng)/環(huán)境 條件及限制：現(xiàn)有的軟硬件條件，平臺的條件，網(wǎng)絡的條件都屬于這個范疇。典型的例如很多移動互聯(lián)網(wǎng)產(chǎn)品，必須要考慮移動網(wǎng)絡的帶寬條件，終端運算性能和能力，以及其移動網(wǎng)絡穩(wěn)定性等等。

事實上，從我的經(jīng)驗來看，一般來說，很多軟件項目及產(chǎn)品，其在非功能性需求上的成本，難度和工作量，是要超過功能性需求的。在特定的軟件領域，例如網(wǎng)站（尤其是淘寶，facebook這樣海量用戶規(guī)模的網(wǎng)站），金融（銀行證券），電信領域，其非功能性需求實現(xiàn)的重要性，工作量，技術難度要遠遠遠遠大于功能性需求的實現(xiàn)。

而且，功能性的需求的實現(xiàn)，其實在大多數(shù)情況下，更依賴于業(yè)務的高手（或者好的產(chǎn)品經(jīng)理）而不是技術的高手，而非功能性需求的實現(xiàn)，恰恰是挑戰(zhàn)技術高手的重要課題。

一個最典型的極限非功能性需求的例子就是電信的計費系統(tǒng)，其實基本功能很簡單，獲取通話時長，按照費率公式算個錢出來，但是放到海量的用戶，實時的計費要求中來看，這是一個極具技術挑戰(zhàn)的活。

還有一個經(jīng)典的案例是，中國某地方性銀行（注意僅僅是地方性的銀行），想要引入一個柜面服務的系統(tǒng)，找到了新家坡的一個廠商，他們在東南亞銀行業(yè)有很多案例，而且功能設計非常完善合理和先進。但是這家地方性銀行引入這個系統(tǒng)以后，2周之內(nèi)發(fā)行了幾十萬張信用卡，這系統(tǒng)就頂不住崩潰了。這就是典型的功能性需求實現(xiàn)完美，但是非功能性缺陷的例子。

從我的經(jīng)驗來看，一般來說，非功能性需求中，性能/容量，以及安全的要求，一般是技術挑戰(zhàn)最多，內(nèi)涵最豐富，成本最高，最值得關注的領域，當然，現(xiàn)在易用性（UE）也是一個極度收到重視的領域。

有志于架構師取向的IT技術人員，非功需求實現(xiàn)的領域，是一個必須關注，必須熟悉的領域。

而本問題最大的根源在于，只看到了網(wǎng)站功能性需求的部分，而沒有注意到非功的部分，對于非專業(yè)的IT技術人員來說，這很正常，但是對于IT技術人員來說，是需要認真關注的必修課。

最后，舉一個可能不太恰當?shù)睦觼碚f明一下：
100米的路，從這頭到那頭，看起來是件很簡單的事情。
但是要求10秒之內(nèi)要從這頭跑到那頭，這就需要田徑高手了。
如果還要求，10秒之內(nèi)跑完，要連著反復跑好幾趟，路上可能有積水濕滑障礙物，那我覺得就只有去找博爾特劉翔之類的頂尖高手去聊聊了

轉載自：http://www.zhihu.com/question/20303645?group_id=46788351#answer-1324063

謝謝瀏覽！

轉載于:https://www.cnblogs.com/Music/p/what-you-see-is-not-what-you-get.html

總結

以上是生活随笔為你收集整理的【转】为什么很多看起来不是很复杂的网站，比如 Facebook、淘宝，都需要大量顶尖高手来开发？...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。