網站架構方法

架構即權衡

事物是發展變化的，事物的發展是一個過程。時間上，事物的發展過程呈現階段性特徵；空間上，每一個階段必然有不一樣的具體業務場景。

故從時空觀來看，網站架構方法大體不外乎兩種：

• 時間上：分階段看待

• 空間上：分場景處理

對於架構而言，沒有銀彈，只有trade-off。架構師則須要階段性場景化思考，而後權衡利弊，解決問題。

問題描述

任何大的事物必然都是從小事物發展起來的，當系統業務足夠簡單時，實現一個網站架構只須要一些通用的解決方案，如早期的LAMP架構，如現今的雲開發模式以及無服務架構。

做爲人與機器的『中間人』- 程序員，負責把業務需求轉換成業務代碼與數據。隨着業務的發展以及需求不斷迭代與豐富，網站系統的複雜度天然從低到高轉變，網站的量（包括用戶量和數據量）從小到大，從大量到海量，網站的類型（包括用戶操做類型與數據類型）從單純到豐富。程序員在負責『翻譯』工做的同時，則還須要解決這些增加過程當中出現的各類問題，保證整個組織實現又好又快發展。

解決問題是工程師的天職，更是程序員的宿命。Ta須要解決當下業務發展中遇到的問題，更須要解決將來業務發展規模化的問題。

即程序員歸根結底解決的是變化這個命題，細分到具體操做層面也能夠分爲下面三類：

1. 解決業務變化問題： 

• 從簡單到複雜，保證系統高可用 - 分層&解耦&冗餘

• 從存量到增量，保證系統可伸縮與可擴展 - 集羣/分佈式/分佈式集羣

1. 解決用戶變化問題，保證系統高併發 - 單機C10K-》集羣-》分佈式-》分佈式集羣

2. 解決數據變化問題：保證系統高性能 - 緩存

• 從量少到量多

• 從單一類型到混合類型

解決方法

拋開編程語言與具體框架的細節，這裏只討論方法。簡單的問題可單槍匹馬，複雜的問題則須要分而治之。下面將從分與治兩個方面來討論具體的網站架構方法。

1）分

空間上，分這個動做能夠分爲兩類：

• 垂直劃分：分層

• 水平劃分：分割

1.1）分層

面對複雜問題時，第一步要想到的就是分層。

當網站發展到必定規模，單一的通用架構已沒法處理這種複雜性，這時架構分層不可避免。

分層的概念在網絡協議上表現的淋漓盡致，經過將一個數據傳輸任務劃分爲多個層級，下層向上層提供完整抽象，每層各司其職。網站系統也可將系統在縱向維度上切分紅幾個部分，每一部分專一於某一方面，職責相對單一，邏輯清晰，而後經過上層對下層的依賴和調用組成一個完整的系統。根據網站系統的職能，大體能夠分爲四層：

• 表示層：網站的UI展現，負責用戶與網站系統的交互。

• 應用層：主要負責具體業務邏輯處理。調用下層服務實現業務需求。

• 服務層：負責爲應用層提供細粒度的業務服務。

• 數據層：負責爲服務層提供數據存儲與訪問。

1.2）分割

當網站規模進一步擴大，功能愈加繁多複雜，服務和數據處理的種類也愈來愈多，這時針對每層進行更爲細粒度的劃分-垂直分割勢在必行。如在服務層，可根據不一樣業務場景進行分割，如將整個電商服務拆分出訂單服務，支付服務，商品服務等；如在數據層，可根據數據類型將數據分爲文本、圖片、視頻、日誌等類型數據，而後針對每一種類型的數據採用適合的存儲結構或服務：文本類型數據使用數據庫存儲；圖片/視頻使用CDN存儲；日誌類型數據使用ES存儲等等。

將這些不一樣功能/類型的服務/數據分割開來，封裝成高內聚低耦合的模塊單元，一方面有助於下降系統的複雜度，減小軟件的開發和維護成本；另外一方面，也便於不一樣模塊的分佈式部署，提升網站的併發處理能力和可伸縮、可擴展能力。

2）治

分完以後下一步則是治之。

2.1）解耦

分層和分割以後的模塊間必然存在依賴關係，即必然存在耦合。解耦是一種理想狀態，理論上相互聯繫的模塊間耦合度不能爲零，可是耦合度能夠下降，即所謂的解耦。

2.1.1）異步化：時間形式上的解耦

耦合的模塊之間存在鏈接，有鏈接在某個時刻就可能會引發阻塞（存在等待的場景）。爲了減小這種模塊之間阻塞問題，提升效率，能夠將一個流程或一條業務線操做分紅多個階段，每一個階段之間經過共享數據（即消息隊列或緩衝區）的方式進行協做，這就是異步化。

異步架構是典型的生產者-消費者模式，二者不存在直接調用，而是經過緩衝區進行通訊，彼此功能實現能夠隨意變化而不互相影響，這對大大提升了網站的性能與可擴展性。

2.1.2）分佈式：空間形式上的解耦

解耦是爲了適應網站日益增加的複雜業務需求，解耦以後的下一步則是將切分後的模塊分佈式部署，即將不一樣模塊部署在不一樣的服務器上，經過遠程調用協同工做，這將進一步提升網站的性能與擴展性。

2.2）併發

用戶量激增，網站併發成爲瓶頸。

I/O多路複用解決了經典的C10K問題（如Nginx，Redis都是典型應用），此時咱們不得不將目光從單機投向集羣，從集羣投向分佈式，從分佈式投向分佈式集羣，以尋求更大範圍的併發。

相對於單機，集羣提高了網站的可伸縮性（指經過不斷地向集羣中加入服務器的手段來緩解不斷上升的用戶併發訪問壓力和不斷增加的數據存儲需求）；分佈式（部署）提高了網站的可擴展性（指網站不須要任何改動或者不多改動既有業務功能就能夠上線新的業務產品的能力）。在綜合了最優網絡I/O模型與分佈式和集羣的優點下，網站的高併發成爲可能。

注：解耦在下降系統複雜度的同時也爲更好地系統實現高併發創造了條件：分佈式場景。

2.3）緩存

緩存的依據是網站訪問數據的特色大致呈現二八定律：80%的業務訪問集中在20%的數據上。因此，一旦遭遇網站的數據訪問性能問題時，首先想到的就是加緩存。

緩存的世界有這麼一句話：有數據的地方就能夠有緩存。從這個角度講，再擴大一點範圍：凡是位於速度相差較大的兩種介質之間，用於協調二者數據傳輸差別的結構，都可稱爲緩存。按照這個概念，只有兩種介質之間存在傳輸速率差，速率較高的一方便可做爲較低方的緩存。

在網站的世界，每一層皆可緩存。以PHP應用爲例：底層有磁盤文件緩存、CPU緩存；應用層有Zend虛擬機緩存、APC緩存等；數據層有資源文件緩存（CDN）、數據緩存（如Redis/Memcache）等。

2.4）冗餘備份：有備無患

實現高可用網站架構的主要手段是：數據和服務的冗餘備份及失效轉移。有備則無患，如數據庫除了按期備份，存檔保持，實現冷備份以外，爲了保證在線業務高可用，還須要對數據庫進行主從分離，實現同步實現熱備份。 一旦某些服務器宕機，就將服務切換到其餘可用的服務器上，若是磁盤損壞，則從備份的磁盤讀取數據。

總結

本文介紹了網站架構中經常使用的一些方法論與手段，皆是從平常實際工做項目中的積累與沉澱，看上去有點理論有點虛，但十分有指導意義。軟件的世界裏沒有好壞，只有優劣，而架構師追求的永遠是業務上的性價比。