淺談Web架構之演化過程

前言

最近在開發過程中，遇到很多緩解配置的問題，工程很難啟動，也不知道為什麼環境需要這麼多配置的意義。就在這個時候，一本好書《大型網站技術：核心原理與案例分析》給我帶來全新視角，必須強勢安利一把。連結地址

本文先淺談書中所提到的web架構演化過程。如果經歷的專案足夠多，是會深有體會的。

大型網站特點

• 1.高併發，大流量
• 2.高可用
• 3.海量資料
• 4.使用者分佈廣泛，網路情況複雜
• 5.安全環境惡劣
• 6.需求快速變更，釋出頻繁，產品釋出頻率是極高的
• 7.漸進式發展。好的網際網路產品都是慢慢運營出來的，不是一開始就開發好的。

演化過程

初始階段

一臺伺服器就綽綽有餘。

伺服器作業系統用Linux，應用程式使用PHP開發，部署在apache上，資料庫使用Mysql。彙集各種免費開源軟體及一臺廉價伺服器就可以開始網站的發展之路了。

回想起自己在學校做過的專案，差不多就是這麼個級別。

應用服務和資料服務分離

三臺伺服器：應用伺服器、檔案伺服器和資料庫伺服器。

應用伺服器需要處理大量的邏輯，所以需要強大的CPU；
資料庫伺服器需要快速磁碟檢索和資料快取，所以需要更大的記憶體和更快的硬碟；
檔案伺服器需要儲存大量使用者上傳的檔案，所以需要更大的硬碟。

使用快取改善網站效能

隨著使用者量逐漸增大，資料庫壓力太大導致訪問延遲，進而影響整個網站的效能。需要進行改進。

先了解下二八定律：80%的業務訪問集中在20%的資料上。所以我們可以把這一小部分資料快取在記憶體中，從而減小資料庫的訪問壓力。

快取分為兩種：快取在應用伺服器上的本地快取和快取在專門的分散式伺服器上的遠端快取。本地快取的訪問速度更快，但是受應用伺服器記憶體限制，資料大小有限。遠端快取可以以叢集的方式，部署大記憶體的伺服器作為專門的快取伺服器。

這也就是為什麼開發過程中測試環境釋出了之後，前端資源有可能未立即奏效的原因。伺服器設定了本地快取，需要待其過期才行。至於瀏覽器端的HTTP快取，可以看看這篇文章

應用伺服器叢集改善併發能力

網站效能得到解決後，在網站訪問高峰期，應用伺服器成為整個網站的瓶頸。

對於網站架構而言，只要能通過增加一臺伺服器的方式改善負載壓力，就可以以同樣的方式持續增加伺服器不斷改善系統效能，從而實現系統的可伸縮性。

通過負載均衡排程伺服器，進行負載均衡。如果很更多的使用者，就在叢集中加入更多的應用伺服器，使應用伺服器的負載壓力不再成為整個網站的瓶頸。

至於負載均衡有哪些方式，以後會具體講到。

資料庫讀寫分離

使用快取後，還是有一部分讀操作和所有的寫操作需要經過資料庫伺服器。使用者達到一定規模後，資料庫因為負載壓力過高會成為網站的瓶頸。

利用主流資料庫自帶的主從熱備功能，通過配置兩臺資料庫主從關係，可以將一臺資料庫伺服器的資料更新同步到另一臺伺服器上，從而實現讀寫分離。

使用反向代理和CDN加速網站響應

CDN和反向代理的基本原理都是快取，區別在於CDN部署在網路提供商的機房，使使用者在請求網站服務時，可以從距離自己最近的網路提供商機房獲取資料；

而反向代理則部署在網站的中心機房，當使用者請求到達中心機房後，首先訪問的伺服器是反向代理伺服器，而如果，就將其直接返回給使用者。

使用分散式檔案系統和分散式資料庫系統

分散式資料庫是網站資料庫拆分的最後手段，只有在單表資料規模非常龐大的時候才使用。不到萬不得已的時候，網站更加常用的資料庫拆分手段是業務分庫，將不同業務的資料庫部署在不同的物理伺服器上。

使用NoSQL和搜尋引擎

隨著業務越來越複雜，對資料儲存和檢索的需求也越來越複雜。

業務拆分

大型網站為了應對日益複雜的業務場景，通過使用分而治之的手段將整個網站業務分為不同的產品線，分歸不同的業務團隊負責。
各應用之間可以通過一個超連結建立關係，也可以通過訊息佇列進行資料分發，當然最多的還是通過訪問同一資料儲存系統來構成一個關聯的完整系統。

分散式服務

如果伺服器資料過多，各種連線關係會很複雜，資料庫連線資源不足，拒絕服務。

每一個應用系統都需要執行許多相同的業務操作，比如使用者管理、商品管理等。那麼可以將這些共用的業務提取出來，獨立部署。由這些可複用的業務連線資料庫，提供共用業務服務，而應用系統只需要管理使用者介面，通過分散式服務呼叫共用業務服務完成具體業務操作。

像筆者所處的開發部門，就把訂單流程、登陸等功能單獨抽出作為公共服務，這樣移動端、PC端都可以呼叫複用服務。

小結

本文只是簡單的說了下書中所講到的網站發展過程的基本流程。但是筆者觀望下自己所處的環境，發現既然全部都有用到。說明實用性確實很強。值得學習。