无服务器架构（Faas/Serverless）是软件架构领域的热门话题。 AWS，Google Cloud和Azure：他们在服务器上投入了大量资金，并且看过很多文章，书籍，开源项目，专门讨论Faas/Serverless的会议。但是没有服务器是什么，为什么（或不是）值得考虑？
1.什么是无服务器？
建筑无服务器是设计应用，包括服务的方式“后端 - 作为一种一即服务”（巴斯），第三方和/或自定义代码的平台（FAAS）上运行的临时容器运行。这种类型的架构消除了大多数始终点亮的传统服务器需求。这可以显着降低项目在线准备的运营成本，复杂性和时间，但代价是更多地依赖于提供商和相对不成熟的支持服务。
首先，没有人清楚知道它是什么服务器。它包含两个不同但相关的领域：
没有服务器可以描述“在富云客户端+第三个服务和托管”的应用程序。这些“富客户端”应用程序通常是在云或SSO服务（Auth0，AWS Cognito等）中使用大型数据库的移动应用程序。这些类型的服务之前被描述为“后端即服务”。
没有服务器也可以指逻辑服务器端仍然由应用程序开发人员编写的，但与传统架构不同，电脑上运行的容器没有状态由事件（触发可能仅持续一次或实施）自动保持调整运行负载运行实例的数量），并且由第三方（也许是名为“FAAS”）的源全面管理。 AWS LAMBDA是当前FAAS平台，这是比国内服务商的云更便宜的最流行的实现方式之一。许多看好亚马逊的市值是第一个突破万亿（苹果可能会面临）。
在本文中，很明显我们将关注最新的FaaS/Serverless。2.几个扩展的例子
考虑一个传统的三层面向客户的系统，它具有服务器端逻辑。一个很好的例子是典型的电子商务应用程序：在线宠物商店。
架构看起来像这样：
在这种体系结构中，客户端可能相对不太智能，并且大多数逻辑在服务器端完成，授权，页面导航，查询，事务等。
在没有服务的架构中，它看起来像这样：
相比之下，我们可以看到一系列明显的变化：
我们删除了原始应用程序的身份验证逻辑，并将其替换为第三方BaaS服务（例如，Auth0）
我们允许客户直接访问我们的数据库（以获取产品列表），而这些产品又完全由第三方（例如Google Firebase）托管。我们可以使用不同的安全配置文件到服务器资源来访问数据库以允许客户端访问数据库。
前两点意味着第三点非常重要：宠物商店服务器中的部分逻辑现在位于客户端，例如，用户会话的后续跟踪，对应用程序的UX结构的理解，读取数据库并转换为使用。诸如视图之类的客户端正在成为单页面应用程序。
我们可能希望在服务器上保留一些与UX相关的功能，例如，如果它是计算密集型或需要访问大量数据。在我们的宠物商店中，一个例子是“搜索”。我们可以实现一个FaaS功能，通过API网关响应HTTP请求，而不是像在原始架构中那样始终打开服务器。客户端和服务器的“搜索”功能从同一数据库中读取产品数据。
最后，出于安全原因，我们可以使用另一个独立于Faas的函数替换购买的实现，这也是API网关引入的。使用FAAS时，常见的方法是将不同的逻辑需求划分为单独的实现组件。
3.“faas”的面纱。
是时候深入研究FAAS的真正含义了。为此，让我们来看看Amazon 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（容器），管理进程等。
水平刻度是完全自动的，灵活的并由Faas管理。如果系统需要并行处理100个请求，Faas将处理请求而无需任何其他配置。执行功能的容器是临时的，FaaS在运行时完全创建并销毁它们。最重要的是，通过FaaS，云提供商可以处理所有底层资源的配置和分配，而无需用户管理集群或虚拟机。
FaaS中的功能通常由提供者定义的事件类型激活。使用AWS，此类事件包括对S3（文件/对象），时间（计划任务）和消息总线消息的更新。
大多数Faas运营商还允许HTTP请求激活功能，这些功能通常通过API网关在AWS中执行。我们在宠物商店的例子中使用API网关进行“搜索”和“购买”功能。这些功能也可以通过平台提供的API直接调用，无论是在外部还是在同一个云环境中，但这是一种相对罕见的用途。
4.法特必须注意的特征。
状态
FaaS函数在本地状态（VM实例/容器）中具有显着限制（即，存储在内存中的变量中的数据或写入本地磁盘的数据）。通常，您可以以这种方式存储，但无法保证此状态在多个调用中保持不变。更重要的是，您不应该假设调用函数的状态可以用于对同一函数的另一个调用。因此，FaaS函数通常被描述为无状态，或者更准确地说，必须持久化的FaaS函数的任何状态必须在FaaS函数的实例之外进行。
对于没有自然状态的FaaS函数，即从输入到输出提供纯函数转换的函数，这是无关紧要的。但对于州而言，这可能很麻烦，而且之前分布的限制现在完全相同。这种面向状态的函数通常使用数据库，缓存（例如Redis）或网络上的文件/对象的存储（例如S3）来存储所有请求的状态。执行时间
FaaS功能通常受限于允许每个呼叫运行的时间。目前，AWS Lambda函数会在事件结束前以“等待时间”最多五分钟响应事件。 Microsoft Azure和Google Cloud Functions具有类似的限制。这意味着长期的任务，某些类别不适合FAAS，除非重新设计架构，您需要创建协调不同的多FAAS功能，在传统的环境，可以有长期执行任务的协调。
开始延迟和“冷启动”
FaaS平台需要一些时间在每个事件之前初始化一个函数实例。不同的功能，它的启动延迟也可以从几毫秒到几秒显着变化，具体取决于许多因素，特别是AWS Lambda作为示例。
初始化函数LAMBDA可以是一个“热启动”或“冷启动”（创建容器的新实例）（使用lambda的功能先前生成的容器），以及所造成的冷开始的延迟这一定是我们关注的问题。
冷启动的等待时间取决于很多因素：语言开发，使用的库，代码量，拉姆达自己的环境功能的配置，如果你需要连接到VPC资源，等等。这些方面由开发人员控制，并且通过这些位置的优化可以减少冷启动的一部分的启动延迟。
冷启动的起始频率也是可调的。例如，如果一个函数每秒处理10个事件并且每个事件需要50毫秒来处理，您可能会看到每100,000-200,000个事件的冷启动。在另一方面，如果你处理事件每隔一小时，你可能会看到一个冷启动每个事件，如亚马逊将拉姆达实例在几分钟内不起作用。了解这一点有助于了解冷启动是否会影响集成，以及是否可能希望在功能实例中“保持活动”以防止其被回收。
冷启动是否有必要过于集中？它取决于应用程序的负载或流量。如果您需要低延迟协商应用程序，最好忘记FaaS系统，无论您使用何种编程语言。
无论您认为您的应用程序是否存在此类问题，您最好使用类似于生产的负载来测试性能。如果此时不好，请不要担心，FaaS提供商会不断改进，您可以在年底满足其要求。
网关API
API网关是HTTP服务器，其中路由和加载点在配置中定义，并且每个路由与处理路由的功能相关联。当API网关收到请求时，它将找到与调用相关FaaS函数的请求匹配的路由配置。 API网关允许更简洁地将HTTP请求参数输入到FaaS函数，或允许HTTP请求完整传递。 FaaS函数将执行其逻辑并将结果返回给API网关，后者又将结果转换为HTTP响应并将其返回给原始调用者。工具
关于该工具成熟度的评论也适用于FaaS。对于今年（2018年），我们已经看到了重大改进，我们希望这些工具能够得到更好的发展。
值得一提的是FaaS世界中“用户体验开发者”的一些很好的例子。第一个是Auth0 Webtask，它非常重视开发人员的经验。其次是微软，其特有的Azure产品。 Microsoft始终将Visual Studio及其反馈循环置于其开发人员产品的最前沿，Azure Functions也不例外。在云中触发事件的输入下，提供本地调试功能的能力非常特殊。
开源电源
服务器上最常见的开源使用是FaaS工具和框架，它们提供了来自云提供商的一些工具抽象。类似工具的一些例子是Claudia和Zappa。另一个例子是Apex，它允许您使用其他语言开发Lambda函数，以及与Amazon直接兼容的函数。但是，AWS SAM自己的部署工具（无服务器应用程序模型）也是开源的。
FaaS所有者的主要好处之一是他们不必担心底层IT基础设施（机器，虚拟机，容器）。但是如果你想关注这些事情会发生什么？也许您有一些云提供商无法满足的安全需求，或者您已购买但不想离开的服务器机架。这些场景中的开源帮助允许您运行自己的FaaS平台“Serverful”，该平台在该领域有很多活动。最初的开源FaaS领导者之一是IBM（使用OpenWhisk，现在是一个Apache项目）。 Microsoft，打开许多功能Azure平台。许多其他自供电FaaS实现使用底层容器平台，通常是Kubernetes，在这个领域，值得探索Galactic Fog，Fission和OpenFaaS等项目。在未来的博客中，我将重点关注OpenFaas项目，该项目目前拥有超过10k +的明星。
5.什么是无服务器？
因为概念太多而且容易混淆，很多读者现在都有这个链接：
与Paas平台相比。
VP云架构战略在AWS中所说的内容：
换句话说，大多数PaaS应用程序不响应事件而启动或消失整个应用程序，并且FaaS平台是。
FaaS和PaaS之间的关键操作差异是扩展。通常，在使用PaaS时，您应该考虑如何使用FaaS应用程序扩展服务实例是完全透明的。即使您将PaaS应用程序设置为自动扩展，也几乎不可能将此操作设置为单个请求级别的扩展。例如，如果您有服务实例，则通常不会为不同的请求设置不同数量的实例。通过大量查询操作和少量更新操作，您可以考虑优化查询，添加缓存等。而不是在1分钟内将其实例扩展到100次，因此FaaS应用程序更有利可图。鉴于此优势，您为什么要使用PaaS？也许主要原因是该工具的成熟。基于Paas的成熟实践，Faas为我们提供了更多扩展系统的想法。
与容器相比
另一种流行的服务抽象是容器，多克尔是这项技术的最明显的例子。诸如Kubernetes之类的容器托管系统正变得越来越流行，从操作系统级别的实现中抽象出各个应用程序。通过这种方式，我们可以看到平台上放置集装箱云如Amazon ECS和EKS（这里建议，Lingque云的AKS分布）和电动机收容谷歌（Alauda集装箱引擎，AKE），这就像无服务器/像那个FaaS，团队根本不需要管理自己的主机服务器。鉴于容器开发的势头，在没有服务器的情况下考虑FaaS是否值得？
操作和维护
没有服务器并不意味着不存在操作和维护，可能意味着有一个系统管理员和操作和维护比服务器的管理更为重要。它还至少意味着：监控，实施，安全，网络，以及一般的生产调试和系统扩展。这些问题在无服务器应用程序中仍然存在，并且仍然需要策略来管理它们。不知何故，Ops在无服务器的世界中更加困难，因为许多都是非常新的。无论哪种方式，在某些时候，抽象都可能泄漏，你最好知道某个地方，人类系统管理员支持你的应用程序。
中文
电话咨询
微信咨询
公众号
