翻译|蔡竹良策展|Ethan本文讨论了用于实现无服务器扩展用例的流行架构，以及何时可以使用它们。在本文中，我们讨论了大规模运行无服务器的注意事项。本文还讨论了当今流行的无服务器扩展用例架构，以及我们如何以及何时可以使用无服务器架构与AWSLambda和DynamoDB示例可扩展性选项进行最佳扩展。1、为什么要讲serverless的可扩展性？当我们谈论可扩展性时，在许多情况下，可扩展性、可用性和性能可以通过客户完全控制的本地基础设施设置得到最佳优化。但是，当预算审批收紧时，操作系统管理、服务器部署、管理员等的24/7维护和计费成本将成为一个问题，并被认为是非常高的成本。现收现付是唯一省钱的方法！在无服务器架构中，需要优化代码以触发响应事件的功能，并且您只需为触发事件处于活动状态的时间付费。只有在出现峰值时，负载的突然峰值才会导致更多事件，从而导致更多成本。因此，它显着降低了运营成本和与之相关的复杂性，开发人员可以专注于只提供富有成效的结果。在无服务器架构的情况下，云服务提供商处理100%的服务器管理，包括流量优化、开发环境更新、资源分配和后端配置。所以这就像以更低的成本获得零到最小的开销！在这里，在高峰负载期间，无服务器功能可以轻松扩展以响应高峰时段的多个并发请求。二、大规模Serverless应用的设计模型注意事项1、设计：Serverless同步模型在Serverless同步模型中，Serverless函数会根据请求/事件的数量进行伸缩，从而产生相应数量的输出。但是，在这种情况下，如果在目标输出系统或下游系统的设计或建模结束时附加过多负载，则可能会崩溃。当峰值负载的目标输出已知时，它是合适的。如果我们知道我们的系统能够大规模处理或存储峰值负载，那么这个模型可以非常简单、快速、成本最低且有条理地高效。2.设计：更适合云原生设计的异步模型在这个模型中，我们考虑解耦我们的架构，并使用中间弹性服务来存储传入的请求轰炸而不丢失任何数据。对于中间存储服务，我们可以考虑任何事件支持模型，如IBMMQ、AmazonSQS等队列，甚至AmazonS3/DynamoDB等持久存储，或任何流服务，如ApacheKafka、AmazonKinesis等。在这个设计，例如，我们可以轮询来自队列/数据存储的请求，然后定义一个批次，其中无服务器功能可以在每次迭代中处理定义的批次大小的请求，并将结果最佳地发送到目标系统。在这个模型中，我们有更多的控制权来处理目标系统的限制（如果有的话），同时确保消息的可靠性。3.以AWSLambdaDynamoDB和SES无服务器选项为例说明的设计模型考虑一个大型航空公司服务提供商，它可能必须处理数百万个因假期不同而有所不同的季节性航班预订。如果航空公司提供商考虑上面详述的设计1，可能的解决方案可能如下所示，其中AWSGateway与多个后端通信，例如AWSLambda、DynamoDB、SES和S3。1.设计实例1这里，我们使用AWSAPIGateway将消息路由到并发的Lambda函数，然后将结果输出到AmazonDynamoDB，它是一个存储数据并可以根据负载规模进行扩展的NoSQL数据库Scale，AmazonSES,经济高效、灵活且可扩展的电子邮件服务，使航空公司服务提供商能够按需向用户发送电子邮件通知，AmazonS3用于托管静态网站内容，例如HTML、媒体文件、CSS、JavaScript作为航空公司客户浏览器的前端.三个目标系统——DynamoDB、SES和S3是可以自行扩展的产品；因此，该设计非常适合考虑CloudWatch警报设置来触发另一组Lambda函数，以向用户发送通知消息。我们可以利用CloudFront在全球范围内以更好的性能安全地分发静态内容，如上所示。使用CloudFront缓存静态内容可提供为查看者提供快速可靠的体验所需的性能和规模。CloudFront会随着请求数据对位于用户所在边缘的全球分布式客户端可用而自动扩展。AmazonCloudFront可用于动态内容并利用缓存等功能。另一种情况可能是，零售连锁店预计仅在超级销售期间出现峰值负载，但当然不能依赖目标系统容量，因为该销售日可能是黑色星期五，而预期的正常工作日吞吐量可能是多方面的。在这里，我们可以通过引入AmazonSQS选择下面指定的选项，例如，可靠地存储消息，然后触发Lambda函数，其批处理大小非常适合其在DynamoDB可扩展数据存储中的底层存储。2.设计示例23.Lambda并发和吞吐量我们可以根据吞吐量和函数执行时间对lambda进行高级并发估计，如下所示：ConcurrencyEstimateAverageFunctionExecutionTime(inseconds)*AverageRequests/Sec=ConcurrencyEstimation示例：如果一个请求的平均执行时间为0.2秒，吞吐量为5个请求/秒，则并发估计=0.2*5=14.Serverless中的扩展限制当所需功能的所有当前容器都已在Serverless功能中时，需要在处理事件中间时向外扩展。它神奇地毫不费力地做到了！例如，AWSLambda函数将自动扩展以支持额外的负载，而无需提前配置。更重要的是，500个容器并行处理500个事件的lambda成本与一个容器一次串行处理一个事件的成本相同。那么我们是说我们可以使用无服务器架构无限扩展吗？很明显不是。那样的话，云服务提供商很快就会倒闭！因此，默认情况下，每个CSP都会为每个帐户每个区域的所有无服务器函数的并发执行数设置这些限制。例如，Lambda函数的此限制目前是每个AWS账户1000个，但我们可以通过联系CSP支持团队请求增加此限制。如果我们达到CSP设置的缩放限制，我们将在执行中看到节流错误。请务必注意，由于此限制适用于账户范围，因此扩展BIG的一个无服务器功能可能会影响同一账户中所有其他功能的性能。因此，建议将预期在不同账户中扩展的不同底层服务分开，以避免这些节流问题。1.并发控制另一种避免由于上述扩展限制引起的节流错误的选择是在CSP级别为每个函数配置并发控制。所以在AWSLambda的情况下，我们可以配置如下：2.ReservedConcurrency我们可以为每个函数设置ReservedConcurrency，这样其他函数就不能使用它的限制并在尝试扩展时导致该函数的限制问题。这通常可以免费配置。3.预置并发通过预置并发，我们可以请求CSP提供一些预配置的环境，以立即运行并响应预期的峰值负载。借助预置并发，CSP负责预置环境，而不会出现任何冷启动延迟。但是，这是付费选项。4.其他压力点除了节流错误，我们可能会在大规模执行过程中看到其他压力点，如下所示：数据库负载会影响查询性能和Lambda执行时间。lambda执行时间越长，成本越高，同时也会导致APIGateway超时（~29秒）。较长的lambda执行时间也会导致Lambda函数超时（约15分钟）。Lambda突发节流导致API网关错误。5.优化如果遇到上面列出的压力点，我们可以采用以下可能的优化方案：(1)Lambda函数->AWSStepFunctions工作流程(2)更丰富的工作流程如下：(3)APIGatewayLimitoptions(4)将API从同步转换为异步，并使用轮询、Webhooks、Websockets等模式无服务器扩展模型无服务器函数（例如Lambda）默认遵循水平扩展模型，通过实例化新容器来处理额外负载。同时，我们还可以配置serverlessfunctions进行垂直扩展。例如，AWS中的Lambda函数可以手动配置为从128MB扩展到10GBRAM（当前），并且性能垂直扩展。原文链接：https://dzone.com/articles/serverless-at-scale译者介绍蔡柱良，社区编辑，从事Java后端开发8年，从事传统广电BOSS系统，后进致力于互联网电子商务，负责Orders、TMS、middleware等。
