乡下人产国偷v产偷v自拍,国产午夜片在线观看,婷婷成人亚洲综合国产麻豆,久久综合给合久久狠狠狠9

  • <output id="e9wm2"></output>
    <s id="e9wm2"><nobr id="e9wm2"><ins id="e9wm2"></ins></nobr></s>

    • 分享

      如何從單個服務器擴展到百萬用戶的系統(tǒng)?

       鷹兔牛熊眼 2019-04-15

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

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

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

      如何進行擴展?

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

      如今,幾乎沒有人說垂直擴展了。原因很簡單:

      • 隨著計算機性能的增長,其價格會成倍增長。

      • 單臺計算機的性能是有上限的,不可能無限制地垂直擴展。

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

      現(xiàn)在我們水平擴展服務。需要哪些步驟呢?

      單臺服務器+數(shù)據(jù)庫


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

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

      增加一個反向代理

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

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

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

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

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

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

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

      引入負載均衡器

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

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

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

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

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

      擴展數(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ù)同步到其他部分即可。缺點是我們?nèi)匀恢挥幸粋€寫數(shù)據(jù)庫實例。

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

      微服務

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

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

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

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

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

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

      • 每個服務都可以單獨擴展,更好地適應需求。

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

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

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

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

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

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

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

      消息隊列

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

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

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

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

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

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

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

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

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

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

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

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

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

      分片,分片,還是分片

      什么是分片?好吧,深呼吸一下,準備好了嗎?我們看下定義:

      '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 億用戶提供個人資料, 可以把你的應用架構(gòu)分解為 26 個 mini-Facebook。

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

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

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


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

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

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

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

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

      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)和權(quán)衡。

      作者:Wolfram Hempel ,Join 翻譯

        本站是提供個人知識管理的網(wǎng)絡存儲空間,所有內(nèi)容均由用戶發(fā)布,不代表本站觀點。請注意甄別內(nèi)容中的聯(lián)系方式、誘導購買等信息,謹防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請點擊一鍵舉報。
        轉(zhuǎn)藏 分享 獻花(0

        0條評論

        發(fā)表

        請遵守用戶 評論公約

        類似文章 更多