每当新技术出现时，技术专家的首要任务就是理解采用它的含义。无服务器架构就是一个很好的例子。
不幸的是，目前很多关于无服务器体系结构的文献只关注它的优点。许多文章(以及使用的例子)都是由云提供商驱动的，因此，毫不意外地提到了积极的一面。本文试图更好地理解无服务器体系结构的特性。
我特意选择了trait这个词，而不是characteristic，因为这些是无服务器体系结构中无法更改的元素。性格是可塑的，性格是与生俱来的。性格也是中性的，因此它既不是积极的也不是消极的。在某些情况下，我将描述的性格类型可能有积极的含义，但我将保持中立的态度，这样你就会明白你将要面对的是什么。
性格也是与生俱来的，因此你必须接受它们，而不是与之抗争，因为这样的尝试很可能代价高昂。另一方面，性格特征需要花费精力去塑造，但你仍然可能犯错误。
我还应该指出Mike Robert撰写的这篇文章——他还探讨了无服务器服务的特性（https://blog.symphonia.io/defining-serverless-part-1-704d72bc8a32）。尽管我们在这里共享相同的术语，但值得注意的是，本文讨论的是体系结构的特性，而不是您使用的服务。
本文的目的不是帮助您深入理解所有的主题，而是为您提供一个大致的概述。这些是本文定义的无服务器架构的特征:
- 低的壁垒
- Hostless
- 无状态的
- 弹性
- 分布式
- 事件驱动的
低的壁垒
开始在无服务器体系结构中运行代码相对简单。您可以按照任何教程开始并让您的代码在生产级生态系统中运行。在许多方面，与典型的DevOps技能相比，学习无服务器体系结构的过程并没有那么困难——当您采用无服务器体系结构时，许多DevOps的元素并不是必需的。例如，您不必学习服务器管理技能，比如配置管理或补丁。这就是为什么低进入壁垒是无服务器体系结构的特征之一。
这意味着最初，开发人员的学习曲线比许多其他体系结构样式要低。这并不意味着学习曲线会保持在较低的水平，实际上，随着开发人员继续他们的旅程，整个学习曲线会变得更陡。
由于这种架构特性，我已经看到许多新开发人员非常快地加入到项目中，并且他们能够有效地为项目做出贡献。开发人员能够快速地达到最新的速度，这可能是无服务器项目具有更快的上市时间的原因之一。
正如我们所注意到的，事情确实变得更加复杂。例如，将基础设施作为代码、日志管理、监视，有时还包括网络，这些仍然是必需的。您必须了解如何在没有服务器的世界中实现它们。如果您来自不同的开发背景，那么您需要了解许多无服务器体系结构特性(本文将介绍这些特性)。
尽管最初进入门槛很低，但开发人员不应该假设他们可以忽略重要的体系结构原则。
我注意到的一件事是，一些开发人员倾向于认为无服务器架构意味着他们不必考虑代码设计。理由是它们只是处理函数，所以代码设计无关紧要。事实上，像SOLID这样的设计原则仍然适用——您不能将代码可维护性外包给您的无服务器平台。尽管您可以打包并将代码上传到云中以使其运行，但我强烈反对这样做，因为在无服务器体系结构中，持续交付实践仍然是相关的。
Hostless
无服务器体系结构的一个明显特征是您不再直接处理服务器。在这个时代，有各种各样的主机可以安装和运行服务——无论是物理机器、虚拟机、容器等等——用一个词来描述这一点很有用。为了避免使用已经重载的术语serverless，我将在这里使用host1，因此特性的名称为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这样的状态的技术，您必须等待，直到它被相应的后端作为服务支持，或者应用您自己的解决方案。
弹性
由于您的体系结构是无主机的，所以您的体系结构也具有弹性的特性。您使用的大多数无服务器服务都设计为高度弹性的，您可以从0扩展到允许的最大值，然后再回到0，大部分服务都是自动管理的。弹性是无服务器体系结构的一个特性。
弹性的好处对于可伸缩性是巨大的。这意味着您不必手动管理资源伸缩。资源配置的许多挑战消失了。在某些情况下，弹性可能只意味着您将只为您所使用的东西付费，因此如果您的使用模式较低，您将降低运行成本。
您可能不得不将您的无服务器体系结构与不支持这种灵活性的遗留系统集成在一起。当这种情况发生时，您可能会破坏下游系统，因为它们可能无法像您的无服务器体系结构那样伸缩。如果您的下游系统是关键系统，那么考虑如何缓解这个问题是很重要的——可能通过限制AWS Lambda并发性或使用队列与下游系统通信。
尽管如此高的弹性会让“拒绝服务”变得更加困难，但相反，你很容易受到“拒绝钱包”攻击。这就是攻击者试图破坏应用程序的地方，他们强迫您通过增加资源分配来超过云帐户限制。为了防止这种攻击，您可能会发现在应用程序中使用DDoS保护(如AWS Shield)很有帮助。在AWS中，设置AWS预算也很有用，这样当您的云账单飙升时，您就会得到通知。如果高弹性不是您在这里所期望的，那么在您的应用程序上设置约束也是很有用的—例如通过限制AWS Lambda的并发性。
分布式
由于无状态计算是一种特性，所以您拥有的所有持久性需求都将作为服务(BaaS)存储在后端，通常是它们的组合。一旦您更多地使用FaaS，您还会发现您的部署单元(即功能)比您所习惯的要小。因此，默认情况下，无服务器体系结构是分布式的——而且有许多组件必须通过网络集成。您的体系结构还包括将服务连接在一起，比如身份验证、数据库、分布式队列等等。
正如我们前面讨论过的，分布式系统有很多好处，包括灵活性。分布式还为您的体系结构带来了一个区域，即默认情况下的高可用性。在没有服务器的上下文中，当您的云供应商所在的区域中的一个可用性区域出现故障时，您的体系结构将能够利用仍在运行的其他可用性区域——从开发人员的角度来看，所有这些可用性区域都是不透明的。
在选择体系结构时总是要进行权衡。在这个特性中，您正在用可用性来交换一致性。通常在云计算中，每个没有服务器的服务也有自己的一致性模型。例如，在AWS S3中，对于S3桶中放入的新对象，您将获得写后读一致性。对于对象更新，S3最终是一致的。对于您来说，必须决定使用哪个BaaS是非常常见的，所以要注意它们一致性模型的行为。
另一个挑战是要熟悉分布式消息传递方法。您需要熟悉并准确理解一次性交付的难题，例如，因为分布式队列的常见消息交付方法是至少一次交付。由于这种交付方法，AWS Lambda可以被调用不止一次，因此您必须确保您的实现是幂等的(理解FaaS重试行为也很重要，其中AWS Lambda可能在失败时被执行不止一次)。您需要了解的其他挑战包括分布式事务的行为。然而，随着微服务的普及，构建分布式系统的学习资源一直在改善。
事件驱动
您的无服务器平台提供的许多BaaS自然会支持事件。对于第三方服务来说，这是一个向用户提供可扩展性的好策略，因为您无法控制它们的服务的代码。由于您将在您的无服务器体系结构中使用大量BaaS，所以您的体系结构是由trait驱动的。
我也认识到，即使您的体系结构是由trait驱动的，但这并不意味着您需要完全接受一个事件驱动的体系结构。然而，我注意到团队倾向于采用事件驱动的体系结构，当它自然地提供给他们时。这是一个类似的想法，将弹性作为特性，您仍然可以关闭它。
事件驱动带来了很多好处。您的体系结构组件之间的耦合程度很低。在无服务器架构中，很容易引入一个新函数来侦听blob存储中的更改:
图1:添加新的无服务器函数
注意，当您添加函数B时，函数A是如何不变的(参见图1)。具有高度内聚功能有很多好处，其中之一是，当一个操作失败时，可以很容易地重试它。当函数B失败时，重新尝试它意味着您不需要运行昂贵的函数A。
特别是在云环境中，云供应商将确保您的FaaS很容易与他们的BaaS集成。FaaS可以通过设计通过事件通知触发。
事件驱动体系结构的缺点是，您可能开始失去系统作为一个整体的整体视图。这使得对系统进行故障排除非常困难。分布式跟踪是您应该研究的一个领域，即使它在无服务器体系结构中仍然是一个成熟的领域。AWS X-Ray是一项可以在AWS中开箱即用的服务。x射线也有它自己的局限性，如果你已经超越了它，你应该关注这个领域，因为有第三方产品正在出现。这就是为什么日志关联id的实践是必不可少的，特别是当您在事务中使用多个BaaS时。所以一定要实现相关id。
结论
我在本文中介绍了六个无服务器体系结构特性:低进入壁垒、无主机、无状态、弹性、分布式和事件驱动。我的意图是尽可能广泛，以便您能够很好地采用无服务器体系结构。无服务器架构带来了一个有趣的范例转换，它使许多软件开发方面变得更好。但它也带来了技术人员必须适应的新挑战。还有一些关于如何处理每个特性带来的挑战的简短建议，希望这些挑战不会阻止您采用无服务器体系结构。
原文：https://www.thoughtworks.com/insights/blog/traits-serverless-architecture
本文：
讨论：请加入知识星球或者小红圈【首席架构师圈】