无服务器架构的特点

每当新技术出现时，技术人员的首要任务是了解采用它的含义。无要的架构是一种情况。

不幸的是，目前关于无服务器体系结构的很多文献只关注它的好处。许多文章(以及使用的例子)都是由云服务提供商推动的，所以毫不意外地谈到了积极的方面。这篇文章试图更好地理解无服务器架构的特征。

我故意选择这个词，而不是特征，因为这些是你无法改变的无服务体系结构的元素。特征是可展望的，特征是固有的。特质也是中立的，因此它不是正面也不是负面的。在某些情况下，我描述的特质类型可能具有积极的内涵，但我将在这个中保持一个中立的头，以便你了解你将面临的东西。

特质也是固有的，因此你必须拥抱他们，而不是打击他们，因为这种尝试可能会昂贵。另一方面，特点需要花费努力塑造它们，你仍然可以让他们错了。

我还应该通过Mike Roberts指出这篇文章 - 谁也探讨了这个特征 无服务器服务．尽管我们在这里使用相同的术语，但需要注意的是，本文研究的是您的体系结构的特征，而不是您使用的服务。

本文的目的不是帮助您深入理解所有的主题，而是为您提供一个大致的概述。以下是本文中定义的无服务器架构的特征:

1. 低障碍进入
2. Hostless
3. 无状态的
4. 弹性
5. 分布式
6. 事件驱动的

低障碍进入

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

这意味着最初，开发人员的学习曲线比许多其他架构样式都较低。这并不意味着学习曲线将保持低，实际上，整体学习曲线变得陡峭，因为开发商继续沿着他们的旅程。

由于这种建筑特征，我已经看到许多新开发人员乘坐了很快的项目，并且他们能够有效地促进该项目。Devs以快速启动的能力可能是无服务器项目有一个原因 更快的上市时间．

我们注意到，事情确实变得更加复杂。例如，基础设施如代码，日志管理，监控和有时网络等的东西仍然是必不可少的。你必须了解如何在无服务器世界中实现它们。如果您来自不同的发展背景，则存在许多无法架构特征 - 将在本文中介绍 - 您需要了解。

我注意到的一件事是一些开发人员认为无服务器架构意味着他们不必考虑代码设计。理由是他们只是处理函数，所以代码设计是无关紧要的。事实上，设计原则，如Solid，仍然适用 - 您无法将代码可维护性外包给无服务器平台。即使您只需捆绑并将代码上传到云即可以使其运行，我强烈地阻止这样做，因为连续传递实践仍然在无服务器架构中仍然相关。

Hostless

无服务器架构的一个明显特征是，您不再直接处理服务器。在这个时代，您可以在各种各样的主机上安装和运行服务——无论是物理机、虚拟机、容器等等——用一个词来描述它是很有用的。为了避免使用已经超载的术语“无服务器”，我将使用“主机”一词¹这就是这个特征的名字，无主。

无主机的一个好处是，在服务器维护方面的操作开销将大大减少。您不需要担心升级服务器，安全补丁将自动为您应用。无主机还意味着您将在应用程序中监视不同类型的指标。这是因为您使用的大多数底层服务不会发布传统的指标，如CPU、内存、磁盘大小等。这意味着您不再需要解释体系结构的底层操作细节。

但是不同的监控指标意味着您必须重新学习如何调优架构。AWS DynamoDB为您提供了监视和调优的读写能力，这是一个您必须理解的概念——而且这种学习是不能转移到其他无服务器平台的。你使用的每一种服务都有其局限性。AWS Lambda有并发执行限制，而不是CPU核的数量。更奇怪的是，改变Lambda的内存分配大小将改变您得到的CPU核数。如果您为您的性能测试和生产环境共享一个AWS帐户，那么如果性能测试意外地消耗了您的全部并发执行限制，那么您的生产可能会宕机。AWS很好地记录了每种服务的限制，因此请务必检查它，以便做出正确的架构决策。

由于无服务器体系结构具有不同的攻击向量，传统的安全防护已不适用。您的应用程序安全实践仍然适用，并且在代码中存储秘密仍然是一个大禁忌。AWS在其 共同责任模式例如，如果数据包含敏感信息，则仍然需要保护数据。我强烈建议你们阅读OWASP无服务器前10名以获得更多关于这个话题的见解。

虽然您的操作开销大大减少了，但值得注意的是，在极少数情况下，您仍然需要管理底层服务器更改的影响。您的应用程序可能依赖于本机库，您需要确保在底层操作系统升级时它们仍然可以工作。例如，在AWS Lambda中 操作系统最近已经升级到2018.03 ami。

无状态的

函数即服务(FaaS)是短暂的，因此不能在内存中存储任何东西，因为运行代码的计算容器将由平台自动创建和销毁。因此，无状态是无服务器体系结构中的一个特征。

无状态是水平缩放应用程序的良好特性。无非是无状态的想法是您不鼓励在应用程序中存储状态。通过在您的应用程序中不存储状态，您将能够旋转更多的实例，而不担心应用程序状态，以水平扩展。我发现这里有趣的是你实际上被迫无国籍，因此错误的房间大大减少了。是的，有一些警告：例如，可以重复使用计算容器，您可以存储状态，但如果您采取该方法，请进行小心。

在应用程序开发方面，您将无法利用需要各国的技术，因为国家管理的负担被迫向呼叫者提供。例如，HTTP会话无法使用，因为您没有具有持久文件存储的传统Web服务器。如果您想使用需要像WebSockets这样的状态的技术，则必须 等待，直到它被支持通过相应的后端作为服务，或应用自己的解决方法。

弹性

随着您的架构是无敌的，您的架构也将具有弹性的特性。您使用的最具无服务器的服务被设计为高度弹性，在那里您可以从Zero缩放到允许的最大值，然后返回零，主要是自动管理。弹性是无服务器架构的特征。

对于可伸缩性来说，弹性的好处是巨大的。这意味着您不必手动管理资源伸缩。资源配置的许多挑战消失了。在某些情况下，具有弹性可能只意味着您只会为所使用的内容付费，因此，如果您的使用模式较低，那么您将降低运行成本。

您必须使用不支持这种弹性的传统系统集成无服务体系结构。当发生这种情况时，您可能会打破下游系统，因为它们可能无法扩展以及无服务器架构。如果您的下游系统是关键系统，则重要的是考虑您如何减轻此问题 - 或许通过限制您的AWS Lambda并发性或利用队列与您的下游系统交谈。

虽然在这种高弹性的情况下，“拒绝服务”(denial of service)将更加困难，但你更容易受到“拒绝钱包”(denial of wallet)攻击。在这种情况下，攻击者试图通过强迫您超过云帐户限制来破坏应用程序，从而迫使您增加资源分配。为了防止这种攻击，您可能会发现在您的应用程序中利用DDoS保护(如AWS Shield)很有帮助。在AWS中，设置AWS预算也很有用，这样当你的云账单暴涨时，你就会得到通知。如果高弹性不是您在这里所期望的，那么在应用程序上设置约束是很有用的—例如通过限制AWS Lambda并发性。

分布式

由于无状态计算是一种特征，您所拥有的所有持久性要求将存储在后端作为服务（BAAS），通常是它们的组合。一旦您拥抱FAAS更多，您也会发现您的部署单元，功能小于您的部署单元。因此，无服务器架构默认分发 - 并且您必须通过网络集成许多组件。您的架构还将包括接线服务，如身份验证，数据库，分布式队列等。

分布式系统有很多好处，包括我们前面讨论过的弹性。在默认情况下，分布式还为您的体系结构带来了单一区域的高可用性。在无服务器环境中，当一个可用性区域在您的云供应商的区域中出现故障时，您的架构将能够利用其他仍在运行的可用性区域——从开发人员的角度来看，所有这些都是不透明的。

在选择架构时总要权衡利弊。在这个特质中，你牺牲了一致性。通常在云中，每个无服务器的服务也有自己的一致性模型。例如，在AWS S3中，S3桶中新对象的put将获得“写后读”的一致性。对于对象更新，S3最终是一致的。对于您来说，决定使用哪个BaaS是很常见的，因此要注意它们的一致性模型的行为。

其他挑战是让您熟悉的是分布式消息传递方法。你需要熟悉并理解难题 只有一次交付例如，因为分布式队列的通用消息传递方法是至少一次传递。由于这种交付方法，AWS Lambda可以被调用不止一次，因此您必须确保您的实现是幂等的(理解您的FaaS重试行为也很重要，其中AWS Lambda可能在失败时执行不止一次)。您需要理解的其他挑战包括分布式事务的行为。然而，随着微服务的流行，构建分布式系统的学习资源一直在改进。

事件驱动的

您的无服务器平台提供的许多BaaS自然会支持事件。对于第三方服务来说，这是一个很好的策略，可以为其用户提供可扩展性，因为您对其服务的代码没有任何控制。由于您将在无服务器架构中使用大量BaaS，因此您的架构是由特性事件驱动的。

我也认识到，即使您的架构是由特性事件驱动的，但这并不意味着您需要完全采用事件驱动的架构。然而，我观察到，当事件驱动架构自然地提供给团队时，团队倾向于接受它。这是一个类似的想法，弹性作为一个特征，你仍然可以关闭它。

作为事件驱动带来了许多好处。您将在架构组件之间具有较低的耦合耦合。在无服务体系结构中，您可以轻松介绍一个侦听Blob Store的更改的新功能：

图1：添加新的无服务器函数

注意，当您添加函数B时，函数A并没有改变(参见图1)。这增加了函数的内聚性。具有高度内聚功能有很多好处，其中之一是当单个操作失败时，您可以轻松地重试该操作。当函数B失败时重新尝试它意味着您不需要运行代价高昂的函数A。

特别是在云计算中，云供应商将确保您的FaaS与他们的BaaS能够轻松集成。火焰原子吸收可以由 事件通知通过设计。

事件驱动架构的缺点是，您可能会开始失去系统作为一个整体的整体观点。这使得对系统进行故障排除具有挑战性。分布式跟踪是您应该研究的一个领域，尽管它在无服务器体系结构中仍然是一个成熟的领域。AWS x射线是一种可以在AWS中开箱即用的服务。x射线确实随它而来 自己的局限性S，如果你已经超过了它，你应该看这个空间，因为有新兴的第三方产品。这就是记录相关ID的做法是必不可少的，特别是在您在事务中使用多个BAAS的情况。因此，确保您实现相关ID。

结论

有六种无服务体系结构的特征，我在本文中介绍：低障碍，无敌，无状态，弹性，分布式和事件驱动。我的意图是尽可能宽阔，以便您可以使用无服务器架构。无刀架架构带来了一个有趣的范式转变，这使得很多软件开发方面更好。但它还介绍了技术人员必须舒适的新挑战。还有一些关于如何解决每个特征的挑战的问题，所以希望这些挑战不会阻止您采用无服务器架构。

感谢James Andrew Gregory和Troy Towson对本文的全面审查。感谢Gareth Morgan对这篇文章的校对和编辑。

脚注

1：术语主机用于本书构建微猎狼