Get best of the week

创建无服务器应用程序的提示和资源


尽管近年来无服务器技术迅速普及，但仍然存在许多误解和担忧。供应商依赖性，工具，费用管理，冷启动，监视和开发生命周期-涉及无服务器技术时，所有这些主题都得到积极讨论。在本文中，我们将研究其中提到的一些主题，并分享一些技巧和指向有用信息源的链接，初学者可以使用它们创建功能强大，灵活且经济的无服务器应用程序。

对无服务器技术的误解


许多人认为无服务器和非服务器数据处理（即服务即功能，FaaS）几乎是同一回事。因此，两者之间的差异不会太大，值得介绍一种新产品。尽管AWS Lambda是无服务器技术鼎盛时期的明星之一，并且是无服务器架构中最受欢迎的元素之一，但该架构不只是FaaS。

无服务器技术的基本原理是，您无需担心管理和扩展基础架构，只需为使用的内容付费。许多服务都适合这些条件-AWS DynamoDB，S3，SNS或SQS，Graphcool，Auth0，Now，Netlify，Firebase等。通常，无服务器意味着要使用云计算的所有功能，而无需为了扩展而管理基础架构及其优化。考虑到遵守安全标准的难度和复杂性，这也意味着基础架构级安全不再是您的问题，而是巨大的优势。最后，您无需购买提供给您的基础结构即可使用。

无服务器状态可以被认为是一种“心态”：解决方案设计中的某种心态。避免需要维护任何基础架构的方法。通过无服务器方法，我们花费时间解决直接影响项目并为用户带来收益的问题：我们创建可持续的业务逻辑，开发用户界面以及开发自适应和可靠的API。

例如，如果您可以避免管理和维护自由文本搜索平台，那么我们将这样做。这种构建应用程序的方法可以极大地加速产品在市场上的发布，因为您不再需要考虑管理复杂的基础架构。摆脱管理基础架构的责任和成本，而专注于创建客户所需的应用程序和服务。帕特里克·德布瓦（Patrick Debois）将此方法称为“ servicefull ”，此术语在无服务器社区中采用。应该将功能视为可部署模块形式的服务的连接链接（而不是部署整个库或Web应用程序）。这为部署管理和应用程序更改提供了令人难以置信的粒度。如果您不能以这种方式部署功能，则可能表明功能执行了太多任务，应该对其进行重构。

一些供应商对云应用程序开发的依赖性感到困惑。无服务器技术也是如此，这几乎不是混淆的结果。根据我们的经验，结合AWS Lambda在AWS上创建无服务器应用程序的能力，这些功能部分地形成了无服务器架构的优势。当合并的结果不仅仅是项之和时，这就是协同作用的一个很好的例子。为了避免对供应商的依赖，您可能会遇到更大的问题。使用容器时，在云提供商之间管理自己的抽象级别更加容易。但是，当涉及到无服务器解决方案时，付出的努力是不会成功的，特别是如果从一开始就考虑经济效率。确保找出供应商如何提供服务。一些专门的服务取决于与其他供应商的集成点，并且它们即开即用地可以提供即插即用的连接性。从网关API端点提供Lambda调用比将请求代理到某个容器或EC2实例要容易得多。 Graphcool使用Auth0提供了简单的配置，比使用第三方身份验证更容易。

为您的无服务器应用程序选择合适的供应商是体系结构级别的解决方案。创建应用程序时，您不希望有一天会返回到服务器管理。选择云供应商与选择使用容器或数据库甚至是编程语言没有什么不同。

考虑：

  • 您需要什么服务以及为什么。
  • 云提供商将提供哪些服务，以及如何使用所选的FaaS解决方案将它们组合在一起。
  • 支持哪些编程语言（动态或静态类型，编译或解释，基准是什么，冷启动时的性能是什么，开源生态系统是什么等）。
  • 您的安全要求是什么（SLA，2FA，OAuth，HTTPS，SSL等）。
  • 如何管理您的CI / CD和软件开发周期。
  • 您可以利用哪些基础设施即代码类解决方案？

如果扩展现有应用程序并逐步添加无服务器功能，则可能会在一定程度上限制可用选项。但是，几乎所有无服务器技术都提供某种API（通过REST或消息队列），使您可以创建扩展而无需考虑应用程序内核和简单的集成。寻找具有清晰API，良好文档和强大社区的服务，这不会出错。易于集成通常可能是一个关键指标，这可能是自2015年Lambda发布以来AWS成功的主要原因之一。

当无服务器性有用时


无服务器技术几乎可以应用在任何地方。但是，它们的优点不仅限于一种应用。今天，由于无服务器技术，云进入门槛如此之低。如果开发人员有想法，但他们不知道如何管理云基础架构和优化成本，则无需为此寻找某种工程师。如果一家初创企业想要创建一个平台，但是担心成本可能会失控，那么它很容易转向无服务器解决方案。

由于节省了成本并且易于扩展，无服务器解决方案同样适用于内部系统和外部系统，甚至适用于拥有数百万用户的Web应用程序。帐户不是以欧元为单位，而是以美分为单位。租用最简单的AWS EC2（t1.micro）实例一个月将花费15欧元，即使您不对其进行任何操作（谁也从未忘记将其关闭？！）。相比之下，为了在同一时间段内达到这样的支出水平，您将需要在1秒钟内运行Lambda 512 MB大小大约300万次。如果您不使用此功能，则无需支付任何费用。

由于无服务器技术主要取决于事件，因此很容易将无服务器基础结构添加到较旧的系统中。例如，使用AWS S3，Lambda和Kinesis，您可以为可以通过API接收数据的旧零售系统创建分析服务。

大多数无服务器平台支持不同的语言。最常见的是Python，JavaScript，C＃，Java和Go。通常在所有语言中对库的使用都没有限制，因此您可以使用自己喜欢的开源库。但是，建议不要滥用依赖关系，以使您的功能发挥最佳性能，并且不要使无服务器应用程序的巨大可伸缩性所带来的好处无效。您需要将越多的软件包装载到容器中，冷启动所需的时间就越长。

冷启动是指您首先需要在使用它们之前初始化容器，运行时和错误处理程序。因此，功能执行的延迟可能会达到3秒，这对于不耐烦的用户来说不是最佳选择。但是，停机几分钟后，首次使用时会发生冷启动。因此，很多人认为这是一个小麻烦，可以通过定期ping功能以使其保持空闲状态来解决。甚至忽略这一方面。

尽管AWS已发布了无服务器Aurora无服务器SQL数据库但是，SQL数据库对于此类应用程序并不理想，因为在执行事务时，它们依赖于连接，而连接可能很快成为AWS Lambda上大量流量的瓶颈。是的，开发人员正在不断改进无服务器Aurora，您应该尝试一下，但是如今DynamoDB之类的NoSQL解决方案对于无服务器系统来说要好得多。但是，毫无疑问，这种情况将很快改变。

该工具包还施加了很多限制，尤其是在本地测试领域。尽管有诸如Docker-Lambda，DynamoDB Local和LocalStack之类的解决方案，但是它们需要艰苦的工作和大量的配置。但是，所有这些项目都在积极开发中，因此工具达到我们所需的水平只是时间问题。

无服务器技术对开发周期的影响


由于基础结构只是配置，因此可以使用脚本（例如Shell脚本）定义和部署代码。或者，您可以采用AWS CloudFormation之类的按代码配置类解决方案。尽管此服务未提供所有区域的配置，但它允许您定义特定的资源以用作Lambda函数。也就是说，在CloudFormation让您失望的地方，您可以编写自己的资源（Lambda函数），这将弥补这一差距。这样，您可以执行任何操作，甚至可以在AWS环境之外配置依赖项。

由于所有这些只是配置，因此您可以为特定环境，区域和用户设置部署脚本的参数，尤其是在使用诸如CloudFormation之类的以代码为基础的类解决方案时。例如，您可以为存储库中的每个分支部署基础结构的副本，以在开发过程中对其进行全面的隔离测试。当开发人员想了解他们的代码在实时环境中是否能正常工作时，这可以大大加快开发人员的反馈速度。管理人员无需担心部署多个环境的成本，因为只支付实际使用费用。

DevOps的担忧更少，因为他们只需要确保开发人员具有正确的配置即可。您不再需要管理实例，平衡器或安全组。因此，尽管能够配置基础结构仍然很重要，但尤其是在进行IAM配置和优化云资源时，NoOps一词正在越来越多地使用。

有非常强大的监视和可视化工具，例如Epsagon，Thundra，Dashbird和IOPipe。它们使您可以监视无服务器应用程序的当前状态，提供日志和跟踪，记录性能指标和体系结构瓶颈，执行成本分析和预测等等。它们不仅为DevOps工程师，开发人员和架构师提供了有关应用程序工作方式的全面概念，而且还使管理人员能够以每秒的资源成本和成本预测来实时监视情况。使用托管基础架构进行管理要困难得多。

设计无服务器应用程序要简单得多，因为您无需部署Web服务器，管理虚拟机或容器，补丁服务器，操作系统，Internet网关等。所有这些职责的抽象使无服务器体系结构可以专注于主要内容-解决方案业务和客户的需求。

尽管该工具包可能会更好（每天都在改进），但是开发人员可以专注于实现业务逻辑以及在体系结构中跨不同服务的应用程序复杂度的最佳分布。无服务器应用程序是由事件驱动程序并由云提供程序抽象化的（例如，SQS，S3事件或DynamoDB流）。因此，开发人员只需要规定业务逻辑来响应某些事件，您就不必担心如何更好地实现数据库和消息队列，或者如何组织特定硬件存储中的数据的最佳工作。

与任何开发过程一样，可以在本地执行和调试代码。单元测试保持不变。通过自定义堆栈配置部署整个应用程序基础结构的能力使开发人员可以快速获得重要的反馈，而不必担心测试成本或对昂贵的托管环境的影响。

用于构建无服务器应用程序的工具和技术


没有构建无服务器应用程序的特定方法。以及用于此任务的一组服务。 AWS是当今功能强大的无服务器解决方案的领导者，但是请注意Google Cloud，Zeit和Firebase。如果使用AWS，则可以推荐使用无服务器应用程序模型（SAM）作为收集应用程序的方法，尤其是在使用C＃时，因为Visual Studio是一个很好的工具包。 SAM CLI可以执行与Visual Studio相同的所有操作，因此，如果切换到另一个IDE或文本编辑器，则不会丢失任何内容。当然，SAM也可以使用其他语言。

如果您使用其他语言编写，那么无服务器框架是一种出色的开源工具，可让您借助功能强大的配置YAML文件来配置任何内容。无服务器框架还支持各种云服务，因此我们建议那些正在寻找多云解决方案的人使用它。他有一个庞大的社区，创建了许多可以满足任何需求的插件。

对于本地测试，开源工具Docker-Lambda，无服务器本地，DynamoDB Local和LocalStack非常适合。无服务器技术及其工具仍处于开发的早期阶段，因此在设置复杂的测试方案时，您将不得不大汗淋漓。但是，仅在环境中扩展堆栈并进行测试就发现价格便宜得令人难以置信。而且您不需要在云环境中进行精确的本地复制。

使用AWS Lambda层可减少已部署程序包的大小并加快加载速度。

针对特定任务使用正确的编程语言。不同的语言各有优缺点。有许多基准测试，但是JavaScript，Python和C＃（.NET Core 2.1+）在AWS Lambda性能方面处于领先地位。最近，运行时API出现在AWS Lambda中，它允许您指定所需的语言和运行时，因此请进行实验。

保持程序包较小以进行部署。它们越小，加载速度越快。避免使用大型库，尤其是当您使用其中的几个功能时。如果您使用JavaScript编程，请使用Webpack等构建工具来优化构建，并仅包含您真正需要的内容。.NET Core 3.0具有QuickJit和Tiered Compilation，可提高性能并在冷启动中提供很多帮助。

首先，无服务器功能对事件的依赖性可能会使业务逻辑的协调复杂化。在这方面，消息队列和状态机可能非常有用。 Lambda函数能够相互调用，但是只有在您不希望收到答案（“射中忘了”）时，您才可以这样做。消息队列对于隔离部分业务逻辑，管理应用程序瓶颈和处理事务（使用FIFO队列）很有用。可以将AWS Lambda函数分配为SQS队列，作为挂起消息队列，以跟踪失败的消息以供以后分析。 AWS Step Functions（状态机）对于管理需要创建功能链的复杂流程非常有用。代替调用Lambda函数的另一个函数，Step函数可以协调状态转换，在函数之间传输数据并控制函数的全局状态。这使您可以确定重试的条件，或确定发生特定错误时需要执行的操作-在某些条件下，这是一个非常强大的工具。

结论


近年来，无服务器技术以前所未有的速度发展。与这种范式转换有关的某些误解。通过抽象化基础架构并管理扩展，无服务器解决方案具有显着的优势：从简化的开发和DevOps流程到大幅降低运营成本。
尽管无服务器方法并非没有缺点，但仍有可靠的设计模式方法可用于创建稳定的无服务器应用程序或将无服务器元素集成到现有体系结构中。

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles