无服务器架构(Faas/Serverless)，是软件架构领域的热门话题。 AWS，Google Cloud和Azure - 在无服务器上投入了大量资金，已经在看到了大量专门针对Faas/Serverless的文章、书籍，开源项目，会议。 但什么是无服务器，为什么(或不是)值得考虑?
1. What is Serverless?
无服务器架构是一种包含第三方“后端即服务”(BaaS)服务的应用程序设计方式，和/或包括(FaaS)平台上的托管临时容器中运行的自定义代码。 此类体系结构消除了对传统的始终在线服务器的大部分需求。 这可以显着降低的运维成本，复杂性以及减少项目的上线准备时间，代价是增加了对供应商依赖性和相对不成熟支持服务的依赖。
首先，没有人清楚地知道无服务器是什么。它包含两个不同但是有关联的领域：
无服务器可以描述一个”富客户端 + 第三方云托管应用程序和服务的”的应用程序。这些“富客户端”应用程序一般是移动应用程序，使用庞大的云端数据库或SSO服务(Auth0，AWS Cognito等)。这些类型的服务以前被描述为“后端即服务”。
无服务器也可以指服务器端逻辑仍然由应用程序开发人员编写，但是与传统体系结构不同，它运行在无状态计算容器中，这些容器是事件触发的短暂的(可能只持续一次调用，或Deployment会保留，根据运行负载自动调节运行实例数量)，并且完全由第三方管理(也许就是”FaaS”此名称的来源 )AWS Lambda是目前Faas平台***的实现之一，比国内的云服务商便宜很多，看好亚马逊市值***破万亿(Apple may 打脸)。
在本文中，显然我们将重点关注后者，FaaS/Serverless。
2. 几个引申的例子
让我们考虑一个带有服务器端逻辑的传统的三层面向客户端的系统。一个很好的例子是一个典型的电子商务应用程序 - 在线宠物商店。
架构像这样：
在这个架构里，客户端可以相对不用那么智能，绝大多数的逻辑在服务端完成，授权，页面导航，查询，交易等等。
在无服务架构里，看起来会是这个样子：
二者对比中，我们可以看到一系列明显的变化：
我们去掉了原始应用程序中的身份验证逻辑，并将其替换为第三方BaaS服务(例如，Auth0)
我们允许客户端直接访问我们的数据库(用于产品列表)，该数据库本身完全由第三方(例如Google Firebase)托管。我们可能采用和服务器资源访问数据库不同的安全配置文件让客户端去访问数据库。
前两点意味着非常重要的第三点：宠物商店服务器中的一些逻辑现在位于客户端内 - 例如，跟踪用户会话，理解应用程序的UX结构，从数据库读取并将其转换为一个可用的视图等客户端正在成为单页应用程序。
我们可能希望在服务器中保留一些与UX相关的功能，例如，如果它是计算密集型或需要访问大量数据。在我们的宠物商店中，一个例子是“搜索”。而不是像原始体系结构中那样拥有一个始终运行的服务器，我们可以实现一个FaaS功能，通过API网关响应HTTP请求。客户端和服务器“搜索”功能都从同一数据库中读取产品数据。
***，我们可以把购买的实现替换成另一个独立的Faas函数，安全的原因吧，这也是由API网关给引入的。在使用FAAS时，把不同的逻辑要求，拆分成独立的部署组件是一种很常见的方法。
3. “Faas”的面纱
现在是时候深入了解FAAS的真正含义。为此，我们来看看亚马逊FaaS产品的开头描述：Lambda。
AWS Lambda允许您在不配置或管理服务器的情况下运行代码。 (1)使用Lambda，您可以运行几乎任何类型的应用程序或后端服务的代码(2)所有这些都是零管理。只需上传代码，Lambda就会负责运行所需的一切(3)以高可用性扩展实例。(4)可以设置代码以自动从其他AWS服务触发(5)或直接从任何Web或移动应用程序调用它。
详细说来：
从FaaS是运行后端代码而无需管理自己的服务器系统或应用程序。与容器和PaaS等其他现代架构趋势相比，是否存在长期存在的服务器和应用程序是一个关键的区别。
FaaS产品不需要对特定框架或库进行编码。 FaaS功能是语言和环境的常规应用程序。例如，AWS Lambda函数可以把Javascript，Python，Go，任何JVM语言(Java，Clojure，Scala等)或任何.NET语言视为“一等公民”。不过Lambda函数还可以与其部署包一起执行在另一个进程，因此实际上可以使用任何可以编译为Unix进程的语言。FaaS函数具有重要的体系结构限制，特别是在涉及状态和执行持续时间时。
部署与传统系统有很大不同，因为我们没有自己运行的服务器应用程序。在FaaS环境中，我们将功能的代码上传到FaaS提供商，提供商执行配置资源，实例VM(Container)，管理流程等所需的一切。
水平缩放完全是自动的，弹性的，并由Faas管理。如果系统需要并行处理100个请求，则Faas将处理该请求而无需你进行任何额外配置。执行函数的容器是临时的，FaaS创建和销毁它们，完全由运行时决定。最重要的是使用FaaS，云厂商可以处理所有底层资源配置和分配，而用户根本不需要集群或VM管理。
FaaS中的函数通常由提供程序定义的事件类型触发。使用AWS，此类事件包括S3(文件/对象)更新，时间(定时任务)以及消息总线的消息。
大多数Faas运营商还允许HTTP请求触发函数，在AWS中，通常通过使用API网关来实现这一点。我们在宠物商店示例中使用API网关进行“搜索”和“购买”功能。函数也可以通过平台提供的API直接调用，无论是在外部还是在同一个云环境中，但这是一种相对不常见的用法。
4. Faas需要关注的特点
有无状态
FaaS函数在本地(VM/容器实例)状态(即存储在内存中的变量中的数据或写入本地磁盘的数据)中具有很大的限制。一般情况下你确实可以这样存储，但是不能保证这种状态在多个调用中保持不变，更重要的是，你本来就不应该假设一次调用函数的状态可用于同一函数的另一次调用。因此，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个事件，您可能会看到一个实例的冷启动。另一方面，如果每小时处理一次事件，你可能会看到每个事件来时的冷启动，因为Amazon会在几分钟后退出非活动的Lambda实例。知道这一点有助于了解冷启动是否会影响集成效果，以及是否可能希望对函数实例执行“保持活动”以避免它们被回收。
冷启动需要太关注吗?这取决于应用程序的负载或流量的情况。如果你需要的是低延迟交易应用程序，那么***忘掉FaaS系统吧，无论你使用哪一种编程语言。
无论你是否认为你的应用是否存在此类问题，你***用类似生产的负载来测试性能。如果此时此刻比较烂，不要着急，FaaS供应商正在持续改进，说不定年底就满足你的要求了。
API网关
API网关是一个HTTP服务器，其中路由和负载点定义在配置中，并且每个路由与处理该路由的函数关联。当API网关收到请求后，它会找到与请求匹配的路由配置，来调用相关的FaaS函数。API网关允许从HTTP请求参数映射到FaaS函数的更简洁的输入，或者让HTTP请求原封不动得通过，FaaS函数将执行其逻辑并将结果返回给API网关，而API网关又将此结果转换为HTTP响应，并将其传递回原始调用方。
工具
关于工具成熟度的评论也适用于FaaS。 到今年(2018年)，我们已经看到了明显的改善，我们希望工具能够更好地发展。
FaaS世界中一些“开发者用户体验”好的例子值得一提。 首先是Auth0 Webtask，它非常重视开发人员用户体验。 其次是Microsoft，其Azure功能产品。 Microsoft一直将Visual Studio及其反馈循环置于其开发人员产品的最前沿，而Azure Functions也不例外。 在云触发事件的输入下，它提供的在本地调试功能的能力非常特殊。
开源势力
无服务器中开源的最常见用途是FaaS工具和框架，它提供了一些跨云提供商的工具抽象，类似工具的例子包括Claudia和Zappa。另一个例子是Apex，它允许你使用亚马逊直接支持的语言之外的语言开发Lambda函数。不过AWS自己的部署工具SAM(无服务器应用程序模型)也是开源的。
专有FaaS的主要好处之一是不必关心底层计算基础架构(机器，虚拟机，容器)。但是如果你想关注这些事情呢?也许你有一些云供应商无法满足的安全需求，或者你有一些你已经购买但不想丢弃的服务器机架。在这些场景中可以开源帮助，允许运行自己的“Serverful”FaaS平台，这个领域有很多活动。开源FaaS的最初***之一是IBM(使用OpenWhisk，现在是一个Apache项目)。Microsoft，它开源了很多Azure功能平台。许多其他自托管FaaS实现使用底层容器平台，通常是Kubernetes，在这个领域，值得探索Galactic Fog，Fission和OpenFaaS等项目。在未来的博客中，我会重点关注OpenFaas项目，该项目目前有超过10k+的Star。
5. Serverless 不是什么
因为概念太多，容易混淆，现在很多Readme都有这个环节：
和Paas平台相比
看下大神(VP Cloud Architecture Strategy at AWS)是怎么说的：
换句话说，大多数PaaS应用程序并不是为了响应事件而使整个应用程序启动或消失，而FaaS平台是。
FaaS和PaaS之间的关键运营差异是扩展。通常使用PaaS，你需要考虑如何扩展服务实例，使用FaaS应用程序，则是完全透明的。即使您将PaaS应用程序设置为自动扩展，你几乎不可能将此操作设置为单个请求的级别的扩展，举个例子，你一个服务实例，一般不会对不同的请求设置不同的实例数量，如果大量查询操作，和少量更新操作，你可能会考虑优化查询，增加缓存等，而不是在1分钟内，将你的实例扩大到100倍，因此FaaS应用程序在成本方面更加高效。
鉴于此优势，您为什么还要使用PaaS?也许***的原因是工具成熟度，基于Paas有很多行之有效的实践，Faas给了我们系统扩展一些更多的思路。
和容器相比
另一种流行的服务抽象是容器，Docker是这种技术最明显的例子。Kubernetes之类的容器托管系统越来越受欢迎，它们从操作系统级部署中抽象出各个应用程序。在这条道路上，我们看到像Amazon ECS和EKS这样的云托管容器平台(这里推荐下，灵雀云的AKS发行版)，以及Google Container Engine(Alauda Container Engine，AKE)，它们像Serverless/FaaS一样，团队完全无需管理自己的服务器主机。鉴于容器发展的势头，还是值得考虑无服务器FaaS吗?
运维
无服务器并不意味着没有运维，它可能意味着没有系统管理员，运维比服务器管理重要，它至少还意味着：监控，部署，安全性，网络，以及通常一些生产调试和系统扩展。这些问题在无服务器应用程序中仍然存在，仍然需要一个策略来处理它们。在某些方面，Ops在无服务器世界中更难，因为很多都如此新鲜。无论哪种方式，在某些时候抽象可能会泄漏，你***知道在某个地方，有一个人类系统管理员正在支持你的应用程序。
和存储过程的对比
另一个主题是无服务器FaaS是“存储过程即服务”。原文中也解释过了，但因为它实际上只是FaaS功能的一个子集，还有文章中提到的代码版本控制的问题，其他的几种开源方案不清楚，但是OpenFaas中有一个项目OpenFaas-Cloud，基于Github做了一个很棒的持续集成过程。
6. 使用Faas/Serverless的好处有哪些?
降低运营成本
无服务器是最简单的外包解决方案。你可以向云服务商付费以管理服务器，数据库甚至应用程序。基于规模经济效应：你为托管数据库支付的费用较少，因为一个供应商运行着数千个非常相似的数据库。
降低的成本来源于两方面，首先是纯粹来自与其他人共享基础设施(例如，硬件，网络)的基础设施成本。第二个是人工运维成本。
但是，这种好处与IaaS、PaaS并无太大差别，只是更省钱了。
BaaS：降低开发成本
IaaS和PaaS基于服务器或容器的商品化。而无服务器 BaaS是应用程序组件的商品化。例如：身份验证是一个很好的例子，许多应用程序编写自己的身份验证功能，这些功能通常包括注册，登录，密码管理以及与其他身份验证提供程序集成等功能。总的来说，这个逻辑在大多数应用程序中非常相似，并且已经创建了像Auth0这样的服务，以允许我们将现成的身份验证功能集成到我们的应用程序中，而无需我们自己开发它，不得不说，真的很省钱。
关于BaaS数据库，如Firebase的数据库服务。一些移动应用程序团队发现让客户端直接与服务器端数据库通信是有意义的。 BaaS数据库消除了大部分数据库管理开销，并且通常提供以无服务器应用程序所期望的模式对不同类型的用户执行适当授权的机制。
是不是有些担心安全?我想在新的云计算时代，我们都要慢慢接受这些变化。
扩容成本
但在基础设施方面，***的好处是您只需支付所需的计算费用，在AWS Lambda的情况下，AWS 为开发人员提供每月 100万的请求和 400,000 GB 的计算时间 ——无需任何费用，省去的可是真金白银!
示例：低频的请求
假设正在运行仅每分钟处理一个请求的服务器应用程序，处理每个请求需要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独有的。
交付速度和持续的验证
随着团队和产品越来越多地面向敏捷，我们希望不断尝试新事物并快速更新现有系统。虽然在持续交付的情况下进行简单的重新部署可以快速迭代稳定的项目，但是从具一个Idea到初始部署能力使我们能够以极快和低成本尝试新的实验。
前文提到的，基于FaaS的持续集成，非常***的让你持续的实验下去
虽然成本效益是无服务器最容易表达的改进，但是这种缩短的交付时间让我最兴奋。它可以实现持续实验的产品开发思维，这是我们如何在公司中交付软件的真正革命。
“绿色”计算?
在过去的几十年中，世界上数据中心的数量和规模都在大幅增加。除了建立这些中心所需的物理资源外，相关的能源需求如此之大，苹果，谷歌等都在谈论将一些数据中心托管在可再生能源附近以减少化石燃烧。
通电后的空闲，使得服务器消耗了大量的能量。
Typical servers in business and enterprise data centers deliver between 5 and 15 percent of their maximum computing output on average over the course of the year. – Forbes
这非常低效，并产生巨大的环境影响。
一方面，云基础设施可能已经帮助减少了这种影响，因为公司可以按需“购买”更多的服务器，只有当他们绝对需要时，而不是提前很长时间配置所有可能必需的服务器。然而，人们还可以争辩说，如果没有足够的容量管理，很多服务器都会被丢弃，那么配置服务器的容易程度可能会使情况变得更糟。
无论我们使用自托管服务器，IaaS还是PaaS基础架构解决方案，我们仍然会手动制定关于我们的应用程序的容量决策，这些决策通常会持续数月或数年。通常，我们对管理容量持谨慎态度，因此我们过度配置，导致刚才描述的效率低下。使用无服务器方法，我们不再自己做出这样的容量决策 - 我们让FaaS供应商为我们的实时需求提供足够的计算容量。然后，供应商可以在其客户中汇总制定自己的容量决策，就像集中供暖，而不是你自己在北方的家里烧锅炉。
