现代云架构中的AWS服务器群和数据库是怎么样的

本文向您介绍现代云架构中的AWS服务器场和数据库。内容非常详细。感兴趣的朋友可以参考一下，希望对你有所帮助。

如今，云计算技术已经成为主流架构和互联网基础设施服务之一。越来越多的企业、组织和个人使用云服务来实现自己的服务架构。云计算技术也是每个IT人需要掌握的基本技能。在云平台市场，亚马逊的AWS一枝独秀，不仅发展早，技术先进，而且市场份额大。我们以AWS的云架构系统为例来说明现代云架构。

AWS服务器：EC2及其实例

应用程序主要依赖于两种类型：服务器和数据库。服务器用于托管应用程序，服务器允许用户连接到服务器并运行应用程序，数据库用于存储数据。

在AWS系统中，服务器由弹性云计算服务(简称EC2)组织。通过这项服务，我们可以选择服务器的设置，如操作系统、CPU大小、内部大小等。选择所有设置后，只需点击按钮启动服务器。由EC2创建的服务器称为EC2实例。一旦服务器启动，应用程序就可以放在服务器上。

但事实上，EC2实例并不是真正的机器。它只是一个虚拟机。因此，我们创建的任何服务器实际上都是一个隔离的虚拟机，它共享AWS主机硬件上的空间。简而言之，虚拟机就像真实计算机中的模拟计算机。他们可能有自己的操作系统、依赖项等。但它们使用并共享真实计算机的资源。

考虑EC2实例或任何基于云的服务器的更简单方法是：

它仍然只是一台电脑。只是别人的。(这种情况下是AWS的。)

我们可以登录它，进行设置，并像任何其他计算机一样进行所需的操作。您创建了一个EC2实例(也称为服务器)，并在其上设置应用程序，就像在自己的计算机上一样。

最后，这是您在配置服务器并将代码放在服务器上时要做的所有事情。所有工具和自动化脚本都删除了手动流程。然而，如果它被视为“只是另一台电脑”，那么更容易专注于如何使用它。

一台服务器将受到限制。即使服务器(EC2实例)使用了强大的配置，数据库仍然非常重要。一般来说，数据库会占用大量的计算、存储空间和网络吞吐量。如果服务器是房子，应用和数据库是住户，那么数据库会积累所有空间，产生大量噪音。当然，这对当地的发展很有帮助。然而，当成千上万(或更多)的用户开始使用应用程序时，如果服务器必须同时处理数据库和应用程序，它将很快耗尽资源。

分离数据库：RDS和Aurora

为了应对单个服务器不可避免的硬件和网络流量瓶颈，我们希望将数据库与应用服务器分开。这是为了允许我们的应用程序和数据库分别扩展。在AWS上，有两种方法可以做到这一点。

第一种方法完全是手动的：创建另一个EC2实例(即另一台服务器)，并在这个实例上安装数据库。

同样，如果EC2实例被视为“只有另一台计算机”，它的操作类似于您自己的计算机。例如，下载MySQL，进行设置，启动数据库并允许来自应用程序的流量。但总的来说，就是这么简单。

完成此操作后，您可以将应用程序服务器指向数据库服务器。数据库管理是它自己的领域是有原因的。有很多维修。更新和维护数据库是一项艰巨的任务。因此，除非有内部专家或团队专门致力于此，否则仍然很难真正管理好自己。

另一种方法是使用AWS提供的关系数据库服务，也称为RDS。

具体来说，AWS有一个非常强大的数据库，叫做Aurora。它可以处理所有的扩展、管理和修复。它还直接兼容MySQL和PostgreSQL。因此，即使您使用这两种方法之一进行本地开发，您仍然可以在部署应用程序时直接使用极光。而且，就像RDS营销团队喜欢指出的那样，它比MySQL快5倍，成本只有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服务器群和数据库是怎么样的就分享到这里了，希望