但是有一天，不知道什么原因，你的網(wǎng)站出名了！ 每分每秒都有成千上萬的用戶蜂擁而至，你的網(wǎng)站變得越來越慢……

對你來講，這是個好消息，但是對你的 Web 應(yīng)用來說這是個壞消息。因為現(xiàn)在它需要擴(kuò)展了，你的應(yīng)用需要為全球用戶提供 7*24 不宕機(jī)服務(wù)。

幾年前，我討論過水平擴(kuò)展與垂直擴(kuò)展。簡而言之， 垂直擴(kuò)展意味著在性能更強(qiáng)的計算機(jī)上運(yùn)行同樣的服務(wù)，而水平擴(kuò)展是并行地運(yùn)行多個服務(wù)。

如今，幾乎沒有人說垂直擴(kuò)展了。原因很簡單：

• 隨著計算機(jī)性能的增長，其價格會成倍增長。

• 單臺計算機(jī)的性能是有上限的，不可能無限制地垂直擴(kuò)展。

• 多核 CPU 意味著即使是單臺計算機(jī)也可以并行的。那么，為什么不一開始就并行化呢？

現(xiàn)在我們水平擴(kuò)展服務(wù)。需要哪些步驟呢？

上圖可能是你后端服務(wù)最初的樣子。有一個執(zhí)行業(yè)務(wù)邏輯的應(yīng)用服務(wù)器（Application Server）和保存數(shù)據(jù)的數(shù)據(jù)庫。

看上去很不錯。但是這樣的配置，滿足更高要求的唯一方法是在性能更強(qiáng)的計算機(jī)上運(yùn)行，這點不是很好。

成為大規(guī)模服務(wù)架構(gòu)的第一步是添加反向代理。類似于酒店大堂的接待處。

你也可以讓客人直接去他們的客房。但是實際上，你需要一個中間人他去檢查是否允許客人進(jìn)入， 如果客房沒有開放，得有人告訴客人，而不是讓客人處于尷尬的境地。這些事情正是反向代理需要做的。

通常，代理是一個接收和轉(zhuǎn)發(fā)請求的過程。正常情況下，「正向代理」代理的對象是客戶端，「反向代理」代理的對象是服務(wù)端，它完成這些功能：

• 健康檢查功能，確保我們的服務(wù)器是一直處于運(yùn)行狀態(tài)的。

• 路由轉(zhuǎn)發(fā)功能，把請求轉(zhuǎn)發(fā)到正確的服務(wù)路徑上。

• 認(rèn)證功能，確保用戶有權(quán)限訪問后端服務(wù)器。

• 防火墻功能，確保用戶只能訪問允許使用的網(wǎng)絡(luò)部分等等。

大多數(shù)反向代理還有另外一個功能：他們也可以充當(dāng)負(fù)載均衡器。

負(fù)載均衡器是個簡單概念，想象下有一百個用戶在一分鐘之內(nèi)在你的網(wǎng)店里付款。

遺憾的是，你的付款服務(wù)器在一分鐘內(nèi)只能處理 50 筆付款。這怎么辦呢？同時運(yùn)行兩個付款服務(wù)器就行了。

負(fù)載均衡器的功能就是把付款請求分發(fā)到兩臺付款服務(wù)器上。用戶 1 往左，用戶 2 往右，用戶 3 再往左。。。以此類推。

如果一次有 500 個用戶需要立刻付款，這該怎么解決呢？確切地說，你可以擴(kuò)展到十臺付款服務(wù)器，之后讓負(fù)載均衡器分發(fā)請求到這十臺服務(wù)器上。

負(fù)載均衡器的使用使得我們可以在多個服務(wù)器之間分配負(fù)載。但是你發(fā)現(xiàn)問題了嗎？

盡管我們可以用成百上千臺服務(wù)器處理請求，但是他們都是用同一個數(shù)據(jù)庫存儲和檢索數(shù)據(jù)。

那么，我們不能以同樣的方式來擴(kuò)展數(shù)據(jù)庫嗎？很遺憾，這里有個一致性的問題。

系統(tǒng)使用的所有服務(wù)需要就他們使用的數(shù)據(jù)達(dá)成一致。數(shù)據(jù)不一致會導(dǎo)致各種問題，如訂單被多次處理，從一個余額只有 100 元的賬戶中扣除兩筆 90 元的付款等等......那么我們在擴(kuò)展數(shù)據(jù)庫的時候如何確保一致性呢？

我們需要做的第一件事是把數(shù)據(jù)庫分成多個部分。一部分專門負(fù)責(zé)接收并存儲數(shù)據(jù)，其他部分負(fù)責(zé)檢索數(shù)據(jù)。

這個方案有時稱為主從模式或者單實例寫多副本讀。這里假設(shè)是從數(shù)據(jù)庫讀的頻率高于寫的頻率。

這個方案的好處是保證了一致性，因為數(shù)據(jù)只能被單實例寫入，之后把寫入數(shù)據(jù)同步到其他部分即可。缺點是我們?nèi)匀恢挥幸粋€寫數(shù)據(jù)庫實例。

這對于中小型的 Web 應(yīng)用來說沒問題， 但是像 Facebook 這樣的則不會這樣做了。

到目前為止，我們的付款、訂單、庫存、用戶管理等等這些功能都在一臺服務(wù)器上。

這也不是壞事，單個服務(wù)器同時意味著更低的復(fù)雜性。隨著規(guī)模的增加，事情會變得復(fù)雜和低效：

• 開發(fā)團(tuán)隊隨著應(yīng)用的發(fā)展而增長。但是隨著越來越多的開發(fā)人員工作在同一臺服務(wù)器上，發(fā)生沖突的可能性很大。

• 僅有一臺服務(wù)器，意味著每當(dāng)我們發(fā)布新版本時，必須要等所有工作完成后才能發(fā)布。

  當(dāng)一個團(tuán)隊想快速地發(fā)布而另外一個團(tuán)隊只完成了一半工作的時候，這種互相依賴性很危險。

對于這些問題的解決方案是一個新的架構(gòu)范式，微服務(wù)。它已經(jīng)在開發(fā)人員中掀起了風(fēng)暴：

• 每個服務(wù)都可以單獨擴(kuò)展，更好地適應(yīng)需求。

• 開發(fā)團(tuán)隊之間相互獨立，每個團(tuán)隊都負(fù)責(zé)自己的微服務(wù)生命周期(創(chuàng)建，部署，更新等)。

• 每個微服務(wù)都有自己的資源，比如數(shù)據(jù)庫，進(jìn)一步緩解了第 4 節(jié)中的問題。

有什么方式能使服務(wù)更高效? 網(wǎng)絡(luò)應(yīng)用的很大一部由靜態(tài)資源構(gòu)成，如圖片、CSS 樣式文件、JavaScript 腳本以及一些針對特定產(chǎn)品提前渲染好的頁面等等。

我們使用緩存而不是對每個請求都重新處理，緩存用于記住最后一次的結(jié)果并交由其他服務(wù)或者客戶端，這樣就不用每次都請求后端服務(wù)了。

緩存的加強(qiáng)版叫內(nèi)容分發(fā)網(wǎng)絡(luò)（Content Delivery Network），遍布全球的大量緩存。

這使得用戶可以從物理上靠近他們的地方來獲取網(wǎng)頁內(nèi)容，而不是每次都把數(shù)據(jù)從源頭搬到用戶那里。

你去過游樂園嗎？你是否走到售票柜臺去買票？也許不是這樣，可能是排隊等候。

政府機(jī)構(gòu)、郵局、游樂園入口都屬于并行概念的例子，多個售票亭同時售票，但似乎也永遠(yuǎn)不足以為每個人立即服務(wù)，于是隊列形成了。

隊列同樣也是用于大型 Web 應(yīng)用。每分鐘都有成千上萬的圖片上傳到 Instagram、Facebook 每個圖片都需要處理，調(diào)整大小，分析與打標(biāo)簽，這些都是耗時的處理過程。

因此，不要讓用戶等到完成所有步驟，圖片接收服務(wù)只需要做以下三件事：

• 存儲原始的、未處理的圖片。

• 向用戶確認(rèn)圖片已經(jīng)上傳。

• 創(chuàng)建一個待辦的任務(wù)。

這個待辦事項列表中的任務(wù)可以被其他任意數(shù)量服務(wù)接收，每個服務(wù)完成其中一個任務(wù)，直到所有的待辦事項完成。管理這些“待辦事項列表”的稱為消息隊列。

使用這樣的隊列有許多優(yōu)點：

• 解耦了任務(wù)和處理過程。有時需要處理大量的圖片，有時很少。有時有大量服務(wù)可用，有時很少可用。簡單地把任務(wù)添加到待辦事項而不是直接處理它們，這確保了系統(tǒng)保持響應(yīng)并且任務(wù)也不會丟失。

• 可以按需擴(kuò)展。啟動大量的服務(wù)比較耗時，所以當(dāng)有大量用戶上傳圖片時再去啟動服務(wù)，這已經(jīng)太晚了。我們把任務(wù)添加到隊列中，我們可以推遲提供額外的處理能力。

好了，如果按照我們上面的所有步驟操作下來，我們的系統(tǒng)已經(jīng)做好提供大流量服務(wù)的準(zhǔn)備了。

但是如果還想提供更大量的，該怎么做呢？還有一些可以做。

什么是分片？好吧，深呼吸一下，準(zhǔn)備好了嗎？我們看下定義：

哎呦...... 分片究竟是什么意思呢？其實也很簡單：Facebook 上需要為 20 億用戶提供個人資料, 可以把你的應(yīng)用架構(gòu)分解為 26 個 mini-Facebook。

用戶名如果以 A 開頭，會被 mini-facebook A 處理， 用戶名如果以 B 開頭，會被 mini-facebook B 來處理……

分片不一定按字母順序，根據(jù)業(yè)務(wù)需要，你可以基于任何數(shù)量的因素，比如位置、使用頻率(特權(quán)用戶被路由到好的硬件)等等。你可以根據(jù)需要以這種方式切分服務(wù)器、數(shù)據(jù)庫或其他方面。

到目前為止，我們一直使用一個負(fù)載均衡器，即使你購買的一些功能強(qiáng)悍(且其價格極其昂貴)的硬件負(fù)載均衡器，但是他們可以處理的請求量也存在硬件限制。

幸運(yùn)地是，我們可以有一個全球性、分散且穩(wěn)定的層，用于在請求達(dá)到負(fù)載均衡器之前對請求負(fù)載均衡。

最棒的地方是免費，這是域名系統(tǒng)或簡稱DNS。DNS 將域名(如 arcentry.com)映射到 IP，143.204.47.77。DNS 允許我們?yōu)橛蛎付ǘ鄠€ IP，每個 IP 都會解析到不同的負(fù)載均衡器。

你看，擴(kuò)展 Web 應(yīng)用確實需要考慮很多東西，感謝你和我們一起待了這么久。

我希望這篇文章能給你一些有用的東西。但是如果你做任何 IT 領(lǐng)域相關(guān)的工作，你在閱讀本文的時候，可能有個問題一直縈繞在你的腦海：'云服務(wù)是怎樣的呢？'

但是云服務(wù)如何呢？確實，它是上面許多問題最有效的解決方案。

你無需解決這些難題。相反，這些難題留給了云廠商，他們?yōu)槲覀兲峁┮粋€系統(tǒng)，可以根據(jù)需求進(jìn)行擴(kuò)展，而不用擔(dān)心錯綜復(fù)雜的問題。

例如，Arcentry 網(wǎng)站不會執(zhí)行上述討論的任何操作(除了數(shù)據(jù)庫的讀寫分離)，而只是把這些難題留給 Amazon Web Service Lambda 函數(shù)處理了，用戶省去了煩惱。

但是，并不是說你使用了云服務(wù)以后(如 Amazon Web Service Lambda)所有的問題都解決了，它隨之而來的是一系列挑戰(zhàn)和權(quán)衡。