今天的云计算技术已经成为主流架构和互联网基础服务架构之一。越来越多的企业、组织和个人使用云服务来实现自己的服务架构。云计算技术也是每个IT从业者都需要掌握的一项基本技能。在云平台市场，亚马逊的AWS一枝独秀。它不仅发展早，技术先进，而且市场占有率大。在本文中，我们以AWS云架构体系为例，来说明现代云架构。AWS服务器：EC2及其实例应用程序依赖于两种主要类型的操作：服务器和数据库。服务器用于承载应用程序，服务器允许用户连接到服务器并运行应用程序，数据库用于存储数据。在AWS系统中，服务器是通过弹性云计算服务（简称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的五倍，而成本仅为MySQL的十分之一。这样用户就可以访问您的服务器以使用该应用程序，并且该应用程序将与RDSAurora数据库进行交互。但是，如果出现流量高峰怎么办？如果企业的服务/公司发展迅速怎么办？如果是自建EC2实例来维护数据库，这就会有问题。如果选择RDSAurora，则无需考虑数据库扩容的问题。但是还会有另一个问题，应用服务器的扩容。服务器集群：EC2AutoScaling集群，解决扩容问题。假设该应用程序已经在网上使用并且正受到大量流量的冲击。如果真是这样的话，耽误小服务器也撑不了多久了。那么我们有什么选择呢？好吧，我们选择更强大更高配置的实例，但这也是一个短期的解决方案。这种方法称为垂直扩展。虽然这在开始阶段会有帮助，但要意识到服务器只能变得这么大。而且，它只是一台服务器，存在单点问题，如果它宕机，那么它上面运行的所有服务都无法使用。这是不灵活的，不是解决问题的好方法。正确答案是什么？通过创建更多实例来共同托管（负载均衡）服务。这种方法称为水平缩放。扩展它使我们的架构不再局限于单个EC2实例。AWS还提供EC2AutoScaling组用于水平扩展和负载平衡。一个AutoScaling组可以包含许多服务器并将它们作为一个整体进行管理。通过使用AutoScaling组，创建和管理多个EC2实例几乎与单个实例一样简单。那么AutoScalingGroup创建了什么样的服务器呢？在启动AutoScaling组之前，首先创建所谓的启动配置，然后创建一个AutoScaling组并为其分配启动配置。然后它将从该模板创建实例并为我们管理它们。可以将启动配置视为EC2实例的蓝图。如果是这种情况，那么AutoScaling小组就像是使用该蓝图构建和管理实例的工头。注意：尽管名称如此，但AutoScaling组实际上并不会自动缩放。可以通过配置来实现，后面会介绍。通过使用AutoScaling组，我们将能够创建可用于托管应用程序的所有服务器。LoadBalancer：通过RDS服务调度流量，我们不用担心数据持久化的问题。但是，可能有多个EC2实例托管我们的应用程序，它们都指向同一个RDSAurora数据库。假设我们有三个EC2实例，用户访问其中一个并更改名称，这不会阻止他们在其他实例上的应用程序。为什么？因为我们所有的应用程序都指向同一个数据库。因此，当用户访问其中一个实例上的应用程序时，它仍将从同一个RDSAurora数据库中获取其数据。负载现在可以分布在3个不同的服务器上。然而，新的问题是：我们的用户连接到哪里？我们如何保存会话？以及，我们如何自动平衡负载？如果我们有三个不同的实例，它们都会有三个不同的IP地址。如果您的应用程序使用会话数据来跟踪用户正在做什么，那么如果他们跳转到另一个实例，这些数据就会丢失。这时候就需要引入负载均衡器。他可以解决刚才讲到的所有问题，甚至更多。本质上，它负责接受传入流量，然后将其分发到最适合处理它的服务器。这听起来像是一项了不起的技术。但就像我们可以在服务器上设置数据库一样，我们也可以使用负载均衡器来做同样的事情。只需创建一个服务器并使用反向代理应用程序，如NGINX、HAProxy或Apache。然后，告诉服务器负载平衡您要选择哪些工具的流量。AWS架构还提供了自己的负载均衡器。在EC2中，有各种负载均衡器自动为我们完成所有这些工作，使得连接到EC2实例变得非常容易。它还为我们提供了许多选项和功能，如果我们想自己实现它，将需要大量工作。由于它们与EC2实例无缝集成，我们无需担心将新实例或正在删除的实例告知AWS负载均衡器。它还跟踪会话数据、执行健康检查并返回指标。各种事情。一旦设置了负载均衡器，它就不会将流量定向到任何单个实例，而是定向到负载均衡器本身。同样，它只是另一台服务器，因此如果其IP地址类似于13.14.15.16，并且您的负载平衡软件正在侦听端口3000，则可以在那里进行管理。显然，利用DNS并为其提供一个友好的URL是可取的，但之后它将能够平衡其背后的服务器之间的流量。结束语本文介绍了AWS云基础设施中的基础服务，包括EC3、AutoScalinggroup、RDSAurora数据库和负载均衡器（还有一个AWSS3服务，是以云对象存储为基础存储），构成了基础云服务，使用它们可用于创建大多数基本应用程序架构。
