假如說1980年代是PC的時代，1990年代是互聯網的時代，那么當下呢？當下是移動互聯網的時代。移動互聯網的基本要義，一言以蔽之，就是把手機與網站相連，每部手機在網站上都有獨立的個人空間，成為手機的鏡像。

　　一部小小的手機里面，可能同時裝載著數十個軟件。而且在同一時刻，可能好幾個軟件在同時運行。另外，還得時刻預備暫停運行，把手機CPU等資源讓給電話通話等優先級別高的工作。還有，時刻需要預備應付網絡連接中斷，手機電池耗盡等等情況。總之，手機軟件的結構設計，是做小的藝術。

　　移動網站的架構設計，與手機軟件的架構設計有著本質的不同。假如說手機軟件的特點在于小，那么網站的特點在于大。僅中國就有幾億手機用戶，作為服務于移動業務的網站，它的質量來自于是否能夠同時為大規模并發用戶提供服務，是否能夠處理海量數據，是否能夠在需要擴大網站吞吐量的時候，只需要增加機器，而不需要對網站架構做大手術。這是做大的藝術。

　　提到做大規模網站，大家一定會想到云計算，想到Google File System，Chubby， BigTable，MapReduce等等。這些技術固然很好，但是它們僅僅是構成一個大型網站的技術要素。實際構建一個大型網站時，光知道技術要素是不夠的，還得明白如何把各個要素有機地結合到一起。

　　“Flickr 網站架構研究”是一篇值得反復閱讀的好文章。這篇文章不僅對一個大型網站的架構進行了系統解剖，逐條梳理，而且行文深進淺出。可惜這樣的文章未幾見。關于大型網站實例的討論，散落在各處，而且內容零散。

　　學習和把握構建大型網站的架構，需要匯總散落的文章，梳理零散的內容。做好這項工作很有意義，但是也比較困難。我們的體會是，不妨捉住以下幾個主題，逐個分析大型網站的實例，然后橫向比較。

　　數據存儲歷來是麻煩，尤其是需要存儲海量數據的時候，往往單個數據庫容量不夠，甚至一個數據庫集群也不夠。常見的解決辦法是分割，譬如按用戶ID把海量數據分割成若干塊，每塊存儲到一個獨立的數據庫里往。但是分割的做法降低了join操縱的效率。

　　Google Bigtable的效率如何？好處是什么，缺陷是什么？Bigtable對什么樣的情景最適用？根據Bigtable原理實現的開源軟件，Hadoop/HBase的運行效率如何？

　　用戶訪問網站時，通常讀的操縱比寫的操縱更頻繁。為了進步讀的操縱，不妨把相關內容緩存到內存里，減少Disk IO的消耗。

　　MemCached 最近大熱，Wikipedia， YouTube， Digg， Twitter等等大型網站都在用MemCached作為緩存工具。SquidCache和Varnish等等工具，也與緩存沾邊。Twitter的做法是把MemCached和Varnish結合起來，同時使用。什么樣的內容，應該用什么樣的緩存工具？不同的工具間如何協調？各大網站的實際運行的結果，有哪些經驗和教訓？

　　有些內容，既沒必要存放在數據庫里，也不適合存放在緩存中，譬如log 和images。在這種情況下，我們需要文件系統。當有海量內容需要存放在文件系統中時，我們需要使用分布式文件系統。Google File System對于什么樣的情景適用，什么樣的情景不適用？分布式文件系統經常需要相應的鎖機制，保證并發的讀寫操縱不相互干擾。Chubby有什么好處？什么情形下不適用？

　　據說MogileFS更適合存儲大量的，但是單體尺寸不大的文件，譬如images。而Google File System更適合存放大尺寸但是數目未幾的文件。有沒有可能把小尺寸的多個文件，合并成一個大文件，然后存儲到Google File System中往。在這種情況下，比較MogileFS與Google FS的性能，是否有高下之分？

　　一套工序通常由若干任務組成。多線程的辦法是由一根線程全權負責整套工序的操縱。另外一個辦法是把工序斬成幾段，每一段由一根或幾根線程負責，這種辦法稱為工作臺。

　　常見的是多線程的辦法。但是工作臺的做法有利于集中計算資源處理繁重的任務，避免瓶頸的出現。但是缺陷是需要在不同線程之間，傳遞記錄中間狀態的數據。么樣的情形適適用多線程，什么時候用工作臺？

　　同一個網站通常會提供多種服務，不同的服務需要調用不同的業務邏輯。有些業務邏輯可以在同一臺服務器上完成，但是當業務邏輯復雜的時候，需要調用多臺服務器合作完成。不同服務的受眾對象不同，流量也不同，不同時段的流量也不同，同一時段不同服務的流量也不同，所以需要動態地分配計算資源。這是 scheduler的工作。

　　Scheduler給不同服務器分配工作時，最簡單的辦法是啟動預先安裝在該服務器上的相關程序。由于不能保證每個程序都十分完美，當一個程序發生錯誤時，應當避免整個服務器因此而崩潰，影響其它工作的正常進行。是否需要動用virtual machine，實現各個不同工作之間相互隔盡？

　　大型網站后臺系統經常由眾多服務器組成，服務器與服務器之間時不時會發生數據交換，譬如Web Server解析完用戶請求后，把請求轉發給某一臺App Server，這一臺App Server完成了部分工作后，把中間數據轉發給下一臺App Server。而第二臺App Server完成任務后，整個工作就結束了，結果應該返回給Web Server。

　　題目是如何讓第一臺App Server如何知道應該把中間結果給第二臺App Server，而第二臺App Server又如何知道它的目的地是Web Server？一個比較有效率的做法，是區別數據流和控制流。Server與Server之間常設通道，專供控制流使用，傳遞指令往控制數據流的發送。數據流不占用控制流通道，只有在需要時，才建立數據流的通道。控制流和數據流的組織，需要結合具體的業務邏輯，才能優化設計，減少帶寬消耗，縮短數據傳輸的時間。

　　網站后臺各個部分是否運轉正常，哪里是瓶頸，哪里空閑。這些都需要實時監控。不僅及時避免整個后臺系統的崩潰，而且可以分析各個部分運行的規律，從而找到優化系統的途徑。題目是，應該選用什么樣的監控工具，才能夠盡量減少對系統程序的干擾，同時提供有價值的信息？

　　通常網站面對的是形形色色的用戶，盡大多數用戶的行為是友好的，但是不排除少數用戶蓄意惡作劇。假如事先沒有設計防范措施，少數惡意用戶的胡作非為，會干擾其他用戶享受正常的服務。

　　題目是，如何防范并且及時制止惡意行為的發生？

　　不論預先設想有多周密，實際運行時，總會碰到這樣那樣的意外情況。譬如敏感詞的出現，往往事先沒有征兆。所以，在設計系統架構時，應該給網管提供必要工具，應付突發事件。