業務驅動技術的發展是亙古不變的道理。最開始的時候，業務量少，業務復雜度低，采取的技術也相對簡單，基本滿足用戶對功能的需求。

隨著 IT 信息化的普及，更多的交易放到了網絡上，信息量增加和訪問次數頻繁就是要解決的問題了。

因此，逐漸加入了緩存、集群等技術手段。同時對業務的擴展性和伸縮性的要求也越來越高。

高并發、高可用、可伸縮、可擴展、夠安全的軟件架構一直是架構設計追求的目標。

今天我們來看一下架構設計經歷了哪些階段，每個階段都解決了哪些問題，又引出了哪些新問題。

主要是引起大家的思考，在不同的業務發展階段采取合適技術手段，用變化擁抱變化是 IT 人追求的目標。

應用與數據一體模式

最早的業務應用以網站、OA 等為主，訪問的人數有限，單臺服務器就能夠應付。

通常，將應用程序和數據庫部署到一臺服務器上面

在這一階段，我們利用 LAMP(Linux Apache MySQL PHP)技術就可以迅速搞定，并且這些工具都是開源的。

很長一段時間內，有各種針對這種應用模式的開源代碼可以使用。這種模式基本上沒有高并發的要求，可用性也很差。

有的服務器采用托管模式，上面就安裝了不同的業務應用，一旦服務器出現問題，所有的應用就罷工了。

不過其開發和部署成本相對較低，適合剛剛起步的應用服務。圖 1 就描述了單個應用和數據庫運行在單臺服務器的模式，我們稱這種模式為應用與數據一體模式。

應用與數據分離模式

隨著業務的發展，用戶數和請求數逐漸上升，服務器的性能出現了問題。其中比較簡單的解決方案就是增加資源，將業務應用和數據存儲分開。

其中，應用服務器需要處理大量的業務請求，對 CPU 和內存有一定要求;而數據庫服務器需要對數據進行存儲和索引等 IO 操作，對磁盤的轉速和內存會考慮更多。

這樣的分離解決了性能的問題，我們需要擴展更多的硬件資源讓其各司其職，使系統可以處理更多的用戶請求。

雖然業務上依舊存在耦和，但硬件層面的分離在可用性上比一體式設計要好很多。

緩存的加入

隨著信息化系統的發展和使用互聯網人數的增多，業務量、用戶量、數據量都在增長。

我們同時發現，用戶會對某些數據的請求量特別大，例如新聞、商品信息和熱門消息。

之前這些信息的獲取方式是依靠數據庫，因此受到數據庫 IO 性能的影響。此時數據庫成為了整個系統的瓶頸。

如果再增加服務器的數量，恐怕也很難解決，于是緩存技術就登場了

這里提到的緩存技術分為客戶端瀏覽器緩存、應用服務器本地緩存和緩存服務器緩存。

①客戶端瀏覽器緩存：當用戶通過瀏覽器請求服務器的時候，會發起 HTTP 請求。如果對每次 HTTP 請求進行緩存，那么可以減少應用服務器的壓力。

②應用服務器本地緩存：它使用的是進程內緩存，又叫托管堆緩存。以 Java 為例，這部分緩存放在 JVM 的托管堆上面，同時會受到托管堆回收算法的影響。

由于它運行在內存中，對數據的響應速度很快，通常我們會把熱點數據放在這里。

在進程內緩存沒有命中的時候，會到緩存服務器中獲取信息，如果還是沒有命中，才會去數據庫中獲取。

③緩存服務器緩存：它相對于應用服務器本地緩存來說，就是進程外緩存，既可以和應用服務部署在同一服務器，也可以部署到不同的服務器。

一般來說，為了方便管理和合理利用資源，會將其部署到專門的緩存服務器上面。由于緩存會占用內存空間，因此這類服務器會配置比較大的內存。

圖 3 描述了緩存請求的次序，先訪問客戶端緩存，之后是進程內的本地緩存，接下來是緩存服務器，最后才是數據。

如果在任意一層獲取了緩存信息，就不再往下訪問了，否則會一直按照這個次序獲取緩存信息，直到數據庫。

用戶請求訪問數據的順序為客戶端瀏覽器緩存→應用服務器本地緩存→緩存服務器緩存。

如果按照以上次序還沒有命中數據，才會訪問數據庫獲取數據。加入緩存的設計，提高了系統的性能。

由于緩存放在內存中，而內存的讀取速度比磁盤要快得多，能夠很快響應用戶請求。

特別針對一些熱點數據，優勢尤為明顯。同時，在可用性方面也有明顯的改善。

即使數據庫服務器出現短時間的故障，緩存服務器中保存的熱點或者核心數據依舊可以滿足用戶暫時的訪問。當然，后面還會對可用性進行優化。

服務器集群的加入

經過前面三個階段的演進，系統對用戶的請求量有了很好的支持。實際上，這都是在解決高性能和可用性的問題，這一核心問題會一直貫穿整個系統架構的演進過程中。

隨著用戶請求量的增加，另外一個問題又出現了，那就是并發。把這兩個字拆開了來看：并，理解為“一起并行“，有同時的意思;發，理解為“發出調用”，也就是請求的意思。

合起來就是多個用戶同時請求應用服務器。如果說原來的系統面對的僅僅只是大數據量的話，那么現在就需要面對多用戶同時請求。

如果還是按照上一個階段的架構圖推導，單個應用服務器已經無法滿足高并發的要求了。

此時，服務器集群就加入戰場了

（編輯：武林網）