QQ遊戲於前幾日終於突破了百萬人同時線上的關口，向著更為遠大的目標邁進，這讓其它眾多傳統的棋牌休閒遊戲平臺黯然失色，相比之下，聯眾似乎已經根本不是QQ的對手，因為QQ除了這100萬的遊戲線上人數外，它還擁有3億多的註冊量（當然很多是重複註冊的）以及QQ聊天軟體900萬的同時線上率，我們已經可以預見未來由QQ構建起來的強大棋牌休閒遊戲帝國。

伺服器程式，其可承受的同時連線數目是有理論峰值的，通過C＋＋中對TSocket的定義型別：word，我們可以判定這個連線理論峰值是65535，也就是說，你的單個伺服器程式，最多可以承受6萬多的使用者同時連線。但是，在實際應用中，能達到一萬人的同時連線並能保證正常的資料交換已經是很不容易了，通常這個值都在2000到5000之間，據說QQ的單臺伺服器同時連線數目也就是在這個值這間。

　　如果要實現2000到5000使用者的單伺服器同時線上，是不難的。在windows下，比較成熟的技術是採用IOCP－－完成埠。與完成埠相關的資料在網上和CSDN論壇裡有很多，感興趣的朋友可以自己搜尋一下。只要運用得當，一個完成埠伺服器是完全可以達到2K到5K的同時線上量的。但，5K這樣的數值離百萬這樣的數值實在相差太大了，所以，百萬人的同時線上是單臺伺服器肯定無法實現的。

　　要實現百萬人同時線上，首先要實現一個比較完善的完成埠伺服器模型，這個模型要求至少可以承載2K到5K的同時線上率（當然，如果你MONEY多，你也可以只開發出最多允許100人線上的伺服器）。在構建好了基本的完成埠伺服器之後，就是有關伺服器組的

架構設計了。之所以說這是一個伺服器組，是因為它絕不僅僅只是一臺伺服器，也絕不僅僅是隻有一種型別的伺服器。

　　簡單地說，實現百萬人同時線上的伺服器模型應該是：登陸伺服器＋大廳伺服器＋房間伺服器。當然，也可以是其它的模型，但其基本的思想是一樣的。下面，我將逐一介紹這三類伺服器的各自作用。

　　登陸伺服器：一般情況下，我們會向玩家開放若干個公開的登陸伺服器，就如QQ登陸時讓你選擇的從哪個QQ遊戲伺服器登陸一樣，QQ登陸時讓玩家選擇的六個伺服器入口實際上就是登陸伺服器。登陸伺服器主要完成負載平衡的作用。詳細點說就是，在登陸伺服器的背後，有N個大廳伺服器，登陸伺服器只是用於為當前的客戶端連線選擇其下一步應該連線到哪個大廳伺服器，當登陸伺服器為當前的客戶端連線選擇了一個合適的大廳伺服器後，客戶端開始根據登陸伺服器提供的資訊連線到相應的大廳上去，同時客戶端斷開與登陸伺服器的連線，為其他玩家客戶端連線登陸伺服器騰出套接字資源。在設計登陸伺服器時，至少應該有以下功能：N個大廳伺服器的每一個大廳伺服器都要與所有的登陸伺服器保持連線，並實時地把本大廳伺服器當前的同時線上人數通知給各個登陸伺服器，這其中包括：使用者進入時的同時線上人數增加資訊以及使用者退出時的同時線上人數減少資訊。這裡的各個大廳伺服器同時線上人數資訊就是登陸伺服器為客戶端選擇某個大廳讓其登陸的依據。舉例來說，玩家A通過登陸伺服器1連線到登陸伺服器，登陸伺服器開始為當前玩家在眾多的大廳伺服器中根據哪一個大廳伺服器人數比較少來選擇一個大廳，同時把這個大廳的連線IP和埠發給客戶端，客戶端收到這個IP和埠資訊後，根據這個資訊連線到此大廳，同時，客戶端斷開與登陸伺服器之間的連線，這便是使用者登陸過程中，在登陸伺服器這一塊的處理流程。

　　大廳伺服器：大廳伺服器，是普通玩家看不到的伺服器，它的連線IP和埠資訊是登陸伺服器通知給客戶端的。也就是說，在QQ遊戲的本地檔案中，具體的大廳伺服器連線IP和埠資訊是沒有儲存的。大廳伺服器的主要作用是向玩家傳送遊戲房間列表資訊，這些資訊包括：每個遊戲房間的型別，名稱，線上人數，連線地址以及其它如遊戲幫助檔案URL的資訊。從介面上看的話，大廳伺服器就是我們輸入使用者名稱和密碼並校驗通過後進入的遊戲房間列表介面。大廳伺服器，主要有以下功能：一是向當前玩家廣播各個遊戲房間線上人數資訊；二是提供遊戲的版本以及下載地址資訊；三是提供各個遊戲房間伺服器的連線IP和埠資訊；四是提供遊戲幫助的URL資訊；五是提供其它遊戲輔助功能。但在這眾多的功能中，有一點是最為核心的，即：為玩家提供進入具體的遊戲房間的通道，讓玩家順利進入其欲進入的遊戲房間。玩家根據各個遊戲房間線上人數，判定自己進入哪一個房間，然後雙擊伺服器列表中的某個遊戲房間後玩家開始進入遊戲房間伺服器。

　　遊戲房間伺服器：遊戲房間伺服器，具體地說就是如“鬥地主1”，“鬥地主2”這樣的遊戲房間。遊戲房間伺服器才是具體的負責執行遊戲相關邏輯的伺服器。這樣的遊戲邏輯分為兩大類：一類是通用的遊戲房間邏輯，如：進入房間，離開房間，進入桌子，離開桌子以及在房間內說話等；第二類是遊戲桌子邏輯，這個就是各種不同型別遊戲的主要區別之處了，比如鬥地主中的叫地主或不叫地主的邏輯等，當然，遊戲桌子邏輯裡也包括有通用的各個遊戲裡都存在的遊戲邏輯，比如在桌子內說話等。總之，遊戲房間伺服器才是真正負責執行遊戲具體邏輯的伺服器。

　　這裡提到的三類伺服器，我均採用的是完成埠模型，每個伺服器最多連線數目是5000人，但是，我在遊戲房間伺服器上作了邏輯層的限定，最多隻允許300人同時線上。其他兩個伺服器仍然允許最多5000人的同時線上。如果按照這樣的結構來設計，那麼要實現百萬人的同時線上就應該是這樣：首先是大廳，1000000/5000＝200。也就是說，至少要200臺大廳伺服器，但通常情況下，考慮到實際使用時伺服器的處理能力和負載情況，應該至少準備250臺左右的大廳伺服器程式。另外，具體的各種型別的遊戲房間伺服器需要多少，就要根據當前玩各種型別遊戲的玩家數目分別計算了，比如鬥地主最多是十萬人同時線上，每臺伺服器最多允許300人同時線上，那麼需要的鬥地主伺服器數目就應該不少於：100000/300=333，準備得充分一點，就要準備350臺鬥地主伺服器。

　　除正常的玩家連線外，還要考慮到：

　　對於登陸伺服器，會有250臺大廳伺服器連線到每個登陸伺服器上，這是始終都要保持的連線；

　　而對於大廳伺服器而言，如果僅僅有鬥地主這一類的伺服器，就要有350多個連線與各個大廳伺服器始終保持著。所以從這一點看，我的結構在某些方面還存在著需要改進的地方，但核心思想是：儘快地提供使用者登陸的速度，儘可能方便地讓玩家進入遊戲中。

posted @ 2011-06-28 15:57 李sir 閱讀(152) 評論(0)  編輯
穩定高效大型系統架構---叢集中介軟體開發

那現在來說，穩定的中介軟體應該是什麼樣子呢？

       對於客戶端請求，如果發現服務停止，可以實現服務無縫轉移－－－這叫不丟失任何服務.

       對於多個客戶端請求，可以講請求輪巡到不同的伺服器上－－－這樣叫負荷平攤，如果再做到可以根據客戶端數量方面地增減伺服器數量，那就能很通過簡單增加伺服器，實現系統效率的提升。

       最牛的是，如果你再加上分散式程式設計。一個函式，根據伺服器負荷平攤的特點，可以讓多個伺服器，同時為一個函式工作。

思考：

       第一：客戶端請求，實現輪巡。

                   知道了請求，需要輪巡。就要先知道有那些伺服器－－－》 設計伺服器註冊登出機制。

                   還要知道請求當前，每臺伺服器上有那些負荷－－－》客戶端請求計算機制。

                   然後根據這些，計算當前請求由那個伺服器來完成任務。

      第二：故障熱切換

                  經試驗驗證，故障有三種情況

                 A）請求選擇伺服器前，有故障。

                 B）伺服器選中後，準備開始要服務時，故障。

                 C)服務正在進行時，發生故障

為解決以上問題，我做出如下架構：

               

1、       在客戶端，開發了安全訪問機制，保證在有服務存在的情況，單次的訪問異常，可以容錯；同時若訪問時發生故障，重新請求。

2、中間層開發了負荷平衡機制，其建立的叢集，對客戶端來說，是一個透明體。客戶端只需要知道公佈的服務叢集IP地址，由負荷平衡自動分配請求；同時伺服器發生故障時，自動從叢集中移去，將請求切換至其它正常的伺服器上。(中間層是一個無狀態，多執行緒，分散式的應用程式服務，對任何一個請求，由哪臺伺服器提供服務都可以達到一致的目標)

posted @ 2011-06-28 15:47 李sir 閱讀(74) 評論(0)  編輯
淺談大型網站動態應用系統架構

動態應用，是相對於網站靜態內容而言，是指以c/c++、PHP、Java、perl、.net等伺服器端語言開發的網路應用軟體，比如論壇、網路相簿、交友、BLOG等常見應用。動態應用系統通常與資料庫系統、快取系統、分散式儲存系統等密不可分。

大型動態應用系統平臺主要是針對於大流量、高併發網站建立的底層系統架構。大型網站的執行需要一個可靠、安全、可擴充套件、易維護的應用系統平臺做為支撐，以保證網站應用的平穩執行。

大型動態應用系統又可分為幾個子系統：

l         Web前端系統

l         負載均衡系統

l         資料庫集群系統

l         快取系統

l         分散式儲存系統

l         分散式伺服器管理系統

l         程式碼分發系統

Web前端系統

結構圖：

 

 

 

為了達到不同應用的伺服器共享、避免單點故障、集中管理、統一配置等目的，不以應用劃分伺服器，而是將所有伺服器做統一使用，每臺伺服器都可以對多個應用提供服務，當某些應用訪問量升高時，通過增加伺服器節點達到整個伺服器叢集的效能提高，同時使他應用也會受益。該Web前端系統基於Apache/Lighttpd/Eginx等的虛擬主機平臺，提供PHP程式執行環境。伺服器對開發人員是透明的，不需要開發人員介入伺服器管理

負載均衡系統

 

 

負載均衡系統分為硬體和軟體兩種。硬體負載均衡效率高，但是價格貴，比如F5等。軟體負載均衡系統價格較低或者免費，效率較硬體負載均衡系統低，不過對於流量一般或稍大些網站來講也足夠使用，比如lvs/nginx/haproxy。大多數網站都是硬體、軟體負載均衡系統並用。

資料庫集群系統

結構圖：

 

 

 

由於Web前端採用了負載均衡叢集結構提高了服務的有效性和擴充套件性，因此資料庫必須也是高可靠的才能保證整個服務體系的高可靠性，如何構建一個高可靠的、可以提供大規模併發處理的資料庫體系？

我們可以採用如上圖所示的方案：

1)        使用 MySQL 資料庫，考慮到Web應用的資料庫讀多寫少的特點，我們主要對讀資料庫做了優化，提供專用的讀資料庫和寫資料庫，在應用程式中實現讀操作和寫操作分別訪問不同的資料庫。

2)        使用 MySQL Replication 機制實現快速將主庫（寫庫）的資料庫複製到從庫（讀庫）。一個主庫對應多個從庫，主庫資料實時同步到從庫。

3)        寫資料庫有多臺，每臺都可以提供多個應用共同使用，這樣可以解決寫庫的效能瓶頸問題和單點故障問題。

4)        讀資料庫有多臺，通過負載均衡裝置實現負載均衡，從而達到讀資料庫的高效能、高可靠和高可擴充套件性。

5)        資料庫伺服器和應用伺服器分離。

6)        從資料庫使用BigIP做負載均衡。

快取系統

 

 

 

快取分為檔案快取、記憶體快取、資料庫快取。在大型Web應用中使用最多且效率最高的是記憶體快取。最常用的記憶體快取工具是Memcachd。使用正確的快取系統可以達到實現以下目標：

1、   使用快取系統可以提高訪問效率，提高伺服器吞吐能力，改善使用者體驗。

2、   減輕對資料庫及儲存集伺服器的訪問壓力

3、 Memcached伺服器有多臺，避免單點故障，提供高可靠性和可擴充套件性，提高效能。

分散式儲存系統

結構圖：

 

 

WEB系統平臺中的儲存需求有下面兩個特點：

1) 儲存量很大，經常會達到單臺伺服器無法提供的規模，比如相簿、視訊等應用。因此需要專業的大規模儲存系統。

2) 負載均衡cluster中的每個節點都有可能訪問任何一個數據物件，每個節點對資料的處理也能被其他節點共享，因此這些節點要操作的資料從邏輯上看只能是一個整體，不是各自獨立的資料資源。

因此高效能的分散式儲存系統對於大型網站應用來說是非常重要的一環。（這個地方需要加入對某個分散式儲存系統的簡單介紹。）

分散式伺服器管理系統

結構圖：

 

 

隨著網站訪問流量的不斷增加，大多的網路服務都是以負載均衡叢集的方式對外提供服務，隨之叢集規模的擴大，原來基於單機的伺服器管理模式已經不能夠滿足我們的需求，新的需求必須能夠集中式的、分組的、批量的、自動化的對伺服器進行管理，能夠批量化的執行計劃任務。

在分散式伺服器管理系統軟體中有一些比較優秀的軟體，其中比較理想的一個是 Cfengine。它可以對伺服器進行分組，不同的分組可以分別定製系統配置檔案、計劃任務等配置。它是基於C/S 結構的，所有的伺服器配置和管理指令碼程式都儲存在Cfengine Server上，而被管理的伺服器執行著 Cfengine Client 程式，Cfengine Client通過SSL加密的連線定期的向伺服器端傳送請求以獲取最新的配置檔案和管理命令、指令碼程式、補丁安裝等任務。

有了Cfengine 這種集中式的伺服器管理工具，我們就可以高效的實現大規模的伺服器叢集管理，被管理伺服器和 Cfengine Server 可以分佈在任何位置，只要網路可以連通就能實現快速自動化的管理。

程式碼釋出系統

結構圖：

 

 

隨著網站訪問流量的不斷增加，大多的網路服務都是以負載均衡叢集的方式對外提供服務，隨之叢集規模的擴大，為了滿足叢集環境下程式程式碼的批量分發和更新，我們還需要一個程式程式碼釋出系統。

這個釋出系統可以幫我們實現下面的目標：

1) 生產環境的伺服器以虛擬主機方式提供服務，不需要開發人員介入維護和直接操作，提供釋出系統可以實現不需要登陸伺服器就能把程式分發到目標伺服器。

2) 我們要實現內部開發、內部測試、生產環境測試、生產環境釋出的4個開發階段的管理，釋出系統可以介入各個階段的程式碼釋出。

3) 我們需要實現原始碼管理和版本控制，SVN可以實現該需求。

這裡面可以使用常用的工具Rsync，通過開發相應的指令碼工具實現伺服器叢集間程式碼同步分發。

posted @ 2011-06-28 15:38 李sir 閱讀(147) 評論(0)  編輯
大型網站採用的具有穩定性的系統構架

千萬級的註冊使用者，千萬級的帖子，nTB級的附件，還有巨大的日訪問量，大型網站採用什麼系統架構保證效能和穩定性？

首先討論一下大型網站需要注意和考慮的問題。

資料庫海量資料處理：負載量不大的情況下select、delete和update是響應很迅速的，最多加幾個索引就可以搞定，但千萬級的註冊使用者和一個設計不好的多對多關係將帶來非常嚴重的效能問題。另外在高UPDATE的情況下，更新一個聚焦索引的時間基本上是不可忍受的。索引和更新是一對天生的冤家。

高併發死鎖：平時我們感覺不到，但資料庫死鎖在高併發的情況下的出現的概率是非常高的。

檔案儲存的問題：大型網站有海量圖片資料、視訊資料、檔案資料等等，他們如何儲存並被有效索引？高併發的情況下IO的瓶頸問題會迅速顯現。也許用RAID和專用存貯伺服器能解決眼下的問題，但是還有個問題就是各地的訪問問題，也許我們的伺服器在北京，可能在雲南或者新疆的訪問速度如何解決？如果做分散式，那麼我們的檔案索引以及架構該如何規劃。

接下來討論大型網站的底層系統架構，來有效的解決上述問題。

毋庸置疑，對於規模稍大的網站來說，其背後必然是一個伺服器叢集來提供網站服務，例如，2004年eBay的伺服器有2400臺，估計現在更多。當然，資料庫也必然要和應用服務分開，有單獨的資料庫伺服器叢集。對於像淘寶網這樣規模的網站而言，就是應用也分成很多組。

下面，就從伺服器作業系統與Web伺服器、資料庫、伺服器叢集與負載均衡、快取、獨立的圖片伺服器、其它等幾個方面來分析大型網站的系統架構。

伺服器作業系統與Web伺服器

最底層首先是作業系統。好的作業系統能提高好的效能、穩定性和安全性，而這些對大型網站的效能、安全性和穩定性都是至關重要的。

淘寶網（阿里巴巴）： Linux作業系統 + Web 伺服器： Apache

新浪：FreeBSD + Web 伺服器：Apache

Yahoo：FreeBSD + Web 伺服器：自己的

Google： 部分Linux + Web 伺服器：自己的

百度：Linux + Web 伺服器： Apache

網易：Linux + Web 伺服器： Apache

eBay： Windows Server 2003/8 （大量） + Web 伺服器：Microsoft IIS

MySpace： Windows Server 2003/8 + Web 伺服器：Microsoft IIS

由此可見，開源作業系統做Web應用是首選已經是一個既定事實。在開源作業系統中Linux和FreeBSD差不太多，很難說哪個一定比另外一個要優秀很多、能夠全面的超越對手，應該是各有所長。但熟悉Linux的技術人員更多些，利於系統管理、優化等，所以Linux使用更廣泛。而Windows Server和IIS雖然有的網站使用，但不開源，而且需要購買微軟的一系列應用產品，限制了其使用。總之，開源作業系統，尤其是Linux做Web應用是首選已經是一個既定事實。

常用的系統架構是：

Linux + Apache + PHP + MySQL

Linux + Apache + Java （WebSphere） + Oracle

Windows Server 2003/2008 + IIS + C#/ASP.NET + 資料庫

資料庫

因為是千萬人同時訪問的網站，所以一般是有很多個數據庫同時工作的，說明白一點就是資料庫叢集和併發控制，資料分佈到地理位置不同的資料中心，以免發生斷電事故。

主流的資料庫有Sun的是MySQL和Oracle。

Oracle是一款優秀的、廣泛採用的商業資料庫管理軟體。有很強大的功能和安全性，可以處理相對海量的資料。而MySQL是一款非常優秀的開源資料庫管理軟體，非常適合用多臺PC Server組成多點的儲存節點陣列（這裡我所指的不是MySQL自身提供的叢集功能），每單位的資料儲存成本也非常的低廉。用多臺PC Server安裝MySQL組成一個儲存節點陣列，通過MySQL自身的Replication或者應用自身的處理，可以很好的保證容錯（允許部分節點失效），保證應用的健壯性和可靠性。可以這麼說，在關係資料庫管理系統的選擇上，可以考慮應用本身的情況來決定。

MySQL資料庫伺服器的master-slave模式，利用資料庫伺服器在主從伺服器間進行同步，應用只把資料寫到主伺服器，而讀資料時則根據負載選擇一臺從伺服器或者主伺服器來讀取，將資料按不同策略劃分到不同的伺服器（組）上，分散資料庫壓力。

伺服器叢集與負載均衡

伺服器群集中每個服務結點執行一個所需伺服器程式的獨立拷貝，而網路負載均衡則將工作負載在這些主機間進行分配。負載均衡建立在現有網路結構之上，它提供了一種廉價有效的方法擴充套件伺服器頻寬和增加吞吐量，加強網路資料處理能力，提高網路的靈活性和可用性。它主要完成以下任務：解決網路擁塞問題，服務就近提供，實現地理位置無關性 ;為使用者提供更好的訪問質量;提高伺服器響應速度;提高伺服器及其他資源的利用效率;避免了網路關鍵部位出現單點失效。

常用的伺服器叢集和資料庫叢集負載均衡實現方法：

Citrix NetScaler的硬體負載均衡交換機做伺服器叢集的負載均衡。

MySQL Proxy做MySQL伺服器叢集的負載均衡並實現讀寫分離。其實現讀寫分離的基本原理是讓主資料庫處理事務性查詢，而從資料庫處理SELECT查詢。資料庫複製被用來把事務性查詢導致的變更同步到叢集中的從資料庫。

CDN （Content Delivery Network）： 幾乎在各大網站都有使用該技術。例如，使得你的網站在各省市訪問更快，其原理是採取了分散式網路快取結構（即國際上流行的web cache技術），通過在現有的Internet中增加一層新的網路架構，將網站的內容釋出到最接近使用者的cache伺服器內，通過DNS負載均衡的技術，判斷使用者來源就近訪問cache伺服器取得所需的內容，解決Internet網路擁塞狀況，提高使用者訪問網站的響應速度，如同提供了多個分佈在各地的加速器，以達到快速、可冗餘的為多個網站加速的目的。

快取

眾所周知，使用快取能有效應對大負載，減少資料庫的壓力，並顯著提高多層應用程式的效能，但如何在叢集環境中使多個快取、多層快取並儲存同步是個重大問題。大型網站一般都使用快取伺服器群，並使用多層快取。業內最常用的有：

Squid cache，Squid伺服器群，把它作為web伺服器端前置cache伺服器快取相關請求來提高web伺服器速度。Squid將大部分靜態資源（圖片，js，css等）快取起來，直接返回給訪問者，減少應用伺服器的負載

memcache，memcache伺服器群，一款分散式快取產品，很多大型網站在應用; 它可以應對任意多個連線，使用非阻塞的網路IO。由於它的工作機制是在記憶體中開闢一塊空間，然後建立一個HashTable，Memcached自管理這些HashTable。

e-Accelerator，比較特殊，PHP的快取和加速器。是一個免費開源的PHP加速、優化、編譯和動態快取的專案，它可以通過快取PHP程式碼編譯後的結果來提高PHP指令碼的效能，使得一向很複雜和離我們很遠的 PHP指令碼編譯問題完全得到解決。通過使用eAccelerator，可以優化你的PHP程式碼執行速度，降低伺服器負載，可以提高PHP應用執行速度最高達10倍。

獨立的圖片伺服器

無論從管理上，還是從效能上看，只要有可能，儘量部署獨立的圖片伺服器。這幾乎成為常識了。具備獨立的圖片伺服器或者伺服器集群后，在 Web 伺服器上就可以有針對性的進行配置優化。

其他

一個網際網路應用，除了伺服器的作業系統，Web Server軟體，應用伺服器軟體，資料庫軟體外，我們還會涉及到一些其他的系統，比如一些中介軟體系統、檔案儲存系統（圖片伺服器，視訊伺服器，管理伺服器，RSS和廣告伺服器等等）、全文檢索、搜尋、等等。會在以後介紹。

posted @ 2011-06-28 15:31 李sir 閱讀(55) 評論(0)  編輯
網站構架師進行大型網站構架的步驟

架構演變第一步：物理分離webserver和資料庫

最開始，由於某些想法，於是在網際網路上搭建了一個網站，這個時候甚至有可能主機都是租借的，但由於這篇文章我們只關注架構的演變歷程，因此就假設這個時候已經是託管了一臺主機，並且有一定的帶寬了，這個時候由於網站具備了一定的特色，吸引了部分人訪問，逐漸你發現系統的壓力越來越高，響應速度越來越慢，而這個時候比較明顯的是資料庫和應用互相影響，應用出問題了，資料庫也很容易出現問題，而資料庫出問題的時候，應用也容易出問題，於是進入了第一步演變階段：將應用和資料庫從物理上分離，變成了兩臺機器，這個時候技術上沒有什麼新的要求，但你發現確實起到效果了，系統又恢復到以前的響應速度了，並且支撐住了更高的流量，並且不會因為資料庫和應用形成互相的影響。

這一步涉及到了這些知識體系：

這一步架構演變對技術上的知識體系基本沒有要求。

構架構演變第二步：增加頁面快取

好景不長，隨著訪問的人越來越多，你發現響應速度又開始變慢了，查詢原因，發現是訪問資料庫的操作太多，導致資料連線競爭激烈，所以響應變慢，但資料庫連線又不能開太多，否則資料庫機器壓力會很高，因此考慮採用快取機制來減少資料庫連線資源的競爭和對資料庫讀的壓力，這個時候首先也許會選擇採用squid 等類似的機制來將系統中相對靜態的頁面（例如一兩天才會有更新的頁面）進行快取（當然，也可以採用將頁面靜態化的方案），這樣程式上可以不做修改，就能夠 很好的減少對webserver的壓力以及減少資料庫連線資源的競爭，OK，於是開始採用squid來做相對靜態的頁面的快取。

這一步涉及到了這些知識體系：

前端頁面快取技術，例如squid，如想用好的話還得深入掌握下squid的實現方式以及快取的失效演算法等。

架構演變第三步：增加頁面片段快取

增加了squid做快取後，整體系統的速度確實是提升了，webserver的壓力也開始下降了，但隨著訪問量的增加，發現系統又開始變的有些慢了，在嘗 到了squid之類的動態快取帶來的好處後，開始想能不能讓現在那些動態頁面裡相對靜態的部分也快取起來呢，因此考慮採用類似ESI之類的頁面片段快取策略，OK，於是開始採用ESI來做動態頁面中相對靜態的片段部分的快取。

這一步涉及到了這些知識體系：

頁面片段快取技術，例如ESI等，想用好的話同樣需要掌握ESI的實現方式等；

架構演變第四步：資料快取

在採用ESI之類的技術再次提高了系統的快取效果後，系統的壓力確實進一步降低了，但同樣，隨著訪問量的增加，系統還是開始變慢，經過查詢，可能會發現系 統中存在一些重複獲取資料資訊的地方，像獲取使用者資訊等，這個時候開始考慮是不是可以將這些資料資訊也快取起來呢，於是將這些資料快取到本地記憶體，改變完畢後，完全符合預期，系統的響應速度又恢復了，資料庫的壓力也再度降低了不少。

這一步涉及到了這些知識體系：

快取技術，包括像Map資料結構、快取演算法、所選用的框架本身的實現機制等。

架構演變第五步： 增加webserver

好景不長，發現隨著系統訪問量的再度增加，webserver機器的壓力在高峰期會上升到比較高，這個時候開始考慮增加一臺webserver，這也是為了同時解決可用性的問題，避免單臺的webserver down機的話就沒法使用了，在做了這些考慮後，決定增加一臺webserver，增加一臺webserver時，會碰到一些問題，典型的有：
1、如何讓訪問分配到這兩臺機器上，這個時候通常會考慮的方案是Apache自帶的負載均衡方案，或LVS這類的軟體負載均衡方案；
2、如何保持狀態資訊的同步，例如使用者session等，這個時候會考慮的方案有寫入資料庫、寫入儲存、cookie或同步session資訊等機制等；
3、如何保持資料快取資訊的同步，例如之前快取的使用者資料等，這個時候通常會考慮的機制有快取同步或分散式快取；
4、如何讓上傳檔案這些類似的功能繼續正常，這個時候通常會考慮的機制是使用共享檔案系統或儲存等；
在解決了這些問題後，終於是把webserver增加為了兩臺，系統終於是又恢復到了以往的速度。

這一步涉及到了這些知識體系：

負載均衡技術（包括但不限於硬體負載均衡、軟體負載均衡、負載演算法、linux轉發協議、所選用的技術的實現細節等）、主備技術（包括但不限於ARP欺騙、linux heart-beat等）、狀態資訊或快取同步技術（包括但不限於Cookie技術、UDP協議、狀態資訊廣播、所選用的快取同步技術的實現細節等）、共享檔案技術（包括但不限於NFS等）、儲存技術（包括但不限於儲存裝置等）。

架構演變第六步：分庫

享受了一段時間的系統訪問量高速增長的幸福後，發現系統又開始變慢了，這次又是什麼狀況呢，經過查詢，發現數據庫寫入、更新的這些操作的部分資料庫連線的資源競爭非常激烈，導致了系統變慢，這下怎麼辦呢，此時可選的方案有資料庫叢集和分庫策略，叢集方面像有些資料庫支援的並不是很好，因此分庫會成為比較普遍的策略，分庫也就意味著要對原有程式進行修改，一通修改實現分庫後，不錯，目標達到了，系統恢復甚至速度比以前還快了。

這一步涉及到了這些知識體系：

這一步更多的是需要從業務上做合理的劃分，以實現分庫，具體技術細節上沒有其他的要求；

但同時隨著資料量的增大和分庫的進行，在資料庫的設計、調優以及維護上需要做的更好，因此對這些方面的技術還是提出了很高的要求的。

架構演變第七步：分表、DAL和分散式快取
隨著系統的不斷執行，資料量開始大幅度增長，這個時候發現分庫後查詢仍然會有些慢，於是按照分庫的思想開始做分表的工作，當然，這不可避免的會需要對程式進行一些修改，也許在這個時候就會發現應用自己要關心分庫分表的規則等，還是有些複雜的，於是萌生能否增加一個通用的框架來實現分庫分表的資料訪問，這個在ebay的架構中對應的就是DAL，這個演變的過程相對而言需要花費較長的時間，當然，也有可能這個通用的框架會等到分表做完後才開始做，同時，在這個階段可能會發現之前的快取同步方案出現問題，因為資料量太大，導致現在不太可能將快取存在本地，然後同步的方式，需要採用分散式快取方案了，於是，又是一通考察和折磨，終於是將大量的資料快取轉移到分散式快取上了。

這一步涉及到了這些知識體系：

分表更多的同樣是業務上的劃分，技術上涉及到的會有動態hash演算法、consistent hash演算法等；

DAL涉及到比較多的複雜技術，例如資料庫連線的管理（超時、異常）、資料庫操作的控制（超時、異常）、分庫分表規則的封裝等；

架構演變第八步：增加更多的webserver

在做完分庫分表這些工作後，資料庫上的壓力已經降到比較低了，又開始過著每天看著訪問量暴增的幸福生活了，突然有一天，發現系統的訪問又開始有變慢的趨勢了，這個時候首先檢視資料庫，壓力一切正常，之後檢視webserver，發現apache阻塞了很多的請求，而應用伺服器對每個請求也是比較快的，看來 是請求數太高導致需要排隊等待，響應速度變慢，這還好辦，一般來說，這個時候也會有些錢了，於是新增一些webserver伺服器，在這個新增 webserver伺服器的過程，有可能會出現幾種挑戰：
1、Apache的軟負載或LVS軟負載等無法承擔巨大的web訪問量（請求連線數、網路流量等）的排程了，這個時候如果經費允許的話，會採取的方案是購 買硬體負載，例如F5、Netsclar、Athelon之類的，如經費不允許的話，會採取的方案是將應用從邏輯上做一定的分類，然後分散到不同的軟負載叢集中；
2、原有的一些狀態資訊同步、檔案共享等方案可能會出現瓶頸，需要進行改進，也許這個時候會根據情況編寫符合網站業務需求的分散式檔案系統等；
在做完這些工作後，開始進入一個看似完美的無限伸縮的時代，當網站流量增加時，應對的解決方案就是不斷的新增webserver。

這一步涉及到了這些知識體系：

到了這一步，隨著機器數的不斷增長、資料量的不斷增長和對系統可用性的要求越來越高，這個時候要求對所採用的技術都要有更為深入的理解，並需要根據網站的需求來做更加定製性質的產品。

架構演變第九步：資料讀寫分離和廉價儲存方案

突然有一天，發現這個完美的時代也要結束了，資料庫的噩夢又一次出現在眼前了，由於新增的webserver太多了，導致資料庫連線的資源還是不夠用，而這個時候又已經分庫分表了，開始分析資料庫的壓力狀況，可能會發現資料庫的讀寫比很高，這個時候通常會想到資料讀寫分離的方案，當然，這個方案要實現並不 容易，另外，可能會發現一些資料儲存在資料庫上有些浪費，或者說過於佔用資料庫資源，因此在這個階段可能會形成的架構演變是實現資料讀寫分離，同時編寫一些更為廉價的儲存方案，例如BigTable這種。

這一步涉及到了這些知識體系：

資料讀寫分離要求對資料庫的複製、standby等策略有深入的掌握和理解，同時會要求具備自行實現的技術；

廉價儲存方案要求對OS的檔案儲存有深入的掌握和理解，同時要求對採用的語言在檔案這塊的實現有深入的掌握。

架構演變第十步：進入大型分散式應用時代和廉價伺服器群夢想時代

經過上面這個漫長而痛苦的過程，終於是再度迎來了完美的時代，不斷的增加webserver就可以支撐越來越高的訪問量了，對於大型網站而言，人氣的重要毋庸置疑，隨著人氣的越來越高，各種各樣的功能需求也開始爆發性的增長，這個時候突然發現，原來部署在webserver上的那個web應用已經非常龐大 了，當多個團隊都開始對其進行改動時，可真是相