翻译者 | 蔡柱梁

策画 | Ethan

责任编辑探讨了现阶段盛行的用作同时实现无伺服器构架扩充实例的构架，和何时能能采用它。

在责任编辑中，他们探讨了小规模运转无伺服器的小常识。责任编辑还探讨了现阶段盛行的用作同时实现这种无伺服器构架扩充实例的构架，和他们如何和何时能能透过 AWS Lambda 和 Dynamo DB 实例可扩充快捷键最差地采用无伺服器构架进行扩充。

一、为何谈及无伺服器的可扩充性？

当他们谈及可扩充性时，在许多情况下，可扩充性、易用性和操控性能透过顾客完全控制的邻近地区基础建设增设，得到最差强化。但是，当财政预算审核缩紧时，作业系统管理工作、伺服器布署、图书馆员等的不间断保护和收费生产成本就会正式成为问题，并被认为是非常高的生产成本。

按需退款正式成为了节约开支的首要条件优先选择！

在无伺服器构架中，需要强化标识符以促发机能以积极响应该事件，因而只需为促发该事件处在激活状态的时间订阅。若要出现最大值时，阻抗忽然攀升会引致更多该事件，从而引致更多生产成本。因而，它显著减少了营运生产成本和与之相关的复杂程度，因而合作开发者能著眼于只提供第二产业结果。在无伺服器构架的情况下，云服务供应商处置 100% 的伺服器管理工作，包括网络流量强化、合作开发自然环境预览、分权和后端实用性。因而，这就像以更低的生产成本获得零到最轻的开支！

在这里，在高峰期阻抗前夕，无伺服器机能能随心所欲扩充以积极响应高峰期时的数个mammalian允诺。

二、小规模无伺服器应用程序的结构设计数学模型小常识

1.结构设计：无伺服器并行数学模型

在无服务器并行数学模型中，无伺服器机能将根据允诺/该事件的数量进行缩放，从而产生相应的输出数量。

但是，在这种情况下，如果目标输出系统或下游系统的结构设计或建模未端有过多额外阻抗，则可能会崩溃。

它适用作最大值阻抗时目标输出已知的情况。如果他们知道他们的系统能够小规模处置或存储最大值阻抗，那么这个数学模型可能非常简单、快速、生产成本最低且方法高效。

2.结构设计：更适合云原生结构设计的异步数学模型

在这个数学模型中，他们考虑解耦他们的构架并采用中间弹性服务来存储传入的允诺轰炸而不会丢失任何数据。

对于中间存储服务，他们能考虑任何该事件支持数学模型，如队列，例如 IBM MQ、Amazon SQS，甚至持久存储，如 Amazon S3/Dynamo DB 等，或任何流服务，如 Apache Kafka、Amazon Kinesis 等。

在此结构设计中，例如，他们能轮询来自队列/数据存储的允诺，然后定义一个批次，其中无伺服器机能能在每次迭代中处置定义的批次大小的允诺，并以最差方式将结果发送到目标系统。

在这个数学模型中，他们能更好地控制来处置目标系统的限制（如果有的话），同时确保消息的可靠性。

三、结构设计数学模型以 AWS Lambda Dynamo DB 和 SES 无伺服器快捷键为例进行说明

考虑一家大型航空公司服务供应商，他们可能必须处置数以百万计的季节性航班预订，这些航班预订因不同的假期而异。

如果航空公司提供商考虑上面详述的结构设计 1，可能的解决方案可能如下所示，其中 AWS Gateway 与数个后端（如 AWS Lambda、Dynamo DB、SES 和 S3）通信。

1.结构设计实例1

在这里，他们采用 AWS API Gateway 将消息路由到并发的 Lambda 函数，然后将结果输出到 Amazon DynamoDB，这是一个 NoSQL 数据库，用作在此处存储数据并能根据扩充的阻抗进行扩充，Amazon SES，生产成本-有效、灵活和可扩充的电子邮件服务，使航空公司服务供应商能够根据需要向用户发送电子邮件通知，Amazon S3 用作托管静态网站内容，如 HTML、媒体文件、CSS、JavaScript 作为前端在航空公司顾客端的浏览器中。

三个目标系统——Dynamo DB、SES 和 S3 本身是具有良好扩充能力的产品；因而，该结构设计非常适合考虑 CloudWatch 警报增设，以促发另一组 Lambda 函数，以便在警报发出任何警报时根据需要向用户发送通知消息。

他们能利用 CloudFront 在全球范围内安全地分发静态内容，并提供更好的操控性，如上所示。采用 CloudFront 缓存静态内容可为提供所需的操控性和规模，从而为查看者提供快速可靠的体验。CloudFront 会随着全球分布的顾客端在的用户所在的边缘获得可用的允诺数据而自动扩充。Amazon CloudFront 可用作动态内容并利用缓存等机能。

另一种情况可能是零售连锁店预计只有在超级销售前夕才会出现最大值阻抗，但当然不能依赖目标系统容量，因为这个销售日可能是黑色星期五的预期正常工作日的吞吐量可能是多方面的。

在这里，他们能透过引入 Amazon SQS 来优先选择下面指定的快捷键，例如，可靠地存储消息，然后以非常适合其在 Dynamo DB 可扩充数据存储中的底层存储的批量大小促发 Lambda 函数。

2.结构设计实例2

3.Lambda mammalian与吞吐量

他们能根据吞吐量和函数执行时间对 lambda 进行高级mammalian估计，如下所示：

mammalian估计

平均函数执行时间（以秒为单位）* 平均允诺/秒 = mammalian估计

例如:如果允诺的平均执行时间为 0.2 秒，吞吐量为 5 个允诺/秒，则mammalian估计 = 0.2 *5 = 1

四、无伺服器中的扩充限制

当所需机能的所有当前容器都已处在处置该事件的中间时，Serverless 机能需要横向扩充。

它毫不费力地神奇地做到了！

例如，AWS Lambda 函数将自动扩充以支持额外的阻抗，而无需提前提供。更重要的是，500 个容器并行处置 500 个该事件的 lambda 生产成本与一个容器一次串行处置一个该事件的生产成本相同。

那么他们是说他们能采用无服务器构架无限扩充吗？

显然不会。那样的话，云服务供应商很快就会破产！

因而，默认情况下，每个 CSP 将针对每个区域每个帐户的所有无伺服器函数的mammalian执行数量增设这些限制。例如，对于每个 AWS 帐户，Lambda 函数的此限制当前为 1000，但他们能透过联系 CSP 支持团队允诺增加此限制。

如果他们达到CSP 增设的缩放限制，他们会在执行中看到节流错误。

需要注意的是，由于此限制是账户范围的，因而扩充 BIG 的一个无伺服器函数可能会影响同一账户中所有其他函数的操控性。因而，建议将预期在不同账户中扩充的不同潜在服务分开，以避免这些节流问题。

1.mammalian控制

避免由于上述扩充限制而引致的节流错误的另一种优先选择是在 CSP 级别为每个函数实用性mammalian控制。

所以在 AWS Lambda 的情况下，他们能实用性如下：

2.预留mammalian

他们能为每个函数增设 Reserved Concurrency，这样其他函数就无法采用它的限制，并在尝试扩充时对该函数造成限制问题。这通常能免费实用性。

3.预置mammalian

借助预实用性mammalian，他们能允诺 CSP 提供一些预实用性自然环境以立即运转并积极响应预期的最大值阻抗。借助预实用性mammalian，CSP 将负责为提供自然环境，而不会出现任何冷启动延迟。然而，这是一个收费快捷键。

4.其他压力点

除了节流错误之外，他们可能会在小规模执行前夕看到如下其他压力点：

5.强化

如果遇到上面列出的压力点，他们能采用以下可能的强化解决方案：

(1)Lambda 函数 -> AWS Step Functions 工作流

(2)更丰富的工作流程如下：

(3)API 网关限制快捷键

(4)将 API 从 Synch 转换为 Asynch，并采用 Polling、Webhooks、Websockets等模式

(5)考虑更改数据库类型，例如 Amazon Aurora Serverless 数据 API 或采用 Dynamo DB

(6)汇集和共享数据库连接

五、无伺服器扩充数学模型

无伺服器机能（例如 Lambda 默认情况下）遵循水平扩充数学模型，透过实例化新容器来处置额外阻抗。

同时，他们也能将无伺服器机能实用性为垂直扩充。例如，AWS 中的 Lambda 函数能手动实用性为从 128 MB 扩充到 10 GB RAM（当前），因而操控性按垂直比例扩充。

原文链接：

翻译者介绍

蔡柱梁，51CTO社区编辑，从事Java后端合作开发8年，做过传统项目广电BOSS系统，后投身互联网电商，负责过订单，TMS，中间件等。