无服务器架构（Faas/Serverless）是软件架构领域的热门话题。AWS、GoogleCloud和Azure——在无服务器方面投入了大量资金，看过很多专门针对Faas/Serverless的文章、书籍、开源项目、会议。但什么是无服务器，为什么（或不）值得考虑？1.什么是无服务器？无服务器架构是一种设计应用程序的方法，包括第三方“后端即服务”（BaaS）服务，和/或包括（在FaaS平台上的托管临时容器中运行的自定义代码。这种类型的架构消除了传统的永远在线的服务器的大部分需求。这可以显着降低运维成本、复杂性和项目上线准备时间，代价是增加对供应商的依赖和相对不成熟的支持服务。第一，没有人有明确的想法什么是serverless。它包含两个截然不同但又相关的领域：Serverless可以描述一个“富客户端+第三方云托管应用和服务”的应用。这些“富客户端”应用一般都是移动应用，使用庞大的云数据库或SSO服务（Auth0、AWSCognito等）。这些类型的服务以前被描述为“后端即服务”。无服务器也意味着服务器端逻辑仍然由th编写eapplicationdeveloper，但与传统架构不同，它运行在事件触发的短暂无状态计算容器中（可能只持续一次调用，或者一个Deployment将被Reserved，运行实例的数量根据运行负载自动调整），以及完全由第三方管理（可能是“FaaS”名字的来源）AWSLambda是目前FaaS平台最好的实现之一，比国内云服务商便宜很多，看好亚马逊市值超万亿（苹果可能会打脸）。在本文中，我们显然会关注后者，即FaaS/Serverless。2.几个扩展示例让我们考虑一个传统的三层面向客户端的系统，它具有服务器端逻辑。典型的电子商务应用就是一个很好的例子——在线宠物店。架构是这样的：在这种架构下，客户端可以相对智能化一些，大部分逻辑都在服务端完成，比如授权、页面导航、查询、事务等。在Serverless架构中，它看起来是这样的：将两者进行比较，我们可以看到一系列明显的变化：我们去除了原始应用程序中的身份验证逻辑，并用第三方BaaS服务（例如Auth0）代替它我们允许客户直接访问我们的数据库（用于产品列表），该数据库本身完全由第三方（例如GoogleFirebase）托管。我们可能会使用与服务器资源不同的安全配置文件来访问数据库，以允许客户端访问数据库。前两点暗示了非常重要的第三点：宠物店服务器中的一些逻辑现在位于客户端内部——例如，跟踪用户会话、了解应用程序的用户体验结构、从数据库读取并将其转换为诸如视图之类的可用客户端正在成为单页应用程序。我们可能希望在服务器中保留一些与用户体验相关的功能，例如，如果它是计算密集型的或需要访问大量数据。在我们的宠物店中，一个例子是“搜索”。我们可以实现一个FaaS功能，通过API网关响应HTTP请求，而不是像原始架构中那样拥有一个永远在线的服务器。客户端和服务器“搜索”功能都从同一个数据库中读取产品数据。***，我们可以用另外一个独立的Faas函数代替购买的实现，为了安全起见，这个也是API网关引入的。在使用FAAS时，将不同的逻辑需求拆分成独立的部署组件是一种非常常见的做法。3.“Faas”的面纱现在是深入了解FAAS到底是什么的时候了。为此，我们先来看看亚马逊FaaS产品Lambda的开篇介绍。AWSLambda允许您在不预置或管理服务器的情况下运行代码。(1)使用Lambda，您可以为几乎任何类型的应用程序或后端服务运行代码(2)所有这些都是零管理。只需上传代码，Lambda将处理运行(3)扩展具有高可用性的实例所需的一切。(4)代码可以设置为从其他AWS服务自动触发(5)或直接从任何Web或移动应用程序调用它。详细来说：fromFaaS就是运行后端代码，而无需管理自己的服务器系统或应用程序。与容器和PaaS等其他现代架构趋势相比，是否存在长期存在的服务器和应用程序是一个关键的区别。FaaS产品不需要编码到特定的框架或库。FaaS功能是语言和环境的常规应用。例如，AWSLambda函数可以将Javascript、Python、Go、任何JVM语言（Java、Clojure、Scala等）或任何.NET语言视为“一等公民”。但是，Lambda函数也可以使用其部署包在另一个进程中执行，因此实际上可以使用任何可以编译为Unix进程的语言。FaaS功能具有重要的架构限制，尤其是在状态和执行持续时间方面。部署与传统系统有很大不同，因为我们没有自己运行的服务器应用程序。在FaaS环境中，我们将功能的代码上传到FaaS提供者，由提供者完成配置资源、实例VM（容器）、管理流程等所需的一切。水平扩展是全自动的、有弹性的，并由Faas管理。如果系统需要并行处理100个请求，Faas将处理它而无需您进行任何额外配置。执行功能的容器是短暂的，FaaS完全在运行时自行决定创建和销毁它们。最重要的是，有了FaaS，云厂商可以搞定所有底层资源的配置和分配，用户根本不需要集群或VM的管理。FaaS中的功能通常由提供者定义的事件类型触发。对于AWS，此类事件包括S3（文件/对象）更新、事件（定时任务）和来自消息总线的消息。大多数FaaS运营商还允许HTTP请求触发功能，而在AWS中，这通常是通过使用API网关来实现的。在宠物店示例中，我们使用API网关实现“搜索”和“购买”功能。也可以通过平台提供的API直接调用函数，无论是在外部还是在同一云环境中，但这种用法相对不常见。4.FaaS的特点需要关注StatelessFaaS功能在本地（VM/容器实例）状态（即数据存储在内存中的变量或写入本地磁盘）有很大的局限性。一般来说，您确实可以像这样存储，但不能保证这种状态会在多次调用中持续存在，更重要的是，您永远不应该假设对一个函数的一次调用的状态可用于对同一函数的另一次调用。因此，FaaS函数通常被描述为无状态的，或者更准确地说，FaaS函数任何需要持久化的状态都需要在FaaS函数实例之外。对于天生无状态的FaaS函数——即那些提供输入到输出的纯函数转换的函数——这是无关紧要的。但是对于有状态的，这就麻烦了，以前分布式的那些限制现在完全一样了。这种面向状态的功能通常会使用数据库、缓存（如Redis）或网络文件/对象存储（如S3）来跨请求存储状态。FaaS函数的执行时间通常受限于每次调用允许运行的时间。目前，AWSLambda函数在终止前有最多五分钟的“超时”来响应事件。MicrosoftAzure和GoogleCloudFunctions也有类似的限制。这意味着某些类别的长期任务不适合FaaS——除非你重新架构，否则你需要创建几个不同的协调的FaaS功能，而在传统环境中，你可能有一个长期任务执行协调和执行。启动延迟和“冷启动”FaaS平台需要一些时间在每个事件之前初始化功能实例。对于不同的功能，它的启动延迟也可能有很大差异，从几毫秒到几秒不等，这取决于很多因素。具体以AWSLambda为例。Lambda函数的初始化可以是“热启动”（使用先前生成的Lambda函数容器）或“冷启动”（创建新的容器实例）。冷启动造成的延迟应该引起我们的注意。冷启动的延迟取决于很多因素：开发语言、使用的库、代码量、Lambda函数环境本身的配置、是否需要连接VPC资源等等。这些方面都在开发者的控制之下，在这些方面做一些优化可以减少冷启动的启动延迟。同样可调的是冷启动的启动频率。例如，如果一个函数每秒处理10个事件，并且每个事件需要50毫秒来处理，那么每100,000-200,000个事件，您可能会看到一个实例的冷启动。另一方面，如果您按小时处理事件，您可能会看到每个事件都冷启动，因为亚马逊会在几分钟后驱逐不活动的Lambda实例。了解这一点有助于了解冷启动是否影响集成性能，以及您是否希望对函数实例执行“保持活动状态”以防止它们被回收。冷启动是不是太令人担忧了？这取决于应用程序的负载或流量条件。如果您需要的是低延迟交易应用程序，那么****忘记FaaS系统，无论您使用哪种编程语言。无论您认为您的应用程序是否存在此类问题，您最好使用类似生产的负载来测试性能。如果此刻不好，不用担心，FaaS提供商正在不断改进，也许他们会在今年年底满足您的要求。APIGatewayAPIGateway是一个HTTP服务器，其中路由和加载点在配置中定义，每个路由都与处理该路由的函数相关联。API网关收到请求后，会找到与请求匹配的路由配置，调用相关的FaaS函数。APIGateway允许更简洁的输入，将HTTP请求参数映射到FaaS函数，或者让HTTP请求按原样通过，FaaS函数将执行其逻辑并将结果返回给API网关，API网关又转换这个结果转化为HTTP响应并将其传回给原始调用者。工具关于工具成熟度的评论也适用于FaaS。到今年（2018年），我们已经看到了明显的改进，我们预计这些工具会发展得更好。FaaS世界中一些优秀的“开发者用户体验”示例值得一提。首先是Auth0Webtask，它非常重视开发人员的用户体验。紧随其后的是微软，其AzureFunctions产品。Microsoft一直将VisualStudio及其反馈循环置于其开发人员产品的最前沿，AzureFunctions也不例外。考虑到云触发事件的输入，它提供的在本地调试功能的能力非常特殊。无服务器中开源最常见的用途是FaaS工具和框架，它们提供了一些跨云提供商的工具抽象。类似工具的示例包括Claudia和Zappa。另一个例子是Apex，它允许您使用Amazon直接支持的语言以外的语言开发Lambda函数。但是AWS自己的部署工具SAM（ServerlessApplicationModel）也是开源的。专有FaaS的主要好处之一是不必关心底层计算基础设施（机器、虚拟机、容器）。但是如果你想关注这些东西呢？也许您有一些您的云提供商无法满足的安全需求，或者您有一些已购买但不想丢弃的服务器机架。开源可以在这些场景中提供帮助，允许您运行自己的“Serverful”FaaS平台，并且在这个领域有很多活动。IBM是开源FaaS的最初拥护者之一（拥有OpenWhisk，现在是Apache项目）。微软开源了很多AzureFunctions平台。许多其他自托管FaaS实现使用底层容器平台，通常是Kubernetes，在这个领域，值得探索GalacticFog、Fission和OpenFaaS等项目。在以后的博客中，我将重点介绍目前拥有超过10k+Star的OpenFaas项目。5.Serverless并不是因为概念太多，容易混淆。现在很多Readmes都有这个链接：和PaaS平台比较看看大师（VPCloudArchitectureStrategyatAWS）是怎么说的：换句话说，大多数PaaS应用程序不会让整个应用响应上去或者下掉一个事件，而FaaS平台。FaaS和PaaS之间的关键操作区别在于扩展性。通常用PaaS，你需要考虑如何扩展服务实例，用FaaS应用，它是完全透明的。即使你把PaaS应用设置为自动扩展，你也几乎不可能把这个操作设置到单次请求的级别。比如你有一个服务实例，一般不会为不同的请求设置不同的实例号。如果是大量的查询操作和少量的更新操作，你可以考虑优化查询，增加缓存等，而不是把你的实例在1分钟内扩容到100次，这样FaaS应用更划算。鉴于这个优势，为什么还要用PaaS呢？也许最大的原因是工具成熟度。基于PaaS的行之有效的实践有很多，Faas给了我们更多的系统扩展思路。与容器相比，另一个流行的服务抽象是容器，而Docker是这项技术最明显的例子。像Kubernetes这样的容器托管系统，从操作系统级部署中抽象出单个应用程序，越来越受欢迎。在这条路上，我们看到像AmazonECS和EKS（这里推荐，灵雀云的AKS发行版）、谷歌容器引擎（AlaudaContainerEngine，AKE）这样的云托管容器平台，就像Serverless/FaaS一样，团队不需要管理他们自己的服务器主机。鉴于容器的发展势头，无服务器FaaS是否仍然值得考虑？OperationsServerless并不是说??没有运维，可能是没有系统管理员，运维比服务器管理更重要，它也至少意味着：监控、部署、安全、网络，以及一般的一些生产调试和系统扩展。这些问题在Serverless应用中仍然存在，仍然需要一个策略来处理它们。在某些方面，Ops在无服务器世界中更难，因为其中很多都是新事物。无论哪种方式，在某些时候抽象可能会泄漏，你知道，在某个地方，有一个人工系统管理员支持你的应用程序。与存储过程对比另一个主题是无服务器FaaS是“存储过程即服务”。原文中也有说明，但由于其实只是FaaS功能的一个子集，以及文中提到的代码版本控制问题，其他几个开源的解决方案都不清楚，不过OpenFaas中有个项目OpenFaas——Cloud，基于Github，做了很棒的持续集成过程。6、使用Faas/Serverless有什么好处？降低运营成本Serverless是最简单的外包解决方案。您可以向云服务提供商付费以管理服务器、数据库甚至应用程序。基于规模经济：您为托管数据库支付的费用更少，因为一个提供商运行着数千个非常相似的数据库。降低的成本来自两个方面，第一是纯粹来自与他人共享基础设施（例如，硬件、网络）的基础设施成本。二是人工运维成本。不过这个好处和IaaS、PaaS差别不大，只是省了更多的钱。BaaS：降低开发成本IaaS和PaaS基于服务器或容器商品化。而无服务器BaaS是应用程序组件的商品化。例如：身份验证就是一个很好的例子，许多应用程序都编写了自己的身份验证功能，这些功能通常包括注册、登录、密码管理以及与其他身份验证提供程序集成等功能。总的来说，这个逻辑在大多数应用程序中都非常相似，并且创建了像Auth0这样的服务，让我们可以将现成的身份验证功能集成到我们的应用程序中，而无需我们自己开发，不得不说，这真的很省钱。关于BaaS数据库，比如Firebase的数据库服务。一些移动应用程序团队发现让客户端直接与服务器端数据库通信是有意义的。BaaS数据库消除了大部分数据库管理开销，并且通常提供机制来以无服务器应用程序预期的模式为不同类型的用户强制执行适当的授权。你是不是有点担心安全？我觉得在新的云计算时代，我们都得慢慢接受这些变化。扩展成本但就基础架构而言，最大的好处是您只需为所需的计算付费，就AWSLambda而言，AWS每月为开发人员提供100万个请求和400,000GB的计算时间-没有成本，真正的钱保存！示例：不频繁的请求假设您正在运行一个服务器应用程序，它每分钟只处理一个请求，每个请求需要50毫秒来处理，并且一个小时内的平均CPU使用率为0.1%。如果将此应用程序部署到其自己的专用主机，则效率非常低。你显然可以在这台机器上运行一千个类似的应用程序，并在这台机器上共享它们。FaaS将降低的成本交到您手中。使用上面的示例应用程序，您只需支付每分钟50毫秒的计算费用。示例：不规则的流量高峰让我们看另一个示例。假设您的服务接收到每秒20个请求的基线流量，但每5分钟接收到每秒200个请求（通常数量的10倍），持续10秒。您当然不希望在流量高峰期间减少响应时间。你怎么解决这个问题？在传统环境中，您可能需要将硬件总量增加10倍，才能处理峰值情况，即使峰值的总持续时间不到机器总正常运行时间的4%。自动缩放可能不是一个好的选择，因为当新实例启动时，高峰期将结束服务器启动所需的时间。就像下图的处理：使用FaaS这个不会有问题，只需要在高峰期支付额外的计算成本。显然，这是一个Serverless/FaaS可以节省大量资金的例子，但重点是从扩展的角度来看。优化是成本节约的根源还有一个有趣的方面：??对代码所做的任何性能优化不仅会提高应用程序的速度，而且还可以直接关系到运营成本的降低。比如你的FaaS功能，原来是100ms，优化后降低到50ms。恭喜，成本降低了一半。它非常简单，不需要更改任何基础架构。运维管理和扩展的提升带来的便利，前面已经多次提到。FaaS的扩展功能不仅降低了计算成本，也减少了运维管理，因为扩展是自动的。在最坏的情况下，如果扩展是手动的，那么运维人员将需要明确地向一组服务器添加和删除实例——使用FaaS时，不要管它，让FaaS提供商扩展您的应用程序。即使您已经在非FaaS架构中使用自动缩放，它仍然需要设置和维护。FaaS不再需要这项工作。降低打包和部署的复杂性与部署整个服务器相比，打包和部署FaaS功能非常简单。您所做的只是将所有代码打包成一个zip文件并上传，您无需决定是否在您的计算机上部署一个或多个容器。如果您刚刚起步，您甚至不需要打包任何东西——您可以在供应商控制台本身编写代码。OpenFaaS很有趣。它允许您直接拉取Github的源代码。配置CI参数后，Commit将更新您的函数。这个过程不需要很长时间来描述，但对于一些团队来说，好处可能是巨大的：一个完全无服务器的解决方案需要零系统管理。PaaS解决方案具有类似的部署优势，但正如我们之前看到的，在比较PaaS和FaaS时，扩展优势是FaaS所独有的。交付速度和持续验证随着团队和产品变得越来越敏捷，我们希望不断尝试新事物并快速更新现有系统。虽然持续交付环境中的简单重新部署允许稳定项目的快速迭代，但从一个想法到初始部署的能力允许我们以极快的速度和低成本尝试新的实验。前面说了，基于FaaS的持续集成非常有利于你继续试验。尽管成本效益是Serverless最简单的改进，但我最兴奋的是这种缩短的交付时间。它支持持续试验的产品开发思维方式，这是我们在公司中交付软件方式的真正革命。“绿色”计算？在过去的几十年里，全球数据中心的数量和规模急剧增加。除了建造这些中心所需的物理资源外，相关的能源需求也非常大，以至于苹果、谷歌和其他公司正在讨论在可再生能源附近设立一些数据中心，以减少化石燃料的燃烧。上电后的空闲时间导致服务器消耗大量能量。商业和企业数据中心的典型服务器在一年中平均提供其最大计算输出的5%到15%。–福布斯这是非常低效的并且对环境有巨大的影响。一方面，云基础设施可能有助于减少这种影响，因为公司可以按需“购买”更多服务器，只有在他们绝对需要它们时，而不是提前很长时间配置所有可能需要的服务器。然而，也有人可能会争辩说，如果许多服务器在没有足够的容量管理的情况下被丢弃，那么易于配置服务器可能会使事情变得更糟。无论我们使用自托管服务器、IaaS还是PaaS基础架构解决方案，我们仍然需要手动对应用程序进行容量决策，通常需要数月或数年时间。通常，我们对管理容量持谨慎态度，因此我们过度供应，导致刚才描述的效率低下。使用无服务器方法，我们不再自己做出此类容量决策——我们让FaaS提供商提供足够的计算容量来满足我们的实时需求。然后供应商可以聚集他们的客户来做出他们自己的容量决策，就像区域供暖一样，而不是在您北方的家中使用自己的锅炉。
