转载

中立观点：无服务器架构的特点 | ThoughtWorks

每当新技术出现时，技术专家的首要任务就是了解采用新技术的含义。无服务器架构就是一个很好的例子。

不幸的是，目前关于无服务器架构的许多文献都只关注它的好处。许多文章 - 以及使用的示例 - 都是由云提供商推动的 - 所以，毫不奇怪地谈论积极因素。这篇文章试图更好地理解无服务器架构的特性。

我故意选择特质trait这个词，而不是特征characteristic，因为这些是无法改变的无服务器架构的元素。特征characteristic是可塑的，特质trait是固有的。特质trait也是中性的，因此它不是正面的也不是消极的。在某些情况下，我将描述的特质trait类型可能具有积极的内涵，但我将保持中立的头脑，以便您了解您将面临的问题。

特质trait也是固有的，因此你必须拥抱它们，而不是与它们作斗争，因为这些尝试可能证明是非常昂贵的。另一方面，特征characteristic需要花费精力来塑造它们，你仍然可以弄错它们。

我还应该指出Mike Robert的这篇文章，他还探讨了无服务器服务的特性。即使我们在这里共享相同的术语，但请注意本文正在研究您的体系结构的特征，而不是您使用的服务。

本文的目的不是帮助您深入理解所有主题，而是为了全面了解您的目标。这些是本文中定义的无服务器体系结构的特征：

进入门槛低
Hostless
无状态
弹性
分散式
事件驱动

进入门槛低

开始在无服务器架构中运行代码是相对简单的。您可以按照任何教程开始，让您的代码在生产级生态系统中运行。在许多方面，无服务器架构的学习曲线不如典型的 DevOps技能那么令人生畏 - 当您采用无服务器架构时，DevOps的许多元素都不是必需的。例如，您不必学习服务器管理技能，例如配置管理或修补。这就是为什么低障碍进入是无服务器架构的特征之一。

这意味着，最初，开发人员的学习曲线比许多其他架构风格要低。这并不意味着学习曲线将保持低水平，实际上，随着开发人员继续他们的旅程，整体学习曲线变得更加陡峭。

由于这种架构特征，我看到许多新开发人员很快就加入了项目，他们已经能够有效地为项目做出贡献。开发人员快速达到速度的能力可能是无服务器项目更快上市时间的一个原因。

正如我们所指出的那样，事情确实变得更加复杂。例如，基础设施作为代码，日志管理，监控以及有时网络等仍然是必不可少的。而且您必须了解如何在无服务器的世界中实现它们。如果您来自不同的开发背景，那么您需要了解许多无服务器架构特征（本文将介绍这些特性）。

尽管最初进入门槛较低，开发者不应该认为他们可以忽略重要的架构原则。

我注意到的一件事是，一些开发人员倾向于认为无服务器架构意味着他们不必考虑代码设计。理由是他们只是进行功能处理，因此代码设计无关紧要。实际上，设计原则（如SOLID）仍然适用 - 您无法将代码可维护性外包给无服务器平台。即使您可以将代码捆绑并上传到云端以使其运行，但我强烈反对这样做，因为持续交付实践仍然与无服务器架构相关。

Hostless

无服务器架构的一个明显特征是您不再直接处理服务器。在这个时代，您可以在其中安装和运行服务的各种主机 - 无论是物理机器，虚拟机，容器等等 - 只需一个单词来描述它就很有用。为了避免使用已经名不副实的术语：Serverless，我将在这里使用hostless。

无主机hostless的一个优点是，您在服务器维护上的运营开销将大大减少。您无需担心升级服务器，并会自动为您应用安全补丁。无主机也意味着您将在应用程序中监控不同类型的指标。发生这种情况是因为您使用的大多数底层服务都不会发布传统指标，如CPU，内存，磁盘大小等。这意味着您不再需要解释架构的低级操作细节。

但是，不同的监控指标意味着您必须重新学习如何调整架构。AWS DynamoDB为您提供了监视和调优的读写容量，这是您必须了解的概念 - 并且学习不可转移到其他无服务器平台。您使用的每项服务也都有其局限性。AWS Lambda具有并发执行限制，而不是您拥有的CPU核心数。为了使它有点奇怪，更改Lambda的内存分配大小将改变您获得的CPU核心数。如果您为性能测试和生产环境共享一个AWS账户，那么如果性能测试意外地消耗了整个并发执行限制，则可能会降低生产。AWS很好地记录了每种服务的限制：

当安全补丁自动应用于底层服务器时，无服务器应用程序更加安全，这是一种常见的误解。这是一个危险的假设。

传统的安全保护不适用，因为无服务器架构具有不同的攻击向量。您的应用程序安全实践仍然适用，并且在代码中存储机密仍然是一个很大的禁忌。AWS在其共享责任模型中概述了这一点，例如，如果数据包含敏感信息，您仍需要保护数据。我强烈建议您阅读 OWASP Serverless Top 10，以获得有关此主题的更多见解。虽然您的运营开销显着降低，但值得注意的是，在极少数情况下，您仍需要管理底层服务器更改的影响。您的应用程序可能依赖于本机库，并且您需要确保它们在升级基础操作系统时仍然可用。例如，在AWS Lambda中，操作系统最近已升级到AMI 2018.03。

无状态

作为服务或FaaS的功能是短暂的，因此您无法在内存中存储任何内容，因为运行代码的计算容器将由您的平台自动创建和销毁。因此，无状态是无服务器架构中的特征。

无状态是横向扩展应用程序的一个很好的特性。无状态的想法是不鼓励你在应用程序中存储状态。通过不在应用程序中存储状态，就能够在不担心应用程序状态的情况下启动更多实例，以便水平扩展。我觉得这里有趣的是你实际上被迫无状态，因此错误的空间大大减少了。是的，有一些注意事项：例如，计算容器可能会被重复使用，您是可以存储状态，但如果采用这种方法，请务必小心。

在应用程序开发方面，您将无法使用需要状态的技术，因为状态管理的负担被强制给调用者。例如，不能使用HTTP会话，因为您没有具有持久文件存储的传统Web服务器。如果要使用需要WebSockets 等状态的技术，则必须等到相应的Backend即服务支持，或者应用自己的解决方法。

弹性

由于您的架构是无主机的，因此您的架构也具有弹性的特性。您使用的大多数无服务器服务都是高度灵活的，您可以从零到最大允许，然后回到零，大多数是自动管理。弹性是无服务器架构的特征。

弹性的好处对于可扩展性来说是巨大的。这意味着您不必手动管理资源扩展。资源分配的许多挑战消失了。在某些情况下，弹性可能只意味着您只需支付使用的费用，因此如果您的使用率较低，您将降低运营成本。

您可能需要将无服务器架构与不支持此类弹性的旧系统集成。发生这种情况时，您可能会破坏下游系统，因为它们可能无法像无服务器架构一样扩展。如果您的下游系统是关键系统，那么考虑如何缓解此问题非常重要 - 可能通过限制AWS Lambda并发或利用队列与下游系统进行通信。

虽然具有如此高弹性的“拒绝服务”将变得更加困难，但您将容易受到“denial of wallet”的攻击。这是攻击者试图通过强制您的资源分配来强制您超过云帐户限制来破坏应用程序的地方。为了防止此类攻击，您可能会发现在您的应用程序中使用DDoS保护（例如AWS Shield）会很有帮助。在AWS中，设置AWS预算也很有用，这样当云账单暴涨时您就会收到通知。如果高弹性不是您期望的那样，那么再次对您的应用程序设置约束是有用的 - 例如通过限制您的AWS Lambda并发性。

分散式

由于无状态计算是一种特性，因此您拥有的所有持久性要求将作为服务（BaaS）存储在后端中，通常是它们的组合。一旦您更多地接受FaaS，您还会发现您的部署单元（功能）比您习惯的要小。因此，默认情况下会分发无服务器架构 - 您必须通过网络集成许多组件。您的体系结构还包括将服务连接在一起，如身份验证，数据库，分布式队列等。正如我们之前讨论的那样，分布式系统有很多好处，包括弹性。分布式也会为您的架构带来单一区域，高可用性。在无服务器环境中，当您的云供应商所在区域中的一个可用区域出现故障时，您的架构将能够利用仍处于运行状态的其他可用区域 - 从开发人员的角度来看，所有这些区域都是不透明的。您选择的架构总是需要权衡。在这个特性中，您通过可用来交易一致性。通常在云中，每个无服务器服务也有自己的一致性模型。例如，在AWS S3中，您将获得S3存储桶中新对象的PUTS的读写后一致性。对于对象更新，S3最终是一致的。您必须决定使用哪种BaaS，这是很常见的，因此请注意其一致性模型的行为。

另一个挑战是让您熟悉的是分布式消息传递方法。您需要熟悉并理解一次交付的难题例如，因为分布式队列的公共消息传递方法至少是一次传递。由于此交付方法，AWS Lambda可以多次调用，因此您必须确保您的实现是幂等的（了解您的FaaS重试行为也很重要，AWS Lambda可能会在失败时执行多次）。您需要了解的其他挑战包括分布式事务的行为。然而，随着微服务的普及，用于构建分布式系统的学习资源一直在不断改进。

事件驱动

您的无服务器平台提供的许多BaaS自然会支持事件。对于为用户提供可扩展性的第三方服务，这是一个很好的策略，因为您无法控制其服务的代码。由于您将在无服务器架构中使用大量BaaS，因此您的架构是由特征引发的事件驱动。我也确实认识到，即使您的体系结构是由特征引发的事件驱动，但这并不意味着您需要完全接受事件驱动的体系结构。但是，我观察到团队倾向于采用事件驱动的架构，当它自然地提供给他们时。这是一个类似的想法，弹性作为一种特性，你仍然可以把它关闭。事件驱动带来许多好处。您的架构组件之间的耦合程度较低。在无服务器架构中，您可以轻松地引入一个侦听blob存储中的更改的新函数：

中立观点：无服务器架构的特点 | ThoughtWorks

注意添加功能B时如何更改功能A（参见图1）。这增加了功能的凝聚力。具有高度内聚功能有很多好处，其中之一就是您可以在失败时轻松重试单个操作。在失败时重试功能B意味着您不需要运行昂贵的功能A.

特别是在云中，云供应商将确保您的FaaS易于与其BaaS集成。FaaS可以通过设计事件通知触发。事件驱动架构的缺点是您可能开始失去整个系统的整体视图。这使得对系统进行故障排除具有挑战性。分布式跟踪是您应该研究的领域，即使它仍然是无服务器架构中的成熟领域。AWS X-Ray是一种可以在AWS中开箱即用的服务。X-Ray确实有它自己的限制，如果你已经超越它，你应该看看这个空间，因为有第三方产品正在出现。这就是记录关联ID的做法至关重要的原因，尤其是在事务中使用多个BaaS的情况。因此，请确保实施关联ID。

结论

我在本文中介绍了无服务器架构的六个特征：低入门级，无主机，无状态，弹性，分布式和事件驱动。我的目的是尽可能广泛，以便您可以很好地采用无服务器架构。无服务器架构带来了一个有趣的范式转换，这使得许多软件开发方面变得更好。但它也带来了技术专家必须适应的新挑战。还有关于如何应对每个特性带来的挑战的简短建议，所以希望这些挑战不会阻止您采用无服务器架构。

感谢James Andrew Gregory和Troy Towson对本文的全面回顾。感谢Gareth Morgan对本文进行校对和复制编辑。

点击标题见原文。

原文 https://www.jdon.com/52955

正文到此结束