作者：Wolfram Hempel ，Join
翻譯編輯：陶家龍、孫淑娟
出處：微信公眾號碼農翻身（ID：coderising）點擊鏈接查看原文（英文）

假如你開發(fā)了一個網站（例如網上商店砸讳、社交網站或者其他任何東西），之后你把它發(fā)布到了網上界牡，網站運行良好簿寂，每天有幾百的訪問量，能快速地響應用戶的請求宿亡。

img

但是有一天常遂，不知道什么原因，你的網站出名了挽荠！ 每分每秒都有成千上萬的用戶蜂擁而至克胳，你的網站變得越來越慢……

對你來講，這是個好消息坤按，但是對你的 Web 應用來說這是個壞消息毯欣。因為現在它需要擴展了，你的應用需要為全球用戶提供 7*24 不宕機服務臭脓。

如何進行擴展酗钞？

幾年前，我討論過水平擴展與垂直擴展来累。簡而言之砚作， 垂直擴展意味著在性能更強的計算機上運行同樣的服務，而水平擴展是并行地運行多個服務嘹锁。

如今葫录，幾乎沒有人說垂直擴展了。原因很簡單：

• 隨著計算機性能的增長领猾，其價格會成倍增長米同。
• 單臺計算機的性能是有上限的，不可能無限制地垂直擴展摔竿。
• 多核 CPU 意味著即使是單臺計算機也可以并行的面粮。那么，為什么不一開始就并行化呢继低？

現在我們水平擴展服務熬苍。需要哪些步驟呢？

單臺服務器+數據庫

img

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

看上去很不錯婿脸。但是這樣的配置，滿足更高要求的唯一方法是在性能更強的計算機上運行柄驻，這點不是很好狐树。

增加一個反向代理

img

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

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

通常傲武，代理是一個接收和轉發(fā)請求的過程蓉驹。正常情況下，「正向代理」代理的對象是客戶端揪利，「反向代理」代理的對象是服務端态兴，它完成這些功能：

• 健康檢查功能，確保我們的服務器是一直處于運行狀態(tài)的疟位。
• 路由轉發(fā)功能瞻润，把請求轉發(fā)到正確的服務路徑上。
• 認證功能甜刻，確保用戶有權限訪問后端服務器绍撞。
• 防火墻功能，確保用戶只能訪問允許使用的網絡部分等等得院。

引入負載均衡器

img

大多數反向代理還有另外一個功能：他們也可以充當負載均衡器傻铣。

負載均衡器是個簡單概念，想象下有一百個用戶在一分鐘之內在你的網店里付款祥绞。

遺憾的是非洲，你的付款服務器在一分鐘內只能處理 50 筆付款。這怎么辦呢蜕径？同時運行兩個付款服務器就行了两踏。

負載均衡器的功能就是把付款請求分發(fā)到兩臺付款服務器上。用戶 1 往左丧荐，用戶 2 往右缆瓣，用戶 3 再往左。虹统。弓坞。以此類推隧甚。

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

擴展數據庫

img

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

盡管我們可以用成百上千臺服務器處理請求超歌，但是他們都是用同一個數據庫存儲和檢索數據砍艾。

那么，我們不能以同樣的方式來擴展數據庫嗎巍举？很遺憾脆荷，這里有個一致性的問題。

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

我們需要做的第一件事是把數據庫分成多個部分桃焕。一部分專門負責接收并存儲數據，其他部分負責檢索數據捧毛。

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

這個方案的好處是保證了一致性岖妄，因為數據只能被單實例寫入型将，之后把寫入數據同步到其他部分即可。缺點是我們仍然只有一個寫數據庫實例荐虐。

這對于中小型的 Web 應用來說沒問題七兜， 但是像 Facebook 這樣的則不會這樣做了。

微服務

img

到目前為止福扬，我們的付款腕铸、訂單、庫存铛碑、用戶管理等等這些功能都在一臺服務器上狠裹。

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

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

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

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

對于這些問題的解決方案是一個新的架構范式讥蔽，微服務涣易。它已經在開發(fā)人員中掀起了風暴：

• 每個服務都可以單獨擴展，更好地適應需求冶伞。
• 開發(fā)團隊之間相互獨立新症，每個團隊都負責自己的微服務生命周期(創(chuàng)建，部署碰缔，更新等)账劲。
• 每個微服務都有自己的資源，比如數據庫金抡，進一步緩解了第 4 節(jié)中的問題。

緩存和內容分發(fā)網絡(CDN)

img

有什么方式能使服務更高效? 網絡應用的很大一部由靜態(tài)資源構成腌且，如圖片梗肝、CSS 樣式文件、JavaScript 腳本以及一些針對特定產品提前渲染好的頁面等等铺董。

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

緩存的加強版叫內容分發(fā)網絡（Content Delivery Network）坝锰，遍布全球的大量緩存。

這使得用戶可以從物理上靠近他們的地方來獲取網頁內容重付，而不是每次都把數據從源頭搬到用戶那里顷级。

消息隊列

img

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

政府機構删掀、郵局翔冀、游樂園入口都屬于并行概念的例子，多個售票亭同時售票披泪，但似乎也永遠不足以為每個人立即服務纤子，于是隊列形成了。

隊列同樣也是用于大型 Web 應用。每分鐘都有成千上萬的圖片上傳到 Instagram控硼、Facebook 每個圖片都需要處理泽论，調整大小，分析與打標簽象颖，這些都是耗時的處理過程佩厚。

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

• 存儲原始的抄瓦、未處理的圖片。
• 向用戶確認圖片已經上傳陶冷。
• 創(chuàng)建一個待辦的任務钙姊。

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

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

• 解耦了任務和處理過程沾谜。有時需要處理大量的圖片膊毁，有時很少。有時有大量服務可用基跑，有時很少可用婚温。簡單地把任務添加到待辦事項而不是直接處理它們，這確保了系統(tǒng)保持響應并且任務也不會丟失媳否。
• 可以按需擴展栅螟。啟動大量的服務比較耗時，所以當有大量用戶上傳圖片時再去啟動服務篱竭，這已經太晚了力图。我們把任務添加到隊列中，我們可以推遲提供額外的處理能力掺逼。

好了吃媒，如果按照我們上面的所有步驟操作下來，我們的系統(tǒng)已經做好提供大流量服務的準備了坪圾。

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

分片漓概，分片，還是分片

img

什么是分片病梢？好吧胃珍，深呼吸一下梁肿，準備好了嗎？我們看下定義：

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

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

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

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

對負載均衡器進行負載均衡

img

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

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

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

你看珊搀，擴展 Web 應用確實需要考慮很多東西冶忱，感謝你和我們一起待了這么久。

我希望這篇文章能給你一些有用的東西境析。但是如果你做任何 IT 領域相關的工作囚枪，你在閱讀本文的時候，可能有個問題一直縈繞在你的腦海："云服務是怎樣的呢劳淆？"

Cloud Computing / Serverless

但是云服務如何呢链沼？確實，它是上面許多問題最有效的解決方案沛鸵。

你無需解決這些難題括勺。相反缆八，這些難題留給了云廠商，他們?yōu)槲覀兲峁┮粋€系統(tǒng)疾捍，可以根據需求進行擴展奈辰，而不用擔心錯綜復雜的問題。

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

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