AWS架构

在这篇文章中,我们将研究在 AWS 上实现的典型高可用性 3 层架构。我们将研究计算选项、负载平衡、一些 AWS 数据库服务,最后看看我们如何迭代地过渡到无服务器架构。

N 层架构是一种众所周知的架构,它将应用程序组织成多个逻辑层。理论上,N 可以是任意数字,但 3 往往是最常见的。在 3 层架构中,应用程序被组织成表示层,它实现了处理用户界面的应用程序组件;实现业务逻辑的逻辑层(有时称为应用层);和数据层,存储和管理与应用程序关联的数据。三层架构的主要驱动力是:

• 解耦

• 独立扩展性

• 不同团队分别开发、管理和维护

虽然我们现在看到越来越多的组织拥有在云中诞生的应用程序,但企业在本地或在混合云环境中运行工作负载是很常见的。其中许多企业正在或计划将其工作负载迁移到云端。刚在云中诞生的应用程序的架构和刚刚迁移到云中的应用程序的架构通常是完全不同的。在云中诞生的应用程序往往更倾向于无服务器计算模型,而从本地迁移到云的应用程序通常从更多的 IaaS 服务开始,然后逐渐过渡到使用更多的 PaaS,甚至可能最终转向无服务器计算模型。无服务器计算模型。

假设您有一个想要迁移到 AWS 的 3 层应用程序。除非你有幸与获得资金并支持重建故事的利益相关者合作,否则我们很可能会在第一次迭代中讨论某种“提升和转移”。如果您的应用程序对业务至关重要,那么您还希望在设计应用程序时考虑到高可用性,而无需完全重新架构。那么让我们看看如何在 AWS 上实现这一点。

主要使用 IaaS 的 3 层架构

我上面展示的是一个单区域高可用的 3 层架构。在这个架构中,我们有:

• 带有 Internet 网关的单个 VPC。

• 使用了 2 个可用区。请注意,这是最低要求,并且是 Application Load Balancer 所必需的。

• 面向 Internet 的 ALB(应用程序负载均衡器)部署在公有子网中的 2 个可用区中。用户将通过此 ALB 访问应用程序。

• ALB 附加到表示层的 EC2 ASG(Auto Scaling Group)。 ASG 部署到表示层的私有子网并跨越 2 个可用区。

• 应用程序(逻辑)层也实施为跨 2AZ 的 EC2 ASG,部署在单独的私有子网中,并以内部 ALB 为前端。

• 表示层通过此内部 ALB 与应用程序(逻辑)层对话。

• 数据层使用RDS实现。在这里,我们使用多 AZ 设置,因此我们在第二个 AZ 中有一个备用实例。我们还使用第二个 AZ 上的只读副本实现读取扩展。

• 这里我们使用带有加权路由的 Route 53 私有托管区域来负载平衡从应用程序(逻辑)层到数据层的流量。如果您的应用程序层能够将读取流量拆分为写入流量,那么这可能不是必需的,但如果您需要添加更多只读副本,它仍然是一件好事。请注意,Route 53 是一种解决方法,因为 RDS 不提供负载平衡端点。奥罗拉可以。如果您不想使用 Route 53,则必须推出自己的数据库负载平衡解决方案,该解决方案通常需要您使用 HAProxy 等自定义软件管理另一组 EC2。

• 每个层都由一个安全组保护,该安全组将流量限制在上一层。因此,数据层的安全组只允许来自应用层安全组的入站流量。应用层的安全组只允许出站到数据层的安全组,只允许从内部 ALB 入站。内部 ALB 的安全组只允许出站到应用层的安全组,并且只允许从表示层的安全组入站。表示层的安全组只允许出站到内部 ALB 的安全组,并且只允许从面向 Internet 的 ALB 入站。面向 Internet 的 ALB 允许从任何地方入站,但只能在 HTTP/HTTPS 端口(80 和 443)上。

设置很好,可以很好地运行您的工作负载,但您必须记住,这些都是在 EC2 上运行的,并且随之而来的是修补的责任。您还需要确保调整实例的大小。实施监控和微调 ASG 的设置会有所帮助,但确实需要一些维护开销。那么我们该如何改进呢?这里的下一个架构可能是向完整无服务器模型的过渡状态架构。

这种过渡状态架构也很有趣,因为它提供了一个中间点,使组织可以达到在云原生架构上运行的点,但同时可以对其进行调整,使其成为与云无关的架构。

3层半无服务器架构

在这个过渡状态架构中:

• 应用(逻辑)层保持不变。对此的论据是,这一层通常是最复杂的。因此,您必须真正评估对这一层进行改造是否会转化为您可以证明的成本节约或运营效率提升。

• RDS 替换为 Amazon Aurora 或 Aurora serverless。我们仍然使用多可用区和副本。但是使用 Aurora,我们将不再需要 Route 53 来进行负载平衡,因为 Aurora 默认提供了它。但是,这完全是可选的,很大程度上取决于您组织的战略。 Aurora 是 AWS 专有的,一些组织可能会有点犹豫,因为他们不喜欢被锁定在单个云提供商的想法。

• 表示层替换为简单地将 S3 存储桶配置为 CloudFront 分配背后的源以提供静态内容。现在,我应该重申这是一篇 AWS 架构文章,因此该架构使用 AWS 服务,但对于希望与云无关的组织,我的建议是不要惊慌。 S3 只是一个对象级存储。物体可以轻松移动; CloudFront 不仅适用于 S3。它可以使用任何 HTTP 服务器作为其源。

• 对于动态内容,API Gateway 和 Lambda 函数应运而生。

• 可选,NoSQL数据库可能也有适用的场景,可以使用DynamoDB。

• 为了将 API 网关集成到应用层,我们使用 VPC 链接。这样,API 网关可以配置为与内部 ALB 通信。

虽然我们还可以更进一步,用容器替换应用程序层中的 EC2 实例,但这种方法在很大程度上也取决于您组织的策略。就像我上面提到的那样,一些组织有点犹豫是否全力以赴,因为他们担心这样做会将他们锁定在特定的云提供商中,并且以后很难转移。如果这种情况适用于您,那么进一步将应用程序层容器化以使用 ECS 或 EKS 并就此停止可能是有意义的。

否则,请参阅下文,了解我们如何通过用更多 API 和 Lambda 函数替换应用程序层来进一步精简和简化此架构。 Lambda 也可以配置为在 VPC 中运行并访问您的 VPC 中的资源。

3 层无服务器架构

在这里,我们看到了 AWS 上的 3 层无服务器架构。关键是没有服务器要管理,没有 EC2,没有 ASG,没有 ALB,因此术语 serverless。虽然这与提供网页的 Web 应用程序最接近,但它的变体也适用于其他应用程序。另一个例子是将此架构用作移动后端。在这种情况下,表示层只是移动应用程序,但架构的其余部分将非常相似,如果不相同的话。

如果我有一个全新的应用程序,我肯定会选择从 3 层无服务器架构开始,因为它操作起来非常简单和高效。对于无服务器,我唯一要注意的最后两件事是:

1. 安全不可协商。您仍需对安全负责。确保您遵循最佳实践:例如授予您的 Lambda 函数最低权限 IAM 角色。不要存储凭据,而是使用秘密管理器。

2. 仔细评估无服务器的成本效益。如果您的工作负载是高度可预测的或恒定的,那么无服务器可能并不总是最佳选择。预留的 EC2 实例可以提供很大的折扣。

与往常一样,这只是一个基线或起点,但我希望它有所帮助。请通读官方 AWS 文档和博客,以更仔细地评估您的用例。