Serverless核心概念在早期,术语无服务器
是指依赖于第三方应用程序或服务来管理服务器端逻辑的应用程序。 此类应用程序是基于云的数据库(如Google Firebase)或身份验证服务(如Auth0或AWS Cognito)。 它们被称为后端即服务(BaaS)服务。 但无服务器也意味着开发为事件触发的代码,并且在无状态计算容器中执行。 这种架构通常称为功能即服务(FaaS)。 让我们更详细地看一下每种类型的服务。
FaaS(Function as a service 函数作为一种服务) 本质上是一个小程序或函数,它执行由事件触发的小任务,而不像单个应用程序那样做很多事情。因此,在FaaS架构中,我们将应用程序分解为小型,自包含的程序或功能,而不是在PaaS上运行并执行多种功能的单一应用程序。例如,API中的每个端点都可以是一个单独的函数,我们可以按需运行这些函数,而不是全时运行应用程序。
常见的方法是在多层体系结构中编写API,类似于三层体系结构,其中代码分解为表示,业务和数据层。所有路由都将在业务层中触发相同的处理函数,并且数据将被处理并发送到数据层,数据层可以是数据库或文件。
在FaaS系统中,预计函数将在几毫秒内启动,以便处理各个请求。相比之下,在PaaS系统中,通常有一个应用程序线程可以长时间运行,并处理多个请求。 FaaS服务按功能的每个执行时间收费,而PaaS服务按服务器应用程序运行的线程的每个运行时间收费。
在微服务架构中,应用程序松散耦合,细粒度和轻量级。微服务诞生的原因是将整体应用程序分解为小型服务,以便可以独立开发,管理和扩展。但FaaS更进一步,将事情分解为甚至更小的称为功能的单位。
趋势非常明确:工作单位越来越小。
OpenFaaS支持Windows和Linux上的Node.js,Python,GO和C#。
我们可以通过云,本地笔记本电脑或内部部署服务器进行设置。我们可以为几乎所有东西编写函数 - 这就是OpenFaas声称的内容。 OpenFaaS是用Golang编写的。它允许通过HTTP / HTTPS请求的事件。
Fission是无服务器架构的另一个开源版本 - 底层技术是Kubernetes和Docker容器,可以部署在云和内部部署基础架构上。它被设计为一组微服务,其组件是控制器,路由器和池管理器。路由器管理HTTP请求,控制器管理功能,事件触发器和环境映像,池管理器管理容器池并将功能加载到这些容器中。这些函数是用Python编写的。
无服务器优势使用无服务器架构有许多优缺点。
为什么有人会使用无服务器架构(如AWS Lambda或OpenWhiz)构建应用程序?
主要原因是应用程序的执行效率,扩展速度,以及最重要的成本。让我们看一些重要的专业人士,然后继续前进。
1. 更快的上市时间我们可以更快地将应用程序推向市场,因为OPS变得更加简单,并且将帮助开发人员专注于他们的开发。 OPS团队无需编写可以处理扩展或担心底层基础架构的代码。
此外,团队可以在第三方集成的帮助下更快地构建应用程序,例如OAuth,Twitter和Maps等API服务。
2.高度可扩展性每家公司都希望他们的应用程序能够更好地运行,零停机时间,并且随着流量的增加而快速,轻松地扩展,但是通过单一的应用程序开发,它可能变得非常困难。随着应用程序负载的增加,Ops团队必须在扩展底层基础架构时保持警惕。由于交通量的增加,停机时间浪费了大量的时间和金钱。
但无服务器计算具有高度可扩展性,可以在几秒钟内对应用程序进行缩放和缩放。
3.低成本在无服务器计算中,开发人员仅在功能运行时付费,与IaaS和PaaS不同,IaaS和PaaS为每台服务器24/7收费。这对于拥有庞大的应用程序,API或微服务设置的公司来说非常有用,这些应用程序,API或微服务目前全天候运行并且100%的时间使用资源,无论是否需要。但是对于无服务器,我们可以按需执行功能并共享资源,而不是全天候运行应用程序,因此我们可以大大减少空闲时间,并使应用程序运行得更快。
4.延迟和地理定位
改进应用程序的可扩展性取决于三个因素:用户数量,用户位置和网络延迟。在当今世界,应用程序拥有全球受众,这可能会增加延迟。但是无服务器平台可以大大减轻延迟的危险。使用无服务器时,实例化容器以在每个事件调用时运行函数,并且可以在用户的地理区域附近创建此容器,这将自动提高应用程序的性能。
让我们看一下无服务器功能的缺点
1.复杂性增加我们使用应用程序越精细,它就越复杂。每个函数的代码可能会变得更简单,但整个应用程序将变得更加复杂。比如说,我们将应用程序分解为10个不同的微服务。我们必须管理10个不同的应用程序,而在单个应用程序中,它只是一个必须管理的应用程序。
2.缺乏工具支持 假设我们将单片应用程序分解为50种不同的功能。仍然有各种各样的流程和工具来管理,记录,监视和部署整体应用程序。由于无服务器是市场上的新产品,因此监控或记录运行几秒钟的应用程序是有限的并且具有挑战性,但是随着时间的推移,将会有许多有效的方法来实现这一点。
3. 与体系结构的复杂性很难决定函数的粒度,并且评估,实现和测试以检查我们的首选项是耗时的。
4. 管理太多功能会很麻烦,同时忽略粒度会导致我们设置迷你巨石。
5.实施中的缺点无服务器的最大挑战是集成测试难。
我们将为应用程序编写许多函数,但是如何将它们集成到应用程序中?当然,在此之前,我们如何测试它们如何有效地协同工作?由于无服务器是新的并且仍在成熟,通过测试添加的选项仍然有限。但是我们将在以后的章节中介绍部署和测试的几个方面。
无服务器DevOps的DevOps是另一个流行语很长一段时间。
与无服务器一样,DevOps也是一个令人困惑的术语。很多人对DevOps有很多不同的看法。有人说DevOps只是工具,有些人认为DevOps包含一些流程 - 甚至IaaS和PaaS也属于DevOps的范畴。根据我的理解,DevOps是工具,流程和反馈的协作。它们齐头并进,以成功实施DevOps。但为什么我们在这里谈论DevOps?简而言之,因为我们需要DevOps才能顺利过渡到生产,记录或监控无服务器功能,并在它们到达用户之前对其进行测试。
借助DevOps功能,我将介绍AWS Lambda函数,Azure功能,Google功能和OpenWhiz的版本控制,持续集成,持续部署,监控和日志记录。版本控制是我们对代码进行版本化的过程,以便我们可以对其进行分支,打包,部署和回滚到以前的版本。持续集成是开发人员使用自动构建将代码集成在一起以在早期检测和缓解问题的实践。持续部署基本上是一个总线或管道,其中代码使用自动化测试不断改进,然后部署到环境中。该管道平稳地向生产方向移动,只需极少的人工干预。