构建服务器_您是否真的在构建无服务器系统？

构建服务器

无服务器计算（或简称为“无服务器”）是软件开发组织中新兴的架构选择。 无服务器计算有两种形式：后端即服务，为应用程序开发人员提供用于推送通知等常见服务的API，以及功能即服务（FaaS），允许开发人员在服务器中部署代码（“功能”）。响应事件而执行的云，而不必担心其执行环境（无论是服务器还是容器）。

当开发人员使用FaaS时，云提供商负责自动部署功能并随着工作负载的变化对其进行扩展。 在本文中，我重点介绍无服务器的FaaS风格，并交替使用“ FaaS”和“无服务器”术语。

无服务器支持者声称，它使软件的开发和部署比以往任何时候都更加轻松，快捷和廉价。 无服务器架构使开发团队能够专注于业务价值，而不是运营开销。 但是有时，在急于采用有前途的新架构时，组织无法跟踪无服务器架构的目标，这是架构范式转换的常见问题。 结果，他们构建的系统无法充分发挥其优势，或者在维护方面比应有的挑战更大。 仅仅因为您的代码实现了FaaS接口并不意味着您在做无服务器的正确操作。

在我深入探讨无服务器实现出现问题的方式之前，让我们退后一步，询问您使用FaaS想要实现的目标。 您真正的目标是什么？

组织通常采用无服务器体系结构，并牢记两个目标：

• 简单的操作模型。 无服务器架构让您专注于一件重要的事情：您的应用程序正在处理的业务流程。 云提供商提供的FaaS框架都承诺会随着使用量的增加和缩小。 如果您的应用程序必须处理更多事件，则它们将运行所需数量的函数副本以处理需求。 您无需担心扩展。 您无需计划下一季度的容量。 监视也要简单得多-您仍然需要监视应用程序的业务输出，但是不需要监视应用程序及其底层基础结构。
• 按使用付费模式。 云提供商根据实际使用情况对FaaS收费； 例如，处理的请求数和使用的内存秒数。 计算可能有些复杂，但是最终逻辑很难争论。 将此与更传统的计算（内部部署和云计算）进行比较，无论您是否充分使用固定计算能力，您都需要为固定容量支付（和容量计划）。

更大的总体目标是降低运营复杂性，并使开发团队专注于以降低的成本实现业务价值。

如果您同意这些是无服务器体系结构的主要目标，则需要当心反模式，以防止您简化扩展能力或仅为使用的功能付费。 让我们看看我在野外看到的三种此类反模式，以及一些有助于解决这些模式的解决方案：

反模式1：滥用预定事件

AWS Lambda提供了调度功能的功能，例如，它们每15分钟运行一次。 但是仅仅因为您可以调度函数并不意味着它是一个好主意。 确实确实需要每天或每小时执行某些任务（例如，数据库备份），在这种情况下，使用计划事件是合理的。 但是我已经看到计划的事件用于检查是否有任何工作要做。

想象一下一个预定每十分钟运行一次的订单处理功能，以检查是否有任何订单以及是否要处理它们。 在这种情况下，无论是否要处理任何订单，您都要为函数调用付费，因此您将无法实现“按使用付费”的目标。 此外，您始终仅触发一个功能，因此，如果您需要比平时更多的资源来处理更多订单，则不会有这些功能。 结果，您错过了轻松扩展的希望。 更不用说在处理新订单时要引入十分钟的延迟。

解

更好的实现方法是确保每个到达的订单都会触发将对其进行处理的功能。 您可以通过与其他云服务（例如S3）或Kafka Connector的内置集成，通过API网关来执行此操作。 这样，如果没有订单，您就不用付款。 如果订单比平时多，则触发更多功能并拥有更多资源来处理所有这些功能。 最重要的是，您现在正在实时处理订单到达时，而不是任意批处理。

这基本上是流处理的定义-处理事件（在事件到达时），而不是按任意时间轴进行。 这也是事件驱动的。 您正在使用事件来驱动功能，而事件是发送通知和共享数据的主要机制。 通过设计一种可以充分利用无服务器框架的架构，您还可以迈出事件驱动流处理架构的第一步。

反模式2：对数据库的依赖性

无服务器功能几乎总是无状态的（ Azure持久功能是一个非常有趣的例外）。 您无法在两次调用之间可靠地在应用程序本身中维护任何状态。 这意味着任何非平凡的功能都将依赖于外部数据库来维护状态。

在大多数情况下，数据库没有“按使用付费”模型，这意味着无论是否使用状态，您都要为存储状态付费。 那么可伸缩性和运营开销又如何呢？ 运营专业人员通常都同意，有状态服务和数据存储将投入90％的精力，而无状态应用程序的操作，容量计划和可伸缩性则要困难得多。 如果您要自己运行数据库，那么整个无服务器体系结构将无法实现操作的简便性。 因此，您必须找到一个托管服务。 不仅如此，您还需要找到一个具有足够弹性的托管服务，以利用无服务器功能进行扩展，并且不需要容量规划。 这并非易事-即使那里最具可扩展性的托管数据存储也具有复杂的定价模型，需要您提前计划容量。 但是首先选择无服务器架构的原因之一是避免进行容量规划。

解

不必担心数据库的可伸缩性， 一些专家建议将功能连接到服务而不是数据存储 。 假设存在一个托管服务可以处理您需要的数据，并且具有适用于您的API和弹性伸缩功能，那么这是一个不错的选择。 例如，如果您的函数可以将数据读写到Salesforce.com而不是数据库中，则这是一个好主意。 使用Apache Kafka的pub / sub功能（与FaaS一样可扩展）也是一个很好的解决方案，前提是其他人正在为您运行它。

但是请记住，如果您的应用程序足够独特，那么您需要编写自己的数据层服务以基本上充当数据库的连接池和数据层，无服务器可能是错误的体系结构。 添加此服务后，您现在会创建相同的操作复杂性和固定成本，而原本以为通过无服务器可以避免这种情况。

反模式3：本地无服务器

这里有许多本地无服务器框架：OpenFaaS，Kubeless，OpenWhisk，Knative，甚至可能更多。 如果您使用一个应用程序，这是合理的，因为您需要在自己的数据中心中运行与在云中相同的应用程序。 但是您需要意识到，本地无服务器没有无服务器所带来的好处（操作简便，成本）。

无论使用哪种框架，如果您在自己的数据中心中运行无服务器，那么无论是否使用基础架构，都需要为基础架构付费。 您自己的运营团队正在运行基础结构，对其进行监视，对其进行维护，对其进行扩展并计划其容量。 没有节省成本，并且在操作上它可能比其他替代方案更复杂，因为您是在无服务器框架之上运行应用程序，在容器编排框架之上运行应用程序是在操作系统之上是容器编排框架。 您可以通过剥离一两层来简化很多工作。

解

我建议仅在针对本地和公共云使用相同的无服务器架构的好处胜过运行对于本地部署而言不必要的额外框架的痛苦时，才运行本地无服务器。

构建无服务器体系结构有很多好处。 如果做得正确，他们会让您的团队专注于业务价值而不是运营，并且在正确的用例中，它可以节省大量成本。 无服务器似乎对于简单，无状态的应用程序特别成功-简单的ETL转换，提供静态Web内容，处理简单的业务事件。 当需求变得更加复杂时，重要的是要牢记全局，并查看整个体系结构是否仍可实现预期的收益。 仅仅因为您实现了FaaS接口，并不意味着您建立了无服务器架构。

翻译自: https://www.infoworld.com/article/3304385/are-you-really-building-a-serverless-system.html

构建服务器