大型網(wǎng)站架構(gòu)演變

1、簡介

大型網(wǎng)站架構(gòu)的演進最開始都是由小及大慢慢演變過來的，任何一個好的架構(gòu)都不是設(shè)計出來的，是經(jīng)過業(yè)務(wù)發(fā)展迭代而來的，這個觀點我是贊同的。對于網(wǎng)站架構(gòu)技術(shù)非常有興趣，一直持續(xù)關(guān)注學(xué)習(xí)架構(gòu)技術(shù)，本次想通過大型網(wǎng)站技術(shù)發(fā)展歷程，剖析大型網(wǎng)站技術(shù)架構(gòu)模式，深入分析大型互聯(lián)網(wǎng)架構(gòu)設(shè)計。這篇文章我們只關(guān)注架構(gòu)的演變歷程。

通過電商業(yè)務(wù)為例，該系統(tǒng)的功能有用戶模塊【用戶注冊和管理】、商品模塊【商品展示和管理】、交易模塊【創(chuàng)建交易和管理】。通過圖例分析一個最初從單臺LAMP怎么發(fā)展到龐大的分布架構(gòu)體系。

線上系統(tǒng)高可用參考指標(biāo)：

2、架構(gòu)演變歷程

2.1. 第一階段【單機構(gòu)建網(wǎng)站】

網(wǎng)站程序用到的開源框架如maven+spring+struct+hibernate、maven+spring+springmvc+mybatis；網(wǎng)站初期，我們經(jīng)常會用單機跑所有的程序和軟件。通常由app server 和DB server組成，如tomcat和mysq；最后通過JDBC進行數(shù)據(jù)庫的連接和操作。

一般5萬pv到30萬pv訪問量，結(jié)合內(nèi)核參數(shù)調(diào)優(yōu)、web應(yīng)用性能參數(shù)調(diào)優(yōu)、數(shù)據(jù)庫調(diào)優(yōu)，基本上能夠穩(wěn)定的運行。

2.2. 第二階段【應(yīng)用服務(wù)器與數(shù)據(jù)庫分離】

隨著網(wǎng)站的發(fā)展當(dāng)訪問量逐漸增大，服務(wù)器的負(fù)載慢慢提高，系統(tǒng)的壓力越來越大，響應(yīng)速度越來越慢，這個時候比較明顯的是數(shù)據(jù)庫和應(yīng)用互相影響，應(yīng)用出問題了，數(shù)據(jù)庫也很容易出現(xiàn)問題，而數(shù)據(jù)庫出問題的時候，應(yīng)用也容易出問題。在服務(wù)器還沒有超載的時候，我們應(yīng)該提前做好準(zhǔn)備，提升網(wǎng)站的負(fù)載能力。假如我們代碼層面已難以優(yōu)化，在不提高單臺機器的性能的情況下，將應(yīng)用和數(shù)據(jù)庫從物理上分離，增加機器是一個不錯的方式，不僅可以有效地提高系統(tǒng)的負(fù)載能力，而且性價比高。此時我們可以把數(shù)據(jù)庫、web服務(wù)器拆分開來，這樣不僅提高了單臺機器的負(fù)載能力，也提高了容災(zāi)能力。

隨著用戶量的增大、對帶寬需求的增大、對CPU處理能力的增大；不足以融合所有用戶的需求了，或者網(wǎng)站業(yè)務(wù)量的需求了。此處很少也不應(yīng)該直接就對它做負(fù)載均衡式的擴展，因為數(shù)據(jù)同步很麻。所以我們架構(gòu)擴展，不會上來就直接做負(fù)載均衡式的每一組組件當(dāng)做一個整體來進行擴展，而是功能上切割 。這個時候技術(shù)上沒有什么新的要求，但你發(fā)現(xiàn)確實起到效果了，系統(tǒng)又恢復(fù)到以前的響應(yīng)速度了，并且支撐住了更高的流量，并且不會因為數(shù)據(jù)庫和應(yīng)用形成互相的影響。

2.3. 第三階段【應(yīng)用服務(wù)器負(fù)載均衡】

隨著訪問量繼續(xù)增加，單臺應(yīng)用服務(wù)器已經(jīng)無法滿足需求了。假設(shè)數(shù)據(jù)庫服務(wù)器沒有壓力，我們可以把應(yīng)用服務(wù)器從一臺變成了兩臺甚至多臺，把用戶的請求分散到不同的服務(wù)器中，從而提高負(fù)載能力。此時我們應(yīng)該選擇一款合適的負(fù)載均衡產(chǎn)品，一般來講keepalived配合上ipvsadm做負(fù)載均衡，可謂是神器。這一階段是需要掌握更多基礎(chǔ)知識的關(guān)鍵節(jié)點。以下可以使用DNS解析對用戶請求做負(fù)載均衡：

需要注意：負(fù)載均衡產(chǎn)品的選擇、負(fù)載均衡算法的選擇、用戶session保持的問題、應(yīng)用占用資源的角度選擇合理的服務(wù)器配置。
解決方案：根據(jù)以下技術(shù)特性選擇適合業(yè)務(wù)的產(chǎn)品、技術(shù)。例如nginx+keepalived一臺服務(wù)器、apache+tomcat一臺服務(wù)器、mysql一臺服務(wù)器。

三種負(fù)載均衡器的優(yōu)缺點說明如下：摘自（互聯(lián)網(wǎng)）
LVS的優(yōu)點：
1、抗負(fù)載能力強、工作在第4層僅作分發(fā)之用，沒有流量的產(chǎn)生，這個特點也決定了它在負(fù)載均衡軟件里的性能最強的；無流量，同時保證了均衡器IO的性能不會受到大流量的影響；
2、工作穩(wěn)定，自身有完整的雙機熱備方案，如LVS+Keepalived和LVS+Heartbeat；
3、應(yīng)用范圍比較廣，可以對所有應(yīng)用做負(fù)載均衡；
4、配置性比較低，這是一個缺點也是一個優(yōu)點，因為沒有可太多配置的東西，所以并不需要太多接觸，大大減少了人為出錯的幾率；
LVS的缺點：
1、軟件本身不支持正則處理，不能做動靜分離，這就凸顯了Nginx/HAProxy+Keepalived的優(yōu)勢。
2、如果網(wǎng)站應(yīng)用比較龐大，LVS/DR+Keepalived就比較復(fù)雜了，特別是后面有Windows Server應(yīng)用的機器，實施及配置還有維護過程就比較麻煩，相對而言，Nginx/HAProxy+Keepalived就簡單多了。

Nginx的優(yōu)點：
1、工作在OSI第7層，可以針對http應(yīng)用做一些分流的策略。比如針對域名、目錄結(jié)構(gòu)。它的正則比HAProxy更為強大和靈活；
2、Nginx對網(wǎng)絡(luò)的依賴非常小，理論上能ping通就就能進行負(fù)載功能，這個也是它的優(yōu)勢所在；
3、Nginx安裝和配置比較簡單，測試起來比較方便；
4、可以承擔(dān)高的負(fù)載壓力且穩(wěn)定，一般能支撐超過幾萬次的并發(fā)量；
5、Nginx可以通過端口檢測到服務(wù)器內(nèi)部的故障，比如根據(jù)服務(wù)器處理網(wǎng)頁返回的狀態(tài)碼、超時等等，并且會把返回錯誤的請求重新提交到另一個節(jié)點；
6、Nginx不僅僅是一款優(yōu)秀的負(fù)載均衡器/反向代理軟件，它同時也是功能強大的Web應(yīng)用服務(wù)器。LNMP現(xiàn)在也是非常流行的web環(huán)境，大有和LAMP環(huán)境分庭抗禮之勢，Nginx在處理靜態(tài)頁面、特別是抗高并發(fā)方面相對apache有優(yōu)勢；
7、Nginx現(xiàn)在作為Web反向加速緩存越來越成熟了，速度比傳統(tǒng)的Squid服務(wù)器更快，有需求的朋友可以考慮用其作為反向代理加速器；
Nginx的缺點：
1、Nginx不支持url來檢測。
2、Nginx僅能支持http和Email，這個它的弱勢。
3、Nginx的Session的保持，Cookie的引導(dǎo)能力相對欠缺。

HAProxy的優(yōu)點：
1、HAProxy是支持虛擬主機的，可以工作在4、7層(支持多網(wǎng)段)；
2、能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導(dǎo)等工作；
3、支持url檢測后端的服務(wù)器；
4、它跟LVS一樣，本身僅僅就只是一款負(fù)載均衡軟件；單純從效率上來講HAProxy更會比Nginx有更出色的負(fù)載均衡速度，在并發(fā)處理上也是優(yōu)于Nginx的；
5、HAProxy可以對Mysql讀進行負(fù)載均衡，對后端的MySQL節(jié)點進行檢測和負(fù)載均衡，不過在后端的MySQL slaves數(shù)量超過10臺時性能不如LVS；
6、HAProxy的算法較多，達到8種；

負(fù)載均衡的基礎(chǔ)技術(shù)：
1、http重定向。HTTP重定向就是應(yīng)用層的請求轉(zhuǎn)發(fā)，用戶的請求到了HTTP重定向負(fù)載均衡服務(wù)器，根據(jù)算法要求用戶重定向，瀏覽器自動重新請求實際服務(wù)器的IP地址。
優(yōu)點：簡單
缺點：性能較差

2、DNS域名解析負(fù)載均衡。DNS域名解析負(fù)載均衡就是在用戶請求DNS服務(wù)器，獲取域名對應(yīng)的IP地址時，DNS服務(wù)器直接解析到負(fù)載均衡后的服務(wù)器IP。
優(yōu)點：使用DNS省心，不用我們?nèi)ゾS護。
缺點：使用DNS，它不具備故障檢測功能，DNS解析結(jié)果會被緩存因此效果一般，DNS負(fù)載均衡多數(shù)為商業(yè)產(chǎn)品，其功能、管理權(quán)限有限。

3、反向代理服務(wù)器。反向代理服務(wù)器轉(zhuǎn)發(fā)的請求在HTTP協(xié)議層面，因此也叫應(yīng)用層負(fù)載均衡。用戶的請求到達反向代理服務(wù)器，由反向代理服務(wù)器根據(jù)算法轉(zhuǎn)發(fā)到具體的服務(wù)器。反向代理軟件常用的有apache、nginx。
優(yōu)點：部署簡單。
缺點：反向代理服務(wù)器是所有請求和響應(yīng)的分發(fā)服務(wù)器，其性能可能會成為瓶頸。特別是上傳大文件。

4、IP層負(fù)載均衡。用戶的請求到達負(fù)載均衡器后，通過修改請求的目的IP地址，實現(xiàn)負(fù)載均衡。代表實現(xiàn)LVS的NAT模式
優(yōu)點：性能更好。
缺點：負(fù)載均衡器的寬帶成為瓶頸。

5、數(shù)據(jù)鏈路層負(fù)載均衡。用戶的請求到達負(fù)載均衡器后，通過修改請求的mac地址，實現(xiàn)負(fù)載均衡。與IP負(fù)載均衡不同當(dāng)請求訪問完服務(wù)器之后，直接返回客戶而無需再經(jīng)過負(fù)載均衡器。代表實現(xiàn)LVS的DR模式

常見的調(diào)度算法：摘自（互聯(lián)網(wǎng)）
1、rr 輪詢調(diào)度算法。顧名思義，輪詢分發(fā)請求。
優(yōu)點：實現(xiàn)簡單
缺點：不考慮每臺服務(wù)器的處理能力

2、wrr 加權(quán)調(diào)度算法。我們給每個服務(wù)器設(shè)置權(quán)值weight，負(fù)載均衡調(diào)度器根據(jù)權(quán)值調(diào)度服務(wù)器，服務(wù)器被調(diào)用的次數(shù)跟權(quán)值成正比。
優(yōu)點：考慮了服務(wù)器處理能力的不同

3、sh 原地址散列：提取用戶IP，根據(jù)散列函數(shù)得出一個key，再根據(jù)靜態(tài)映射表，查處對應(yīng)的value，即目標(biāo)服務(wù)器IP。過目標(biāo)機器超負(fù)荷，則返回空。

4、dh 目標(biāo)地址散列：同上，只是現(xiàn)在提取的是目標(biāo)地址的IP來做哈希。
優(yōu)點：以上兩種算法的都能實現(xiàn)同一個用戶訪問同一個服務(wù)器。

5、lc 最少連接。優(yōu)先把請求轉(zhuǎn)發(fā)給連接數(shù)少的服務(wù)器。
優(yōu)點：使得集群中各個服務(wù)器的負(fù)載更加均勻。

6、wlc 加權(quán)最少連接。在lc的基礎(chǔ)上，為每臺服務(wù)器加上權(quán)值。算法為：（活動連接數(shù)*256+非活動連接數(shù)）÷權(quán)重 ，計算出來的值小的服務(wù)器優(yōu)先被選擇。
優(yōu)點：可以根據(jù)服務(wù)器的能力分配請求。

7、sed 最短期望延遲。其實sed跟wlc類似，區(qū)別是不考慮非活動連接數(shù)。算法為：（活動連接數(shù)+1)*256÷權(quán)重，同樣計算出來的值小的服務(wù)器優(yōu)先被選擇。

8、nq 永不排隊。改進的sed算法。我們想一下什么情況下才能“永不排隊”，那就是服務(wù)器的連接數(shù)為0的時候，那么假如有服務(wù)器連接數(shù)為0，均衡器直接把請求轉(zhuǎn)發(fā)給它，無需經(jīng)過sed的計算。

9、LBLC 基于局部性的最少連接。均衡器根據(jù)請求的目的IP地址，找出該IP地址最近被使用的服務(wù)器，把請求轉(zhuǎn)發(fā)之，若該服務(wù)器超載，最采用最少連接數(shù)算法。

10、LBLCR 帶復(fù)制的基于局部性的最少連接。均衡器根據(jù)請求的目的IP地址，找出該IP地址最近使用的“服務(wù)器組”，注意，并不是具體某個服務(wù)器，然后采用最少連接數(shù)從該組中挑出具體的某臺服務(wù)器出來，把請求轉(zhuǎn)發(fā)之。若該服務(wù)器超載，那么根據(jù)最少連接數(shù)算法，在集群的非本服務(wù)器組的服務(wù)器中，找出一臺服務(wù)器出來，加入本服務(wù)器組，然后把請求轉(zhuǎn)發(fā)之。

session會話保持：
session sticky
ip based
cookie based
session replication
session server

1、Session Sticky。始終將同一個請求者的連接定向至同一個RS（第一次請求時仍由調(diào)度方法選擇）；沒有容錯能力，有損均衡效果。常見的算法有ip_hash法，即上面提到的兩種散列算法。
優(yōu)點：實現(xiàn)簡單。
缺點：無高可用，反均衡。

2、Session Replication。在RS之間同步session，因此每個RS持集群中所有的session；對于大規(guī)模集群環(huán)境不適用。
優(yōu)點：減輕負(fù)載均衡服務(wù)器的壓力，可以隨意調(diào)度。
缺點：帶寬、內(nèi)存占用量大，并發(fā)能力有限。

3、Session Server：利用單獨部署的服務(wù)器來統(tǒng)一管理session; 實現(xiàn)了session和應(yīng)用服務(wù)器的解耦。
優(yōu)點：相比session replication的方案，集群間對于寬帶和內(nèi)存的壓力減少了很多。
缺點：需要維護存儲session的數(shù)據(jù)庫。

4、Cookie Base：cookie base就是把session存在cookie中，由瀏覽器來告訴應(yīng)用服務(wù)器用戶的session是什么，同樣實現(xiàn)了session和應(yīng)用服務(wù)器的解耦。
優(yōu)點：實現(xiàn)簡單，基本免維護。
缺點：cookie長度限制，安全性低，寬帶消耗。

應(yīng)用從資源占用的角度分類：
1、CPU Bound 【CPU密集型】一般指aap server
2、IO Bound 【IO密集型】一般指db server

有了以上理論經(jīng)驗，根據(jù)業(yè)務(wù)我們可以重新對架構(gòu)演進為以下方案：

2.4. 第四階段【數(shù)據(jù)庫讀寫分離】

前面幾個階段我們都是假設(shè)后端數(shù)據(jù)庫負(fù)載沒問題，但隨著訪問量的增大，數(shù)據(jù)庫的負(fù)載也在慢慢增高。那么可能有人馬上想到跟應(yīng)用服務(wù)器一樣，把數(shù)據(jù)庫一分為二再負(fù)載均衡即可。但對于數(shù)據(jù)庫來說，并沒有那么簡單。假如我們簡單的把數(shù)據(jù)庫一分為二，然后對于數(shù)據(jù)庫的請求，分別負(fù)載到A機器和B機器，那么顯然會造成兩臺數(shù)據(jù)庫數(shù)據(jù)不一致的問題。那么對于這種情況，我們可以先考慮使用讀寫分離的方式。

需要注意：引用MySQL主從勢必會面臨的問題，數(shù)據(jù)復(fù)制的問題、應(yīng)用選擇數(shù)據(jù)源的問題
解決方案：使用MySQL自帶的master+slave的方式實現(xiàn)主從復(fù)制。采用第三方數(shù)據(jù)庫中間件，例如mycat。mycat是從cobar發(fā)展而來的。mycat目前是國內(nèi)比較好的mysql開源數(shù)據(jù)庫分庫分表中間件。

2.5. 第五階段【引入搜索引擎實現(xiàn)全文搜索】

MySQL對于全局搜索能力支持不強，MySQL只對MyISAM引擎做全文索引但不支持事務(wù)，而MySQL對InnoDB引擎不支持全文索引。當(dāng)一個站點到了這一個階段其用戶搜索量是非常大的。做為一個電商站點的交易達成有70%是通過搜索進行的，由此像這種越來越多的搜索需求使得我們數(shù)據(jù)庫根本就沒辦法應(yīng)付這種需要，因為每一次搜索都是一次全面查詢，常常對模糊查找力不從心，即使做了讀寫分離，這個問題還未能解決。我們要想應(yīng)付這種需求，一般只能自己構(gòu)建搜索引擎來緩解讀庫的壓力。

搜索引擎并不能替代數(shù)據(jù)庫，他解決了某些場景下的“讀”的問題，是否引入搜索引擎，需要綜合考慮整個系統(tǒng)的需求。引入搜索引擎后的系統(tǒng)結(jié)構(gòu)：

2.6. 第六階段【引入緩存】

1、頁面緩存
web服務(wù)器壓力較大時，如果讓站點的一部分內(nèi)容能緩存，一部分內(nèi)容不能緩存，我們可以使用ESI動態(tài)緩存技術(shù)。web緩存服務(wù)器還可以對jpg、jpeg、gif、png、html、css、js格式的頁面做緩存。例如：varnish, squid

2、數(shù)據(jù)緩存
隨著訪問量的增加，逐漸出現(xiàn)了許多用戶訪問同一部分內(nèi)容的情況，對于這些比較熱門的內(nèi)容，沒必要每次都從數(shù)據(jù)庫讀取，我們可以使用緩存技術(shù)。例如：memcached, redis

優(yōu)點：減輕數(shù)據(jù)庫的壓力、大幅度提高訪問速度
缺點：需要維護緩存服務(wù)器、提高了編碼的復(fù)雜性

緩存服務(wù)器集群的調(diào)度算法不同與上面提到的應(yīng)用服務(wù)器和數(shù)據(jù)庫，最好采用“一致性哈希算法”。

2.7. 第七階段【數(shù)據(jù)庫拆分】

當(dāng)訪問量逐漸增大，單一應(yīng)用增加機器帶來的效果不明顯，需要考結(jié)合業(yè)務(wù)考慮數(shù)據(jù)庫拆分，來提升系統(tǒng)運行效率。我們的網(wǎng)站演進到現(xiàn)在，交易、商品、用戶的數(shù)據(jù)都還在同一個數(shù)據(jù)庫中。盡管采取了增加緩存，讀寫分離的方式，但隨著數(shù)據(jù)庫的壓力繼續(xù)增加，數(shù)據(jù)庫的瓶頸越來越突出，此時主庫寫操作壓力只能做數(shù)據(jù)庫拆分，我們可以有垂直拆分和水平拆分兩種選擇。

1、垂直拆分：把數(shù)據(jù)庫中不同的業(yè)務(wù)的數(shù)據(jù)拆分到不同的數(shù)據(jù)庫服務(wù)器中。

2、水平拆分：把一個單獨的表中的數(shù)據(jù)拆分到多個不同的數(shù)據(jù)庫服務(wù)器上。

2.8. 第八階段【應(yīng)用拆分】

隨著業(yè)務(wù)的發(fā)展，業(yè)務(wù)越來越多，應(yīng)用越來越大。我們需要考慮如何避免讓應(yīng)用越來越臃腫。這就需要把應(yīng)用拆開，從一個應(yīng)用變?yōu)閭z個甚至更多。還是以我們上面的例子，我們可以把用戶、商品、交易拆分開。變成“用戶、商品”和“用戶，交易”兩個子系統(tǒng)。

需要注意：這樣拆分后，可能會有一些相同的代碼，如用戶相關(guān)的代碼，商品和交易都需要用戶信息，所以在兩個系統(tǒng)中都保留差不多的操作用戶信息的代碼。如何保證這些代碼可以復(fù)用是一個需要解決的問題。
解決方案：通過走服務(wù)化的路線來解決，把公共的服務(wù)拆分出來，形成一種服務(wù)化的模式，簡稱SOA。

服務(wù)化之后的系統(tǒng)結(jié)構(gòu)：

需要注意：如何進行遠(yuǎn)程的服務(wù)調(diào)用
解決方案：我們可以通過引入消息中間件來解決

2.9. 第九階段【引入消息中間件】

隨著網(wǎng)站的繼續(xù)發(fā)展，我們的系統(tǒng)中可能出現(xiàn)不同語言開發(fā)的子模塊和部署在不同平臺的子系統(tǒng)。此時我們需要一個平臺來傳遞可靠的，與平臺和語言無關(guān)的數(shù)據(jù)，并且能夠把負(fù)載均衡透明化，能在調(diào)用過程中收集調(diào)用數(shù)據(jù)并分析之，推測出網(wǎng)站的訪問增長率等等一系列需求，對于網(wǎng)站應(yīng)該如何成長做出預(yù)測。開源消息中間件有阿里的dubbo，可以搭配Google開源的分布式程序協(xié)調(diào)服務(wù)zookeeper實現(xiàn)服務(wù)器的注冊與發(fā)現(xiàn)。

引入消息中間件后的結(jié)構(gòu)：

3、高性能設(shè)計

三層架構(gòu)(3-tier architecture) 通常意義上的三層架構(gòu)就是將整個業(yè)務(wù)應(yīng)用劃分為：界面層（User Interface layer）、業(yè)務(wù)邏輯層（Business Logic Layer）、數(shù)據(jù)訪問層（Data access layer）。區(qū)分層次的目的即為了“高內(nèi)聚低耦合”的思想。在軟件體系架構(gòu)設(shè)計中，分層式結(jié)構(gòu)是最常見，也是最重要的一種結(jié)構(gòu)。微軟推薦的分層式結(jié)構(gòu)一般分為三層，從下至上分別為：數(shù)據(jù)訪問層、業(yè)務(wù)邏輯層（又或稱為領(lǐng)域?qū)樱?、表示層。（百度百科?/p>

微服務(wù)的特點：
單一職責(zé)：微服務(wù)中每一個服務(wù)都對應(yīng)唯一的業(yè)務(wù)能力，做到單一職責(zé)。
微：微服務(wù)的服務(wù)拆分粒度很小，例如一個用戶管理就可以作為一個服務(wù)。每個服務(wù)雖小，但“五臟俱全”。
面向服務(wù)：面向服務(wù)是說每個服務(wù)都要對外暴露服務(wù)接口API。并不關(guān)心服務(wù)的技術(shù)實現(xiàn)，做到與平臺和語言無關(guān)，也不限定用什么技術(shù)實現(xiàn)，只要提供Rest的接口即可。
自治：自治是說服務(wù)間互相獨立，互不干擾
團隊獨立：每個服務(wù)都是一個獨立的開發(fā)團隊，人數(shù)不能過多。
技術(shù)獨立：因為是面向服務(wù)，提供Rest接口，使用什么技術(shù)沒有別人干涉
前后端分離：采用前后端分離開發(fā)，提供統(tǒng)一Rest接口，后端不用再為PC、移動段開發(fā)不同接口
數(shù)據(jù)庫分離：每個服務(wù)都使用自己的數(shù)據(jù)源
部署獨立，服務(wù)間雖然有調(diào)用，但要做到服務(wù)重啟不影響其它服務(wù)。有利于持續(xù)集成和持續(xù)交付。每個服務(wù)都是獨立的組件，可復(fù)用，可替換，降低耦合，易維護。

架構(gòu)優(yōu)化：
? 以用戶為中心，提供快速的網(wǎng)頁訪問體驗。主要參數(shù)有較短的響應(yīng)時間，較大的并發(fā)處理能力，較高的吞吐量，穩(wěn)定的性能參數(shù)；
? 可分為前端優(yōu)化，應(yīng)用層優(yōu)化，代碼層優(yōu)化，存儲層優(yōu)化；
? 前端優(yōu)化：網(wǎng)站業(yè)務(wù)邏輯之前的部分；
? 瀏覽器優(yōu)化：減少Http請求數(shù)，使用瀏覽器緩存，啟用壓縮，Css Js位置，Js異步，減少Cookie傳輸；
? CDN加速，反向代理；
? 應(yīng)用層優(yōu)化：處理網(wǎng)站業(yè)務(wù)的服務(wù)器。使用緩存，異步，集群；
? 代碼優(yōu)化：合理的架構(gòu)，多線程，資源復(fù)用（對象池，線程池等），良好的數(shù)據(jù)結(jié)構(gòu)，JVM調(diào)優(yōu)，單例，Cache等；
? 存儲優(yōu)化：緩存，固態(tài)硬盤，光纖傳輸，優(yōu)化讀寫，磁盤冗余，分布式存儲（HDFS），NOSQL等。