当今云计算技术成了主流的架构和互联网基础服务架构之一。越来越多的企业、组织和人使用云服务来实现自己的服务架构。云计算技术也是每一个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服务是云对象存储，作为基础存储)，这构成了基础的云服务，使用他们就可以为了创建绝大多数基本的应用架构。
原文链接：https://www.toutiao.com/a6794268724397343245/
