上圖展示了一個(gè)典型的,，三層架構(gòu)的高性能 Web 應(yīng)用。這種成熟的架構(gòu)多年以來(lái)已被廣泛部署于包括 Google,、Yahoo、Facebook、Twitter,、Wikipedia 在內(nèi)的諸多大型 Web 應(yīng)用中,。

• 連接管理：分別維護(hù)客戶端和應(yīng)用服務(wù)器的連接池，管理并關(guān)閉已超時(shí)的長(zhǎng)連接。
  　

• 攻擊檢測(cè)和安全隔離：由于反向代理服務(wù)無(wú)需完成任何動(dòng)態(tài)頁(yè)面生成任務(wù)，所有與業(yè)務(wù)邏輯相關(guān)的請(qǐng)求都轉(zhuǎn)發(fā)至后端應(yīng)用服務(wù)器處理。因此反向代理服務(wù)幾乎不會(huì)被應(yīng)用程序設(shè)計(jì)或后端數(shù)據(jù)漏洞所影響,。反向代理的安全性和可靠性通常僅取決于產(chǎn)品本身,。在應(yīng)用服務(wù)的前端部署反向代理服務(wù)器可以有效地在后端應(yīng)用和遠(yuǎn)程用戶間建立起一套可靠的安全隔離和攻擊檢測(cè)機(jī)制,。
  
  如果需要的話,，還可以通過(guò)在外網(wǎng),、反向代理、后端應(yīng)用和數(shù)據(jù)庫(kù)等邊界位置添加額外的硬件防火墻等網(wǎng)絡(luò)隔離設(shè)備來(lái)實(shí)現(xiàn)更高的安全性保證,。
  　

• 負(fù)載均衡：通常使用輪轉(zhuǎn)（Round Robin）或最少連接數(shù)優(yōu)先等策略完成基于客戶請(qǐng)求的負(fù)載均衡；也可以使用 SSI 等技術(shù)將一個(gè)客戶請(qǐng)求拆分成若干并行計(jì)算部分分別提交到多個(gè)應(yīng)用服務(wù)器。
  　

• 分布式的 cache 加速：可以將反向代理分組部署在距離熱點(diǎn)地區(qū)地理位置較近的網(wǎng)絡(luò)邊界上。通過(guò)在位于客戶較近的位置提供緩沖服務(wù)來(lái)加速網(wǎng)絡(luò)應(yīng)用,。這實(shí)際上就構(gòu)成了 CDN 網(wǎng)絡(luò),。
  　

• 靜態(tài)文件伺服：當(dāng)收到靜態(tài)文件請(qǐng)求時(shí),，直接返回該文件而無(wú)需將該請(qǐng)求提交至后端應(yīng)用服務(wù)器,。
  　

• 動(dòng)態(tài)響應(yīng)緩存：對(duì)一段時(shí)間內(nèi)不會(huì)發(fā)生改變的動(dòng)態(tài)生成響應(yīng)進(jìn)行緩存，避免后端應(yīng)用服務(wù)器頻繁執(zhí)行重復(fù)查詢和計(jì)算。
  　

• 數(shù)據(jù)壓縮傳輸：為返回的數(shù)據(jù)啟用 GZIP/ZLIB 壓縮算法以節(jié)約帶寬,。
  　

• 數(shù)據(jù)加密保護(hù)（SSL Offloading）：為與客戶端的通信啟用 SSL/TLS 加密保護(hù),。
  　

• 容錯(cuò)：跟蹤后端應(yīng)用服務(wù)器的健康狀況,，避免將請(qǐng)求調(diào)度到發(fā)生故障的服務(wù)器。
  　

• 用戶鑒權(quán)：完成用戶登陸和會(huì)話建立等工作,。
  　

• URL別名：對(duì)外建立統(tǒng)一的url別名信息，屏蔽真實(shí)位置,。
  　

• 應(yīng)用混搭：通過(guò)SSI和URL映射技術(shù)將不同的web應(yīng)用混搭在一起,。
  　

• 協(xié)議轉(zhuǎn)換：為使用 SCGI 和 FastCGI 等協(xié)議的后端應(yīng)用提供協(xié)議轉(zhuǎn)換服務(wù),。

目前比較有名的反向代理服務(wù)包括：Apache httpd+mod_proxy / IIS+ARR / Squid / Apache Traffic Server / Nginx / Cherokee / Lighttpd / HAProxy 以及 Varnish 等等。

應(yīng)用層實(shí)現(xiàn)了 Web 應(yīng)用的所有業(yè)務(wù)邏輯,，通常要完成大量的計(jì)算和數(shù)據(jù)動(dòng)態(tài)生成任務(wù),。應(yīng)用層內(nèi)的各個(gè)節(jié)點(diǎn)不一定是完全對(duì)等的，還可能以 SOA,、μSOA 等架構(gòu)拆分為不同服務(wù)集群。

上圖給出了一個(gè)典型的高并發(fā)、高性能應(yīng)用層節(jié)點(diǎn)工作模型,。每個(gè) Web 應(yīng)用節(jié)點(diǎn)（在圖 5中由標(biāo)有'App'字樣的方框表示）通常都會(huì)工作在自己的服務(wù)器（物理服務(wù)器或VPS）之上,，多個(gè)應(yīng)用節(jié)點(diǎn)可以有效地并行工作，以方便地實(shí)現(xiàn)橫向擴(kuò)展,。

在上圖所示的例子中,，Web 應(yīng)用節(jié)點(diǎn)由 IO 回調(diào)線程池、Web 請(qǐng)求隊(duì)列以及后臺(tái)工作線程池等三個(gè)重要部分組成,，其伺服流程如下：

1. 當(dāng)一個(gè) Web 請(qǐng)求到達(dá)后,，底層操作系統(tǒng)通過(guò) IOCP、epoll,、kqueue,、event ports、real time signal (posix aio),、/dev/poll,、pollset 等各類與具體平臺(tái)緊密相關(guān)的 IO 完成（或 IO 就緒）回調(diào)機(jī)制通知 AIO（Asynchronous IO）回調(diào)線程，對(duì)這個(gè)已到達(dá)的 Web 請(qǐng)求進(jìn)行處理,。
   　

2. 在 AIO 回調(diào)池中的工作線程接收到一個(gè)已到達(dá)的 Web 請(qǐng)求后,，首先嘗試對(duì)該請(qǐng)求進(jìn)行預(yù)處理。在預(yù)處理過(guò)程中,，將會(huì)使用位于本地的高速緩存來(lái)避免成本較高的數(shù)據(jù)庫(kù)查詢,。如果本地緩存命中，則直接將緩存中的結(jié)果（仍然以異步 IO 的方式）返回客戶端,，并結(jié)束本次請(qǐng)求,。
   　

3. 如果指定的 Web 請(qǐng)求要求查詢的數(shù)據(jù)無(wú)法被本地緩存命中，或者這個(gè) Web 請(qǐng)求需要數(shù)據(jù)庫(kù)寫入操作,，則該請(qǐng)求將被 AIO 回調(diào)線程追加到指定的隊(duì)列中,，等待后臺(tái)工作線程池中的某個(gè)空閑線程對(duì)其進(jìn)行進(jìn)一步處理。
   　

4. 后臺(tái)工作線程池中的每個(gè)線程都分別維護(hù)著兩條長(zhǎng)連接：一條與底層到數(shù)據(jù)庫(kù)服務(wù)相連,，另一條則連接到分布式緩存（memcached）網(wǎng)絡(luò),。通過(guò)讓每個(gè)工作線程維護(hù)屬于自己的長(zhǎng)連接，后臺(tái)工作線程池實(shí)現(xiàn)了數(shù)據(jù)庫(kù)和分布式緩存連接池機(jī)制。長(zhǎng)連接（Keep-Alive）通過(guò)為不同的請(qǐng)求重復(fù)使用同一條網(wǎng)絡(luò)連接大大提高了應(yīng)用程序處理效率和網(wǎng)絡(luò)利用率,。
   　

5. 后臺(tái)工作線程在 Web 請(qǐng)求隊(duì)列上等待新的請(qǐng)求到達(dá),。在從隊(duì)列中取出一個(gè)新的請(qǐng)求后，后臺(tái)工作線程首先嘗試使用分布式緩存服務(wù)命中該請(qǐng)求中的查詢操作,，如果網(wǎng)絡(luò)緩存未命中或該請(qǐng)求需要數(shù)據(jù)庫(kù)寫入等進(jìn)一步處理,，則直接通過(guò)數(shù)據(jù)庫(kù)操作來(lái)完成這個(gè) Web 請(qǐng)求。
   　

6. 當(dāng)一個(gè) Web 請(qǐng)求被處理完成后,，后臺(tái)工作線程會(huì)將處理結(jié)果作為 Web 響應(yīng)以異步 IO 的方式返回到指定客戶端,。
   　

上述步驟粗略描述了一個(gè)典型 Web 應(yīng)用節(jié)點(diǎn)的工作方式。值得注意的是,，由于設(shè)計(jì)思想和具體功能的差異，不同的 Web 應(yīng)用間,，無(wú)論在工作模式或架構(gòu)上都可能存在很大的差異,。

需要說(shuō)明的是，與 epoll/kqueue/event ports 等相位觸發(fā)的通知機(jī)制不同,，對(duì)于 Windows IOCP 和 POSIX AIO Realtime Signal 這類邊緣觸發(fā)的 AIO 完成事件通知機(jī)制,，為了避免操作系統(tǒng)底層 IO 完成隊(duì)列（或?qū)崟r(shí)信號(hào)隊(duì)列）過(guò)長(zhǎng)或溢出導(dǎo)致的內(nèi)存緩沖區(qū)被長(zhǎng)時(shí)間鎖定在非分頁(yè)內(nèi)存池，在上述系統(tǒng)內(nèi)的 AIO 回調(diào)方式實(shí)際上是由兩個(gè)獨(dú)立的線程池和一個(gè) AIO 完成事件隊(duì)列組成的：一個(gè)線程池專門負(fù)責(zé)不間斷地等待系統(tǒng) AIO 完成隊(duì)列中到達(dá)的事件,，并將其提交到一個(gè)內(nèi)部的 AIO 完成隊(duì)列中（該隊(duì)列工作在用戶模式,，具有用戶可控的彈性尺寸，并且不會(huì)鎖定內(nèi)存）,；與此同時(shí)另一個(gè)線程池等待在這個(gè)內(nèi)部 AIO 完成隊(duì)列上,，并且處理不斷到達(dá)該隊(duì)列的 AIO 完成事件。這樣的設(shè)計(jì)降低了操作系統(tǒng)的工作負(fù)擔(dān),，避免了在極端情況下可能出現(xiàn)的消息丟失,、內(nèi)存泄露以及內(nèi)存耗盡等問(wèn)題，同時(shí)也可以幫助操作系統(tǒng)更好地使用和管理非分頁(yè)內(nèi)存池,。

作為典型案例：包括搜索引擎,、Gmail 郵件服務(wù)在內(nèi)的大部分 Google Web 應(yīng)用均是使用 C/C++ 實(shí)現(xiàn)的。得益于 C/C++ 語(yǔ)言的高效和強(qiáng)大,，Google 在為全球 Internet 用戶提供最佳 Web 應(yīng)用體驗(yàn)的同時(shí),，也實(shí)現(xiàn)了在其遍及全球的上百萬(wàn)臺(tái)分布式服務(wù)器上完成一次 Web 搜索，總能耗僅需 0.0003 kW·h 的優(yōu)異表現(xiàn),。關(guān)于 Google Web 應(yīng)用架構(gòu)以及硬件規(guī)模等進(jìn)一步討論,，請(qǐng)參考：http://en./wiki/Google 以及 http://en./wiki/Google_search。

Memcached 服務(wù)作為一個(gè)完全基于內(nèi)存和 對(duì)的分布式數(shù)據(jù)對(duì)象緩沖服務(wù),，擁有令人難以置信的查詢效率以及一個(gè)優(yōu)雅的,，無(wú)需服務(wù)器間通信的大型分布式架構(gòu)。對(duì)于高負(fù)載 Web 應(yīng)用來(lái)說(shuō),，Memcached 常被用作一種重要的數(shù)據(jù)庫(kù)訪問(wèn)加速服務(wù),，因此它不是一個(gè)必選組件。用戶完全可以等到現(xiàn)實(shí)環(huán)境下的數(shù)據(jù)庫(kù)服務(wù)出現(xiàn)了性能瓶頸時(shí)在部署它,。值得強(qiáng)調(diào)的是,，雖然 memcached 并不是一個(gè)必選組件，但通過(guò)其在 YouTube,、Wikipedia,、Amazon.com、SourceForge,、Facebook,、Twitter 等大型 Web 應(yīng)用上的多年部署可以證明：memcached 不但能夠在高負(fù)載環(huán)境下長(zhǎng)期穩(wěn)定地工作，而且可以戲劇性地提升數(shù)據(jù)查詢的整體效率,。有關(guān) memcached 的進(jìn)一步討論,，請(qǐng)參考：http://en./wiki/Memcached。

當(dāng)然,，我們也應(yīng)該注意到：以 memcached 為代表的分布式緩存系統(tǒng),，其本質(zhì)上是一種以犧牲一致性為代價(jià)來(lái)提升平均訪問(wèn)效率的妥協(xié)方案——緩存服務(wù)為數(shù)據(jù)庫(kù)中的部分記錄增加了分布式副本。對(duì)于同一數(shù)據(jù)的多個(gè)分布式副本來(lái)說(shuō),，除非使用 Paxos,、Raft 等一致性算法，不然無(wú)法實(shí)現(xiàn)強(qiáng)一致性保證,。

矛盾的是,，memory cache 本身就是用來(lái)提升效率的，這使得為了它使用上述開(kāi)銷高昂的分布式強(qiáng)一致性算法變得非常不切實(shí)際：目前的分布式強(qiáng)一致性算法均要求每次訪問(wèn)請(qǐng)求（無(wú)論讀寫）都需要同時(shí)訪問(wèn)包括后臺(tái)數(shù)據(jù)庫(kù)主從節(jié)點(diǎn)在內(nèi)的多數(shù)派副本——顯然,，這還不如干脆不使用緩存來(lái)的有效率,。

另外，即使是 Paxos、Raft 之類的分布式一致性算法也只能在單個(gè)記錄的級(jí)別上保證強(qiáng)一致,。意即：即使應(yīng)用了此類算法,，也無(wú)法憑此提供事務(wù)級(jí)的強(qiáng)一致性保證。

除此之外,，分布式緩存也增加了程序設(shè)計(jì)的復(fù)雜度（需要在訪問(wèn)數(shù)據(jù)庫(kù)的同時(shí)嘗試命中或更新緩存）,，并且還增加了較差情形下的訪問(wèn)延遲（如：未命中時(shí)的 RTT 等待延遲，以及節(jié)點(diǎn)下線,、網(wǎng)絡(luò)通信故障時(shí)的延遲等）,。

與此同時(shí)，可以看到：從二十年前開(kāi)始,，各主流數(shù)據(jù)庫(kù)產(chǎn)品其實(shí)均早已實(shí)現(xiàn)了成熟,、高命中率的多層（磁盤塊、數(shù)據(jù)頁(yè),、結(jié)果集等）緩存機(jī)制,。既然分布式緩存有如此多的缺陷，而數(shù)據(jù)庫(kù)產(chǎn)品又自帶了優(yōu)秀的緩存機(jī)制,，它為何又能夠成為現(xiàn)代高負(fù)載 Web App 中的重要基石呢？

其根本原因在于：對(duì)于十年前的技術(shù)環(huán)境來(lái)說(shuō),，當(dāng)時(shí)十分缺乏橫向擴(kuò)展能力的 RDBMS（SQL）系統(tǒng)已成為了嚴(yán)重制約 Web App 等網(wǎng)絡(luò)應(yīng)用擴(kuò)大規(guī)模的瓶頸,。為此，以 Google BigTable,、Facebook Cassandra,、MongoDB 為代表的 NoSQL 數(shù)據(jù)庫(kù)產(chǎn)品，以及以 memcached,、redis 為代表的分布式緩存產(chǎn)品紛紛粉墨登場(chǎng),，并各自扮演了重要作用。

與 MySQL,、ORACLE、DB2,、MS SQL Server,、PostgreSQL 等當(dāng)時(shí)的 '傳統(tǒng)' SQL數(shù)據(jù)庫(kù)產(chǎn)品相比，無(wú)論 NoSQL 數(shù)據(jù)庫(kù)還是分布式緩存產(chǎn)品,，其本質(zhì)上都是以犧牲前者的強(qiáng)一致性為代價(jià),，來(lái)?yè)Q取更優(yōu)的橫向擴(kuò)展能力。

應(yīng)當(dāng)看到,，這種取舍是在當(dāng)時(shí)技術(shù)條件下做出的無(wú)奈,、痛苦的抉擇，系統(tǒng)因此而變得復(fù)雜——在需要事務(wù)和強(qiáng)一致性保障，并且數(shù)據(jù)量較少的地方,，使用無(wú)緩存層的傳統(tǒng) RDBMS,；在一致性方面有一定妥協(xié)余地，并且讀多寫少的地方盡量使用分布式緩存來(lái)加速,；在對(duì)一致性要求更低的大數(shù)據(jù)上使用 NoSQL,；如果數(shù)據(jù)量較大，同時(shí)對(duì)一致性要求也較高,，就只能嘗試通過(guò)對(duì) RDMBS 分庫(kù)分表等方法來(lái)盡量解決,，為此還要開(kāi)發(fā)各種中間件來(lái)實(shí)現(xiàn)數(shù)據(jù)訪問(wèn)的請(qǐng)求分發(fā)和結(jié)果集聚合等復(fù)雜操作……各種情形不一而足，而它們的相互組合和交織則再次加劇了復(fù)雜性,。

回顧起來(lái),，這是一個(gè)舊秩序被打破，新秩序又尚未建立起來(lái)的混亂時(shí)代——老舊 RMDBS 缺乏橫向擴(kuò)展能力,，無(wú)法滿足新時(shí)代的大數(shù)據(jù)處理需求,，又沒(méi)有一種能夠替代老系統(tǒng)地位，可同時(shí)滿足大部分用戶需求的普適級(jí)結(jié)構(gòu)化數(shù)據(jù)管理方案,。

這是一個(gè)青黃不接的時(shí)代,，而 BigTable、Cassandra,、memcached 等產(chǎn)品則分別是 Google,、Facebook 以及 LiveJournal 等廠商在那個(gè)時(shí)代進(jìn)行 '自救' 的結(jié)果。這樣以：'花費(fèi)最小代價(jià),，滿足自身業(yè)務(wù)需求即可' 為目標(biāo)的產(chǎn)物自然不太容易具備很好的普適性,。

然而今天（2015），我們終于就快要走出這個(gè)窘境,。隨著 Google F1,、MySQL Cluster（NDB）、Clustrix,、VoltDB,、MemSQL、NuoDB 等眾多 NewSQL 解決方案的逐步成熟以及技術(shù)的不斷進(jìn)步,，橫向擴(kuò)展能力逐漸不再成為 RDBMS 的瓶頸,。今天的架構(gòu)設(shè)計(jì)師完全可以在確保系統(tǒng)擁有足夠橫向擴(kuò)展能力的同時(shí)，實(shí)現(xiàn)分布式的事務(wù)級(jí)（XA）強(qiáng)一致性保證：

如上圖所示,，在 NewSQL 具備了良好的橫向擴(kuò)展能力后,，架構(gòu)中不再迫切需要分布式緩存和 NoSQL 產(chǎn)品來(lái)彌補(bǔ)這方面的短板，這使得設(shè)計(jì)和開(kāi)發(fā)工作再次回歸到了最初的簡(jiǎn)潔和清晰,。而對(duì)象存儲(chǔ)（Object Storage）服務(wù)則提供了對(duì)音頻,、視頻,、圖片、文件包等海量非結(jié)構(gòu)化BLOB數(shù)據(jù)的存儲(chǔ)和訪問(wèn)支持,。

這樣簡(jiǎn)潔,、清晰、樸素的架構(gòu)使一切看起來(lái)仿佛回歸到了多年以前,，對(duì)象存儲(chǔ)服務(wù)就像 FAT,、NTFS、Ext3 等磁盤文件系統(tǒng),，NewSQL 服務(wù)則好像當(dāng)年 MySQL,、SQL Server 等 '單機(jī)版' 數(shù)據(jù)庫(kù)。但一切卻又已不同,，業(yè)務(wù)邏輯,、數(shù)據(jù)庫(kù)和文件存儲(chǔ)均已演進(jìn)成為支持橫向擴(kuò)展的高可用集群，在性能,、容量,、可用性、可靠性,、可伸縮性等方面有了巨大的飛躍：人類總是以螺旋上升的方式不斷進(jìn)步——在每一次看似回歸的變遷中,，實(shí)包含了本質(zhì)的升華。

隨著 GlusterFS,、Ceph,、Lustre 等可 mount 且支持 Native File API 的分布式文件系統(tǒng)越來(lái)越成熟和完善，也有望于大部分場(chǎng)合下逐漸替換現(xiàn)有的對(duì)象存儲(chǔ)服務(wù),。至此 Web App 架構(gòu)的演進(jìn)才能算是完成了一次重生——這還算不上是涅槃，當(dāng)我們能夠在真正意義上實(shí)現(xiàn)出高效,、高可用的多虛一（Single System Image）系統(tǒng)時(shí),，涅槃才真正降臨。那時(shí)的我們編寫分布式應(yīng)用與如今編寫一個(gè)單機(jī)版的多線程應(yīng)用將不會(huì)有任何區(qū)別——進(jìn)程天然就是分布式,、高可用的,！

具體來(lái)說(shuō)，在項(xiàng)目驗(yàn)證,、應(yīng)用部署和服務(wù)運(yùn)營(yíng)的初期階段,，可以將以上三層服務(wù)組件集中部署于同一臺(tái)物理服務(wù)器或 VPS 內(nèi)。與此同時(shí),，可通過(guò)取消 memcached 服務(wù),，以及使用資源開(kāi)銷小并且易于部署的嵌入式數(shù)據(jù)庫(kù)產(chǎn)品來(lái)進(jìn)一步降低部署難度和系統(tǒng)整體資源開(kāi)銷,。

隨著項(xiàng)目運(yùn)營(yíng)的擴(kuò)大和負(fù)載的持續(xù)加重，當(dāng)單服務(wù)器方案和簡(jiǎn)單的縱向擴(kuò)展已無(wú)法滿足項(xiàng)目運(yùn)營(yíng)負(fù)荷時(shí),，用戶即可通過(guò)將各組件分布式地運(yùn)行在多臺(tái)服務(wù)器內(nèi)來(lái)達(dá)到橫向擴(kuò)展的目的,。例如：反向代理可通過(guò) DNS CNAME 記錄輪轉(zhuǎn)或 3/4 層轉(zhuǎn)發(fā)（LVS、HAProxy等）的方式實(shí)現(xiàn)分布式負(fù)載均衡,。應(yīng)用服務(wù)則可由反向代理使用基于輪轉(zhuǎn)或最小負(fù)載優(yōu)先等策略來(lái)實(shí)現(xiàn)分布式和負(fù)載均衡,。此外，使用基于共享 IP 的服務(wù)器集群方案也能夠?qū)崿F(xiàn)負(fù)載均衡和容錯(cuò)機(jī)制,。

與此類似,，memcached 和數(shù)據(jù)庫(kù)產(chǎn)品也都有自己的分布式運(yùn)算、負(fù)載均衡以及容錯(cuò)方案,。此外,，數(shù)據(jù)庫(kù)訪問(wèn)性能瓶頸可通過(guò)更換非關(guān)系式（NoSQL）的數(shù)據(jù)庫(kù)產(chǎn)品，或使用主-從數(shù)據(jù)庫(kù)加復(fù)制等方式來(lái)提升,。而數(shù)據(jù)庫(kù)查詢性能則可通過(guò)部署 memcached 或類似服務(wù)來(lái)極大程度地改善,。