构建一个自动化的软件系统意味着多年来设置具有专用 CPU 配置、内存、存储和其他资源的多台服务器。 接下来，组建了一个管理员团队来管理这些系统。 然后开发团队接管了基础设施并开始创建连接服务器的流程。
这个过程可能很复杂，因为它涉及到许多不同的团体为了一个共同的目标而共同努力。 这些利益冲突可能会成为一个问题。
它也可能非常昂贵。 这要求您的工资单上有管理员。 持续运行的服务器会消耗资源，尽管未被使用。
为了随着时间的推移保持最佳性能，您需要一个自动扩展服务器资源的自动扩展解决方案。
云平台有一个优势：它允许您创建端到端架构，而无需服务器集群设置。 从管理的角度来看，没有什么可维护的。
对于初创公司和项目的最小可行产品 (MVP) 阶段来说，这是一种具有成本效益的选择。 如果难以预测未来的生产负载和用户活动，这是一个很好的起点。 这就是确定集群服务器的配置可能具有挑战性的地方。
通过无服务器云服务实现流程自动化是无服务器架构脱颖而出的原因。 它连接服务并产生类似于传统集群服务器的结果。
这是仅使用原生 AWS 服务构建此类架构的示例。
获取服务无服务器流
想象一下，您想创建一个平台来收集一些具体资产基础设施（可以是任何制造或公用事业资产）的各种数据和图片（或照片）。
- 为了使未来的分析成为可能，有必要首先摄取传入的数据。
- 应用业务规则后，后端程序将计算出的输出作为规范化信息保存在关系数据库中。
- 显示标准化干净数据的应用程序前端允许用户查看结果。
让我们检查一下架构可以包含哪些组件。
AWS S3 存储桶
资料来源：aws.amazon.com
Amazon S3 存储桶是在 AWS 云中存储文件或图片的绝佳方式。 S3 存储桶的存储价格非常低。 更重要的是，引入 S3 存储桶生命周期策略进一步降低了这个价格。
这样的策略会自动将旧文件移动到不同类别的 S3 存储桶中，例如存档或深度存档访问。 这些类的不同之处还在于访问时间的速度，但对于旧数据，这将不是一个问题。 它主要用于在发生紧急事件时访问存档数据，而不是用于标准操作需要。
- 您可以在子文件夹中组织数据。
- 您应该设置适当的权限限制。
- 将标签添加到存储桶，使其易于识别并可能在动态 S3 存储桶策略中使用。
- 该存储桶在设计上是无服务器的。 它只是您数据的存储空间。
S3 存储桶在设计上是无服务器的。 它只是您数据的存储空间。
AWS 雅典娜数据库
资料来源：aws.amazon.com
Athena 可以轻松创建 AWS 基本数据湖。 它是一个没有服务器的数据库，使用 S3 存储桶来存储其数据。 数据组织由结构化文件格式维护，例如镶木地板或逗号分隔值 (CSV) 文件。 S3 存储桶保存文件，每当进程从数据库中选择数据时，Athena 都会引用它们。
请注意，Athena 不支持其他被视为标准的各种功能，例如更新语句。 这就是为什么您需要将 Athena 视为一个非常简单的选项。
但是，它支持索引和分区。 它还可以非常轻松地水平扩展，因为这与向基础设施添加新桶一样复杂。 对于简单而实用的数据湖创建，这在大多数情况下仍然足够。
为了获得良好的性能，选择最好的数据设计并着眼于未来的使用是必不可少的。 必须非常清楚您希望选择数据的方式。 一旦表格已经存在并且填充了大量数据，稍后重新创建表格是很困难的。
如果您希望创建一个简单且不可变的数据池，并且易于随时间水平扩展，那么 Athena DB 是一个不错的选择，非常适合您的目标。
AWS 极光数据库
资料来源：aws.amazon.com
Athena DB 擅长存储未经整理的数据。 毕竟，这就是您希望存储原始内容的方式，以最大限度地提高其未来的重用率。 但是，向前端应用程序提供选择结果的速度很慢。
最好的选择之一，主要是从易于执行设置的角度来看，是以无服务器模式运行的 Aurora 数据库。
Aurora 远不是一个基本的数据库。 它是 AWS 中最先进的原生关系数据库解决方案之一。 它也是一个高度复杂的本机关系数据库解决方案，每个版本都在改进。
Aurora 的独特之处在于它可以在无服务器模式下运行，这使其从其他关系型服务中脱颖而出。 这是该模式的工作原理：
- 要配置 Aurora 集群，请使用 AWS 控制台。 您将需要指定标准 CPU 和 RAM 级别以及自动缩放功能的最大间隔。 这将影响 Aurora 集群可以动态添加或删除的性能。 根据数据库的当前利用率，AWS 决定向上或向下扩展。
- 除非用户或进程发起真正的请求，否则 Aurora 集群不会启动。 例如，计划的批处理开始时。 或者，如果应用程序执行后端 API 调用以从数据库中检索数据。 请求过程完成后，数据库将自动打开并在预定时间内保持活动状态。
- 如果数据库中没有更多工作，Aurora 集群将自动关闭。
再次强调一下，无服务器 Aurora DB 仅在必须执行实际工作时才运行。 如果没有处理任何工作，自动启动的集群将再次关闭。 实际工作是您支付的费用，而不是您的空闲时间。
无服务器 Aurora 完全由 AWS 管理，不需要管理员。
AWS 放大
Amplify 提供了一个无服务器平台，用于快速部署使用 JavaScript 和 React 库制作的前端应用程序。 无需设置集群服务器。 使用 AWS 控制台直接部署代码，或使用自动化 DevOps 管道。
您可以调用后端 API 来访问存储在数据库中的数据。 这些调用允许您访问前端应用程序中的实际数据。 后端的主要性能优化应该由团队来完成。 如果直接在 API 调用中设计有效的选择语句，您甚至可以进一步降低 UI 中响应缓慢的可能性。
AWS 步骤功能
资料来源：aws.amazon.com
尽管系统的所有主要组件都是无服务器的，但这并不能保证完全无服务器的架构。 这只有在组件之间的所有批处理都是无服务器的情况下才有可能。
AWS Step 函数提供了 AWS 云上的最佳解决方案。 AWS Lambda 函数的连接列表构成了步骤函数。 这些函数创建了一个具有清晰开始和结束状态的流程图。 通常用 Python 或 Node JS 语言编写的 lambda 函数是一段可执行代码，可以处理所需的任何内容。
以下是如何执行阶跃函数的示例：
这种无服务器流程有一个主要缺点：每个 lambda 函数最多只能运行 15 分钟。 因此，将流程拆分为更小的 lambda 函数可以减少问题。
可以在一个步骤中同时调用多个 lambda 函数，这基本上意味着将一个步骤与同时执行的多个 lambda 并行化。 在继续之前，只需等待所有并行 lambda 处理完成即可。 然后，进行下一个 lambda 处理。
最后的话
无服务器架构提供了一个独特的机会来创建一个涵盖整个系统环境的云平台。 该平台可横向扩展，同时运营成本低。
它是预算受限项目的完美解决方案。 这是一个极好的探索选项，通常是在没有人知道实际生产负载的情况下。 在您成功让所有用户入职后，这一点尤为重要。 项目团队仍然可以全面了解系统的工作原理。 您可以获得所有这些好处，但仍然无需接受妥协。
此覆盖范围不足以适用于所有情况，尤其是那些涉及高 CPU 使用率的情况。 然而，AWS 云在无服务器用例方面不断发展。 在为下一个 AWS 云项目决定无服务器选项之前，进行彻底的研究通常是个好主意。
接下来，查看适用于现代应用程序的最佳无服务器数据库。
