共計 3437 個字符，預計需要花費 9 分鐘才能閱讀完成。
這篇文章給大家介紹現代云架構中的 AWS 服務器群和數據庫是怎么樣的，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。
當今云計算技術成了主流的架構和互聯網基礎服務架構之一。越來越多的企業、組織和人使用云服務來實現自己的服務架構。云計算技術也是每一個 IT 人士需要掌握的基礎技能。在云平臺市場，亞馬遜的 AWS 一枝獨秀，不光發展早，技術先進，而且市場占有率也大。我們以 AWS 的云架構體系為例子說明現代云架構。
AWS 服務器：EC2 及其實例
應用程序的運行主要依賴兩類：服務器和數據庫。服務器，用來承載應用程序，服務器允許用戶連接到該服務器并運行應用，而數據庫用來保存數據。
在 AWS 體系中，服務器的的組織形式是通過 Elastic Cloud Compute 服務(簡稱為 EC2)。通過該服務，我們可以選擇服務器的設置，例如操作系統，CPU 大小，內大小等。選擇好所有設置后，啟動服務器只需要點擊按鈕就可以。通過 EC2 創建的服務器稱為 EC2 實例。一旦該服務器啟動，就可以將應用程序放置在該服務器上。
但是實際上，EC2 實例不是一臺真正的機器。它只是一個虛擬機。因此，我們創建的任何服務器實際上都是隔離的虛擬機，它們在 AWS 的宿主機硬件上共享空間。簡而言之，虛擬機 (即 VM) 就像是真實計算機中的模擬計算機。它們可以具有自己的操作系統，依賴項等，但是它們使用并共享真實計算機的資源。
考慮 EC2 實例或任何基于云的服務器的比較簡單方法是：
它仍然只是一臺計算機。只是別人的。(在這種情況下，是 AWS 的。)
我們可以登錄到它，進行設置，并像在其他任何計算機上一樣進行所需的操作。您創建了一個 EC2 實例 (又名服務器) 并在其上設置應用程序，就像在自己的計算機上一樣。
最后，這是在配置服務器并將代碼放置在服務器上時要做的所有事情。所有工具和自動化腳本都刪除了手動過程。但是，如果將其視為 僅是另一臺計算機，那么將精力集中在如何使用它上就容易得多。
一臺服務器會有限制。即使一臺服務器 (EC2 實例) 使用很強大的配置，數據庫還是非常重要的。一般來說數據庫會占用大量計算量，大量存儲空間和大量網絡吞吐量。如果服務器是一棟房子，而應用程序和數據庫是居民，則該數據庫將累積所有空間并產生大量噪音。當然，這對于本地開發而言效果很好。但是，當成千上萬的用戶 (或更多) 開始使用該應用程序時，如果該服務器必須同時處理數據庫和應用程序，則它將很快耗盡其資源。
分離數據庫：RDS 和 Aurora
為了應對單一服務器不可避免的硬件和網絡流量瓶頸，我們希望將數據庫與應用程序服務器分離。這樣做是為了允許我們的應用程序和數據庫分別擴展。在 AWS 上，有兩種方法可以做到這一點。
第一種方法是完全手動的：創建另一個 EC2 實例 (即另一個服務器) 并將在該實例上安裝數據庫。
同樣，如果將 EC2 實例視為 僅另一臺計算機，則其操作方式與在自己的計算機上類似。例如，下載 MySQL，進行設置，啟動數據庫并允許來自應用程序的流量。但總的來說確實如此簡單。
完成此操作后，就可以把應用程序服務器指向數據庫服務器即可。數據庫管理是其自己的領域，這是有原因的。有很多修補，更新和維護數據庫是一項艱巨的任務。因此，除非有內部專家或團隊專門致力于此，否則真的想在進行自我管理還是有一定的難度。
另一中方法就是，使用 AWS 提供了的關系數據庫服務，也稱為 RDS。
具體來說，AWS 有一個非常強大的數據庫，稱為 Aurora。它可以處理所有擴展，管理和修補。它還直接兼容 MySQL 和 PostgreSQL。因此，即使使用這兩種方法之一進行本地開發，在部署應用程序時仍可以直接使用 Aurora。而且，正如 RDS 營銷團隊喜歡指出的那樣，它的速度是 MySQL 的五倍，成本的十分之一。
這樣用戶可以訪問您的服務器以使用該應用程序，并且該應用程序將與 RDS Aurora 數據庫進行交互。
但是，如果出現流量高峰會怎樣? 如果企業的服務 / 公司快速發展了會怎么樣? 如果是自建 EC2 實例維護數據庫這將是個問題。如果選擇的是 RDS Aurora，就可以無需考慮對數據庫擴容的問題了。但是還會面臨另一個問題，應用程序服務器將的擴容問題。
服務器集群：EC2 Auto Scaling 組
為了解決擴展問題。假設該應用程序已經在線使用，并受到大量流量的沖擊。如果是這樣的話，耽擱小服務器將不能扛太久的時間。
那么我們有什么選擇呢? 好吧，我們選擇更強大、配置更高的實例，單這也是一個短期解決方案。這方法叫豎直擴展。盡管這可以在開始階段提供幫助，但要意識到服務器只能變得如此之大。此外，它只是一臺服務器，存在單點問題，如果它掛了，那么在它上面運行的所有服務都不能使用。這沒有彈性，不是解決的好方法。
那正確的答案是什么? 通過創建更多的實例來共同承載 (負載均衡) 服務。這種方法叫橫向擴展。橫向擴展它使我們的架構不受限于個別 EC2 實例。
AWS 也提供了 EC2 Auto Scaling 組來實現橫向擴展和負載均衡。Auto Scaling 組可有許多服務器構成并對其進行整體管理，通過使用 Auto Scaling 組，創建和管理多個 EC2 實例幾乎與一臺實例同樣簡單。
那么 Auto Scaling Group 會創建什么類型的服務器? 在啟動 Auto Scalin 組之前，首先要創建所謂的啟動配置，然后創建一個 Auto Scaling 組并為其指定啟動配置。然后它將從該模板創建實例并為我們管理它們。
可以將啟動配置視為 EC2 實例的藍圖。如果是這種情況，那么 Auto Scaling 組就像是使用該藍圖構建和管理實例的領班。
注意：盡管它的名字 Auto Scaling 組，但實際上它并不會自動進行擴展。可以通過配置做到，后面將會介紹。
通過使用 Auto Scaling 組，我們將能夠創建可以供托管應用程序的所有服務器。
負載均衡器：調度流量
通過 RDS 服務，在數據持久性方面我們無需擔心。但是，可能有多個 EC2 實例托管我們的應用程序，它們都指向同一個 RDS Aurora 數據庫。加入我們有如三個 EC2 實例，一個用戶訪問了其中一臺并更改了名稱，這不會阻止他們在其他實例上的應用程序。為什么? 因為我們所有的應用程序都指向同一數據庫。因此，當用戶訪問其中一個實例上的應用程序時，它仍將從同一 RDS Aurora 數據庫中獲取其數據。
現在可以將負載分散到 3 個不同的服務器上。但是，新問題是：
我們的用戶連接到哪里? 如何保存會話? 而且，我們如何自動平衡負載?
如果我們有三個不同的實例，那么它們都將具有三個不同的 IP 地址。如果你的應用程序使用會話數據來跟蹤用戶的操作，那么如果他們跳到另一個實例，那將會丟失。
這時候就需要引入負載均衡器了。他可以解決了剛才談到的所有問題，甚至更多。本質上，它負責接受傳入的流量，然后將其分發到最適合處理它的服務器。這聽起來像是一項神奇的技術。但是就像我們可以在服務器上建立數據庫一樣，我們可以對負載均衡器執行相同的操作。只需創建一個服務器，然后使用 NGINX，HAProxy 或 Apache 之類反向代理應用即可。然后，將要選擇的那些工具告訴要負載均衡流量的服務器。
AWS 架構體系中也提供了自己的負載均衡器。在 EC2 中，有各種各樣的負載均衡器可以自動為我們完成所有這些工作，可以非常輕松地連接到 EC2 實例。它還為我們提供了許多選項和功能，如果我們想自己實現該功能，則將需要大量的工作。
由于它們與 EC2 實例無縫集成，因此我們無需擔心將新實例或要刪除的實例告知 AWS 負載均衡器。它還能跟蹤會話數據，執行運行狀況檢查并返回指標。各種各樣的事情。
設置了負載平衡器之后，無需將流量指向任何單個實例，而是將其指向負載平衡器本身。同樣，它只是另一臺服務器，因此，如果它的 IP 地址是 13.14.15.16 之類的東西，并且的負載平衡軟件正在監聽端口 3000，那么可以在這里進行管理。顯然，希望利用 DNS 并為其提供一個友好的 URL，但在此之后，它將可以平衡其背后的服務器之間的流量。
上面介紹了 AWS 云基礎架構中的基礎服務，包括 EC3、Auto Scaling 組，RDS Aurora 數據庫和負載均衡器(還有一個 AWS S3 服務是云對象存儲，作為基礎存儲)，這構成了基礎的云服務，使用他們就可以為了創建絕大多數基本的應用架構。
關于現代云架構中的 AWS 服務器群和數據庫是怎么樣的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
