请选择 进入手机版 | 继续访问电脑版

了解现代云架构之AWS服务器群和数据库

AWS  / 只看大图  / 倒序浏览   © 著作权归作者本人所有

#楼主# 4 天前

跳转到指定楼层
当今云计算技术成了主流的架构和互联网基础服务架构之一。越来越多的企业、组织和人使用云服务来实现自己的服务架构。云计算技术也是每一个IT人士需要掌握的基础技能。在云平台市场,亚马逊的AWS一枝独秀,不光发展早,技术先进,而且市场占有率也大。本文我们以AWS的云架构体系为例子说明现代云架构。

了解现代云架构之AWS服务器群和数据库-1.jpg

AWS服务器:EC2及其实例

应用程序的运行主要依赖两类:服务器和数据库。服务器,用来承载应用程序,服务器允许用户连接到该服务器并运行应用,而数据库用来保存数据。

在AWS体系中,服务器的的组织形式是通过Elastic Cloud Compute服务(简称为EC2)。通过该服务,我们可以选择服务器的设置,例如操作系统,CPU大小,内大小等。选择好所有设置后,启动服务器只需要点击按钮就可以。通过EC2创建的服务器称为 EC2实例。一旦该服务器启动,就可以将应用程序放置在该服务器上。

了解现代云架构之AWS服务器群和数据库-2.jpg

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

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

它仍然只是一台计算机。只是别人的。(在这种情况下,是AWS的。)

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

最后,这是在配置服务器并将代码放置在服务器上时要做的所有事情。所有工具和自动化脚本都删除了手动过程。但是,如果将其视为"仅是另一台计算机",那么将精力集中在如何使用它上就容易得多。

一台服务器会有限制。即使一台服务器(EC2实例)使用最强大的配置,数据库还是非常重要的。一般来说数据库会占用大量计算量,大量存储空间和大量网络吞吐量。如果服务器是一栋房子,而应用程序和数据库是居民,则该数据库将累积所有空间并产生大量噪音。当然,这对于本地开发而言效果很好。但是,当成千上万的用户(或更多)开始使用该应用程序时,如果该服务器必须同时处理数据库和应用程序,则它将很快耗尽其资源。
分离数据库:RDS和Aurora

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

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

了解现代云架构之AWS服务器群和数据库-3.jpg

同样,如果将EC2实例视为"仅另一台计算机",则其操作方式与在自己的计算机上类似。例如,下载MySQL,进行设置,启动数据库并允许来自应用程序的流量。但总的来说确实如此简单。

完成此操作后,就可以把应用程序服务器指向数据库服务器即可。数据库管理是其自己的领域,这是有原因的。有很多修补,更新和维护数据库是一项艰巨的任务。因此,除非有内部专家或团队专门致力于此,否则真的想在进行自我管理还是有一定的难度。

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

具体来说,AWS有一个非常强大的数据库,称为Aurora。它可以处理所有扩展,管理和修补。它还直接兼容MySQL和PostgreSQL。因此,即使使用这两种方法之一进行本地开发,在部署应用程序时仍可以直接使用Aurora。而且,正如RDS营销团队喜欢指出的那样,它的速度是MySQL的五倍,成本的十分之一。

这样用户可以访问您的服务器以使用该应用程序,并且该应用程序将与RDS Aurora数据库进行交互。

但是,如果出现流量高峰会怎样?如果企业的服务/公司快速发展了会怎么样?如果是自建EC2实例维护数据库这将是个问题。如果选择的是RDS Aurora,就可以无需考虑对数据库扩容的问题了。但是还会面临另一个问题,应用程序服务器将的扩容问题。
服务器集群:EC2 Auto Scaling组

为了解决扩展问题。假设该应用程序已经在线使用,并受到大量流量的冲击。如果是这样的话,耽搁小服务器将不能扛太久的时间。

那么我们有什么选择呢?好吧,我们选择更强大、配置更高的实例,但这也是一个短期解决方案。这方法叫竖直扩展。尽管这可以在开始阶段提供帮助,但要意识到服务器只能变得如此之大。此外,它只是一台服务器,存在单点问题,如果它挂了,那么在它上面运行的所有服务都不能使用。这没有弹性,不是解决的好方法。

了解现代云架构之AWS服务器群和数据库-4.jpg

那正确的答案是什么?通过创建更多的实例来共同承载(负载均衡)服务。这种方法叫横向扩展。横向扩展它使我们的架构不受限于个别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数据库中获取其数据。

了解现代云架构之AWS服务器群和数据库-5.jpg

现在可以将负载分散到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/
转播转播 分享淘帖
回复

使用道具

成为第一个回答人

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则