免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

盡管我們可以用成百上千臺(tái)服務(wù)器處理請(qǐng)求，但是他們都是用同一個(gè)數(shù)據(jù)庫(kù)存儲(chǔ)和檢索數(shù)據(jù)。

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

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

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

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

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

這對(duì)于中小型的 Web 應(yīng)用來(lái)說(shuō)沒(méi)問(wèn)題， 但是像 Facebook 這樣的則不會(huì)這樣做了。

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

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

• 開(kāi)發(fā)團(tuán)隊(duì)隨著應(yīng)用的發(fā)展而增長(zhǎng)。但是隨著越來(lái)越多的開(kāi)發(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í)候，這種互相依賴(lài)性很危險(xiǎn)。

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

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

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

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

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

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

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

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

你去過(guò)游樂(lè)園嗎？你是否走到售票柜臺(tái)去買(mǎi)票？也許不是這樣，可能是排隊(duì)等候。

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

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

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

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

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

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

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

使用這樣的隊(duì)列有許多優(yōu)點(diǎn)：

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

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

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

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

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

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

用戶(hù)名如果以 A 開(kāi)頭，會(huì)被 mini-facebook A 處理， 用戶(hù)名如果以 B 開(kāi)頭，會(huì)被 mini-facebook B 來(lái)處理……

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

到目前為止，我們一直使用一個(gè)負(fù)載均衡器，即使你購(gòu)買(mǎi)的一些功能強(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)稱(chēng)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èn)題一直縈繞在你的腦海：'云服務(wù)是怎樣的呢？'

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

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

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

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