來自：碼農翻身（微信號：coderising）
作者 | Wolfram Hempel
翻譯 | Join
你開發(fā)了一個網(wǎng)站（例如網(wǎng)上商店世蔗、社交網(wǎng)站或者其他任何東西）廷支，之后你把它發(fā)布到了網(wǎng)上禾怠，網(wǎng)站運行良好，每天有幾百的訪問量，能快速地相響應用戶的請求。
但是有一天酸役，不知道什么原因，你的網(wǎng)站出名了驾胆！
每分每秒都有成千上萬的用戶蜂擁而至涣澡，你的網(wǎng)站變得越來越慢……
對你來講，這是個好消息丧诺，但是對你的Web應用來說這是個壞消息入桂。因為現(xiàn)在它需要擴展了，你的應用需要為全球用戶提供7*24不宕機服務驳阎。
如何進行擴展抗愁？
幾年前，我討論過水平擴展與垂直擴展呵晚。簡而言之驹愚， 垂直擴展意味著在性能更強的計算機上運行同樣的服務，而水平擴展是并行地運行多個服務劣纲。
如今，幾乎沒有人說垂直擴展了谁鳍。原因很簡單：
隨著計算機性能的增長癞季，其價格會成倍增長
單臺計算機的性能是有上限的，不可能無限制地垂直擴展
多核CPU意味著即使是單臺計算機也可以并行的倘潜。那么绷柒，為什么不一開始就并行化呢？
現(xiàn)在我們水平擴展服務涮因。需要哪些步驟呢废睦？
1、單臺服務器 + 數(shù)據(jù)庫
上圖可能是你后端服務最初的樣子养泡。有一個執(zhí)行業(yè)務邏輯的應用服務器（Application Server）和保存數(shù)據(jù)的數(shù)據(jù)庫嗜湃。
看上去很不錯奈应。但是這樣的配置，滿足更高要求的唯一方法是在性能更強的計算機上運行购披，這點不是很好杖挣。
2、增加一個反向代理
成為大規(guī)模服務架構的第一步是添加反向代理刚陡。類似于酒店大堂的接待處惩妇。
你也可以讓客人直接去他們的客房。但是實際上筐乳，你需要一個中間人他去檢查是否允許客人進入歌殃， 如果客房沒有開放，得有人告訴客人蝙云，而不是讓客人處于尷尬的境地氓皱。這些事情正是反向代理需要做的。
通常贮懈，代理是一個接收和轉發(fā)請求的過程匀泊。正常情況下，「正向代理」代理的對象是客戶端朵你，「反向代理」代理的對象是服務端各聘，它完成這些功能：
健康檢查功能，確保我們的服務器是一直處于運行狀態(tài)的
路由轉發(fā)功能抡医，把請求轉發(fā)到正確的服務路徑上
認證功能,確保用戶有權限訪問后端服務器
防火墻功能躲因，確保用戶只能訪問允許使用的網(wǎng)絡部分等等
3、引入負載均衡器
大多數(shù)反向代理還有另外一個功能：他們也可以充當負載均衡器忌傻。
負載均衡器是個簡單概念大脉，想象下有一百個用戶在一分鐘之內在你的網(wǎng)店里付款。遺憾的是水孩，你的付款服務器在一分鐘內只能處理50筆付款镰矿。這怎么辦呢？同時運行兩個付款服務器就行了俘种。
負載均衡器的功能就是把付款請求分發(fā)到兩臺付款服務器上秤标。用戶1往左，用戶2往右宙刘，用戶3再往左苍姜。。悬包。以此類推衙猪。
如果一次有500個用戶需要立刻付款，這該怎么解決呢？確切地說垫释，你可以擴展到十臺付款服務器丝格，之后讓負載均衡器分發(fā)請求到這十臺服務器上。
4饶号、擴展數(shù)據(jù)庫
負載均衡器的使用使得我們可以在多個服務器之間分配負載铁追。但是你發(fā)現(xiàn)問題了嗎？盡管我們可以用成百上千臺服務器處理請求茫船，但是他們都是用同一個數(shù)據(jù)庫存儲和檢索數(shù)據(jù)琅束。
那么，我們不能以同樣的方式來擴展數(shù)據(jù)庫嗎算谈？很遺憾涩禀，這里有個一致性的問題。
系統(tǒng)使用的所有服務需要就他們使用的數(shù)據(jù)達成一致然眼。數(shù)據(jù)不一致會導致各種問題艾船，如訂單被多次處理，從一個余額只有100元的賬戶中扣除兩筆90元的付款等等......那么我們在擴展數(shù)據(jù)庫的時候如何確保一致性呢高每？
我們需要做的第一件事是把數(shù)據(jù)庫分成多個部分屿岂。一部分專門負責接收并存儲數(shù)據(jù)，其他部分負責檢索數(shù)據(jù)鲸匿。這個方案有時稱為主從模式或者單實例寫多副本讀爷怀。這里假設是從數(shù)據(jù)庫讀的頻率高于寫的頻率。這個方案的好處是保證了一致性带欢，因為數(shù)據(jù)只能被單實例寫入运授，之后把寫入數(shù)據(jù)同步到其他部分即可。缺點是我們仍然只有一個寫數(shù)據(jù)庫實例乔煞。
這對于中小型的Web應用來說沒問題吁朦， 但是像Facebook這樣的則不會這樣做了。我們會在第九節(jié)中研究擴展數(shù)據(jù)庫的步驟渡贾。
5逗宜、微服務
到目前為止，我們的付款空骚、訂單纺讲、庫存、用戶管理等等這些功能都在一臺服務器上府怯。
這也不是壞事，單個服務器同時意味著更低的復雜性防楷。隨著規(guī)模的增加牺丙，事情會變得復雜和低效：
開發(fā)團隊隨著應用的發(fā)展而增長。但是隨著越來越多的開發(fā)人員工作在同一臺服務器上，發(fā)生沖突的可能性很大冲簿。
僅有一臺服務器粟判，意味著每當我們發(fā)布新版本時，必須要等所有工作完成后才能發(fā)布峦剔。當一個團隊想快速地發(fā)布而另外一個團隊只完成了一半工作的時候档礁，這種互相依賴性很危險。
對于這些問題的解決方案是一個新的架構范式：微服務吝沫， 它已經(jīng)在開發(fā)人員中掀起了風暴呻澜。
每個服務都可以單獨擴展，更好地適應需求
開發(fā)團隊之間相互獨立惨险，每個團隊都負責自己的微服務生命周期(創(chuàng)建羹幸，部署，更新等)
每個微服務都有自己的資源辫愉，比如數(shù)據(jù)庫栅受，進一步緩解了第4節(jié)中的問題。
6.緩存和內容分發(fā)網(wǎng)絡(CDN)
有什么方式能使服務更高效? 網(wǎng)絡應用的很大一部由靜態(tài)資源構成,如圖片恭朗、CSS樣式文件屏镊、JavaScript腳本以及一些針對特定產品提前渲染好的頁面等等。
我們使用緩存而不是對每個請求都重新處理痰腮，緩存用于記住最后一次的結果并交由其他服務或者客戶端而芥，這樣就不用每次都請求后端服務了。
緩存的加強版叫內容分發(fā)網(wǎng)絡（Content Delivery Network）诽嘉，遍布全球的大量緩存蔚出。這使得用戶可以從物理上靠近他們的地方來獲取網(wǎng)頁內容，而不是每次都把數(shù)據(jù)從源頭搬到用戶那里虫腋。
7骄酗、消息隊列
你去過游樂園嗎？你是否走到售票柜臺去買票悦冀？也許不是這樣趋翻，可能是排隊等候。政府機構盒蟆、郵局踏烙、游樂園入口都屬于并行概念的例子，多個售票亭同時售票历等，但似乎也永遠不足以為每個人立即服務讨惩，于是隊列形成了。
隊列同樣也是用于大型Web應用寒屯。每分鐘都有成千上萬的圖片上傳到Instagram荐捻、Facebook每個圖片都需要處理黍少，調整大小，分析與打標簽处面，這些都是耗時的處理過程厂置。
因此，不要讓用戶等到完成所有步驟魂角，圖片接收服務只需要做以下三件事：
存儲原始的昵济、未處理的圖片
向用戶確認圖片已經(jīng)上傳
創(chuàng)建一個待辦的任務
這個待辦事項列表中的任務可以被其他任意數(shù)量服務接收，每個服務完成其中一個任務野揪，直到所有的待辦事項完成访忿。管理這些“待辦事項列表”的稱為消息隊列。使用這樣的隊列有許多優(yōu)點：
解耦了任務和處理過程囱挑。有時需要處理大量的圖片醉顽，有時很少。有時有大量服務可用平挑，有時很少可用游添。簡單地把任務添加到待辦事項而不是直接處理它們，這確保了系統(tǒng)保持響應并且任務也不會丟失通熄。
可以按需擴展唆涝。啟動大量的服務比較耗時，所以當有大量用戶上傳圖片時再去啟動服務唇辨，這已經(jīng)太晚了廊酣。我們把任務添加到隊列中，我們可以推遲提供額外的處理能力赏枚。
好了亡驰，如果按照我們上面的所有步驟操作下來，我們的系統(tǒng)已經(jīng)做好提供大流量服務的準備了饿幅。但是如果還想提供更大量的凡辱，該怎么做呢？還有一些可以做：
8栗恩、分片透乾，分片，還是分片
什么是分片磕秤？好吧乳乌，深呼吸一下，準備好了嗎市咆？我們看下定義：
"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來處理……
分片不一定按字母順序其弊，根據(jù)業(yè)務需要，你可以基于任何數(shù)量的因素膀斋，比如位置、使用頻率(特權用戶被路由到好的硬件)等等痹雅。你可以根據(jù)需要以這種方式切分服務器仰担、數(shù)據(jù)庫或其他方面。
9绩社、對負載均衡器進行負載均衡
到目前為止摔蓝，我們一直使用一個負載均衡器，即使你購買的一些功能強悍(且其價格極其昂貴)的硬件負載均衡器愉耙，但是他們可以處理的請求量也存在硬件限制贮尉。
幸運地是，我們可以有一個全球性朴沿、分散且穩(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)鞠呈，可以根據(jù)需求進行擴展，而不用擔心錯綜復雜的問題右钾。
例如蚁吝。Arcentry網(wǎng)站不會執(zhí)行上述討論的任何操作(除了數(shù)據(jù)庫的讀寫分離)旱爆，而只是把這些難題留給Amazon Web Service Lambda函數(shù)處理了，用戶省去了煩惱窘茁。
但是,并不是說你使用了云服務以后(如 Amazon Web Service Lambda)怀伦，所有的問題都解決了,它隨之而來的是一系列挑戰(zhàn)和權衡。請繼續(xù)關注本系列的下一篇文章山林，
了解更多關于"the cloud for newbs and non-techies".
原文鏈接：
https://arcentry.com/blog/scaling-webapps-for-newbs-and-non-techies/
