作者

LucianoMammino　　　　　　译者

明知山　　　　　　策划

丁晓昀　　

作为fourTheorem的一名云架构师，我发现许多公司都在努力规模化他们的应用程序并充分利用云计算的能力。

其中一些公司既是初创公司，也是合并重组过的公司，它们以单体的形式开发产品，并最终占据了一定的市场份额。他们的业务在增长，但他们很难扩大应用程序的部署规模。

他们的服务通常部署在本地的私有服务器上或托管供应商的虚拟服务器上。随着服务需求的增长，他们的生产环境开始变得越来越慢，服务可用性出现了间隙性下降，并最终影响到服务质量和进一步增长的潜力。

此时，将产品迁移到AWS等云供应商可能是一个明智的解决方案。迁移到云端后，他们可以按需使用资源，并按需支付费用。云资源可以动态伸缩，以适应突发的流量，使用户体验始终保持良好的水平。

有趣的是，我接触过的一些公司认为，为了过渡到云计算，他们必须重新设计应用程序的整个架构，并转向微服务甚至无服务器。

在大多数情况下，重新设计整个应用程序的时间和成本将会令人望而却步，而这些成本原本应该用于构建有助于业务进一步增长的功能。这种想法让企业对云计算可能带来的机会持怀疑态度，他们最终倾向于选择短期的伸缩策略，也就是将应用服务器升级成更强大、更昂贵的机器。

当然，单台服务器的规模是有限的，最终，企业不得不重新开始考虑替代方案。

在本文中，我将介绍一种简单的云架构，企业可以以增量的方式将单体应用程序迁移到云端，而无需对架构进行重大修改。我们将讨论云计算可伸缩性所需的最低要求和基本组件。我们还将探讨一些常见的问题，可能涉及修改应用程序代码库。最后，我们将分析在完成云端迁移后可能出现的一些进一步改进的可能性。

我已经看到很多公司用这种方法成功地迁移到云端。在云端站稳了脚跟并让应用程序稳定下来之后，他们就可以专注于为客户提供服务，并进一步发展业务。此外，因为技术已不再是阻碍因素，他们可以开始试验，并将应用程序的一部分转成解耦的服务。这样，公司就可以开始过渡到微服务架构甚至Lambda函数等新技术，这些技术可以帮助他们在开发过程中实现更大的灵活性，并为业务带来额外的增长机会。

　　　　一家虚构的公司　　

我们举个具体的例子，引入一家虚构的公司，我们将它作为一个虚构的案例研究，以此来探索如何进行云迁移。

Eaglebox是一家文件存储公司，他们的EagleboxApp是一个Web和移动端应用程序，为用户提供保存和组织文件的功能，并能够从多个设备上进行远程访问。

我们举几个EagleboxApp的具体用例：

用户登录应用程序，可以看到之前上传的所有文件。

用户上传新文档，并通过提供特定的标签（客户端ID、案例号等）来组织文档。

用户可以搜索包含特定关键字或标签的文档。

EagleboxApp是一个单体应用程序，使用Django框架开发，数据库为PostgreSQL。

EagleboxApp目前部署在Eaglebox公司本地的服务器上，用户所有的文件都保存在机器的磁盘上（是的，它们会频繁备份！）。类似地，PostgreSQL也运行在同一台机器上。数据库数据也经常备份，但没有副本。

Eaglebox最近与一些大公司签订了一些合同，从那时起，他们就在努力扩大他们的基础设施。他们的服务器变得越来越慢，磁盘很快就饱和了，需要大量的维护。用户体验已经变得很差，整个业务目前处于风险之中。

我们来看看如何通过重新设计可伸缩的架构来帮助Eaglebox迁移到云端。

　　　　面临的挑战　　

根据EagleBox的工程师告诉我们的情况，我们已经确定了几个需要解决的关键问题：

一台机器上的负载过多，导致整个应用程序缓慢和无响应，有时甚至不可用。

本地磁盘上的文件太多，快速填满磁盘，当没有更多可用磁盘空间时，会发生什么情况？

PostgreSQL数据库作为服务与应用程序运行在同一台机器上，致使整台服务器面临更大的压力。数据库读写正在成为应用程序的另一个瓶颈。

单体虚拟机成为单点故障点。如果由于某种原因发生故障，整个应用程序就会宕机。

除了这些技术问题之外，我们还需要承认，EagleBox团队没有云架构方面的经验，迁移到云端对他们来说将是一次学习的机会。所以，我们要控制迁移变更的数量，让团队有时间适应和吸收新知识，这一点很重要。

我们提出一种新的架构，既要解决所有现有的技术问题，又要提供通往云端的最短路径，并且不要求团队做出重大的技术变更。

　　　　一种简单且可伸缩的云架构　　

为了解决EagleBox面临的挑战，我们提出一种简单、可伸缩、弹性的云架构，并将AWS作为首先的云供应商。

这种架构将有以下几个部分组成：

应用程序负载均衡器(入口点)；

一组EC2虚拟机(多个运行应用程序的实例)；

文件存储(S3)；

会话存储(内存缓存RedisElastiCache)；

运行在RDS上的多区域可用性Postgres数据库。

图1.架构概览

在图1中，我们可以看到架构的高级视图。接下来我们将介绍各个组件。

　　　　数据中心和网络　　

在讨论各种组件的细节之前，有必要简要地探讨一下AWS是如何公开数据中心的，以及如何为我们的架构配置网络。我们不会讲得太详细，但需要涉及一些基础知识，知道会出现什么样的故障、在出现故障时如何保持应用程序运行，以及当流量增加时如何扩展它。

“云”并非万无一失，它也会出问题。AWS、Azure和谷歌云等云供应商为我们提供了设计弹性架构的工具和最佳实践，但这是一种共享责任模型，我们需要了解供应商可以提供哪些保证、哪里可能会出问题以及是怎样出问题的。

说到网络，我们需要介绍一些高级概念。需要注意的是，这里我只提到AWS，但这些概念也同样适用于Azure和谷歌云。

区域（Region）：世界各地的物理位置(如“北弗吉尼亚”、“爱尔兰”或“悉尼”)，AWS在这些物理位置托管数据中心。区域可以提供更接近客户的基础设施，让应用程序具有更低的延迟和更快的响应。

可用性区域（AvailabilityZone）：AWS区域内的个体数据中心，主要是为了实现冗余的电力、网络和连接。不同可用性区域中的数据中心相互脱节，如果其中一个发生严重的中断，很少会同时影响到多个可用性区域。为了保证可用性，最好将冗余基础设施分布在一个区域内的不同可用性区域。

VPC：在一个区域内为AWS用户提供的私有网络。它在逻辑上与AWS中的其他虚拟网络隔离。每个VPC由一个或多个子网，每个子网都包含一定范围的私有IP地址。

子网：VPC和可用性区域内的IP地址范围，用于在网络内启动和连接资源。子网分为公共子网和私有子网。公共子网用于运行VPC以外的实例，这些实例可以分配公网IP地址。通常，我们会将前端服务器(或负载均衡器)放在公共子网中，将其他的(后端服务、数据库等)放在私有子网中。网络流量可以通过路由表在子网之间流动，例如，公共子网中的负载均衡器可以通过路由表将流量转发给私有子网的后端实例。

在我们的架构中，我们将使用如图2所示的VPC配置。

图2.我们架构中的VPC配置

主要的想法就是选择一个离客户较近的区域，并在该区域内创建一个专用VPC。然后，我们将使用3个不同的可用性区域，每个可用性区域都有一个公共子网和一个私有子网。

公共子网只用于负载均衡器，架构中的其他组件(虚拟机、缓存服务器和数据库)全部使用私有子网。

操作点：从为所选的区域内配置VPC开始，确保在不同的可用性区域中分别创建了公共子网和私有子网。

　　　　负载均衡器　　

负载均衡器是所有进入Eaglebox应用服务器的流量的“入口”。这是一个弹性应用负载均衡器(Layer7)，可以管理HTTP、HTTPS、WebSocket和gRPC流量。它负责将流入的流量分配给后端的虚拟机。它可以检查目标虚拟机的运行状况，确保只将流入的流量转发给运行状况良好且响应迅速的实例。

操作点：确保单体应用程序提供了一个可用于检查实例健康状况的端点。如果还没有，请在应用程序中添加。

负载均衡器与ACM(AWS证书管理器)集成，可以使用证书并提供HTTPS流量，确保所有进出的流量都是加密的。

从网络方面来看，负载均衡器可以使用所有的公共子网，所以也就可以使用所有的可用性区域。负载均衡器也因此具备高可用性：如果一个可用性区域突然不可用，流量将自动通过其他可用性区域进行路由。

在AWS中，弹性负载均衡器能够很好地处理不断增长的流量，每个实例能够分发每秒数百万个请求。对于大多数现实中的应用程序来说，我们不需要为负载均衡器的伸缩问题操心。最后，值得一提的是，这种负载均衡器完全由AWS负责托管，因此我们不需要操心系统配置或软件更新方面的事情。

　　　　虚拟机　　

EagleboxApp是一个用Python开发的Web应用程序，使用了Django框架。我们希望能够同时在不同的服务器上运行应用程序的多个实例，这样就可以根据不断增加的流量进行伸缩。理想情况下，我们希望将不同的实例分布到不同的可用性区域。同样，如果一个可用性区域变得不可用，其他区域还有实例可以处理流量并避免宕机。

要让实例可动态伸缩，可以使用自动伸缩组。我们可以定义应用程序新实例自动启动(或销毁)的条件。例如，我们可以使用平均CPU负载水平或每个实例的平均请求数来确定是否需要启动新实例，或者，如果已经有足够的可用容量，可以降低实例数量以节省成本。为了保证高可用性，我们需要确保每个可用性区域中至少有一个实例可用。

要使用虚拟机，就需要构建虚拟机镜像。镜像可以有效地把操作系统、所有必要的软件(例如Python运行时)、应用程序的源代码和所有依赖项打成包。

为了启动虚拟机实例，必须定义镜像，这里涉及的细节可能并不重要，但它确实与在本地托管软件的方式有很大不同。在本地，虚拟机通常会一直保持运行。在配置完毕后，IT人员通常会登录到机器上给软件打补丁、重新启动服务或部署新的应用程序版本。但如果存在多个实例，并且需要自动启动和销毁，这种方式就不可行了。

在云端，虚拟机是“不可变”的：一旦启动，就不应该被修改。如果需要发布更新，就构建新的镜像并启动新实例，同时逐步销毁旧实例。

但是，这种不变性不仅影响部署或软件更新，它还影响数据(或“状态”)的管理方式。我们无法在虚拟机里存储持久状态，因为一旦机器被关闭，我们将丢失所有的数据，因此，我们不能在本地文件系统存储文件或在应用程序内存中保存会话数据。

基于这样的模型，“基础设施”和“数据”变成了相互独立的

转载请注明:http://www.aideyishus.com/lkgx/611.html