當今雲計算技術成了主流的架構和互聯網基礎服務架構之一。越來越多的企業、組織和人使用雲服務來實現自己的服務架構。雲計算技術也是每一個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服務是雲對象存儲，作為基礎存儲），這構成了基礎的雲服務，使用他們就可以為了創建絕大多數基本的應用架構。
閱讀更多 蟲蟲安全 的文章
