在过去的几个月中，AWS围绕其Aurora产品发布了一些公告，例如：
Postgres Aurora无服务器（测试版） – 11/20/2018

所有这些功能都朝着使无服务器数据库成为可用于生产的解决方案的最终目标努力。即使提供了最新的产品，您是否应该探索向无服务器架构的迁移？本博客着重介绍了在数据层使用后端即服务（BaaS）时的一些注意事项。
假设您已经进行了必要的架构更改并且已经迁移，或者已经熟悉使用Aurora Classic实施新数据库。Aurora当前提供两种模型-Provisioned和无服务器Aurora。供应的传统AWS数据库具有自我管理的EC2实例，或使用AWS托管的RDS实例作为PAAS模型运行。在这两种情况下，除了创建安全组以允许应用程序侦听TCP连接字符串之外，还必须分配内存和CPU。

在这种模式下，问题可以直接到达连接。在开始看到性能下降或当限制达到最大时无法完全连接之前，有多少个连接可以访问数据库的限制。除此之外，您的应用程序可能还会收到不同程度的流量（例如，在旺季或促销期间使用的零售应用程序）。即使您在前面实现了一个缓存层（例如Memcache或Redis），您仍然会遇到这样的情况：实例最终将不得不垂直扩展到一个更健壮的实例，或者水平地使用副本来分布读写。
这是无服务器提供一些价值的地方。值得回顾的是，无服务器数据库并不等于没有服务器。那里有服务器，但是服务器是从用户（或本例中的应用程序）中抽象出来的。遵循最近的计算趋势，Serverless专注于编写业务逻辑，而不再关注基础架构管理和资源调配，以从需求阶段部署到产品准备就绪阶段。在传统的数据库模型中，您仍然负责保护设备，身份验证，加密以及与实际业务功能无关的其他操作。
Aurora Serverless的工作方式
无服务器Aurora提供的可帮助减轻扩展和连接问题的产品是后端即服务解决方案。应用程序和Aurora实例必须部署在同一VPC中，并通过通过网络负载平衡器（NLB）的端点进行连接。这样做可以使连接终止于负载均衡器而不是应用程序。

通过抽象化连接，您不再需要创建逻辑来管理负载平衡算法，也不必担心进行DNS更改以促进数据库端点更改。NLB具有通过请求路由器建立的路由逻辑，该请求路由器与当时可用的任何实例建立连接，然后映射到基础的无服务器数据库存储。如果无服务器数据库需要扩展，则资源池始终可用并保持温暖。如果实例缩小到零，则连接将无法持久。

通过拥有可用的热实例池，您现在拥有了按使用量付费的模型，您可以在其中为使用的资源付费。您仍然会遇到无法修改的最大连接数问题，但是自初始版本以来，较小的2和4 ACU实施允许的数量有所增加。
注意：冷却时间不是即时的，在实例完全空闲后最多可能需要5分钟，并且您仍需为此付费。同样，即使实例保持温暖，与这些实例的连接仍必须启动。如果在此期间对数据库进行查询，则查询完全执行之前，您会看到25秒或更长时间的等待时间。
费用注意事项：
您真的可以完全缩小规模吗？从技术上讲，如果满足某些条件，则：

CPU利用率低于30％
少于40％的连接正在使用

为了实现这一目标并节省成本，数据库必须完全空闲。不能有长时间运行的查询或锁定的表。此外，应用程序外部的各种活动都可以生成查询，例如打开的会话，监视工具，运行状况检查等等。只有在满足条件且活动为零时，数据库才会暂停。
.06 / VCU的无服务器Aurora的价格高于其预配置的.041的价格。Aurora classic还按小时收费，其中无服务器Aurora至少按5分钟和5分钟的冷却时间按秒收费。我们已经讨论过，在许多情况下，降温不是即时的，现在您堆积如山，直到那段时间之后再过5分钟，账单才会停止。如果您使用传统的最小2 VCU设置，并且从不按比例缩小实例，则成本会增加至少3倍。因此，要获得相同的成本回报，您的数据库将只需要运行1/3的时间，并且对于停放的开发/测试盒或仅在单个时区的工作时间内使用的应用程序而言，可以实现该数据库。默认情况下，无服务器Aurora应该是高度可用的，
允许最少1ACU允许您完全缩减到无服务器数据库的选项，并使价格点与RDS更可比，而无需启用暂停。
迁移
迁移到无服务器Aurora相对简单，因为您只需从现有数据库中加载快照即可。
数据API
使用Data API，您不再需要持久连接来查询数据库。在以前的方案中，如果在冷静期后执行查询，则获取可能需要25秒或更长时间。在这种情况下，即使无服务器数据库闲置了一段时间，您也可以查询它。您可以通过API网关利用Lambda函数，该函数适用于VPC实现。AWS曾提到，它将在未来几个月内平均使用数据API执行查询的时间提供性能指标。

结论
通过创建EC2，Docker和Lambda函数，我们已经看到了计算领域的更多创新，而不是数据层的创新。传统的预置关系数据库难以扩展，并且对连接数量有有限的限制。通过消除对实例的需求，此抽象级别为不可预测的工作负载提供了强大的用例。感谢AWS在此层设计解决方案。最近几个月的最新更新彰显了AWS解决复杂问题的意愿。运行1ACU确实可以将成本降低到与RDS相当的水平，同时提供了一种机制，如果您禁用暂停功能，则可以提高性能。但是，尽管现在可以更经济高效地运行Aurora无服务器24/7，但这种情况与具有开/关数据库的签名用例形成了对比。
无服务器似乎仍然更适合很少使用的数据库，并且偶尔会出现高峰或主要在工作时间使用的应用程序。管理时间仍然是一个代价，无服务器数据库尽管取得了进步，但仍然有许多未知数。管理员可能需要一些时间和耐心才能真正获得高性能，高可用性且不太昂贵的配置。即使您不必依靠自动化并可以手动扩展Aurora无服务器群集，也要花一些精力以不立即终止连接的方式。今天，如果真正的无服务器数据库是理想的目标，则可以将ECS或Fargate与竞价型实例配合使用，并以较低的成本实施可产生相似或更好结果的解决方案。我仍然建议在开发/测试工作负载中使用此工具，并查看该工具是否仍可以提供很多价值，是否可以逐步开发出适合较小工作负载的产品。希望AWS不久将发布适用于MySQL 5.7和Postgres的GA产品。

ITPub博客

无服务器Aurora –是否已准备好投入生产？

最新文章