无服务器架构
无服务器体系结构是包含第三方“后端即服务”（BaaS）服务和/或包括在“功能即服务”（FaaS）平台上的托管临时容器中运行的自定义代码的应用程序设计。通过使用这些思想以及诸如单页应用程序之类的相关思想，这样的体系结构消除了对传统的永远在线服务器组件的大量需求。无服务器体系结构可能会受益于显着降低的运营成本，复杂性和工程交货时间，但代价是对供应商的依赖性和相对不成熟的支持服务的依赖会增加。
2018年5月22日
使用这种体系结构，客户端可能相对不智能，系统中的许多逻辑（身份验证，页面导航，搜索，交易）由服务器应用程序实现。
使用无服务器架构，最终可能看起来像这样：
这是一个大大简化的视图，但是即使在这里，我们也看到了许多重大变化：
如果我们选择将AWS Lambda用作FaaS平台，则无需完全重写即可将搜索代码从原始Pet Store服务器移植到新的Pet Store Search功能，因为Lambda支持Java和Javascript（我们的原始实现语言）。
- 我们已经删除了原始应用程序中的身份验证逻辑，并已将其替换为第三方BaaS服务（例如Auth0）。
- 使用BaaS的另一个示例，我们允许客户端直接访问数据库的一个子集（用于产品列表），该数据库的一部分完全由第三方（例如Google Firebase）托管。我们可能具有不同的安全配置文件客户端以这种方式访问数据库，而不是访问数据库的服务器资源。
- 前两点暗示着非常重要的第三点：Pet Store服务器中的某些逻辑现在位于客户端之内，例如，跟踪用户会话，了解应用程序的UX结构，从数据库中读取并将其转换为客户端正在逐步成为 单页应用程序。
- 例如，如果服务器的计算密集型或需要访问大量数据，我们可能希望在服务器中保留一些与UX相关的功能。在我们的宠物店中，“搜索”就是一个例子。代替拥有原始体系结构中始终运行的服务器，我们可以实现FaaS函数，该函数通过API网关（稍后描述）响应HTTP请求。客户端和服务器的“搜索”功能均从同一数据库读取产品数据。
- 最后，我们可以用另一个单独的FaaS功能代替“购买”功能，出于安全原因选择将其保留在服务器端，而不是在客户端中重新实现。它也以API网关开头。使用FaaS时，将不同的逻辑需求分解为单独部署的组件是一种非常普遍的方法。
向后退一步，此示例演示了有关无服务器架构的另一个非常重要的观点。在原始版本中，所有流程，控制和安全性均由中央服务器应用程序管理。在无服务器版本中，没有这些问题的中央仲裁者。取而代之的是，相对于编排，我们更喜欢编排，每个组件都在架构上起着更重要的作用-这种想法在微服务方法中也很常见。
这种方法有很多好处。正如Sam Newman在他的《Building Microservices》一书中指出的那样，以这种方式构建的系统无论是整体还是通过组件的独立更新，通常都“更加灵活且易于更改”。有更好的关注点划分；而且还有一些引人入胜的成本优势，Gojko Adzic在这次精彩的演讲中谈到了这一点。
当然，这样的设计是一个折衷方案：它需要更好的分布式监视（稍后将对此进行详细介绍），并且我们更加依赖底层平台的安全功能。从根本上说，比起最初使用的整体式应用程序，有更多的活动部件可以吸引我们的注意。灵活性和成本的好处是否值得多个后端组件增加复杂性，这在很大程度上取决于上下文。
消息驱动的应用程序
另一个示例是后端数据处理服务。
假设您正在编写一个以用户为中心的应用程序，该应用程序需要快速响应UI请求，其次，它需要捕获正在发生的所有不同类型的用户活动，以进行后续处理。想想一个在线广告系统：当用户点击一个广告时，您想非常快速地将他们重定向到该广告的目标。同时，您需要收集点击发生的事实，以便可以向广告客户收取费用。（此示例不是假设的，我以前在Intent Media的团队 正是有这种需求，他们以无服务器方式实现了这一需求。）
传统上，该体系结构可能如下所示。“广告服务器”同步响应用户（未显示），并向频道发布“点击消息”。然后，该消息由更新数据库的“点击处理器”应用程序异步处理，例如，以减少广告商的预算。
在无服务器世界中，它看起来如下：
你能看到区别么？与我们的第一个示例相比，这里的体系结构更改要小得多，这就是为什么异步消息处理是无服务器技术非常流行的用例的原因。我们已经使用FaaS函数替换了长期存在的消息消费者 应用程序。此功能在供应商提供的事件驱动的上下文中运行。请注意，云平台供应商同时提供了消息代理和FaaS环境，这两个系统紧密相连。
FaaS环境还可以通过实例化功能代码的多个副本来并行处理多个消息。根据我们编写原始过程的方式，这可能是我们需要考虑的新概念。
打开“功能即服务”的包装
我们已经提到了很多FaaS，但是现在该深入了解它的真正含义了。为此，我们来看一下 亚马逊的FaaS产品Lambda的开篇说明。我已经添加了一些令牌，我将对其进行扩展。
AWS Lambda允许您运行代码而无需置备或管理服务器。（1） ...使用Lambda，您几乎可以为任何类型的应用程序或后端服务运行代码（2） -所有这些都可以实现零管理。只需上传您的代码，Lambda就可以以高可用性处理运行（3）和扩展（4）代码所需的一切。您可以设置代码以自动从其他AWS服务触发（5）或直接从任何Web或移动应用程序调用它（6）。
如果我们回到前面的单击处理示例，则FaaS会用不需要预置服务器或运行所有应用程序的应用程序替换单击处理服务器（可能是物理计算机，但肯定是特定的应用程序）。时间。
FaaS功能虽然在架构上有很大的限制，尤其是在状态和执行时间方面。我们将尽快解决。
让我们再次考虑一下点击处理示例。转移到FaaS时唯一需要更改的代码是“主要方法”（启动）代码，因为该代码已被删除，并且有可能是顶级消息处理程序（“消息侦听器接口”实现）的特定代码。 ，但这可能只是方法签名的更改。在FaaS世界中，其余的代码（例如，写入数据库的代码）没有什么不同。
让我们回到点击处理器。假设我们过得愉快，客户点击的广告数量是往常的十倍。对于传统架构，我们的点击处理应用程序是否可以处理？例如，我们是否开发了应用程序以能够一次处理多个消息？如果这样做，应用程序的一个正在运行的实例是否足以处理负载？如果我们能够运行多个进程，那么自动缩放是自动的还是需要手动重新配置？使用FaaS方法时，所有这些问题都已得到解答-您需要提前编写函数以假定水平缩放并行性，但是从那时起，FaaS提供程序将自动处理所有缩放需求。
- 从根本上讲，FaaS是关于在不管理自己的服务器系统或长期使用的服务器应用程序的情况下运行后端代码的。与容器和PaaS（平台即服务）等其他现代体系结构趋势进行比较时，第二个子句（服务器服务器应用程序的寿命很长）是一个关键区别。
- FaaS产品不需要编码到特定的框架或库。FaaS功能在语言和环境方面是常规应用程序。例如，可以使用Javascript，Python，Go，任何JVM语言（Java，Clojure，Scala等）或任何.NET语言，将“ AWS Lambda函数”实现为“一流”。但是，您的Lambda函数还可以执行与其部署工件捆绑在一起的另一个进程，因此您实际上可以使用可以编译为Unix进程的任何语言（请参阅本文稍后的Apex）。
- 部署与传统系统非常不同，因为我们没有自己运行的服务器应用程序。在FaaS环境中，我们将用于功能的代码上载到FaaS提供程序，该提供程序会执行资源调配，实例化VM，管理流程等所需的所有其他操作。
- 水平缩放是完全自动的，灵活的，并且由提供者管理。如果您的系统需要并行处理100个请求，则提供商将无需您进行任何额外配置即可处理该请求。执行您的功能的“计算容器”是短暂的，而FaaS提供程序仅根据运行时需求来创建和销毁它们。最重要的是，使用FaaS ，供应商可以处理所有基础资源的配置和分配-用户完全不需要集群或VM管理。
- FaaS中的功能通常由提供者定义的事件类型触发。使用Amazon AWS，此类刺激包括S3（文件/对象）更新，时间（计划任务）以及添加到消息总线的消息（例如Kinesis）。
- 大多数提供程序还允许触发功能作为对入站HTTP请求的响应。在AWS中，通常可以通过使用API网关来启用此功能。我们在Pet Store示例中使用了API网关来实现“搜索”和“购买”功能。也可以通过平台提供的API直接调用功能，无论是在外部还是在同一云环境中，但这都是相对罕见的用法。
州
FaaS功能在进入本地（机器/实例绑定）状态时有很大的限制，即存储在内存中的变量中的数据或写入本地磁盘的数据。您确实有可用的存储空间，但是不能保证在多次调用中都可以保持这种状态，更重要的是，您不应假设某个函数的一次调用的状态可用于同一函数的另一次调用。因此，通常将FaaS函数描述为无状态的，但是更准确地说，必须将FaaS函数的任何状态持久化都需要在FaaS函数实例之外进行外部化。
对于自然无状态的FaaS功能（即，将输入完全转换为输出的功能），这无关紧要。但是，对于其他人而言，这可能会对应用程序体系结构产生重大影响，尽管这不是唯一的应用程序-“十二要素应用程序”概念具有完全相同的限制。这种面向状态的功能通常将利用数据库，跨应用程序缓存（如Redis）或网络文件/对象存储（如S3）来存储请求中的状态，或提供处理请求所需的其他输入。
执行时间
FaaS功能通常受每个调用允许运行多长时间的限制。目前，AWS Lambda函数响应事件的“超时”最多是五分钟，然后才终止。Microsoft Azure和Google Cloud Functions具有类似的限制。
这意味着某些类别的长期任务在没有重新架构的情况下不适合FaaS功能-您可能需要创建多个不同的协调FaaS功能，而在传统环境中，您可能只有一个长期任务同时执行协调和执行。
启动延迟和“冷启动”
FaaS平台在每个事件之前都要花一些时间来初始化函数实例。即使对于一项特定功能，此启动等待时间也可能有很大差异，具体取决于众多因素，并且可能在几毫秒到几秒钟的范围内变化。这听起来很糟糕，但是让我们更具体一些，以AWS Lambda为例。
Lambda函数的初始化将是“热启动”（重用先前事件中的Lambda函数及其主机容器的实例）或“冷启动”（创建新的容器实例，启动函数主机进程等）毫不奇怪，当考虑启动延迟时，最引起关注的是这些冷启动。
冷启动延迟取决于许多变量：使用的语言，使用的库数量，拥有的代码量，Lambda函数环境本身的配置，是否需要连接到VPC资源等。这些方面都在开发人员的控制之下，因此通常可以减少冷启动过程中引起的启动延迟。
与冷启动持续时间一样可变的是冷启动频率。例如，如果一个函数每秒处理10个事件，每个事件需要50毫秒来处理，那么您大概只会在每100,000–200,000个事件中看到Lambda的冷启动。另一方面，如果您每小时处理一次事件，则可能会看到每个事件的冷启动，因为亚马逊会在几分钟后淘汰不活动的Lambda实例。知道这一点将帮助您了解冷启动是否会对总体产生影响，以及您是否希望对功能实例执行“保持生命”以避免将它们放牧。
开始感冒了吗？这取决于应用程序的样式和流量形状。我以前在Intent Media的团队有一个用Java（通常是启动时间最慢的语言）实现的异步消息处理Lambda应用程序，该应用程序每天处理数亿条消息，他们不关心此组件的启动延迟。就是说，如果您正在编写一个低延迟的交易应用程序，那么无论您使用哪种语言实现，您现在都可能不想使用云托管的FaaS系统。
无论您是否认为应用程序可能会遇到此类问题，都应使用类似于生产的负载来测试性能。如果您的用例现在不起作用，您可能要在几个月后再试一次，因为这是FaaS供应商不断改进的主要领域。
有关冷启动的更多详细信息，请参阅有关该主题的文章。
API网关
我们前面提到的无服务器的一个方面是“ API网关”。API网关是HTTP服务器，其中在配置中定义了路由和端点，并且每个路由都与用于处理该路由的资源相关联。在无服务器架构中，此类处理程序通常是FaaS功能。
当API网关接收到一个请求时，它将找到与该请求匹配的路由配置，并且在FaaS支持的路由的情况下，它将使用原始请求的表示形式调用相关的FaaS函数。通常，API网关将允许从HTTP请求参数映射到FaaS函数的更简洁的输入，或者通常将整个HTTP请求作为JSON对象传递。FaaS函数将执行其逻辑并将结果返回到API网关，API网关随后会将结果转换为HTTP响应，并将其传递回原始调用方。
Amazon Web Services拥有自己的API网关（简称为“ API Gateway ”），其他供应商也提供类似的功能。亚马逊的API网关本身就是一项BaaS（是，BaaS！）服务，因为它是您配置的外部服务，但不需要自己运行或配置。
除了纯粹路由请求之外，API网关还可以执行身份验证，输入验证，响应代码映射等。（如果在考虑这是否真的是一个好主意时，您的蜘蛛侠感觉有些刺痛，请坚持该想法！稍后我们将对此进行进一步考虑。）
具有FaaS功能的API网关的一个用例是，以无服务器方式创建HTTP开头的微服务，并具有FaaS功能带来的所有扩展，管理和其他好处。
当我第一次写这篇文章时，至少用于Amazon API Gateway的工具还很不成熟。从那时起，此类工具已得到显着改进。像AWS API Gateway这样的组件并不是很“主流”，但是希望它们比以前减轻了一些痛苦，并且只会继续改进。
工装
上面有关工具成熟度的评论通常也适用于无服务器FaaS。在2016年，情况相当艰难；到2018年，我们已经看到了显着的进步，并且我们期望工具会变得更好。
值得一提的是FaaS世界中几个著名的“开发者UX”实例。首先是Auth0 Webtask，它在其工具中将开发人员UX置于重要位置。其次是微软，其Azure Functions产品。Microsoft一直将Visual Studio及其紧密的反馈循环放在其开发人员产品的最前沿，Azure Functions也不例外。给定来自云触发的事件的输入，它提供的本地调试功能的能力非常特殊。
仍需要重大改进的领域是监视。我稍后再讨论。
开源的
到目前为止，我主要讨论了专有的供应商产品和工具。大多数无服务器应用程序都使用此类服务，但是这个世界上也有开源项目。
Serverless中开源的最常见用途是FaaS工具和框架，尤其是流行的Serverless Framework，其目的是使AWS API Gateway和Lambda的使用比使用AWS提供的工具更容易。它还提供了一些跨供应商的工具抽象，有些用户认为这很有价值。类似工具的示例包括Claudia和Zappa。另一个示例是Apex，它特别有趣，因为它允许您使用非Amazon直接支持的语言开发Lambda函数。
不过，大型供应商本身并不会在开源工具聚会上落伍。AWS自己的部署工具，SAM-的无服务器应用模式-is也是开源的。
专有FaaS的主要好处之一是不必担心基础计算基础架构（机器，VM，甚至容器）。但是，如果您 想担心这样的事情怎么办？也许您有云供应商无法满足的一些安全需求，或者也许您已经购买了一些机架并且不想丢弃的服务器。开源软件可以在这些情况下帮助您运行自己的“服务器式” FaaS平台吗？
是的，这个领域有很多活动。开源FaaS的最初领导者之一是IBM（使用OpenWhisk，现在是Apache项目），而且令人惊讶的是，至少对我来说是！！ Microsoft开源了很多 Azure Functions平台。许多其他自托管的FaaS实现使用底层容器平台（通常是Kubernetes），这出于很多原因是很有意义的。在这个领域中，值得探索诸如 Galactic Fog，Fission和 OpenFaaS之类的项目。这是一个瞬息万变的大世界，我建议您查看Cloud Native Computing Federation（CNCF）所做的工作无服务器工作组已经对其进行了跟踪。
什么是无服务器？
到目前为止，我已经将无服务器描述为两种思想的结合：后端即服务和功能即服务。我还研究了后者的功能。为了更精确地了解我所认为的无服务器服务的关键属性（以及为什么我认为更老的服务（例如S3）都是无服务器的），请参考我的另一篇文章：定义无服务器。
在我们开始着眼于利弊的非常重要的领域之前，我想花一点时间定义一下。让我们定义什么不是Serverless。
与PaaS的比较
鉴于无服务器FaaS功能与十二要素应用程序非常相似，它们是否只是Heroku的另一种形式的“平台即服务”（PaaS）？对于简短的回答，请参阅Adrian Cockcroft
如果您的PaaS可以在20毫秒内有效地启动实例并运行半秒，则将其称为无服务器。 -阿德里安·科克罗夫特
换句话说，大多数PaaS应用程序都不适合响应事件而上下移动整个应用程序，而FaaS平台正是 这样做的。
如果我是一名优秀的十二因子应用程序开发人员，这并不一定会影响我对应用程序进行编程和架构的方式，但是确实会对我操作它们的方式产生重大影响。由于我们都是精通DevOps的优秀工程师，因此我们在考虑运营的同时也在考虑开发，对吧？
FaaS和PaaS之间的关键操作差异是扩展。通常，使用PaaS时，您仍然需要考虑如何进行扩展—例如，使用Heroku，您要运行多少个Dynos？使用FaaS应用程序，这是完全透明的。即使您将PaaS应用程序设置为自动缩放，也不会按照单个请求的级别进行此操作（除非您具有非常特殊的流量配置文件），所以FaaS应用程序在成本方面的效率要高得多。
有了这个好处，为什么还要使用PaaS？有几个原因，但是工具可能是最大的原因。还有一些人使用诸如Cloud Foundry之类的PaaS平台在混合的公共云和私有云之间提供通用的开发体验；在撰写本文时，还没有像这样成熟的FaaS。
与容器比较
使用无服务器FaaS的原因之一是避免必须在操作系统级别上管理应用程序进程。PaaS服务（如Heroku）也提供了此功能，我在上面已经描述了PaaS与无服务器FaaS有何不同。另一个流行的流程抽象是容器，其中Docker 是这种技术最明显的例子。容器托管系统（例如 Mesos和Kubernetes）越来越流行，它们从OS级别的部署中抽象出各个应用程序。沿着这条路走得更远，我们看到了像Amazon ECS和EKS这样的云托管容器平台，以及 Google Container Engine与无服务器FaaS一样，使团队完全不必管理自己的服务器主机。鉴于容器的发展势头，是否仍然值得考虑无服务器FaaS？
原则上，我为PaaS提出的论点仍然适用于容器-因为无服务器FaaS缩放是自动管理的，透明的和细粒度的，并且这与我前面提到的自动资源供应和分配有关。传统上，容器平台仍然需要您管理集群的大小和形状。
我还要指出，尽管容器技术越来越接近于成熟，但它仍不成熟和稳定。当然，这并不是说无服务器FaaS已经成熟，但是选择您想要的粗糙边缘仍然是当务之急。
还需要提及的是，自扩展容器集群现在在容器平台中可用。Kubernetes内置了“ Horizontal Pod Autoscaling ”功能，AWS Fargate等服务也承诺了“无服务器容器”。
正如我们看到的，无服务器FaaS和托管容器之间的管理和扩展差距缩小了，它们之间的选择可能取决于应用程序的样式和类型。例如，对于每个应用程序组件具有很少事件类型的事件驱动样式，FaaS可能被视为更好的选择，而对于具有多个入口点的同步请求驱动的组件，容器可能被视为更好的选择。我希望在相当短的时间内，许多应用程序和团队将同时使用这两种架构方法，并且看到这种使用模式的出现将非常令人着迷。
#NoOps
Serverless并不表示“没有操作”，尽管它可能表示“ No sysadmin”，具体取决于您的Serverless兔子漏洞有多深。
“操作”比服务器管理意味着更多。这也至少意味着监控，部署，安全性，网络，支持以及通常的一些生产调试和系统扩展。无服务器应用程序仍然存在这些问题，并且您仍然需要一种策略来应对它们。在某些方面，Ops在无服务器世界中会变得更加困难，因为其中很多都是新事物。
系统管理员仍在发生-您只是将其与Serverless外包。这不一定是一件坏事（或好事），我们会大量外包，其优缺点取决于您要尝试执行的操作。无论哪种方式，抽象都可能在某个时候泄漏，并且您需要知道某个地方的系统管理员正在支持您的应用程序。
慈善专业了关于这一主题的精彩演讲在第一Serverlessconf。（您也可以阅读她的两篇文章： WTF是Operations？和Operational Best Practices。）
存储过程即服务
我不知道无服务器服务是否会变成存储过程之类的东西，这个好主意很快就会变成大量的技术债务 -Camille Fournier
我看到的另一个主题是无服务器FaaS是“存储过程即服务”。我认为这是因为FaaS函数的许多示例（包括我在本文中使用的一些示例）都是与数据库紧密集成的小段代码。如果仅此而已，我们可以使用FaaS，因为我认为该名称将很有用，但是由于它实际上只是FaaS功能的一部分，因此我认为用这些术语来思考FaaS不会有用。
话虽如此，值得考虑的是FaaS是否也存在存储过程中的一些相同问题，包括Camille在上述推文中提到的技术债务问题。使用存储过程有很多经验教训，值得在FaaS上下文中进行回顾并了解它们是否适用。考虑一下存储过程：
- 通常需要供应商特定的语言，或者至少需要供应商特定的框架/语言扩展
- 难以测试，因为它们需要在数据库的上下文中执行
- 版本控制或将其视为一流应用程序时比较棘手
尽管并非所有这些都一定适用于存储proc的所有实现，但它们无疑是一个可能遇到的问题。让我们看看它们是否可能适用于FaaS：
（1）绝对不是我到目前为止所见过的FaaS实现的问题，因此我们可以立即清除掉其中的一个。
对于（2），因为我们正在处理“正义代码”，所以单元测试肯定和其他任何代码一样容易。集成测试是一个不同的（也是合法的）问题，我们将在后面讨论。
对于（3），再次，因为FaaS功能是“正义代码”，所以版本控制就可以了。直到最近，应用程序打包也是一个问题，但是我们开始在这里看到成熟，例如 我前面提到的Amazon无服务器应用程序模型（SAM）和无服务器框架之类的工具。在2018年初，亚马逊甚至推出了“无服务器应用程序存储库”（SAR），为组织提供了一种基于AWS无服务器服务分发应用程序和应用程序组件的方法。（在我标题为《检查AWS无服务器应用程序存储库》的文章中，详细了解SAR 。）
好处
到目前为止，我主要尝试坚持只定义和解释无服务器架构的含义。现在，我将讨论这种设计和部署应用程序的方式的优点和缺点。如果没有经过认真考虑并权衡利弊，您绝对不应该决定使用Serverless。
让我们从彩虹和独角兽的土地开始，看看Serverless的好处。
降低运营成本
最简单的说，无服务器是一种外包解决方案。它使您可以雇人管理服务器，数据库，甚至可以自己管理的应用程序逻辑。由于您使用的是其他许多人也会使用的预定义服务，因此我们看到了 规模经济效应：您为托管数据库支付的费用更少，因为一个供应商正在运行数千个非常相似的数据库。
降低的成本在您看来是两个方面的总和。首先是基础设施成本的增加，这完全来自与他人共享基础设施（例如，硬件，网络）。第二个是人工成本的增加：您将可以花费更少的时间在外包的无服务器系统上，而不是自己开发和托管的等效系统上。
但是，此好处与从基础架构即服务（IaaS）或平台即服务（PaaS）所获得的好处并没有太大不同。但是，我们可以通过两种关键方式扩展此优势，一种针对无服务器BaaS和FaaS。
BaaS：降低开发成本
IaaS和PaaS的前提是可以对服务器和操作系统管理进行修改。另一方面，无服务器后端即服务是整个应用程序组件被修改的结果。
认证就是一个很好的例子。许多应用程序都编写了自己的身份验证功能，其中通常包括注册，登录，密码管理以及与其他身份验证提供程序集成的功能。总体而言，此逻辑在大多数应用程序中都非常相似，并且已经创建了诸如Auth0之类的服务，以使我们能够将现成的身份验证功能集成到我们的应用程序中，而无需我们自己开发。
BaaS数据库（例如Firebase的数据库服务）在同一线程上。一些移动应用程序团队发现让客户端直接与服务器端数据库通信是有意义的。BaaS数据库消除了许多数据库管理开销，并且通常以无服务器应用程序期望的模式提供机制，以对不同类型的用户执行适当的授权。
根据您的背景，这些想法可能会让您感到困惑（很可能是由于我们将在“缺点”部分中介绍的原因），但是无可否认，有成功的公司能够使用几乎任何自己的服务器生产引人注目的产品的数量端代码。乔·艾米森（Joe Emison） 在第一次无服务器会议上给出了几个例子。
FaaS：扩展成本
正如我在本文前面提到的，无服务器FaaS的乐趣之一是“水平扩展是完全自动的，弹性的，并由提供程序管理。” 这样做有很多好处，但是在基础设施方面，最大的好处是，您只需要为所需的计算付费，就AWS Lambda而言，降至100ms边界。根据您的流量规模和形状，这对您来说可能是巨大的经济利益。
示例：偶尔的请求
假设您正在运行一个服务器应用程序，该服务器应用程序每分钟仅处理一个请求，处理每个请求需要50毫秒，并且一小时的平均CPU使用率为0.1％。如果将此应用程序部署到其自己的专用主机，则效率极低。一千台其他类似的应用程序都可以共享一台计算机。
无服务器FaaS捕获了这种低效率，从而以降低的成本为您带来了好处。在上面的示例应用程序中，您每分钟只需要支付100毫秒的计算时间，占总时间的0.15％。
这具有以下连锁优势：
- 对于具有很小负载需求的可能的微服务，它提供了按逻辑/域分解组件的支持，即使如此细粒度的操作成本本来是不允许的。
- 这样的成本收益是一个伟大的民主化者。如果公司或团队想要尝试新事物，则在使用FaaS满足其计算需求时，与“将脚趾浸入水中”相关的运营成本非常低。实际上，如果您的总工作量相对较小（但并不完全微不足道），则由于某些FaaS供应商提供的“免费套餐”，您可能根本不需要为任何计算付费。
示例：流量不一致
让我们看另一个例子。假设您的流量配置文件非常刺眼-也许您的基准流量是每秒20个请求，但是每五分钟您会在10秒钟内每秒接收200个请求（是通常数量的10倍）。出于示例的考虑，我们还假设基准性能最大化了首选的主机服务器类型，并且您不想减少流量高峰阶段的响应时间。您如何解决呢？
在传统环境中，即使峰值的总持续时间少于总计算机正常运行时间的4％，您可能仍需要将硬件总数增加10倍，而不是处理峰值。由于需要花费多长时间才能启动新服务器实例，因此自动缩放可能不是一个好选择。到您的新实例启动时，高峰阶段将结束。
但是，使用无服务器FaaS，这将不再是问题。从字面上看，您所做的工作与流量配置文件统一时没有什么不同，并且您只需要在峰值阶段支付额外的计算能力。
显然，我在这里特意选择了一些示例，这些示例的无服务器FaaS可以节省大量成本，但是从扩展的角度来看，要表明这一点，除非您拥有非常稳定的流量形状，并且该流量形状始终使用服务器主机的全部容量，然后您可以使用FaaS节省资金。
关于上述内容的一个警告：如果您的流量是一致的，并且始终可以很好地利用运行中的服务器，您可能看不到这种成本优势，而实际上，使用FaaS可能会花费更多。您应该做一些数学运算，并将当前提供商的成本与运行全职服务器的等效成本进行比较，以查看成本是否可以接受。
有关FaaS的成本收益的更多详细信息，我建议Gojko Adzic和Robert Chatley发表论文“无服务器计算：经济和架构影响”。
优化是节省成本的根源
关于FaaS成本，还有一个值得一提的有趣方面：您对代码进行的任何性能优化都不仅会提高应用程序的速度，而且还可以直接和直接地链接到降低运营成本（取决于粒度）供应商的收费方案。例如，假设某个应用程序最初需要一秒钟来处理事件。如果通过代码优化将其减少到200毫秒，它将（在AWS Lambda上）立即节省80％的计算成本，而无需进行任何基础架构更改。
简化运营管理
下一部分带有一个巨大的星号-对于Serverless，操作的某些方面仍然很困难，但现在我们仍然与独角兽和Rainbow朋友保持联系...
在无服务器BaaS方面，运营管理比其他体系结构更简单的原因很明显：支持更少的组件等于更少的工作。
在FaaS方面，有很多方面正在发挥作用，我将深入探讨其中的几个方面。
FaaS带来的收益超出基础架构成本
尽管在上一节中我们对扩展感到新鲜，但值得注意的是，FaaS的扩展功能不仅降低了计算成本，而且还因为扩展是自动的，因此还减少了运营管理。
最好的情况是，如果您的扩展过程是手动的，例如，一个人需要明确地将实例添加到服务器阵列中并从中删除实例，那么使用FaaS，您可以欣然忘记，并让您的FaaS供应商为您扩展应用程序。
即使您已经在非FaaS架构中使用自动缩放功能，仍然需要进行设置和维护。FaaS不再需要这项工作。
同样，由于提供者对每个请求/事件都进行了扩展，因此 您不再需要考虑在内存不足或看到过多的性能问题之前可以处理多少个并发请求的问题-至少不在内部您的FaaS托管组件。鉴于下游数据库和非FaaS组件的负载可能会大大增加，因此必须重新考虑它们。
减少打包和部署复杂性
与部署整个服务器相比，打包和部署FaaS功能非常简单。您要做的就是将所有代码打包到一个zip文件中，然后上传。没有人偶/主厨，没有启动/停止shell脚本，没有决定是否在一台机器上部署一个或多个容器。如果您只是入门，甚至不需要打包任何内容-您可以在供应商控制台本身中编写代码（显然，不建议将其用于生产代码！）。
这个过程不需要花很长时间来描述，但是对于某些团队来说，这种好处可能是绝对巨大的：完全无服务器的解决方案需要零系统管理。
PaaS解决方案具有类似的部署优势，但是正如我们之前所见，将PaaS与FaaS进行比较时，扩展优势是FaaS独有的。
上市时间和持续实验
简化的运营管理是我们工程师所理解的好处，但这对我们的业务意味着什么？
显而易见的原因是成本：正如我已经描述的那样，花在手术上的时间减少等于手术所需的人员减少。但是我认为更重要的原因是 上市时间。随着我们的团队和产品越来越趋向于精益和敏捷流程，我们希望不断尝试新事物并快速更新现有系统。尽管在连续交付的情况下进行简单的重新部署可以使稳定的项目快速迭代，但是具有良好的 从新想法到初始部署的功能使我们能够以低摩擦和最小的成本尝试新的实验。
FaaS的从新想法到初始部署的故事通常非常出色，特别是对于由供应商生态系统中成熟定义的事件触发的简单功能而言。例如，假设您的组织已经在使用AWS Kinesis（类似于Kafka的消息传递系统），用于通过您的基础架构广播各种类型的实时事件。借助AWS Lambda，您可以在几分钟内针对该Kinesis流开发和部署新的生产事件侦听器-您可以在一天内尝试多个不同的实验！
尽管成本优势是使用Serverless最容易表达的改进， 但是交货时间的减少使我最兴奋。它可以实现持续试验的产品开发思路，这是我们在公司中交付软件的方式的真正革命。
“绿色”计算？
在过去的几十年中，全球数据中心的数量和规模都在急剧增加。除了建立这些中心所需的物理资源之外，相关的能源需求也是如此之大，以至于苹果，谷歌等都谈论将其一些数据中心托管在可再生能源附近，以减少化石燃料燃烧的影响。否则将需要这些站点。
闲置但通电的服务器消耗了不菲的能量-它们是我们需要那么多更大的数据中心的重要原因：
在一年中，企业和企业数据中心的典型服务器平均提供其最大计算输出的5％至15％。
-福布斯
这是极其低效的，并且会给环境带来巨大影响。
一方面，云基础设施可能已经帮助减少了这种影响，因为公司可以仅在绝对需要时才按需“购买”更多服务器，而不是提前很长时间才提供所有可能的服务器。但是，还有人可能会争辩说，如果许多服务器没有适当的容量管理而被遗弃，那么配置服务器的便利性可能会使情况变得更糟。
无论我们使用的是自托管服务器，IaaS还是PaaS基础架构解决方案，我们仍在手动做出有关应用程序的容量决策，这些决策通常会持续数月或数年。通常，我们在管理容量方面非常谨慎，这是正确的，因此我们过度配置，导致上述效率低下。使用无服务器方法， 我们不再需要自己做出容量决定—我们让无服务器供应商实时提供满足我们需求的足够计算能力。然后，供应商可以汇总其整个客户的容量决策。
与传统的容量管理方法相比，这种差异将导致跨数据中心的资源使用效率更高，从而减少对环境的影响。
缺点
因此，亲爱的读者，我希望您在彩虹，独角兽以及所有闪闪发光的事物中度过美好时光，因为我们将被现实的湿鱼拍打在脸上。
无服务器架构肯定有很多优点，但它们之间存在重大折衷。这些权衡中的一些是概念固有的。它们不能完全由进步来解决，并且始终需要加以考虑。其他则与当前的实现方式联系在一起。随着时间的流逝，我们可以期待看到这些解决方案。
固有的缺点
供应商控制
使用任何外包策略，您都将某些系统的控制权交给了第三方供应商。缺乏控制可能表现为系统停机，意外限制，成本变化，功能丧失，强制API升级等。慈善专业，谁我前面提到，在解释中的权衡部分更多的细节这个问题 这篇文章：
[供应商服务]如果很聪明，则会对您的使用方式施加严格的限制，因此他们更有可能实现其可靠性目标。当用户拥有灵活性和选择权时，就会造成混乱和不可靠。如果平台必须在您的幸福感与成千上万个其他客户的幸福感之间进行选择，那么他们将每次都选择一个，即他们应该选择的一个。
-慈善专业
多租户问题
多租户是指在同一台计算机上（可能在同一托管应用程序中）运行多个不同客户（或租户）的多个软件实例的情况。这是我们前面提到的实现规模效益的战略。服务供应商竭尽全力使客户感到他们是使用系统的唯一人，通常优质服务供应商会做得很好。但是，没有人能提供完美的解决方案，有时甚至是多租户的解决方案，在安全性（一个客户可以查看另一人的数据），健壮性（一个客户的软件错误导致另一个客户的软件失败）方面都存在问题。导致另一个变慢）。
这些问题不是无服务器系统所独有的，它们在使用多租户的许多其他服务产品中也存在。AWS Lambda现在已经足够成熟，以至于我们不希望看到这种问题，但是对于任何较不成熟的服务，无论是来自AWS还是其他供应商，您都应该注意这些问题。
供应商锁定
您很可能从一个供应商处使用的任何无服务器功能都将由另一供应商以不同的方式实现。如果要更换供应商，几乎肯定需要更新您的操作工具（部署，监视等），您可能需要更改代码（例如，满足不同的FaaS界面），甚至可能如果竞争对手的供应商实施方式存在差异，则需要更改设计或体系结构。
即使您设法轻松迁移生态系统的一部分，您也可能会受到另一体系结构组件的更大影响。例如，假设您正在使用AWS Lambda来响应AWS Kinesis消息总线上的事件。AWS Lambda， Google Cloud Functions和 Microsoft Azure Functions之间的差异可能相对较小，但是您仍然无法将后两个供应商实现直接连接到您的AWS Kinesis流。这意味着，如果不将基础架构的其他部分也进行移动，就无法将代码从一种解决方案迁移或移植到另一种解决方案。
很多人都被这个想法吓到了-知道今天选择的云供应商明天是否需要更改会带来很多工作，这真不是一种好感觉。因此，有些人采用“多云”方法，以与实际使用的云供应商无关的方式开发和操作应用程序。通常，这甚至比单云方法要贵得多，因此，尽管供应商锁定是一个合理的问题，但我仍然建议选择一个您满意的供应商并尽可能地利用其功能。我将在本文中更多地讨论其原因。
安全问题
采用无服务器方法会给您带来大量安全问题。这只是一些要考虑的问题的简短摘要，请务必探索其他可能影响您的因素。
- 您使用的每个无服务器供应商都会增加您的生态系统所采用的不同安全性实现的数量。这会增加您的恶意意图的表面积，并增加成功攻击的可能性。
- 如果直接从您的移动平台上使用BaaS数据库，则将失去服务器端应用程序在传统应用程序中提供的保护性屏障。尽管这不是一个大问题，但在设计和开发应用程序时确实需要格外小心。
- 当您的组织采用FaaS时，您可能会在整个公司中经历FaaS功能的寒武纪爆发。这些功能中的每一个都为问题提供了另一个载体。例如，在AWS Lambda中，每个Lambda函数通常都与已配置的IAM策略并驾齐驱，这很容易出错。这不是一个简单的话题，也不是一个可以忽略的话题。IAM管理至少在生产AWS账户内需要仔细考虑。
跨客户端平台重复逻辑
使用“完整” BaaS架构，无需在服务器端编写自定义逻辑，而所有逻辑都在客户端中。这对于您的第一个客户端平台可能很好，但是一旦您需要下一个平台，就需要重复执行该逻辑的一个子集，并且在传统的体系结构中不需要此重复。例如，如果在这种系统中使用BaaS数据库，则所有客户端应用程序（可能是Web，本机iOS和本机Android）现在都需要能够与供应商数据库进行通信，并且需要了解如何从中映射。您的数据库架构到应用程序逻辑。
此外，如果您想随时迁移到新数据库，则需要在所有不同的客户端之间复制该编码/协调更改。
服务器优化损失
拥有完整的BaaS架构，就没有机会优化服务器设计以提高客户端性能。在“后端对于前端”模式存在于服务器内你的整个系统的抽象某些底层方面，一方面使客户可以更快速地执行操作，并且在移动应用的情况下，使用较少的电池电量。这种模式不适用于完整的BaaS。
对于完整的BaaS架构而言，这和以前的缺点都存在，在该架构中，所有自定义逻辑都在客户端中，唯一的后端服务由供应商提供。这两者的缓解措施是采用FaaS或其他某种轻量级服务器端模式，以将某些逻辑移至服务器。
无服务器FaaS的服务器内状态
在遇到一些BaaS特定的缺点之后，让我们讨论一下FaaS。我之前说过：
当涉及本地..状态时，FaaS功能具有明显的限制。..您不应假定某个函数的一次调用的状态可用于同一函数的另一次调用。
做出此假设的原因是，使用FaaS，我们通常无法控制用于我们功能的主机容器何时启动和停止。
前面我还说过，替代本地状态的方法是遵循“十二要素”应用程序的因子6，即要接受这种约束：
十二因素过程是无状态的，没有共享。任何需要保留的数据都必须存储在有状态的支持服务中，通常是数据库。
Heroku建议采用这种思维方式，但是您可以在Hera Dynos的PaaS上运行时弯曲规则，因为您可以控制何时启动和停止Heroku Dynos。有了FaaS，您就不会违反规则。
因此，如果您无法将FaaS保存在内存中，您的状态将如何发展？上面的引用是指使用数据库，在许多情况下，快速NoSQL数据库，进程外缓存（例如Redis）或外部对象/文件存储（例如S3）将是您的一些选择。但是这些都比内存中或机器上的持久性慢很多。您需要考虑您的应用程序是否适合于此。
在这方面的另一个问题是内存中的缓存。从外部存储的大数据集中读取的许多应用程序将保留该数据集一部分的内存缓存。您可能正在从数据库的“参考数据”表中读取数据，并使用诸如Ehcache之类的东西。或者，您可能正在从指定缓存头的HTTP服务中读取信息，在这种情况下，内存中的HTTP客户端可以提供本地缓存。
FaaS确实允许使用局部缓存，并且如果您的函数使用得足够频繁，这可能会很有用。例如，对于AWS Lambda，我们通常希望一个函数实例能够持续运行几个小时，只要它至少每隔几分钟使用一次即可。这意味着我们可以使用Lambda可以提供给我们的（可配置）3 GB RAM或512 MB本地“ / tmp”空间。对于某些缓存，这可能就足够了。否则，您将不再需要进程内缓存，而将需要使用诸如Redis或Memcached之类的低延迟外部缓存。但是，这需要额外的工作，并且可能会因您的用例而过慢。
实施弊端
先前描述的缺点很可能在无服务器环境中始终存在。我们将看到缓解解决方案方面的改进，但是它们总是会存在的。
但是，其余的缺点完全归因于当前的技术水平。通过卖方和/或英雄社区的意愿和投资，这些都可以消除。实际上，自本文的第一个版本以来，该列表已经缩小。
组态
当我撰写本文的第一个版本时，AWS很少提供Lambda函数的配置方式。我很高兴地说这已经解决，但是如果您使用的是较不成熟的平台，那仍然值得一试。
自己做
这就是为什么一个例子买者自负是当你正在处理FAAS一个关键短语。AWS Lambda限制了在给定时间可以运行多少个Lambda函数的并发执行。说这个限制是一千；这意味着您可以随时执行一千个函数实例。如果您需要超越此限制，则可能会开始遇到异常，排队和/或总体速度变慢的情况。
这里的问题是此限制涉及整个AWS账户。一些组织将相同的AWS账户用于生产和测试。这意味着，如果您组织中某个地方的某人执行一种新型的负载测试，并开始尝试执行一千个并发Lambda函数，则您会意外地 对生产应用程序进行DoS。哎呀。
即使您使用不同的AWS账户进行生产和开发，一个过载的生产lambda（例如，处理来自客户的批量上传）也可能导致您单独的实时lambda支持的生产API变得无响应。
亚马逊在这里通过保留并发的方式 提供了一些保护。保留并发性允许您限制Lambda函数的并发性，这样它就不会消耗您帐户的其余部分，同时确保无论帐户中其他函数在做什么，总有可用的容量。但是，默认情况下，帐户未启用保留并发，因此需要仔细管理。
执行时间
在本文的前面，我提到过，如果AWS Lambda函数运行超过五分钟，它们就会中止。现在已经保持了几年的一致性，AWS没有显示任何更改的迹象。
启动延迟
我之前谈到过冷启动，并提到了有关该主题的文章。随着时间的推移，AWS已改进了该领域，但是这里仍然存在重大问题，尤其是对于仅偶尔触发的JVM实现的功能和/或需要访问VPC资源的功能。预计在这一领域将继续改善。
好的，特别是在AWS Lambda上就足够了。我确信其他供应商的壁橱里也几乎没有丑陋的骷髅头。
测验
出于我之前提到的原因，无服务器应用程序的单元测试相当简单：您编写的任何代码都是“公正的代码”，并且在大多数情况下，您不必使用一堆自定义库或接口必须实施。
另一方面，对无服务器应用程序进行集成测试非常困难。在BaaS世界中，您故意依赖外部提供的系统，而不是自己的数据库。那么您的集成测试是否也应该使用外部系统？如果是，那么这些系统对测试方案的适应性如何？您能轻易拆掉状态吗？您的供应商能否为您提供不同的计费策略来进行负载测试？
如果您想存根那些外部系统进行集成测试，供应商是否提供本地存根模拟？如果是这样，存根的保真度有多好？如果供应商不提供存根，您将如何自己实施？
尽管在FaaS领域有所改进，但同样存在这类问题。现在可以在本地为Lambda和Microsoft Azure运行FaaS函数。但是，没有本地环境可以完全模拟云环境。我不建议仅依靠本地FaaS环境。实际上，我会进一步建议在运行自动化集成测试的规范环境（至少作为部署管道的一部分）应该是云，并且应该将本地测试环境主要用于交互式开发和调试。这些本地测试环境不断改进-SAM CLI例如，可为开发Lambda支持的HTTP API应用程序提供快速反馈。
还记得我在云中运行集成测试时在前几节中提到的那些跨帐户执行限制吗？您可能希望至少将此类测试与生产云帐户隔离开，并可能使用比此更细粒度的帐户。
之所以考虑集成测试很重要，部分原因是我们与无服务器FaaS的集成单元（即每个功能）比其他体系结构要小得多，因此我们对集成测试的依赖远胜于与其他体系结构的集成建筑风格。
依靠基于云的测试环境，而不是在笔记本电脑上本地运行所有内容，这真让我感到震惊。但是，时代在变，我们从云中获得的功能与Google等工程师十年来的功能相似。亚马逊现在甚至允许您在云中运行IDE。我还没有实现这一目标，但是可能即将到来。
调试
使用FaaS进行调试是一个有趣的领域。根据上面讨论的测试更新，这里已经取得了进展，主要与在本地运行FaaS功能有关。如前所述，Microsoft为本地运行但由远程事件触发的功能提供了出色的调试支持。亚马逊提供了类似的功能，但尚未由生产事件触发。
实际在生产云环境中运行的调试功能是另一回事。Lambda至少还没有对此的支持，尽管很高兴看到这样的功能。
部署，打包和版本控制
这是一个积极改进的领域。AWS在改进该领域方面已取得了长足的进步，稍后我将在“无服务器的未来”一节中进一步讨论它。
发现
“发现”是微服务领域中一个经常讨论的话题：这是一个服务如何调用另一个服务的正确版本的问题。在无服务器世界中，几乎没有关于发现的讨论。最初，这与我有关，但现在，我不必担心。Serverless的许多用法本质上是事件驱动的，在这里，事件的使用者通常会在某种程度上自行注册。对于FaaS的面向API的用法，我们通常在API网关后面使用它们。在这种情况下，我们在API网关的前面使用DNS，并在网关后面使用自动部署/流量转移。我们甚至可以在API网关的前面使用其他层（例如，使用AWS CloudFront）以支持跨区域弹性。
我将这个想法保留在“局限性”中，因为我认为它尚未得到证实，但毕竟可能会很好。
监控和可观察性
由于容器的短暂性，对于FaaS而言，监视是一个棘手的领域。大多数云供应商都为您提供了一些监控支持，并且我们在这里也看到了许多来自传统监控供应商的第三方工作。尽管如此，他们和您的最终能力，仍然取决于供应商为您提供的基本数据。在某些情况下这可能很好，但是至少对于AWS Lambda来说，这是非常基本的。我们在这方面真正需要的是开放的API，以及第三方服务可以提供更多帮助的功能。
API网关定义和雄心勃勃的API网关
ThoughtWorks作为其Technology Radar出版物的一部分，已经讨论了雄心勃勃的API网关。虽然该链接通常指的是API网关（例如，对于那些在传统上部署了微服务的前端），但它绝对可以应用于将API网关用作HTTP前端到FaaS功能。问题在于API网关提供了在其自己的配置/定义域中执行许多特定于应用程序的逻辑的机会。这种逻辑通常很难测试，版本控制，有时也很难定义。通常，将这种逻辑像其他应用程序一样保留在程序代码中要好得多。
不过这里肯定有紧张气氛。如果我们将API网关视为BaaS，那么考虑它为我们提供的所有选项以节省工作量，是否有价值？而且，如果我们为每个请求支付API网关的使用费用，而不是按CPU利用率支付费用，那么最大化使用API网关功能的成本是否更具成本效益？
我的指导是明智地使用增强的API网关功能，并且只有从长远来看确实可以节省您的精力时，包括如何部署，监视和测试。绝对不要使用源代码可控的配置文件或部署脚本中无法表达的API网关功能。
关于定义的困难，Amazon的API网关用来强迫您创建一些棘手的配置，以将HTTP请求和响应映射到Lambda函数或从Lambda函数映射。Lambda代理集成使很多事情变得更加简单，但是您仍然需要了解一些偶尔棘手的细微差别。使用诸如Serverless Framework和Claudia.js或Amazon的Serverless Application Model之类的开源项目，这些元素本身变得更加容易。
延期运营
我之前提到过，Serverless并非“无所事事”，从监视，体系结构扩展，安全性和网络角度来看，还有很多事情要做。但是，在您入门时很容易忽略操作（“看，妈，没有操作系统！”）。这里的危险逐渐变成一种错误的安全感。也许您已经启动并运行了您的应用程序，但是它意外出现在Hacker News上，突然您要处理的流量就增加了10倍！您不小心进行了DoS，并且不知道如何处理。
解决方法是教育。使用无服务器系统的团队需要尽早考虑运营活动，这由供应商和社区来提供指导以帮助他们理解这意味着什么。先发制人的负载测试和混乱的工程等领域也将帮助团队自学。
无服务器的未来
我们即将结束无服务器架构世界的旅程。最后，我将讨论一些领域，我认为未来几个月和几年中无服务器世界可能会发展。
减轻弊端
无服务器仍然是一个新世界。因此，上一章关于弊端的内容非常广泛，我什至没有涵盖我所能拥有的一切。Serverless的最重要发展将是减轻固有缺陷并消除或至少改善实现缺陷。
工装
对于无服务器，工具仍然是一个问题，因为这是许多新技术。在过去两年中，部署/应用程序捆绑和配置都得到了改善，其中无服务器框架和亚马逊的无服务器应用模型处于领先地位。但是，尽管亚马逊和谷歌可以向微软和Auth0寻求更多的灵感，但是“前10分钟”的体验仍然没有普遍令人惊奇。
我很高兴看到云供应商积极解决的一个问题是更高级别的发布方法。在传统系统中，团队通常需要编写自己的流程来处理“交通转移”的想法，例如蓝绿色部署和Canary发布。考虑到这一点，Amazon支持Lambda和API Gateway的自动流量转移。这种概念在无服务器系统中更为有用，在无服务器系统中，由这么多单独部署的组件组成一个系统，根本不可能一次释放100个Lambda函数。实际上，纳特·普赖斯（Nat Pryce） 我向我描述了一种“混合办公桌”方法的想法，这种方法使我们可以逐步将组中的组件引入和带出交通流。
分布式监视可能是最需要改进的领域。我们已经从亚马逊的X-Ray和各种第三方产品中看到了早期的工作，但这绝对不是一个可以解决的问题。
我也希望远程调试更加广泛。Microsoft Azure Functions支持此功能，但Lambda不支持。能够断点远程运行的功能是一项非常强大的功能。
最后，我希望看到“元操作”工具的改进，即如何更有效地管理成百上千的FaaS功能，已配置的服务等。例如，组织需要能够看到何时不再需要某些服务实例使用（出于安全目的，如果没有其他要求），他们需要更好的分组和跨服务成本的可见性（尤其是对承担成本责任的自治团队而言），以及更多。
国家管理
FaaS缺乏持久的服务器内状态对于许多应用程序来说都是很好的选择，但是对于许多其他应用程序来说，这是一个大问题，无论是大型缓存集还是对会话状态的快速访问。
对于高吞吐量应用程序，一种解决方法可能是让供应商在事件之间保持功能实例的生存时间更长，并让常规的进程内缓存方法完成其工作。由于缓存不会为每个事件预热，因此这不会100％地起作用，但这与使用自动缩放的传统部署应用程序已经存在的问题相同。
更好的解决方案可能是对进程外数据的访问延迟非常低，例如能够以非常低的网络开销查询Redis数据库。鉴于亚马逊已经在其Elasticache产品中提供了托管Redis解决方案，并且它们已经允许使用Placement Groups相对托管EC2（服务器）实例，所以这似乎没有太大的作用。
不过，更可能的是，我认为我们将看到采用各种混合（无服务器和非无服务器）应用程序架构来考虑外部状态约束。例如，对于低延迟应用程序，您可能会看到一种常规的，长时间运行的服务器处理初始请求的方法，从本地和外部状态收集处理该请求所需的所有上下文，然后将完全上下文化的请求移交给FaaS功能场，无需在外部查找数据。
平台改进
无服务器FaaS的某些缺点现在归结为平台的实现方式。执行时间，启动延迟和跨功能限制是三个明显的限制。这些可能会由新的解决方案解决，也可能会采用可能需要额外成本的解决方法。例如，我认为可以通过允许客户请求以低延迟始终提供两个FaaS功能实例的方式来减轻启动延迟，而客户为此付费。Microsoft Azure Functions具有“持久功能”和“应用服务计划”托管功能的这种想法。
当然，我们将看到平台解决方案不仅可以解决当前的缺陷，而且也将令人兴奋。
教育
通过培训可以减轻Serverless的许多特定于供应商的固有缺陷。使用此类平台的每个人都必须积极考虑由一个或多个应用程序供应商托管如此多的生态系统意味着什么。我们需要考虑以下问题：“如果一个供应商不可用，我们是否要考虑来自不同供应商的并行解决方案？” 和“在局部中断的情况下应用程序如何正常降级？”
教育的另一个领域是技术操作。现在，许多团队的系统管理员比以前更少了，Serverless将加速这一变化。但是系统管理员所做的不只是配置Unix框和Chef脚本-他们通常是支持，网络，安全等方面的第一线人员。
真正的DevOps文化在无服务器世界中变得尤为重要，因为那些其他非系统管理员的活动仍然需要完成，而现在通常由开发人员来负责。这些活动对于许多开发人员和技术领导者来说可能并非自然而然，因此，教育和与操作人员的密切合作至关重要。
提高透明度并提高供应商的期望
最后，关于缓解的主题：由于我们依赖于他们的更多托管功能，因此我们对他们的平台的期望必须更加明确。尽管迁移平台很困难，但并非没有可能，不值得信任的供应商将看到他们的客户将其业务转移到其他地方。
模式的出现
我们对如何以及何时使用无服务器架构的理解仍处于起步阶段。现在，团队正在无服务器平台上抛出各种想法，并发现了什么。感谢先驱！我们开始看到推荐实践的模式，并且这种知识只会增长。
我们看到的一些模式是在应用程序体系结构中。例如，FaS功能在变得笨拙之前能达到多少？假设我们可以原子地部署一组FaaS函数，那么创建此类分组的好方法是什么？它们是否与我们当前将逻辑整合到微服务中的方式密切相关，还是架构上的差异将我们推向了另一个方向？
无服务器应用程序体系结构中活跃讨论的一个特别有趣的领域是它如何与事件思考进行交互。AWS Lambda产品负责人Ajay Nair在2017年对此进行了精彩演讲，这是CNCF无服务器工作组的主要讨论领域之一。
进一步扩展这一点，有什么好的方法可以在FaaS和传统的“始终在线”持久服务器组件之间创建混合架构？将BaaS引入现有生态系统的好方法是什么？反过来说，一个完全或主要是BaaS系统需要开始拥抱或使用更多自定义服务器端代码的警告信号是什么？
我们还看到了更多的讨论使用模式。FaaS的标准示例之一是媒体转换，例如，每当将大型媒体文件存储到S3存储桶中，然后自动运行进程以在另一个存储桶中创建较小版本的文件。但是，我们现在还看到Serverless在数据处理管道，高度可扩展的Web API中的大量使用，以及在操作中用作通用“胶水”代码。这些模式中的一些可以实现为通用组件，可以直接部署到组织中。我已经写过有关Amazon的Serverless Application Repository的文章，它具有这种想法的早期形式。
最后，随着工具的改进，我们开始看到推荐的操作模式。我们如何在逻辑上汇总FaaS，BaaS和传统服务器的混合体系结构的日志记录？我们如何最有效地调试FaaS功能？这些问题的许多答案（以及新兴的模式）都来自云供应商本身，我希望这一领域的活动会有所增长。
全球分布的架构
在我之前给出的Pet Store示例中，我们看到单个Pet Store服务器被分解为多个服务器端组件，并且一些逻辑一直移到客户端，但是从根本上讲，这仍然是一种专注于客户端，或在已知位置的远程服务上。
我们现在开始在无服务器世界中看到的是责任分配的模糊性。一个示例是Amazon的Lambda @ Edge产品：一种在Amazon的CloudFront内容交付网络中运行Lambda功能的方法。现在，借助Lambda @ Edge，Lambda功能已在全球范围内分发-工程师的一次上载活动将意味着该功能已部署到全球100多个数据中心 。这不是我们习惯的设计，并且同时具有很多约束和功能。
此外，Lambda函数可以在设备上运行，机器学习模型可以在移动客户端上运行，并且在您不了解之前，“客户端”和“服务器端”的分歧似乎不再有意义。实际上，我们现在已经看到了从本地用户那里散发出来的组件的局部范围。无服务器将变为无区域。
超越“ FaaSification”
到目前为止，我所见过的FaaS的大多数用法主要是采用现有的代码和设计思想并将它们“ FaaSizing”：将它们转换为一组无状态函数。这很强大，但是我希望使用FaaS作为基础实现可以使开发人员受益于FaaS，而无需实际将其应用程序视为一组离散功能，因此我们将开始看到更多的抽象，甚至还有语言。
举例来说，我不知道Google是否为其数据流产品使用FaaS实现，但是我可以想象有人创建了一个做类似事情的产品或开源项目，并使用FaaS作为实现。这里的比较类似于Apache Spark。Spark是用于大规模数据处理的工具，并提供可以使用Amazon EMR和Hadoop作为其基础平台的非常高级的抽象。
测验
我认为在无服务器系统的集成和验收测试方面还有很多工作要做，但是其中许多工作与以更传统的方式开发的“云原生”微服务系统相同。
这里一个激进的想法是接受诸如在生产中进行测试和监视驱动的开发之类的想法；一旦代码通过了基本的单元测试验证，请部署到一部分流量，并查看其与以前版本的比较。这可以与我前面提到的流量转移工具结合使用。这并非在所有情况下都适用，但是对于许多团队来说，这可能是一个令人惊讶的有效工具。
可移植的实现
团队可以使用多种方式使用Serverless，而与特定的云供应商的联系则更少。
供应商实现的抽象
的无服务器架构的存在主要是缓解操作任务用于无服务器的应用程序，而且还提供了中立的关于在哪里和如何这样的应用部署的量。例如，根据每个平台的操作能力，即使现在就可以在AWS API Gateway + Lambda和Auth0 Webtask之间轻松切换也很不错。
这方面的一个棘手的方面是造型抽象FAAS编码接口，而无需标准化的一些想法，但是这恰恰是CNCF无服务器工作组的工作 CloudEvents。
但是，一旦操作复杂性浮出水面，为多个平台提供部署抽象究竟有多少价值，这是令人怀疑的。例如，在一个云中正确实现安全性在另一云中可能总是不同。
可部署的实施
建议我们使用无服务器技术而不使用第三方提供程序可能听起来很奇怪，但是请考虑以下想法：
- 也许我们是一家大型技术组织，我们希望开始为所有移动应用程序开发团队提供 类似于Firebase的数据库体验，但我们希望将现有的数据库体系结构用作后端。
- 我之前谈到过“服务器式” FaaS平台—能够在我们的某些项目中使用FaaS风格的体系结构，但出于合规性，法律等原因，必须在内部运行我们的应用程序。
在这两种情况下，使用无服务器方法仍然有许多好处，而没有来自供应商托管的好处。这里有一个先例-考虑平台即服务（PaaS）。最初流行的PaaS都是基于云的（例如Heroku），但是很快，人们看到了在自己的系统上运行PaaS环境的好处-所谓的“私有” PaaS（例如，Cloud Foundry，如我所提到的）本文前面的内容）。
我可以想象，像私有PaaS实现一样，我们将看到BaaS和FaaS概念的开源和商业实现都变得流行，尤其是那些与诸如Kubernetes之类的容器平台集成的概念。
社区
已经存在一个大型的无服务器社区，其中包含多个会议，许多城市的聚会以及各种在线团体。我希望这种情况将继续增长，可能与Docker和Spring这样的社区一样。
结论
无服务器，尽管名称令人困惑，但它是一种体系结构样式，在该体系结构中，我们依赖于运行服务器端系统作为应用程序的一部分，而这种情况的范围比平时要小。我们通过两种技术来做到这一点：BaaS（将第三方远程应用程序服务直接集成到我们的应用程序的前端中）和FaaS（将服务器端代码从长期运行的组件移至临时函数实例）。
无服务器并不是解决每个问题的正确方法，因此请警惕有人说无服务器将取代您现有的所有体系结构。如果您现在进入无服务器系统，尤其是在FaaS领域，请小心。尽管有很多东西可以掠夺，例如规模扩展和节省的部署工作，但也有大量的调试和监视巨龙潜伏在下一个角落。
但是，这些财富不应该过分地消除，因为无服务器架构具有很多积极的方面，包括降低了运营和开发成本，简化了运营管理并降低了对环境的影响。但是我认为最重要的好处是减少了创建新应用程序组件的反馈循环。我是“精益”方法的忠实拥护者，这在很大程度上是因为我认为，尽快将技术提供给最终用户以获取早期反馈并减少Serverless的上市时间具有很多价值。恰好符合这一理念。
无服务器服务，以及我们对如何使用它们的理解，今天（2018年5月）正处于成熟的“略显尴尬的少年时代”。在未来几年中，该领域将取得许多进步，而无服务器如何适合我们的体系结构工具包将使您着迷。
致谢
感谢以下人员对本文的投入：Obie Fernandez，Martin Fowler，Paul Hammant，Badri Janakiraman，Kief Morris，Nat Pryce，Ben Rady，Carlos Nunez，John Chapin，Robert Bagge，Karel Sague Alfonso，Premanand Chandrasekaran，Augusto Marietti ，罗伯托·萨里奥南迪亚（Roberto Sarrionandia），唐娜（Donna Malayeri）。
感谢Badri Janakiraman和Ant Stanley，他们为边栏的术语来源提供了输入。
感谢我以前在Intent Media团队中的成员以适当的怀疑热情对待这项新技术：John Chapin，Pete Gieser，SebastiánRojas和PhilippeRené。
感谢Sid Orlando进行文案编辑。
最后，感谢无服务器社区中的朋友和同事，特别是我在本文中链接到的那些朋友和同事。
重大修订
1017
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
