共计 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 服务器群和数据库是怎么样的就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
