反向代理和CDN加速網站響應使用反向代理和CDN加速網站響應：CDN 和反向代理的基本原理都是緩存，區別在於：CDN部署在網絡提供商的機房；反向代理則部署在網站的中心機房；使用 CDN 和反向代理的目的都是盡早返回數據給用戶，一方面加快用戶訪問速度，另一方面也減輕後端服務器的負載壓力。使用反向代理和 CDN 加速網站響應優點：減輕應用負載壓力，異地緩存有效解決不同地方用戶訪問過慢的問題；缺點：成本大幅增加，架構進一步復雜化，也維護難度進一步增大，靜態文件緩存更新失效問題；技術點：CDN、反向代理方案；使用NoSQL和搜索引擎到這裡，已經基本做到瞭DB層面和應用層面的橫向擴展瞭，可以開始關註一些其它方面，例如：站內搜索的精準度，對DB的依賴，開始引入全文索引、NoSQL。NoSQL和搜索引擎都是源自互聯網的技術手段，對可伸縮的分佈式特性具有更好的支持。應用服務器則通過一個統一數據訪問模塊訪問各種數據，減輕應用程序管理諸多數據源的麻煩。使用NoSQL和搜索引擎優點：降低DB依賴；缺點：單點問題，談不上高可用；技術點：NoSQL、搜索引擎、分佈式；到目前為止，一個能夠承載日均百萬級訪問量的中型網站架構基本介紹完瞭。如何保證高可用在做擴展滿足瞭基本的性能需求後，我們會逐漸關註“可用性”（也就是我們通常聽別人吹牛時說的SLA、幾個9）。如何保證真正“高可用”，也是個難題。對關鍵應用/服務，做集群冗餘負載，這也是保證高可用比較常用的手段：文件系統、數據庫系統集群；靜態內容服務器集群；CDN服務器集群；反向代理服務器集群；負載均衡調度器集群；分佈式NoSQL服務器集群；搜索引擎服務器集群；分佈式緩存服務器集群；分佈式Session服務器集群；使用集群冗餘負載 保證高可用優點：集群負載，保證高可用；缺點：數據一致性、數據有狀態問題；技術點：負載調度器、集群方案；截止目前為止，都沒有怎麼去改動應用程序的架構，或者說通俗點，都不怎麼需要大面積的修改代碼。如果上面那些手段都用光瞭，還是支撐不住怎麼辦？不停的加機器也不是辦法啊？應用垂直拆分隨著業務越來越復雜，網站的功能越來越多，雖然部署層面是采用的集群，但是應用程序架構層面還是“集中式”的，這樣會導致很多耦合，不便於開發、維護，而且容易“一榮俱損”。所以，通常會把網站拆分出不同的子站點來單獨宿主。通過分而治之的手段將整個網站業務分成不同的產品線，如首頁、商鋪、訂單、賣傢、買傢等拆分成不同的產品線，分歸不同的業務團隊負責。各個應用之間可以通過建立一個超鏈接建立關系，也可以通過消息隊列進行數據分發。應用垂直拆分（分壓，解耦）優點：降低耦合、分壓；缺點：應用架構復雜；技術點：業務抽取拆分；業務垂直分庫應用都拆瞭，由於單個數據庫的連接，QPS，TPS，I/O處理能力都非常有限，DB層面也可以去做垂直分庫操作。業務垂直分庫 分壓 解耦優點：降低DB耦合、分壓DB；缺點：數據訪問模塊復雜；技術點：業務抽取拆分；分佈式服務化拆分應用和DB之後，其實還是會有很多問題。不同的站點，裡面可能會有相同邏輯和功能的代碼。當然，對於一些基礎的功能我們可以封裝DLL或者Jar包去到處提供引用，但是這種強依賴也很容易造成一些問題（版本問題、依賴關系等處理起來非常麻煩）。既然每一個應用系統都需要執行許多相通的業務操作，比如用戶管理、商品管理等，那麼可以將這些共用的業務提取出來，獨立部署。這樣，傳說中的SOA的價值就得到體現瞭。分佈式服務化（解耦，去重復）優點：服務統一管理，提供重用度；缺點：應用架構更復雜；技術點：業務抽取拆分、服務化技術方案；消息隊列應用、服務之間還是會出現一些依賴問題，這時候，高吞吐量的解耦利器出現瞭。消息隊列（服務間異步解耦 高吞吐量）優點：提高吞吐量、應用、服務之間解耦；缺點：存在消息消費延遲問題；技術點：消息隊列技術方案；分庫分表*後，再介紹一個大型互聯網公司都用的絕技–分庫分表。個人經驗，不是業務發展和各方面非常迫切，不要輕易走這一步。因為分庫分表誰都會幹，關鍵是拆完之後怎麼辦。目前，市面上還沒有完全開源免費的方案，能讓你一勞永逸地解決數據庫拆分問題。分庫分表：橫向拆分；縱向拆分；分佈式數據庫訪問層；數據庫中間件（代理）；網站架構總結上面講述瞭在網站業務發展的不同階段，會面臨不同的問題，針對不同的問題，會選擇不同的架構。大型網站架構就是在不同階段時解決不同問題的過程中慢慢演進來的。