當(dāng)今云計算技術(shù)成了主流的架構(gòu)和互聯(lián)網(wǎng)基礎(chǔ)服務(wù)架構(gòu)之一。越來越多的企業(yè)、組織和人使用云服務(wù)來實現(xiàn)自己的服務(wù)架構(gòu)。云計算技術(shù)也是每一個IT人士需要掌握的基礎(chǔ)技能。在云平臺市場,亞馬遜的AWS一枝獨秀,不光發(fā)展早,技術(shù)先進,而且市場占有率也大。本文我們以AWS的云架構(gòu)體系為例子說明現(xiàn)代云架構(gòu)。

AWS服務(wù)器:EC2及其實例
應(yīng)用程序的運行主要依賴兩類:服務(wù)器和數(shù)據(jù)庫。服務(wù)器,用來承載應(yīng)用程序,服務(wù)器允許用戶連接到該服務(wù)器并運行應(yīng)用,而數(shù)據(jù)庫用來保存數(shù)據(jù)。
在AWS體系中,服務(wù)器的的組織形式是通過Elastic Cloud Compute服務(wù)(簡稱為EC2)。通過該服務(wù),我們可以選擇服務(wù)器的設(shè)置,例如操作系統(tǒng),CPU大小,內(nèi)大小等。選擇好所有設(shè)置后,啟動服務(wù)器只需要點擊按鈕就可以。通過EC2創(chuàng)建的服務(wù)器稱為 EC2實例。一旦該服務(wù)器啟動,就可以將應(yīng)用程序放置在該服務(wù)器上。

但是實際上,EC2實例不是一臺真正的機器。它只是一個虛擬機。因此,我們創(chuàng)建的任何服務(wù)器實際上都是隔離的虛擬機,它們在AWS的宿主機硬件上共享空間。簡而言之,虛擬機(即VM)就像是真實計算機中的模擬計算機。它們可以具有自己的操作系統(tǒng),依賴項等,但是它們使用并共享真實計算機的資源。
考慮EC2實例或任何基于云的服務(wù)器的比較簡單方法是:
它仍然只是一臺計算機。只是別人的。(在這種情況下,是AWS的。)
我們可以登錄到它,進行設(shè)置,并像在其他任何計算機上一樣進行所需的操作。您創(chuàng)建了一個EC2實例(又名服務(wù)器)并在其上設(shè)置應(yīng)用程序,就像在自己的計算機上一樣。
最后,這是在配置服務(wù)器并將代碼放置在服務(wù)器上時要做的所有事情。所有工具和自動化腳本都刪除了手動過程。但是,如果將其視為"僅是另一臺計算機",那么將精力集中在如何使用它上就容易得多。
一臺服務(wù)器會有限制。即使一臺服務(wù)器(EC2實例)使用很強大的配置,數(shù)據(jù)庫還是非常重要的。一般來說數(shù)據(jù)庫會占用大量計算量,大量存儲空間和大量網(wǎng)絡(luò)吞吐量。如果服務(wù)器是一棟房子,而應(yīng)用程序和數(shù)據(jù)庫是居民,則該數(shù)據(jù)庫將累積所有空間并產(chǎn)生大量噪音。當(dāng)然,這對于本地開發(fā)而言效果很好。但是,當(dāng)成千上萬的用戶(或更多)開始使用該應(yīng)用程序時,如果該服務(wù)器必須同時處理數(shù)據(jù)庫和應(yīng)用程序,則它將很快耗盡其資源。
分離數(shù)據(jù)庫:RDS和Aurora
為了應(yīng)對單一服務(wù)器不可避免的硬件和網(wǎng)絡(luò)流量瓶頸,我們希望將數(shù)據(jù)庫與應(yīng)用程序服務(wù)器分離。這樣做是為了允許我們的應(yīng)用程序和數(shù)據(jù)庫分別擴展。在AWS上,有兩種方法可以做到這一點。
第一種方法是完全手動的:創(chuàng)建另一個EC2實例(即另一個服務(wù)器)并將在該實例上安裝數(shù)據(jù)庫。

同樣,如果將EC2實例視為"僅另一臺計算機",則其操作方式與在自己的計算機上類似。例如,下載MySQL,進行設(shè)置,啟動數(shù)據(jù)庫并允許來自應(yīng)用程序的流量。但總的來說確實如此簡單。
完成此操作后,就可以把應(yīng)用程序服務(wù)器指向數(shù)據(jù)庫服務(wù)器即可。數(shù)據(jù)庫管理是其自己的領(lǐng)域,這是有原因的。有很多修補,更新和維護數(shù)據(jù)庫是一項艱巨的任務(wù)。因此,除非有內(nèi)部專家或團隊專門致力于此,否則真的想在進行自我管理還是有一定的難度。
另一中方法就是,使用AWS提供了的關(guān)系數(shù)據(jù)庫服務(wù),也稱為RDS。
具體來說,AWS有一個非常強大的數(shù)據(jù)庫,稱為Aurora。它可以處理所有擴展,管理和修補。它還直接兼容MySQL和PostgreSQL。因此,即使使用這兩種方法之一進行本地開發(fā),在部署應(yīng)用程序時仍可以直接使用Aurora。而且,正如RDS營銷團隊喜歡指出的那樣,它的速度是MySQL的五倍,成本的十分之一。
這樣用戶可以訪問您的服務(wù)器以使用該應(yīng)用程序,并且該應(yīng)用程序?qū)⑴cRDS Aurora數(shù)據(jù)庫進行交互。
但是,如果出現(xiàn)流量高峰會怎樣?如果企業(yè)的服務(wù)/公司快速發(fā)展了會怎么樣?如果是自建EC2實例維護數(shù)據(jù)庫這將是個問題。如果選擇的是RDS Aurora,就可以無需考慮對數(shù)據(jù)庫擴容的問題了。但是還會面臨另一個問題,應(yīng)用程序服務(wù)器將的擴容問題。
服務(wù)器集群:EC2 Auto Scaling組
為了解決擴展問題。假設(shè)該應(yīng)用程序已經(jīng)在線使用,并受到大量流量的沖擊。如果是這樣的話,耽擱小服務(wù)器將不能扛太久的時間。
那么我們有什么選擇呢?好吧,我們選擇更強大、配置更高的實例,單這也是一個短期解決方案。這方法叫豎直擴展。盡管這可以在開始階段提供幫助,但要意識到服務(wù)器只能變得如此之大。此外,它只是一臺服務(wù)器,存在單點問題,如果它掛了,那么在它上面運行的所有服務(wù)都不能使用。這沒有彈性,不是解決的好方法。

那正確的答案是什么?通過創(chuàng)建更多的實例來共同承載(負載均衡)服務(wù)。這種方法叫橫向擴展。橫向擴展它使我們的架構(gòu)不受限于個別EC2實例。
AWS也提供了EC2 Auto Scaling組來實現(xiàn)橫向擴展和負載均衡。Auto Scaling組可有許多服務(wù)器構(gòu)成并對其進行整體管理,通過使用Auto Scaling組,創(chuàng)建和管理多個EC2實例幾乎與一臺實例同樣簡單。
那么 Auto Scaling Group會創(chuàng)建什么類型的服務(wù)器?在啟動Auto Scalin組之前,首先要創(chuàng)建所謂的啟動配置,然后創(chuàng)建一個Auto Scaling組并為其指定啟動配置。然后它將從該模板創(chuàng)建實例并為我們管理它們。
可以將啟動配置視為EC2實例的藍圖。如果是這種情況,那么Auto Scaling組就像是使用該藍圖構(gòu)建和管理實例的領(lǐng)班。
注意:盡管它的名字Auto Scaling組,但實際上它并不會自動進行擴展。可以通過配置做到,后面將會介紹。
通過使用Auto Scaling組,我們將能夠創(chuàng)建可以供托管應(yīng)用程序的所有服務(wù)器。
負載均衡器:調(diào)度流量
通過RDS服務(wù),在數(shù)據(jù)持久性方面我們無需擔(dān)心。但是,可能有多個EC2實例托管我們的應(yīng)用程序,它們都指向同一個RDS Aurora數(shù)據(jù)庫。加入我們有如三個EC2實例,一個用戶訪問了其中一臺并更改了名稱,這不會阻止他們在其他實例上的應(yīng)用程序。為什么?因為我們所有的應(yīng)用程序都指向同一數(shù)據(jù)庫。因此,當(dāng)用戶訪問其中一個實例上的應(yīng)用程序時,它仍將從同一RDS Aurora數(shù)據(jù)庫中獲取其數(shù)據(jù)。

現(xiàn)在可以將負載分散到3個不同的服務(wù)器上。但是,新問題是:
我們的用戶連接到哪里?如何保存會話?而且,我們?nèi)绾巫詣悠胶庳撦d?
如果我們有三個不同的實例,那么它們都將具有三個不同的IP地址。如果你的應(yīng)用程序使用會話數(shù)據(jù)來跟蹤用戶的操作,那么如果他們跳到另一個實例,那將會丟失。
這時候就需要引入負載均衡器了。他可以解決了剛才談到的所有問題,甚至更多。本質(zhì)上,它負責(zé)接受傳入的流量,然后將其分發(fā)到最適合處理它的服務(wù)器。這聽起來像是一項神奇的技術(shù)。但是就像我們可以在服務(wù)器上建立數(shù)據(jù)庫一樣,我們可以對負載均衡器執(zhí)行相同的操作。只需創(chuàng)建一個服務(wù)器,然后使用NGINX,HAProxy或Apache之類反向代理應(yīng)用即可。然后,將要選擇的那些工具告訴要負載均衡流量的服務(wù)器。
AWS架構(gòu)體系中也提供了自己的負載均衡器。在EC2中,有各種各樣的負載均衡器可以自動為我們完成所有這些工作,可以非常輕松地連接到EC2實例。它還為我們提供了許多選項和功能,如果我們想自己實現(xiàn)該功能,則將需要大量的工作。
由于它們與EC2實例無縫集成,因此我們無需擔(dān)心將新實例或要刪除的實例告知AWS負載均衡器。它還能跟蹤會話數(shù)據(jù),執(zhí)行運行狀況檢查并返回指標(biāo)。各種各樣的事情。
設(shè)置了負載平衡器之后,無需將流量指向任何單個實例,而是將其指向負載平衡器本身。同樣,它只是另一臺服務(wù)器,因此,如果它的IP地址是13.14.15.16之類的東西,并且的負載平衡軟件正在監(jiān)聽端口3000,那么可以在這里進行管理。顯然,希望利用DNS并為其提供一個友好的URL,但在此之后,它將可以平衡其背后的服務(wù)器之間的流量。
結(jié)論
本文我么介紹了AWS云基礎(chǔ)架構(gòu)中的基礎(chǔ)服務(wù),包括EC3、 Auto Scaling組,RDS Aurora數(shù)據(jù)庫和負載均衡器(還有一個AWS S3服務(wù)是云對象存儲,作為基礎(chǔ)存儲),這構(gòu)成了基礎(chǔ)的云服務(wù),使用他們就可以為了創(chuàng)建絕大多數(shù)基本的應(yīng)用架構(gòu)。
原文鏈接:https://www.toutiao.com/a6794268724397343245/