典型 Web App 架構(gòu)

反向代理服務(wù)

以下是一個(gè)典型的高負(fù)載 web 應(yīng)用示例：上圖展示了一個(gè)典型的，三層架構(gòu)的高性能 Web 應(yīng)用纱皆。這種成熟的架構(gòu)多年以來(lái)已被廣泛部署于包括 Google湾趾、Yahoo、Facebook派草、Twitter搀缠、Wikipedia 在內(nèi)的諸多大型 Web 應(yīng)用中。

位于三層構(gòu)架中最外層的反向代理服務(wù)器負(fù)責(zé)接受用戶的接入請(qǐng)求近迁，在實(shí)際應(yīng)用中胡嘿，代理服務(wù)器通常至少還要完成以下列表中的一部分任務(wù)：

連接管理：分別維護(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)用服務(wù)

應(yīng)用服務(wù)層位于數(shù)據(jù)庫(kù)等后端通用服務(wù)層與反向代理層之間，向上接收由反向代理服務(wù)轉(zhuǎn)發(fā)而來(lái)的客戶端訪問(wèn)請(qǐng)求上祈，向下訪問(wèn)由數(shù)據(jù)庫(kù)層提供的結(jié)構(gòu)化存儲(chǔ)與數(shù)據(jù)查詢服務(wù)培遵。

應(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è)重要部分組成，其伺服流程如下：

當(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)行處理春畔。

在 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)求。

如果指定的 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)一步處理塔逃。

后臺(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ò)利用率。

后臺(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)求。

當(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)一步討論晒屎，你可以加這個(gè)群獲取：交流學(xué)習(xí)群：744642380里面會(huì)分享一些資深架構(gòu)師錄制的視頻錄像：有Spring缓升，MyBatis鼓鲁，Netty源碼分析，高并發(fā)港谊、高性能骇吭、分布式、微服務(wù)架構(gòu)的原理歧寺，JVM性能優(yōu)化這些成為架構(gòu)師必備的知識(shí)體系燥狰。還能領(lǐng)取免費(fèi)的學(xué)習(xí)資源，目前受益良多

數(shù)據(jù)庫(kù)和memcached服務(wù)

數(shù)據(jù)庫(kù)服務(wù)為上層

Web 應(yīng)用提供關(guān)系式或結(jié)構(gòu)化的數(shù)據(jù)存儲(chǔ)與查詢支持成福。取決于具體用例碾局，Web

應(yīng)用可以使用數(shù)據(jù)庫(kù)連接器之類的插件機(jī)制來(lái)提供對(duì)不同數(shù)據(jù)庫(kù)服務(wù)的訪問(wèn)支持。在這種架構(gòu)下奴艾，用戶可以靈活地選擇或變更最適合企業(yè)現(xiàn)階段情況的不同數(shù)據(jù)庫(kù)產(chǎn)品净当。例如：用戶可以在原型階段使用

SQLite 之類的嵌入式引擎完成快速部署和功能驗(yàn)證；而在應(yīng)用的初期階段切換到廉價(jià)的 MySql

數(shù)據(jù)庫(kù)解決方案蕴潦；等到業(yè)務(wù)需求不斷上升像啼，數(shù)據(jù)庫(kù)負(fù)載不斷加重時(shí)再向 Clustrix、MongoDB潭苞、Cassandra忽冻、MySql

Cluster、ORACLE 等更昂貴和復(fù)雜的解決方案進(jìn)行遷移此疹。

Memcached 服務(wù)作為一個(gè)完全基于內(nèi)存和

Value> 對(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)一步討論篡悟，你可以加這個(gè)群獲取：交流學(xué)習(xí)群：744642380里面會(huì)分享一些資深架構(gòu)師錄制的視頻錄像：有Spring匾寝，MyBatis搬葬，Netty源碼分析，高并發(fā)艳悔、高性能急凰、分布式、微服務(wù)架構(gòu)的原理猜年，JVM性能優(yōu)化這些成為架構(gòu)師必備的知識(shí)體系抡锈。還能領(lǐng)取免費(fèi)的學(xué)習(xí)資源，目前受益良多

當(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)程天然就是分布式、高可用的栏渺！

三層架構(gòu)的可伸縮性

小到集中部署于單臺(tái)物理服務(wù)器或 VPS 內(nèi)呛梆，大到 Google 遍及全球的上百萬(wàn)臺(tái)物理服務(wù)器所組成的分布式應(yīng)用。前文描述的三層 Web 應(yīng)用架構(gòu)體現(xià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)極大程度地改善送漠。