Web服務的一個重要特點就是流量大、數據多，僅靠一臺服務器肯定難以支撐大規模的服務。 所以我們經常會看到諸如以下的一些術語，教人好生不懂：

*：系統架構、物理架構、Web服務基礎設施

*：應用服務器

*：數據庫服務器

*：索引服務器

*：反向代理服務器

*：緩存服務器

*：分布式、可擴展性

*：cpu負載、IO負載

如果你也不懂，那麽本文對你來說就是一個很好的開始，關於web服務架構方面，前面還有幾篇不錯的文章可供參考閱讀---大型網站架構演化歷程（上）、大型網站架構演化歷程（下）、大型網站的靈魂——性能（請戳我）。

本文的主要目標—讀懂下面這張圖例：

cpu負載和I/O負載

我們從CPU和IO說起。 一個典型的Web服務就是網站服務——用戶通過瀏覽器向服務器發起請求，服務器從數據庫提取數據後，加工處理返回HTML頁面給用戶。

上圖中的4個箭頭“<—”都需要消耗Server的CPU計算資源，而從Database中獲取數據則消耗IO資源。 當用戶數量、請求數量上升時，Server的CPU資源告急（IO資源負載也有增加）；當儲存的數據量上升時，Server的IO資源也要告急。

比如說單臺Server每分鐘可以處理3000次請求（PV, Page View），那麽每月就可以處理100萬PV，超過這個數量服務器就撐不住了； 每次請求都需要從文件系統提取數據的話，由於讀取磁盤所需的時間是內存的100000-1000000倍，每分鐘的請求數多了數據提取速度必然跟不上，數據庫就掛了。

可擴展性

如何處理規模逐漸增大服務需求呢？這要求你的系統要有可擴展性：

橫向擴展：橫向擴展又叫分布式，一臺Server撐不住我就多來幾臺。 但現實遠比理想復雜。

縱向擴展：縱向擴展是金融高富帥或者企業軟件比較常采用的方法，因為服務器的價格和性能不成正比，性能達到一定程度後，每一分性能的提高需要投入更多的錢——服務器性能的邊際價格是不斷上升的。 對於互聯網的草根創業團隊來說，這顯然是不可接受的。

cpu能力的擴展

CPU負載的分散比較容易，因為CPU的計算不存在依賴性，即當前請求的結果不依賴於上一次請求的結果。 HTTP協議的stateless就是一個很好的例子。 這樣CPU撐不住的時候，我直接clone幾臺完全一起的就好了，而被克隆的這種服務一般就稱作應用服務器。

應用服務器和Web服務器的界限並不很清晰。 Web服務器負責接收用戶發過來的請求和返回資源對象給用戶，而應用服務器則負責通過計算產生這個資源對象（比如調用CGI腳本）。

這樣CPU的負載問題就解決了，我們的架構變成了這個樣子。

I/O能力的擴展

內存讀取的速度遠高於磁盤，根據操作系統緩存（Cache）的原理，我們提高數據讀取速度的基本思路是——提高內存大小可以顯著的降低IO負載，即為你的Server換上更大更多的內存條。 相應的基本方針——當操作系統的緩存無法處理時，再進一步考慮分布式。 IO負載分散的本質也就是廉價小容量內存的分散。

IO負載的分散可比CPU的難多了，由於存在數據同步的問題，我們這裏不討論數據庫服務器之間全盤的數據復制和冗余化。 既然數據量太大，大到一臺服務器的內存裝不下，那我們就把數據分割開來——數據分割（數據壓縮也可以達到一定的效果）。

Web服務的請求是存在訪問模式，比如爬蟲和普通用戶的訪問（爬蟲會請求很早以前的頁面，而普通用戶大多訪問當前的熱門頁面），我們把應對用戶的熱門的資源對象放在一臺服務器，應對爬蟲的資源對象放在另一臺。

即使不存在訪問模式，我們也可以通過分區（Partitioning），即表分割來做到。 比如現在MySQL數據庫裏有一個用戶ID表，用戶量增長後表的record數是13億，我們根據ID的大小來排序，分割成幾個ID表，每個表幾千萬個ID，這樣單個表大小就是GB級別——內存夠裝了。

不管是哪一種情況，我們都需要一臺索引服務器，來做應用服務器和數據服務器的mapping。

那麽現在我們的架構就是：

本文的說明就到這裏為止了，相信你現在再回頭看開頭的那張系統架構圖將會非常容易了吧。

轉自：燈塔大數據

如何讀懂Web服務的系統架構圖