每一個模式描述了一個在我們周圍不斷髮生的問題及該問題解決方案的核心。這樣，你就能一次又一次地使用該方案而不必做重複的工作。-- 什麼是模式？

也許網際網路產品不是隨便複製就能成功的，創新的產品更能為使用者創造價值。但是網站架構卻有一些共同的模式，這些模式已經被許多大型網站一再驗證，通過對這些模式的學習，我們可以掌握大型網站架構的一般思路和解決方案，以指導我們的架構設計。

1.網站架構模式

為了解決大型網站面臨的高併發訪問、海量資料處理、高可靠執行等一系列問題與挑戰，大型網際網路公司在實踐中提出了許多解決方案，以實現網站高效能、高可用、易伸縮、可擴充套件、安全等各種技術架構目標。這些解決方案又被更多網站重複使用，從而逐漸形成大型網站架構模式。

1.1 分層

分層是企業應用系統中最常見的一種架構模式，將系統在橫向維度上切分成幾個部分，每個部分負責一部分相對比較單一的職責，然後通過上層對下層的依賴和呼叫組成個完整的系統。
分層結構在計算機世界中無處不在，網路的7層通訊協議是一種分層結構；計算機硬體、作業系統、應用軟體也可以看作是一種分層結構。在大型網站架構中也採用分層結構，將網站軟體系統分為應用層、服務層、資料層，如下所示。

通過分層，可以更好地將一個龐大的軟體系統切分成不同的部分，便於分工合作開發和維護；各層之間具有一定的獨立性，只要維持呼叫介面不變，各層可以根據具體問題獨立演化發展而不需要其他層必須做出相應調整。
但是分層架構也有一些挑戰，就是必須合理規劃層次邊界和介面，在開發過程中嚴格遵循分層架構的約束，禁止跨層次的呼叫（應用層直接呼叫資料層）及逆向呼叫（資料層呼叫服務層，或者服務層呼叫應用層）在實踐中，大的分層結構內部還可以繼續分層，如應用層可以再細分為檢視層（美工負責）和業務邏輯層（工程師負責）；服務層也可以細分為資料介面層（適配各種輸入和輸出的資料格式）和邏輯處理層。
分層架構是邏輯上的，在物理部署上，三層結構可以部署在同一個物理機器上，但是隨著網站業務的發展，必然需要對已經分層的模組分離部署，即三層結構分別部署在不同的伺服器上，使網站擁有更多的計算資源以應對越來越多的使用者訪問。所以雖然分層架構模式最初的目的是規劃軟體清晰的邏輯結構便於開發維護，但在網站的發展過程中，分層結構對網站支援高併發向分散式方向發展至關重要。因此在網站規模還很小的時候就應該採用分層的架構，這樣將來網站做大時才能有更好地應對。

1.2 分割

如果說分層是將軟體在橫向方面進行切分，那麼分割就是在縱向方面對軟體進行切分。
網站越大，功能越複雜，服務和資料處理的種類也越多，將這些不同的功能和服務分割開來，包裝成高內聚低耦合的模組單元，一方面有助於軟體的開發和維護；另一方面，便於不同模組的分散式部署，提高網站的併發處理能力和功能擴充套件能力。

大型網站分割的粒度可能會很小。比如在應用層，將不同業務進行分割，例如將購物、論壇、搜尋、廣告分割成不同的應用，由獨立的團隊負責，部署在不同的伺服器上；在同一個應用內部，如果規模龐大業務複雜，會繼續進行分割，比如購物業務，可以進一步分割成機票酒店業務、3C業務，小商品業務等更細小的粒度。而即使在這個粒度上，還是可以繼續分割成首頁、搜尋列表、商品詳情等模組，這些模組不管在邏輯上還是物理部署上，都可以是獨立的。同樣在服務層也可以根據需要將服務分割成合適的模組。

1.3 分散式

對於大型網站，分層和分割的一個主要目的是為了切分後的模組便於分散式部署，即將不同模組部署在不同的伺服器上，通過遠端呼叫協同工作。分散式意味著可以使用更多的計算機完成同樣的功能，計算機越多，CPU、記憶體、儲存資源也就越多，能夠處理的併發訪問和資料量就越大，進而能夠為更多的使用者提供服務。
但分散式在解決網站高併發問題的同時也帶來了其他問題。首先，分散式意味著服務呼叫必須通過網路，這可能會對效能造成比較嚴重的影響；其次，伺服器越多，伺服器宕機的概率也就越大，一臺伺服器宕機造成的服務不可用可能會導致很多應用不可訪問，使網站可用性降低；另外，資料在分散式的環境中保持資料一致性也非常困難，分
布式事務也難以保證，這對網站業務正確性和業務流程有可能造成很大影響；分散式還導致網站依賴錯綜複雜，開發管理維護困難。因此分散式設計要根據具體情況量力而行，切莫為了分散式而分散式。
在網站應用中，常用的分散式方案有以下幾種。

• 分散式應用和服務：將分層和分割後的應用和服務模組分散式部署，除了可以改善網站效能和併發性、加快開發和釋出速度、減少資料庫連線資源消耗外；還可以使不同應用複用共同的服務，便於業務功能擴充套件。

• 分散式靜態資源：網站的靜態資源如 Js，CSS，Logo 圖片等資源獨立分散式部署，並採用獨立的域名，即人們常說的動靜分離。靜態資源分散式部署可以減輕應用伺服器的負載壓力；通過使用獨立域名加快瀏覽器併發載入的速度；由負責使用者體驗的團隊進行開發維護有利於網站分工合作，使不同技術工種術業有專攻。

• 分散式資料和儲存：大型網站需要處理以P為單位的海量資料，單臺計算機無法提供如此大的儲存空間，這些資料需要分散式儲存。除了對傳統的關係資料庫進行分散式部署外，為網站應用而生的各種 NOSQL 產品幾乎都是分散式的。

• 分散式計算：嚴格說來，應用、服務、實時資料處理都是計算，網站除了要處理這些線上業務，還有很大一部分使用者沒有直觀感受的後臺業務要處理，包括搜尋引擎的索引構建、資料倉庫的資料分析統計等。這些業務的計算規模非常龐大，目前網站普遍使
  用 Hadoop 及其 MapReduce 分散式計算框架進行此類批處理計算，其特點是移動計算而不是移動資料，將計算程式分發到資料所在的位置以加速計算和分散式計算。

此外，還有可以支援網站線上伺服器配置實時更新的分散式配置；分散式環境下實現併發和協同的分散式鎖；支援雲端儲存的分散式檔案系統等。

1.4 叢集

使用分散式雖然已經將分層和分割後的模組獨立部署，但是對於使用者訪問集中的模組(比如網站的首頁)，還需要將獨立部署的伺服器叢集化，即多臺伺服器部署相同應用構成一個叢集，通過負載均衡裝置共同對外提供服務。
因為伺服器叢集有更多伺服器提供相同服務，因此可以提供更好的併發特性，當有更多使用者訪問的時候，只需要向叢集中加入新的機器即可。同時因為一個應用由多臺伺服器提供，當某臺伺服器發生故障時，負載均衡裝置或者系統的失效轉移機制會將請求轉發到叢集中其他伺服器上，使伺服器故障不影響使用者使用。所以在網站應用中，即使是訪問量很小的分散式應用和服務，也至少要部署兩臺伺服器構成一個小的叢集，目的就是提高系統的可用性。

1.5 快取

快取就是將資料存放在距離計算最近的位置以加快處理速度。快取是改善軟體效能的第一手段，現代CPU越來越快的一個重要因素就是使用了更多的快取，在複雜的軟體設計中，快取幾乎無處不在。大型網站架構設計在很多方面都使用了快取設計。

• CDN：即內容分發網路，部署在距離終端使用者最近的網路服務商，使用者的網路請求總是先到達他的網路服務商那裡，在這裡快取網站的一些靜態資源（較少變化的資料），可以就近以最快速度返回給使用者，如視訊網站和入口網站會將使用者訪問量大的熱點內容快取在CDN。

• 反向代理：反向代理屬於網站前端架構的一部分，部署在網站的前端，當用戶請求到達網站的資料中心時，最先訪問到的就是反向代理伺服器，這裡快取網站的靜態資源，無需將請求繼續轉發給應用伺服器就能返回給使用者。

• 本地快取：在應用伺服器本地快取著熱點資料，應用程式可以在本機記憶體中直接訪問資料，而無需訪問資料庫。

• 分散式快取：大型網站的資料量非常龐大，即使只快取一小部分，需要的記憶體空間也不是單機能承受的，所以除了本地快取，還需要分散式快取，將資料快取在一個專門的分散式快取叢集中，應用程式通過網路通訊訪問快取資料。

使用快取有兩個前提條件，一是資料訪問熱點不均衡，某些資料會被更頻繁的訪問，這些資料應該放在快取中；二是資料在某個時間段內有效，不會很快過期，否則快取的資料就會因已經失效而產生髒讀，影響結果的正確性。網站應用中，快取除了可以加快資料訪問速度，還可以減輕後端應用和資料儲存的負載壓力，這一點對網站資料庫架構至關重要，網站資料庫幾乎都是按照有快取的前提進行負載能力設計的。

1.6 非同步

計算機軟體發展的一個重要目標和驅動力是降低軟體耦合性。事物之間直接關係越少，就越少被彼此影響，越可以獨立發展。大型網站架構中，系統解耦合的手段除了前面提到的分層、分割、分佈等，還有一個重要手段是非同步，業務之間的訊息傳遞不是同步呼叫，而是將一個業務操作分成多個階段，每個階段之間通過共享資料的方式非同步執行進行協作。
在單一伺服器內部可通過多執行緒共享記憶體佇列的方式實現非同步，處在業務操作前面的執行緒將輸出寫入到佇列，後面的執行緒從佇列中讀取資料進行處理；在分散式系統中，多個伺服器叢集通過分散式訊息佇列實現非同步，分散式訊息佇列可以看作記憶體佇列的分散式部署。
非同步架構是典型的生產者消費者模式，兩者不存在直接呼叫，只要保持資料結構不變，彼此功能實現可以隨意變化而不互相影響，這對網站擴充套件新功能非常便利。除此之外，使用非同步訊息佇列還有如下特性。

• 提高系統可用性。消費者伺服器發生故障，資料會在訊息佇列伺服器中儲存堆積，生產者伺服器可以繼續處理業務請求，系統整體表現無故障。消費者伺服器恢復正常後，繼續處理訊息佇列中的資料。

• 加快網站響應速度。處在業務處理前端的生產者伺服器在處理完業務請求後，將資料寫入訊息佇列，不需要等待消費者伺服器處理就可以返回，響應延遲減少。

• 消除併發訪問高峰。使用者訪問網站是隨機的，存在訪問高峰和低谷，即使網站按照般訪問高峰進行規劃和部署，也依然會出現突發事件，比如購物網站的促銷活動，微博上的熱點事件，都會造成網站併發訪問突然增大，這可能會造成整個網站負載過重，響應延遲，嚴重時甚至會出現服務宕機的情況。使用訊息佇列將突然增加的訪問請求資料放入訊息佇列中，等待消費者伺服器依次處理，就不會對整個網站負載造成太大壓力。

但需要注意的是，使用非同步方式處理業務可能會對使用者體驗、業務流程造成影響，需要網站產品設計方面的支援。

1.7 冗餘

網站需要7×24小時連續執行，但是伺服器隨時可能出現故障，特別是伺服器規模比較大時，出現某臺伺服器宕機是必然事件。要想保證在伺服器宕機的情況下網站依然可以繼續服務，不丟失資料，就需要一定程度的伺服器冗餘執行，資料冗餘備份，這樣當某臺伺服器宕機時，可以將其上的服務和資料訪問轉移到其他機器上。
訪問和負載很小的服務也必須部署至少兩臺伺服器構成一個叢集，其目的就是通過冗餘實現服務高可用。資料庫除了定期備份，存檔儲存，實現冷備份外，為了保證線上業務高可用，還需要對資料庫進行主從分離，實時同步實現熱備份。
為了抵禦地震、海嘯等不可抗力導致的網站完全癱瘓，某些大型網站會對整個資料中心進行備份，全球範圍內部署災備資料中心。網站程式和資料實時同步到多個災備資料中心。

1.8 自動化

在無人值守的情況下網站可以正常執行，一切都可以自動化是網站的理想狀態。目前大型網站的自動化架構設計主要集中在釋出運維方面。
釋出對網站都是頭等大事，許多網站故障出在釋出環節，網站工程師經常加班也是因為釋出不順利。通過減少人為干預，使釋出過程自動化可有效減少故障。釋出過程包括諸多環節。自動化程式碼管理，程式碼版本控制、程式碼分支建立合併等過程自動化，開發工程師只要提交自己參與開發的產品代號，系統就會自動為其建立開發分支，後期會自
動進行程式碼合併；自動化測試，程式碼開發完成，提交測試後，系統自動將程式碼部署到測試環境，啟動自動化測試用例進行測試，向相關人員傳送測試報告，向系統反饋測試結果；自動化安全檢測，安全檢測工具通過對程式碼進行靜態安全掃描及部署到安全測試環境進行安全攻擊測試，評估其安全性；最後進行自動化部署，將工程程式碼自動部署到線上生產環境。
此外，網站在執行過程中可能會遇到各種問題：伺服器宕機、程式Bug、儲存空間不足、突然爆發的訪冋高峰。網站需要對線上生產環境進行自動化監控，對伺服器進行心跳檢測，並監控其各項效能指標和應用程式的關鍵資料指標。如果發現異常、超出預設的閾值，就進行自動化報警，向相關人員傳送報警資訊，警告故障可能會發生。在檢測到故障發生後，系統會進行自動化失效轉移，將失效的伺服器從叢集中隔離出去，不再處理系統中的應用請求。待故障消除後，系統進行自動化失效恢復，重新啟動服務，同步資料保證資料的一致性。在網站遇到訪問高峰，超出網站最大處理能力時，為了保證整個網站的安全可用，還會進行自動化降級，通過拒絕部分請求及關閉部分不重要的服務將系統負載降至一個安全的水平，必要時，還需要自動化分配資源，將空閒資源分配給重要的服務，擴大其部署規模。

1.9 安全

網際網路的開放特性使得其從誕生起就面對巨大的安全挑戰，網站在安全架構方面也積累了許多模式：通過密碼和手機校驗碼進行身份認證；登入、交易等操作需要對網路通訊進行加密，網站伺服器上儲存的敏感資料如使用者資訊等也進行加密處理；為了防止機器人程式濫用網路資源攻擊網站，網站使用驗證碼進行識別；對於常見的用於攻擊網站的 XSS 攻擊、SQL 注入、進行編碼轉換等相應處理；對於垃圾資訊、敏感資訊進行過濾；對交易轉賬等重要操作根據交易模式和交易資訊進行風險控制。

2.架構模式在新浪微博的應用

短短几年時間新浪微博的使用者數就從零增長到數億，明星使用者的粉絲數達數千萬圍繞著新浪微博正在發展一個集社交、媒體、遊戲、電商等多位一體的生態系統。同大多數網站一樣，新浪微博也是從一個小網站發展起來的。簡單的LAMP（Linux+ Apache+ MySQL+PHP）架構，支撐起最初的新浪微博，應用序用PHP開發，所有的資料，包括微博、使用者、關係都儲存在 MySQL資料庫中。

這樣簡單的架構無法支撐新浪微博快速發展的業務需求，隨著訪問使用者的逐漸增加，系統不堪重負。新浪微博的架構在較短時間內幾經重構，最後形成現在的架構，如圖所示。

系統分為三個層次，最下層是基礎服務層，提供資料庫、快取、儲存、搜尋等資料服務，以及其他一些基礎技術服務，這些服務支撐了新浪微博的海量資料和高併發訪問，是整個系統的技術基礎。
中間層是平臺服務和應用服務層，新浪微博的核心服務是微博、關係和使用者，它們是新浪微博業務大廈的支柱。這些服務被分割為獨立的服務模組，通過依賴呼叫和共享基礎資料構成新浪微博的業務基礎。
最上層是API和新浪微博的業務層，各種客戶端(包括Web網站)和第三方應用，通過呼叫AP整合到新浪微博的系統中，共同組成一個生態系統。
這些被分層和分割後的業務模組與基礎技術模組分散式部署，每個模組都部署在組獨立的伺服器叢集上，通過遠端呼叫的方式進行依賴訪問。新浪微博在早期還使用過一種叫作 MPSS（MultiPort Single Server，單伺服器多埠）的分散式叢集部署方案，在叢集中的多臺伺服器上，每臺都部署多個服務，每個服務使用不同的埠對外提供服務，通過這種方式使得有限的伺服器可以部署更多的服務例項，改善服務的負載均衡和可用性。現在網站應用中常見的將物理機虛擬化成多個虛擬機器後，在虛擬機器上部署應用的方案跟新浪微博的 MPSS 方案異曲同工，只是更加簡單，還能在不同虛擬機器上使用相同的埠號。

在新浪微博的早期架構中，微博釋出使用同步推模式，使用者發表微博後系統會立即將這條微博插入到資料庫所有粉絲的訂閱列表中，當用戶量比較大時，特別是明星使用者釋出微博時，會引起大量的資料庫寫操作，超出資料庫負載，系統性能急劇下降，使用者響應延遲加劇。後來新浪微博改用非同步推拉結合的模式，使用者發表微博後系統將微博寫
入訊息佇列後立即返回，使用者響應迅速，訊息佇列消費者任務將微博推送給所有當前線上粉絲的訂閱列表中，非線上使用者登入後再根據關注列表拉取微博訂閱列表。

由於微博頻繁重新整理，新浪微博使用多級快取策略，熱門微博和明星使用者的微博快取在所有的微博伺服器上，線上使用者的微博和近期微博快取在分散式快取叢集中，對於微博操作中最常見的“刷微博“操作，幾乎全部都是快取訪問操作，可以獲得很好的系統性能。
為了提高系統的整體可用性和效能，新浪微博啟用了多個數據中心。這些資料中心既是地區使用者訪問中心，使用者可以就近訪問最近的資料中心以加快訪問速度，改善系統性能；同時也是資料冗餘複製的災備中心，所有的使用者和微博資料通過遠端訊息系統在不同的資料中心之間同步，提高系統可用性。
同時，新浪微博還開發了一系列自動化工具，包括自動化監控，自動化釋出，自動化故障修復等，這些自動化工具還在持續開發中，以改善運維水平提高系統可用性。
由於微博的開放特性，新浪微博也遇到了一系列的安全挑戰，垃圾內容、殭屍粉、微博攻擊從未停止，除了使用一般網站常見的安全策略，新浪微博在開放平臺上使用多級安全稽核的策略以保護系統和使用者。

3.小結

在程式設計與架構設計領域，模式正變得越來越受人關注，許多人寄希望通過模式一勞永逸地解決自己的問題。正確使用模式可以更好地利用業界和前人的思想與實踐，用更少的時間開發出更好的系統，使設計者的水平也達到更高的境界。但是模式受其適用場景限制，對系統的要求和約束也很多，不恰當地使用模式只會畫虎不成反類犬，不
但沒有解決原來的老問題，反而帶來了更棘手的新問題。
好的設計絕對不是模仿，不是生搬硬套某個模式，而是對問題深刻理解之上的創造與創新，即使是“微創新”，也是讓人耳目一新的似曾相識。山寨與創新的最大區別不在於是否抄襲，是否模仿，而在於對問題和需求是否真正理解與把握。

參考資料

[1]《大型網站技術架構 核心原理與案例分析》李智