共计 4843 个字符，预计需要花费 13 分钟才能阅读完成。
作者 | Wisen Tanasa
编译 | 刘雅梦
策动 | 辛晓亮
本文介绍了 Serverless（无服务器）架构的六个特质（Traits）：入门门槛低（Low barrier-to-entry）、无主机（Hostless）、无状态（Stateless）、弹性（Elasticity）、分布式（Distributed）和事件驱动（Event-driven）。其目标是提倡大家尽可能宽泛地采纳 Serverless 架构。
Serverless 架构带来了一个乏味的范式转变，这使得软件开发的许多方面都变得更好了。但它也带来了技术人员必须要适应的新挑战。对于如何应答每种特质所带来的挑战，我也给出一些简短的倡议，心愿这些挑战不会阻止大家采纳 Serverless 架构。
每当新技术呈现时，技术专家的首要任务就是要了解采纳新技术的意义。Serverless（无服务器）架构就是一个很好的例子。
可怜的是，目前对于 Serverless 架构的文献大多都只关注于它的长处。许多文章（以及应用示例）都是由云供应商推出的，因而，会毫不意外地议论其踊跃方面。本文的用意是让大家更好地了解 Serverless 架构的特质。
本文的目标不是帮忙你深刻了解所有的主题，而是为你提供一个大抵的概述。以下是本文中定义的 Serverless 架构的 Traits 特质：
- 入门门槛低（Low barrier-to-entry）
- 无主机（Hostless）
- 无状态（Stateless）
- 弹性（Elasticity）
- 分布式（Distributed）
- 事件驱动（Event-driven）
01 入门门槛低
让你的代码开始在 Serverless 架构中运行相对来说是简略的。你能够参照任何教程来开始，并让代码在生产级生态系统中运行。在许多方面，Serverless 架构的学习曲线并没有典型的 DevOps 技能 那么令人生畏——当你应用 Serverless 架构时，DevOps 的许多元素就都是不必要的了。
例如，你不用学习服务器治理技能，如配置管理或补丁。这就是为什么入门门槛低是 Serverless 架构的 Traits 特质之一。
这意味着，最后开发人员的学习曲线比许多其余架构格调的曲线都要低。但这并不意味着学习曲线会始终放弃在较低的程度，事实上，随着开发人员持续他们的旅程，整体学习曲线将会变得更平缓。
因为这种架构特质，我看到许多新的开发人员很快就退出到了我的项目中，并且他们可能无效地为我的项目做出奉献。开发人员可能疾速上手，这可能是 Serverless 我的项目能 更快上市的起因之一。
正如咱们所指出的那样，事件的确会变得更加简单。例如，基础设施即代码（Infrastructure as a code，Iac）、日志治理、监控，有时还包含网络，这些依然都是必不可少的。你必须要理解如何在 Serverless 的世界中实现它们。如果你来自不同的开发背景，那么你须要理解一些 Serverless 架构的 Traits 特质（本文将介绍这些 Traits 特质）。
02 无主机
Serverless 架构的一个显著特质是，你无需间接解决服务器。在这个时代，你能够在各种各样的主机上安装并运行服务——无论是物理机、虚拟机、容器等。
无主机的一个劣势是，你在服务器保护方面的操作开销将会大大减少。你无需再为降级服务器而忧心，安全补丁将主动为你执行。无主机还意味着在应用程序中你须要监控的度量指标也会不同。这是因为你应用的大多数底层服务不会再公布 CPU、内存、磁盘大小等传统度量指标了。这意味着你不再须要了解架构的低级操作细节。
但不同的监控指标意味着，你必须重新学习如何调整你的架构。AWS DynamoDB 提供了能够供你进行监控和调控的读写能力，这是一个你必须要理解的概念，而且这种学习是不能迁徙到其余 Serverless 平台的。你应用的每项服务都有其局限性。AWS Lambda 具备并发执行的限度，你所领有的 CPU 核数不存在限度。更奇怪的是，更改 Lambda 的内存调配大小将会更改取得的 CPU 核数。如果你为了性能测试和生产环境共享一个 AWS 帐户，那么如果性能测试意外地耗费了你的全副并发执行限度，可能会导致生产的宕机。AWS 很好地记录了每项服务的限度，因而请务必查看它们，以便做出正确的架构决策。
一个常见的误会是，Serverless 应用程序更平安，因为安全补丁会主动利用于你的底层服务器。这个假如很危险。
因为 Serverless 架构具备不同的攻打向量，传统的平安防护已不再实用。应用程序的平安实际依然实用，并且在代码中存储机密依然是一个很大的禁忌。AWS 在其责任共担模式中概述了这一点。例如，如果数据蕴含敏感信息，你依然须要爱护数据。我强烈建议你浏览 10 大 OWASP Serverless 我的项目 以取得更多无关该主题的见解。
尽管你的运维操作开销大大减少了，但值得注意的是，在极少数状况下，你依然须要治理底层服务器更改后的影响。你的应用程序可能依赖于原生库，并且你须要确保在降级根底操作系统时它们仍能够工作。例如，在 AWS Lambda 中，操作系统最近已降级到了 AMI 2018.03。
03 无状态
函数即服务，即 FaaS，是很短暂的，因而你不能在内存中存储任何内容，因为运行代码的计算容器将由平台主动创立和销毁。因而，无状态（Stateless）是 Serverless 架构中的一个 Trait 特质。
无状态是程度扩大应用程序的一个很好的特质。无状态的概念是激励你在应用程序中不要存储状态。通过不在应用程序中存储状态，你将可能启动更多的实例，而无需放心应用程序的状态，从而实现程度扩大。我在这里发现了一个乏味的点，实际上无状态是被迫的，因而谬误的空间大大减少了。是的，这里有一些注意事项：例如，计算容器可能会被重复使用，你能够存储状态，然而如果你采纳这种办法，请务必审慎解决。
就利用程序开发而言，你将无奈应用须要状态的技术，因为状态治理的累赘是强加给调用方的。例如，不能应用 HTTP 会话，因为你没有具备长久化文件存储的传统 Web 服务器。如果你想应用 WebSockets 等须要状态的技术，那么你须要期待，等到相应的后端即服务（BaaS）反对这些技术为止，或者利用你本人的解决方案。
04 弹性
因为你的架构是无主机的，那么你的架构也将具备弹性的特质。你应用的大多数 Serverless 服务都被设计为具备高弹性，你能够从零扩大到容许的最大值，而后再回到零，大部分是主动治理的。弹性是 Serverless 架构的一个 Trait 特质。
对于可扩展性来说，弹性的益处是微小的。这意味着你不用手动治理资源扩大。资源分配的许多挑战都隐没了。在某些状况下，具备弹性可能只意味着你只需为所应用的内容付费，因而，如果你的应用模式较低，则能够升高运行老本。
你可能须要将 Serverless 架构与不反对这种弹性的遗留系统集成。当这种状况产生时，你可能会毁坏上游零碎，因为它们可能无奈像 Serverless 架构那样扩大。如果你的上游零碎是要害零碎，那么思考如何缓解此问题是至关重要的——可能是通过限度 AWS Lambda 的并发性或利用队列与上游零碎对话。
尽管在这种高弹性的状况下，“拒绝服务”攻打（denial of service，DOS）将会变得更加艰难，反而更容易受到“回绝钱包”（denial of wallet）攻打。在这种状况下，攻击者试图通过强制减少资源分配来迫使你超出云帐户的限度，从而毁坏应用程序。为了避免这种攻打，你可能会发现在你的应用程序中应用 DDoS 爱护（如 AWS Shield）是很有帮忙的。在 AWS 中，设置 AWS 估算也很有用，这样当你的云账单暴涨时，你就会收到告诉。如果高弹性不是你所冀望的，那么在应用程序上设置束缚是很有用的，比方通过限度 AWS Lambda 并发性。
05 分布式
因为无状态计算是一种特质，所有的持久性需要都将存储在后端即服务（BaaS）中，通常是 BaaS 的组合中。一旦你更多地应用 FaaS，你还会发现你的部署单元（即函数）比你已习惯了的可能还要小。因而，在默认状况下，Serverless 架构是分布式的，并且有许多组件必须要通过网络来进行集成。你的架构还将包含将服务连贯在一起，比方身份验证、数据库、分布式队列等。
分布式系统有很多益处，比方咱们后面探讨过的弹性。在默认状况下，分布式还能为你的架构带来了单区域的高可用性。在 Serverless 环境中，当云供应商所在区域的某个可用性区域呈现故障时，你的架构将可能利用其余仍在运行的可用性区域——从开发人员的角度来看，所有这些都是不通明的。
在抉择架构时总要权衡利弊。在这个特质中，你就义了一致性来换取可用性。通常在云上，每个 Serverless 服务也都有本人的一致性模型。例如，在 AWS S3 中，通过在 S3 桶中对新对象的 PUT 操作能够取得“写后读”（read-after-write）的一致性。对于对象更新，S3 是最终统一的。对于你来说，决定应用哪种 BaaS 是很常见的，因而要留神它们的一致性模型的行为。
另一个挑战是你须要相熟分布式音讯的传递办法。例如，你须要相熟并理解 准确一次投递（exactly-once delivery）这一难题，因为分布式队列的常见音讯投递形式是至多一次投递（at-least-once-delivery）。因为这种投递形式，AWS Lambda 能够被屡次调用，因而你必须确保你的实现是幂等的（理解 FaaS 的重试行为也很重要，其中 AWS Lambda 可能会在失败时屡次执行）。你须要理解的其余挑战还包含分布式事务的行为。然而，随着微服务的遍及，构建分布式系统的学习资源始终在演进。
06 事件驱动
Serverless 平台提供的许多 BaaS 天然会反对事件。对于第三方服务来说，这是一个很好的策略，它们能够为其用户提供可扩展性，因为你无法控制他们服务的代码。因为你将在 Serverless 架构中应用大量的 BaaS，因而你的架构是具备事件驱动这一 Trait 特质的。
我还意识到，即便你的架构是具备事件驱动这一 Trait 特质的，但这并不意味着你须要齐全采纳事件驱动的架构。然而，我察看到，当将事件驱动架构天然地提供给团队时，团队更偏向于承受它。这个特质和弹性特质相似，不须要时，你依然能够敞开它。
事件驱动能带来很多益处。架构组件之间的耦合水平很低。在 Serverless 架构中，你能够很容易地引入一个新函数来监听 blob 存储中的更改：
留神，当增加函数 B 时，函数 A 并没有扭转。这减少了函数的内聚性。函数具备高内聚是有很多益处的，其中一个益处是当单个操作失败时，你能够轻松地重试该操作。当函数 B 失败重试时，意味着你不须要运行昂扬的函数 A。
特地是在云计算中，云供应商将确保你的 FaaS 与他们的 BaaS 可能轻松集成。FaaS 能够被设计成由 事件告诉 触发。
事件驱动架构的毛病是，开始时你可能会失去零碎作为一个整体的整体视图。这会使得对系统进行故障排除变得更具挑战性。分布式跟踪是你应该钻研的一个畛域，只管它在 Serverless 架构中依然是一个成熟的畛域。AWS X-Ray 是一种能够在 AWS 中开箱即用的服务。X-Ray 的确有其本身的局限性，如果你曾经超过了它，你应该关注这个畛域，因为有第三方的产品正在涌现。这就是为什么记录关联 ID（Correlation IDs）的实际是必不可少的，特地是在事务中应用多个 BaaS 的状况下。所以肯定要确保实现关联 ID。
07 论断
本文介绍了 Serverless 架构的六个 Traits 特质：入门门槛低、无主机、无状态、弹性、分布式和事件驱动。我的目标是提倡大家尽可能宽泛地采纳 Serverless 架构。Serverless 架构带来了一个乏味的范式转变，这使得软件开发的许多方面都变得更好了。但它也带来了技术人员必须要适应的新挑战。对于如何应答每种 Trait 特质所带来的挑战，我也给出一些简短的倡议，心愿这些挑战不会阻止你采纳 Serverless 架构。
点击进入取得更多技术信息~~
