1.HTML靜態化

如果網站的請求量過大，我們可以將頁面靜態化提供訪問來緩解伺服器壓力，能夠緩解伺服器壓力加大以及降低資料庫資料的頻繁交換。適合於某些訪問了過大，但是內容不經常改變的頁面，如首頁、新聞頁等

2.檔案伺服器

顧名思義，檔案伺服器就是將檔案系統單獨拿出來提供專注於處理檔案的儲存訪問系統，甚至於對個檔案伺服器。因為對於圖片這種資源的訪問儲存是web服務最耗資源的地方，將檔案伺服器單獨部署既可以將壓力轉移，交給專門的系統處理，又可以分擔風險，如果圖片伺服器出現問題，那麼主伺服器能夠保證正常，頂多就是檔案請求不到。

3.負載均衡

負載均衡將是大型網站解決高負荷訪問和大量併發請求採用的終極解決辦法。

負載均衡建立在現有網路結構之上，它提供了一種廉價有效透明的方法擴充套件網路裝置和伺服器的頻寬、增加吞吐量、加強網路資料處理能力、提高網路的靈活性和可用性。其原理就是將大量工作分攤到多個操作單元上進行執行，例如Web伺服器、FTP伺服器、企業關鍵應用伺服器和其它關鍵任務伺服器等，從而共同完成工作任務。

四個分類

軟體負載均衡解決方案是指在一臺或多臺伺服器相應的作業系統上安裝一個或多個附加軟體來實現負載均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的優點是基於特定環境，配置簡單，使用靈活，成本低廉，可以滿足一般的負載均衡需求。 
軟體解決方案缺點也較多，因為每臺伺服器上安裝額外的軟體執行會消耗系統不定量的資源，越是功能強大的模組，消耗得越多，所以當連線請求特別大的時候，軟體本身會成為伺服器工作成敗的一個關鍵；軟體可擴充套件性並不是很好，受到作業系統的限制；由於作業系統本身的Bug，往往會引起安全問題。

硬體負載均衡解決方案是直接在伺服器和外部網路間安裝負載均衡裝置，這種裝置通常稱之為負載均衡器，由於專門的裝置完成專門的任務，獨立於作業系統，整體效能得到大量提高，加上多樣化的負載均衡策略，智慧化的流量管理，可達到最佳的負載均衡需求。 
負載均衡器有多種多樣的形式，除了作為獨立意義上的負載均衡器外，有些負載均衡器整合在交換裝置中，置於伺服器與Internet連結之間，有些則以兩塊網路介面卡將這一功能整合到PC中，一塊連線到Internet上，一塊連線到後端伺服器群的內部網路上。 
一般而言，硬體負載均衡在功能、效能上優於軟體方式，不過成本昂貴。 
本地/全域性

負載均衡從其應用的地理結構上分為本地負載均衡(Local Load Balance)和全域性負載均衡(Global Load Balance，也叫地域負載均衡)

本地負載均衡是指對本地的伺服器群做負載均衡，全域性負載均衡是指對分別放置在不同的地理位置、有不同網路結構的伺服器群間作負載均衡。

本地負載均衡能有效地解決資料流量過大、網路負荷過重的問題，並且不需花費昂貴開支購置效能卓越的伺服器，充分利用現有裝置，避免伺服器單點故障造成資料流量的損失。其有靈活多樣的均衡策略把資料流量合理地分配給伺服器群內的伺服器共同負擔。即使是再給現有伺服器擴充升級，也只是簡單地增加一個新的伺服器到服務群中，而不需改變現有網路結構、停止現有的服務。

全域性負載均衡主要用於在一個多區域擁有自己伺服器的站點，為了使全球使用者只以一個IP地址或域名就能訪問到離自己最近的伺服器，從而獲得最快的訪問速度，也可用於子公司分散站點分佈廣的大公司通過Intranet（企業內部網際網路）來達到資源統一合理分配的目的。 
全域性負載均衡有以下的特點： 
實現地理位置無關性，能夠遠距離為使用者提供完全的透明服務。 
除了能避免伺服器、資料中心等的單點失效，也能避免由於ISP專線故障引起的單點失效。 
解決網路擁塞問題，提高伺服器響應速度，服務就近提供，達到更好的訪問質量。

4.反向代理

客戶端直接訪問的伺服器並不是直接提供服務的伺服器，它從別的伺服器獲取資源，然後將結果返回給使用者。

代理伺服器和反向代理伺服器：

　　代理伺服器是代我們訪獲取資源，然後將結果返回。例如，訪問外網的代理伺服器。反向代理伺服器是我們正常訪問一臺伺服器的時候，伺服器自己呼叫了別的伺服器。 
　　反向代理就是說，使用者的請求請求到負載均衡的裝置上，負載均衡裝置再講請求分發到空閒的應用伺服器上處理，處理完成之後再通過負載均衡裝置返回給使用者，這樣對於使用者來說，後來的分發是不可見的。

反向代理的實現 
1）需要有一個負載均衡裝置來分發使用者請求，將使用者請求分發到空閒的伺服器上 
2）伺服器返回自己的服務到負載均衡裝置 
3）負載均衡將伺服器的服務返回使用者

　　代理伺服器我們主動使用，是為我們服務的，不需要有自己的域名；反向代理是伺服器自己使用的，我們並不知道，有自己的域名。

5.動靜分離

所謂動靜分離就是將網站靜態資源（HTML，JavaScript，CSS，img等檔案）與後臺應用分開部署，提高使用者訪問靜態程式碼的速度，降低對後臺應用訪問。上面的檔案伺服器就是動靜分離的一部分。

動靜分離的一種做法是將靜態資源部署在nginx上，後臺專案部署到應用伺服器上，根據一定規則靜態資源的請求全部請求nginx伺服器，達到動靜分離的目標。

靜態資源部署至CDN上

我們的方案是直接將靜態資源全部存放在CDN伺服器上。因為之前專案中的JavaScript,CSS以及img檔案都是存放在CDN伺服器上，將HTML檔案一起存放到CDN上之後，可以將靜態資源統一放置在一種伺服器上，便於前端進行維護；而且使用者在訪問靜態資源時，可以很好利用CDN的優點——CDN系統能夠實時地根據網路流量和各節點的連線、負載狀況以及到使用者的距離和響應時間等綜合資訊將使用者的請求重新導向離使用者最近的服務節點上。

後端API提供資料 
後端應用提供API，根據前端的請求進行處理，並將處理結果通過JSON格式返回至前端。目前應用主要採用Java平臺開發，因此應用伺服器主要是Tomcat伺服器，現在也開始有部分應用採用 node進行開發，應用伺服器也開始使用node伺服器。

前後端域名 
動靜分離因為靜態資源和應用服務分別部署在不同的伺服器上，因此會面臨域名策略的選擇。 
相同域名 
採用相同域名下，使用者請求api時可以避免跨域所帶來的問題，相對開發更為快速，工作量也相對小一些。 
不同域名 
前後端採用不同域名時，需要前後端開發時相容跨域請求的情況，開發量相對上一種會稍多一些。解決跨域方式最常用的方式就是採用JSONP，還有一種解決方式使用CORS（HTTP訪問控制）允許某些域名下的跨域請求。 
目前在我們的專案中JSONP方式更多，CORS因為需要瀏覽器支援，因此只會在APP內嵌HTML5，且需要POST方式時中使用。 
採用不同域名的方式優點也是非常明顯的，不同域名採用兩個域名伺服器，不同的域名伺服器根據請求的不同採用不同的負載均衡策略；而且不同域名也可以郵箱方式前端攜帶過多的Cookie。

優點

api介面服務化：動靜分離之後，後端應用更為服務化，只需要通過提供api介面即可，可以為多個功能模組甚至是多個平臺的功能使用，可以有效的節省後端人力，更便於功能維護。 
前後端開發並行：前後端只需要關心介面協議即可，各自的開發相互不干擾，並行開發，並行自測，可以有效的提高開發時間，也可以有些的減少聯調時間 
減輕後端伺服器壓力，提高靜態資源訪問速度：後端不用再將模板渲染為html返回給使用者端，且靜態伺服器可以採用更為專業的技術提高靜態資源的訪問速度。

缺點

不利於網站SEO（搜尋引擎優化）:搜尋引擎的網路爬蟲一般是根據url訪問頁面，獲取頁面的內容後去掉沒用的資訊例如：CSS，JavaScript，然後分析剩下的文字內容；動靜分離架構模式前端資料即在是由JavaScript來完成，這就會導致網路爬蟲得到的資訊部分丟失。在開發中可以採用前端快取不經常變化資料的方式來解決，只有哪些經常發生變化的資料才每次向後端請求。 
開發量變大，前後端交流成本升高：後端api返回的資料，往往是有自身邏輯在內的，比如返回資料中的包含status（1-處理中，2-處理成功，3-處理失敗），前端需要理解status的不同含義，對應的前端操作需要理解（如，status =1 or status = 2，不可提交）。 
在業務高速發展時需要慎重考慮：因為開發量變大，如果在業務開始階段，缺乏前端又要求開發速度很快，就需要慎重考慮這種方式的實現成本對業務發展的影響。

6.資料庫sql優化

對於相同功能的sql，如果資料庫的sql沒有做過優化和做過優化的sql比較起來，其處理能力完全是天壤之別，其差距可以有幾倍甚至幾十上百上千的速度差距、資源消耗差距。所以對於一個優秀的web應用，sql優化是必須做的。

7.快取

對於快取我想大家都不陌生，快取可以讓我們將一些有時效性的、經常訪問的、不便於儲存資料庫等的資料，我們可以將資料儲存在專門的用於快取的應用程式中，如果有必要，還可以將快取應用伺服器單獨部署，如果資料量過大，我們還可以組成快取伺服器叢集，比如：cache、redis等都是比較專注於快取資料的。

只所以使用快取，是因為一是減少資料庫的訪問壓力，二是一般專注於快取的應用對於資料的讀寫較於資料庫都是非常快的

8.資料庫讀寫分離

讀寫分離是為了提供程式的效能，隨著使用者的增加，資料庫的壓力也會越來越大，對資料庫或者SQL的基本優化可能達不到最終的效果，讀寫分離簡單的說是把對資料庫讀和寫的操作分開對應不同的資料庫伺服器，這樣能有效地減輕資料庫壓力，也能減輕io壓力。主資料庫提供寫操作，從資料庫提供讀操作。主資料庫提供寫操作，從資料庫提 供讀操作，其實在很多系統中，主要是讀的操作。當主資料庫進行寫操作時，資料要同步到從的資料庫，這樣才能有效保證資料庫完整性。Quest SharePlex就是比較牛的同步資料工具，聽說比oracle本身的流複製還好，mysql也有自己的同步資料技術。mysql只要是通過二進位制日誌來複制資料。通過日誌在從資料庫重複主資料庫的操作達到複製資料目的。這個複製比較好的就是通過非同步方法，把資料同步到從資料庫。

當然同樣的因為資料的複製同步需要時間，對於一些實時性要求非常高的邏輯可能會有問題。

9.資料庫活躍資料分離

所謂的活躍資料就是經常用到的資料，比如經常活躍的使用者資料等。不活躍資料，比如好長時間不等路的使用者資料，還有幾個月前的資料等等。

對於這種不活躍的資料參與到查詢中，會很大的拖累查詢速度嗎，所以講非活躍資料單獨同步到一個數據庫中，這樣大概率的查詢只需要查活躍資料的資料庫，只有活躍資料的資料庫查不到時，才去查非活躍資料庫。

10.批量讀取和延遲修改 
高併發情況可以將多個查詢請求合併到一個。同一查詢，同一返回處理，降低短時間內的資料庫請求數量。高併發且頻繁修改的可以暫存快取中，然後統一進行修改。

11.資料庫叢集和庫表雜湊 
通常對於一個伺服器的處理的瓶頸大多在於資料庫的瓶頸，對於大資料量的請求處理，單個數據庫處理能力有限，所以我們可以部署多個數據庫，然後將資料庫組成一個叢集。

對於資料庫叢集，每個成熟的資料庫都有自己的解決方案，我們按照方案進行擴充套件即可。

上面提到的資料庫叢集由於在架構、成本、擴張性方面都會受到所採用DB型別的限制，於是我們需要從應用程式的角度來考慮改善系統架構，庫表雜湊是常用並且最有效的解決方案。我們在應用程式中安裝業務和應用或者功能模組將資料庫進行分離，不同的模組對應不同的資料庫或者表，再按照一定的策略對某個頁面或者功能進行更小的資料庫雜湊，比如使用者表，按照使用者ID進行表雜湊，這樣就能夠低成本的提升系統的效能並且有很好的擴充套件性。sohu的論壇就是採用了這樣的架構，將論壇的使用者、設定、帖子等資訊進行資料庫分離，然後對帖子、使用者按照板塊和ID進行雜湊資料庫和表，最終可以在配置檔案中進行簡單的配置便能讓系統隨時增加一臺低成本的資料庫進來補充系統性能。