无服务器架构(Faas/Serverless)

摘要
无服务器架构(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供应商为咱们的实时需求提供足够的计算容量。而后，供应商能够在其客户中汇总制定本身的容量决策，就像集中供暖，而不是你本身在北方的家里烧锅炉。

FaaS的不足之处和用武之地，To Be Continued。

Serverless Architectures

It’s all about functional stateless microservices