原文來自https://www.cnblogs.com/netoxi/p/7258895.html
如何打造一個高可用、高性能、易擴展、可伸縮且安全的網站？如何讓網站應用所需靈活變動，即時是山寨他人的產品，也可以山寨的更高、更快、更強，一年時間用戶數從零過億呢？對此我總結一下：
1.1 大型網站軟件系統的特點
- 高併發，大流量;
- 高可用：系統7*24小時不間斷服務；
- 海量數據：存儲、管理海量數據；需要使用大量服務器；
- 用戶分佈廣泛，網絡情況複雜；許多大型互聯網都是爲全球用戶提供服務的，用戶分佈範圍廣，各地網絡情況千差萬別；
- 安全環境惡劣；由於互聯網的開放性，使得互聯網更容易受到攻擊，大型網站幾乎每天都會被黑客攻擊；
- 需求快速變更，發佈頻繁；和傳統軟件的版本發佈頻率不同，互聯網產品爲快速適應市場，滿足用戶需求，其產品發佈頻率是極高的；
- 漸進式發展：與傳統軟件產品或企業應用系統一開始就規劃好全部的功能和非功能需求不同，幾乎所有的大型互聯網網站都是從一個小網站開始，漸進地發展起來的。
1.2 大型網站架構演化發展歷程
初始階段的網站架構：
需求/解決問題：
小型網站最開始沒有什麼人訪問；
架構：
應用程序、數據庫、文件等所有資源都在一臺服務器上；
應用服務與數據服務分離：
需求/解決問題：
網站業務發展，一臺服務器無法滿足要求；越來越多用戶訪問導致性能變差；越來越多的數據導致存儲空間不足
架構：
應用和數據分離，採用三臺服務器：應用服務器，文件服務器，數據庫服務器；應用服務器處理大量業務邏輯，需要更快更強大的CPU；數據庫服務器快速磁盤檢索和數據緩存，需要更快的磁盤和更大的內存；文件服務器存儲大量用戶上傳的文件，需要更大的磁盤。
使用緩存改善網站性能：
需求/解決問題：
用戶逐漸增多，數據庫壓力太大導致訪問延遲。
架構：
根據二八定律：80%的業務訪問集中在20%的數據上，把小部分數據緩存在內存中，可減少數據庫訪問壓力。
類型 | 原理 | 優點 | 缺點 |
本地緩存 | 緩存在應用服務器 | 訪問速度更快 | 受應用服務器內存限制 |
分佈式緩存 | 部署大內存緩存服務器集羣 | 理論上不受內存容量限制 | -- |
使用應用服務器集羣改善網站的併發處理能力：
需求/解決問題：
單一服務器處理的連接請求有限；
架構：
通過負載均衡調度服務器，可將來自用戶瀏覽的訪問請求分發到應用服務器集羣中的任何一臺服務器上，實現系統的可伸縮性。
數據庫讀寫分離：
需求/解決問題：
一部分讀操作（緩存訪問不命中、緩存過期）和全部的寫操作需要訪問數據庫。
架構：
應用服務器寫數據時，訪問主數據庫，主數據庫通過主從複製機制將數據更新同步到從數據庫；當應用服務器讀數據時，可通過從數據庫獲得數據。通常在應用服務器端使用專門的數據訪問模塊，使數據庫讀寫分離對應用透明。
使用反向代理和CDN加速網站響應：
需求/解決問題：
中國網絡環境複雜，不同地區的用戶訪問網站時，速度差別極大，網站訪問延遲導致用戶流失率提高。
架構：
CDN和反向代理目的都是儘早返回數據、加快訪問速度、減輕後端服務器負載壓力。
1. CDN：部署在網絡提供商機房。用戶請求網站服務時，可從距離自己最近的網絡提供商機房獲取數據。
2. 反向代理：部署在網站中心機房。用戶請求到達中心機房後，首先訪問反向代理服務器，如果反向代理服務器緩存着用戶請求的資源，就將其直接返回給用戶。
使用分佈式文件系統和分佈式數據庫：
需求/解決問題：
讀寫分離伸縮性有限。
架構：
只有在單表數據規模非常龐大的時候（不到萬不得已）才數據庫拆分，按業務分庫，不同的業務數據部署在不同的物理服務器上；
使用分佈式文件系統和分佈式數據庫：
需求/解決問題：
隨着網站業務越來越複雜，對數據存儲和檢索的需求也越來越複雜；
架構：
1. NoSQL和搜索引擎都是源自互聯網的技術手段，可伸縮的分佈式特性更好；
2. 應用服務器通過一個統一數據訪問模塊訪問各種數據。
業務拆分：
需求/解決問題：
業務場景日益複雜。
架構：
1. 將整個網站業務分成不同產品線（如大型購物交易網站拆分爲首頁、商鋪、訂單、買家、賣家），分歸不同業務團隊負責。
2. 根據產品線劃分，將網站拆分成不同應用，每個應用獨立部署維護。應用間關聯方式：
a) 超鏈接（首頁上導航鏈接每個應用地址）；
b) 通過消息隊列進行數據分發；
c) 通過同一數據存儲系統構成一個關聯的完整系統（最多）。
分佈式服務：
需求/解決問題：
所有應用要和所有數據庫系統鏈接，在數萬臺服務器規模的網站中，連接數目時服務器規模的平方，導致數據庫連接資源不足，拒絕服務。
架構：
將共用的業務提取出服務，獨立部署。
