作者 | Wolfram Hempel?

翻譯 | Join

你開發(fā)了一個(gè)網(wǎng)站（例如網(wǎng)上商店、社交網(wǎng)站或者其他任何東西），之后你把它發(fā)布到了網(wǎng)上，網(wǎng)站運(yùn)行良好，每天有幾百的訪問量，能快速地相響應(yīng)用戶的請(qǐng)求。

但是有一天，不知道什么原因，你的網(wǎng)站出名了！?

每分每秒都有成千上萬的用戶蜂擁而至，你的網(wǎng)站變得越來越慢……

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

如何進(jìn)行擴(kuò)展？

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

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

• 隨著計(jì)算機(jī)性能的增長(zhǎng)，其價(jià)格會(huì)成倍增長(zhǎng)

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

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

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

1.單臺(tái)服務(wù)器 + 數(shù)據(jù)庫(kù)

?

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

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

2. 增加一個(gè)反向代理

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

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

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

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

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

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

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

3.引入負(fù)載均衡器

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

負(fù)載均衡器是個(gè)簡(jiǎn)單概念，想象下有一百個(gè)用戶在一分鐘之內(nèi)在你的網(wǎng)店里付款。遺憾的是，你的付款服務(wù)器在一分鐘內(nèi)只能處理50筆付款。這怎么辦呢？同時(shí)運(yùn)行兩個(gè)付款服務(wù)器就行了。

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

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

4.擴(kuò)展數(shù)據(jù)庫(kù)

負(fù)載均衡器的使用使得我們可以在多個(gè)服務(wù)器之間分配負(fù)載。但是你發(fā)現(xiàn)問題了嗎？盡管我們可以用成百上千臺(tái)服務(wù)器處理請(qǐng)求，但是他們都是用同一個(gè)數(shù)據(jù)庫(kù)存儲(chǔ)和檢索數(shù)據(jù)。

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

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

我們需要做的第一件事是把數(shù)據(jù)庫(kù)分成多個(gè)部分。一部分專門負(fù)責(zé)接收并存儲(chǔ)數(shù)據(jù)，其他部分負(fù)責(zé)檢索數(shù)據(jù)。這個(gè)方案有時(shí)稱為主從模式或者單實(shí)例寫多副本讀。這里假設(shè)是從數(shù)據(jù)庫(kù)讀的頻率高于寫的頻率。這個(gè)方案的好處是保證了一致性，因?yàn)閿?shù)據(jù)只能被單實(shí)例寫入，之后把寫入數(shù)據(jù)同步到其他部分即可。缺點(diǎn)是我們?nèi)匀恢挥幸粋€(gè)寫數(shù)據(jù)庫(kù)實(shí)例。

這對(duì)于中小型的Web應(yīng)用來說沒問題， 但是像Facebook這樣的則不會(huì)這樣做了。我們會(huì)在第九節(jié)中研究擴(kuò)展數(shù)據(jù)庫(kù)的步驟。

5.微服務(wù)

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

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

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

• 僅有一臺(tái)服務(wù)器，意味著每當(dāng)我們發(fā)布新版本時(shí)，必須要等所有工作完成后才能發(fā)布。當(dāng)一個(gè)團(tuán)隊(duì)想快速地發(fā)布而另外一個(gè)團(tuán)隊(duì)只完成了一半工作的時(shí)候，這種互相依賴性很危險(xiǎn)。

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

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

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

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

6.緩存和內(nèi)容分發(fā)網(wǎng)絡(luò)(CDN)

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

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

緩存的加強(qiáng)版叫內(nèi)容分發(fā)網(wǎng)絡(luò)（Content Delivery Network），遍布全球的大量緩存。 這使得用戶可以從物理上靠近他們的地方來獲取網(wǎng)頁(yè)內(nèi)容，而不是每次都把數(shù)據(jù)從源頭搬到用戶那里。

7.消息隊(duì)列

你去過游樂園嗎？你是否走到售票柜臺(tái)去買票？也許不是這樣，可能是排隊(duì)等候。政府機(jī)構(gòu)、郵局、游樂園入口都屬于并行概念的例子，多個(gè)售票亭同時(shí)售票，但似乎也永遠(yuǎn)不足以為每個(gè)人立即服務(wù)，于是隊(duì)列形成了。

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

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

• 存儲(chǔ)原始的、未處理的圖片

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

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

這個(gè)待辦事項(xiàng)列表中的任務(wù)可以被其他任意數(shù)量服務(wù)接收，每個(gè)服務(wù)完成其中一個(gè)任務(wù)，直到所有的待辦事項(xiàng)完成。管理這些“待辦事項(xiàng)列表”的稱為消息隊(duì)列。使用這樣的隊(duì)列有許多優(yōu)點(diǎn)：

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

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

好了，如果按照我們上面的所有步驟操作下來，我們的系統(tǒng)已經(jīng)做好提供大流量服務(wù)的準(zhǔn)備了。但是如果還想提供更大量的，該怎么做呢？還有一些可以做：

8.分片，分片，還是分片

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

"Sharding is a technique of parallelizing an application's stacks by separating them into multiple units, each responsible for a certain key or namespace"

哎呦...... 分片究竟是是什么意思呢？

其實(shí)也很簡(jiǎn)單：Facebook上需要為20億用戶提供個(gè)人資料, 可以把你的應(yīng)用架構(gòu)分解為 26個(gè)mini-Facebook,?用戶名如果以A開頭，會(huì)被mini-facebook A處理， 用戶名如果以B開頭，會(huì)被mini-facebook B來處理……

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

9. 對(duì)負(fù)載均衡器進(jìn)行負(fù)載均衡

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

幸運(yùn)地是，我們可以有一個(gè)全球性、分散且穩(wěn)定的層，用于在請(qǐng)求達(dá)到負(fù)載均衡器之前對(duì)請(qǐng)求負(fù)載均衡。最棒的地方是免費(fèi)，這是域名系統(tǒng)或簡(jiǎn)稱DNS。DNS將域名(如arcentry.com)映射到IP，143.204.47.77。DNS允許我們?yōu)橛蛎付ǘ鄠€(gè)IP，每個(gè)IP都會(huì)解析到不同的負(fù)載均衡器。

你看，擴(kuò)展Web應(yīng)用確實(shí)需要考慮很多東西，感謝你和我們一起待了這么久。我希望這篇文章能給你一些有用的東西。但是如果你做任何IT領(lǐng)域相關(guān)的工作，你在閱讀本文的時(shí)候，可能有個(gè)問題一直縈繞在你的腦海："云服務(wù)是怎樣的呢？"

Cloud Computing / Serverless

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

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

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

但是,并不是說你使用了云服務(wù)以后(如 Amazon Web Service Lambda)，所有的問題都解決了,它隨之而來的是一系列挑戰(zhàn)和權(quán)衡。請(qǐng)繼續(xù)關(guān)注本系列的下一篇文章，

了解更多關(guān)于"the cloud for newbs and non-techies".

?

原文鏈接：

https://arcentry.com/blog/scaling-webapps-for-newbs-and-non-techies/

總結(jié)

以上是生活随笔為你收集整理的图解：从单个服务器扩展到百万用户的系统的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。