上圖座標指向矽谷，最近開始研究網際網路分布式架構，風口浪尖，高大上；特與極客朋友們分享，共勉。
網際網路架構
近些年來，網際網路的高速發展，大資料時代，booming years，我們作為技術極客，需要跟得上節奏，趨勢。
1 大型**特性
大型**，無論是電商還是社交**等通常都具有以下特性，如高併發，低延遲，海量資料，可擴充套件性，ha 7*24；用資料來說明的話就是：google日均uv數3億，日均pv高達35+億；facebook周上傳10億以上；**雙十一，第一分鐘uv高達1000萬。而這些都是我們傳統應用無法想象，無法望其項背的。
2 架構演化
還記得一位美國老闆說過，"project is evolutionary not revolutionary!
". 網際網路領域也是一樣的。隨著業務的發展，併發量，資料儲存量等；系統開始演進，分而治之。其實，計算機世界包括硬體，網路，軟體無不是引入新的層，物件，服務；從而分而治之來化繁為簡解決問題的；而真實世界的事又何嘗不是如此呢？當然，分而治之，拆分解決了一些問題，但是又會引入另外一種複雜/互動的問題。當然，分而治之，拆分解決了一些問題，但是又會引入另外一種複雜/互動的問題。 1.
一台伺服器：
曾經記得若干年前的網際網路，或者其實現在的小型**都是以經典的lamp組合即搞定，即linux, apache, mysql, php，甚至應用＋檔案 ＋ 資料庫全部在一台伺服器搞定。 2.
三颱伺服器：
隨著業務發展，
併發量，資料儲存量等都不能滿足時，開始拆分；首先將應用與資料分離；拆成三颱伺服器：應用伺服器，檔案伺服器和資料庫伺服器。其中，應用伺服器需要計算，因此需要更強大cpu;資料庫伺服器則需要快速磁碟與資料快取；而檔案伺服器則需要更大硬碟。 3.
引入快取：
繼續改進，引入快取機制改進訪問解決熱門業務。目前架構：
4. 集群：
到了步驟3，看起來一切不錯。可隨著業務量，訪問量的繼續飆公升，正所謂快樂的煩惱，應用伺服器吃不消，直接宕機，導致所有業務癱瘓，正所謂單點問題。我們引入集群，解決單點問題，提供可擴充套件性。我們稍微看一下目前的架構：
注意，此時我們需要引入負載均衡器來協調使用者訪問哪乙個應用伺服器；如果有錢的主可以選擇f5, 或者lvs, nginx等。至此，一起看起來都是那麼完美。
5.資料庫讀寫分離：
隨後而來的是，**的訪問瓶頸在高併發下繼續存在。究其原因，雖然引入快取解決了大部分資料讀訪問，讓然會有一部分讀操作如快取麼有命中，或者快取過期之類的需要訪問資料庫，當然，所有的寫操作都需要直接訪問資料庫；如何解決？繼續分而治之了。目前主流資料庫都已經提供了主從熱備功能，自動備份同步；我們正好可以利用此功能。讀都走從資料庫，寫走主資料庫。如此，巧妙的解決了讀寫分離。
引入反向**與cdn:
繼續提公升訪問速度，提供更好使用者體驗。這裡強調一下，**訪問速度/延遲與使用者流失率正相關。目前主要主流手段為cdn與反向**；二者原理都是基於快取機制。區別在於，cdn是部署在網路**商機房，而反向**則不熟在自己**機房。
可以看出，引入cdn與反向**都是希望盡早返回資料給使用者。科普一下：
cdn（content delivery network）
是個古老的東西，在網際網路發展之初就已經出現了。一群mit的精英份子發現如果要讓任
何地方的人都可以很快的開啟自己的**的話，就需要象在世界各地蓋教堂一樣，把自己的網頁發布到離信眾最近的地方去。所以，他們用一種簡單的快取映象的辦法實現了這種發布。最早的入主這個教堂網路的是yahoo！cdn在利用dns的轉授權來引導最終訪問者找到最理想的快取或者映象站點，它是基於網域名稱的一種服務。
反向**
：反向**（reverse proxy）方式是指以**伺服器來接受internet上的連線請求，然後將請求**給內部網路上的伺服器，並將從伺服器上得到的結果返回給internet上請求連線的客戶端，此時**伺服器對外就表現為乙個反向**伺服器。目前用的最廣的要算是nginx，出自俄羅斯人igor sysoev之手筆。 7.
分布式檔案/資料庫系統：
繼續開刀，當然所用的變革都是因為時機到了，業務發展，我們的系統從而隨著演進，可不是為了演進而演進啊。檔案系統比較簡單，引入分布式檔案伺服器。資料庫則較難，不得已才拆分。拆分資料庫後，需要引入統一資料訪問模組。
8 . nosql與搜尋引擎：
著名的nosql終於登場，關係型資料再怎麼拆分，隨著資料量的增加，仍然面臨效能瓶頸，如多表關聯，全表掃瞄等棘手問題。nosql表示無壓力，如hbase，源自網際網路，天然為網際網路而生，天生俱有分布式，可伸縮性。 9.
業務分拆：
好吧，能想的技術架構都已經用了，都已經8板斧了，沒轍了。只好開刀業務，哈哈。其實，業務包括業務條線，業務流程，如果能把業務規劃的很好，包括流程，可以解決很多問題，包括效能；比如分時搶購**等。回到業務拆分，通常根據業務場景，如電商業務包括了首頁，商鋪，訂單，交易，購物車等產品線來拆分。
可拆分之後，如何串聯起來呢？ 應用之間通常採用幾種辦法，如通過超連結；訊息佇列；又或者是通過同乙個資料庫來關聯共享。
10. 分布式服務：
出大招了，正所謂分久必合。拆了這麼多，這麼細，必然造成複雜度指數級提公升，部署，維護越來越困難，而且一定是有很多共同的功能，如使用者管理，登陸管理，產品管理，交易支付等公共業務。好吧，整合服務，通過分布式服務呼叫業務服務。
到此，此架已經可以解決絕大多數網際網路問題，當然，看圖容易，真實實現架構則需耗費大量人力，物力，財力。阿里當年也經過了數十年的演變才至此。
3. 網際網路架構
我們來看一張完整的分布式網際網路架構圖吧：
清楚麼？可以看出，創新的業務產生了創新的技術，是業務與技術的完美結合。此處提一點，不要本末倒置，有些在業務方向還沒有搞清楚的情況下，就盲目搭建大型網際網路架構，可謂有錢 ＋ 燒錢。還有一些小型初創，為了技術而技術，盲目模仿facebook, bat，得不償失。
另外，網際網路技術發展到此處，已經進入雲計算，容器服務階段；中小企業再野不用，也不需要從新造輪子，直接用大公司提供的雲計算，容器服務可，從而專心業務發展。
好了，拋磚引玉，簡單聊了一下，小朋友醒了，要開始「三陪」了。注：很多想法參考自網上，以及技術叢書。
大型網際網路架構概述
一 dns 1 當使用者在 瀏覽器中輸入 位址 後，瀏覽器會檢查 瀏覽器快取 中是否存在對應 網域名稱的解析結果 如果有，則解析過程結束 否則進入下乙個步驟 2 瀏覽器查詢 作業系統快取 中是否存在這個 網域名稱的解析結果 這個快取的內容 就是作業系統的 hosts檔案 如果有，則解析過程結束 否則...
大型網際網路web系統架構 總體架構
一 將大型網際網路web系統分為七大塊四大類，如下 1.1 管理類 分發系統 1.2 前端 web前端系統 負載均衡系統 1.3 服務端 分布式伺服器管理系統 快取系統 分布式儲存系統 1.4 持久層 資料庫集群系統 二 web前端系統 2.1 要解決的主要問題 2.1.1 不同應用伺服器共享 2....
網際網路架構
網際網路架構，主要追求的是高可用，可擴充套件 這兩個特性 在這裡做了一些個人的總結，算是給2014年的工作做個總結。推陳出新 一定要做的，死守積累會逐漸丟失人才，但凡技術公司都會不斷更新技術 kiss原則 keep it stupid優秀的 都會很簡單，簡單理解，簡單更改，能把複雜的事情做簡單是一種...