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

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

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

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

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

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

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

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

?

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

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

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

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

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

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

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

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

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

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

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

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

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

而且，功能性的需求的實現，其實在大多數情況下，更依賴于業務的高手（或者好的產品經理）而不是技術的高手，而非功能性需求的實現，恰恰是挑戰技術高手的重要課題。

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

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

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

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

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

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

轉載自：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、淘宝，都需要大量顶尖高手来开发？...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。