资讯首页 新闻资讯 云计算测评 云服务商动态
上云无忧 > 云计算资讯  > 云计算测评 > Lambda测评:更受大型企业欢迎

Lambda测评:更受大型企业欢迎

来自: 网络|发布时间: 2020-02-06 12:38:28|浏览量:462| 评论: 0

最近一段时间,“无服务器”可以说是风头正劲。但更重要的是,这个概念并非空有炒作——自诞生以来不到五年,AWS Lambda 已经得到近半数 AWS 云服务用户的接纳。在本份统计报告中,我们跟进数千家企业的无服务器技术使用情况,旨在总结无服务器计算在现实世界中的普及水平(以及整体使用量)。


无服务器计算,强调的是一种前所未有的资源使用方式:它同样采用公有云最鲜明的按需计费模式,但交付的却是“函数”资源,而非传统的基础设施组件。顺带一提,函数是指部分特定代码段,负责根据用户请求或者其他事件的调用执行离散的业务逻辑单元。


在本份报告中,我们将主要着眼于 AWS Lambda——截至目前,它仍是现有及未来潜在用户群体当中成熟度最大、使用范围最广的无服务器平台。当然,在本报告的后续迭代中,我们也会根据情况关注其他服务供应商(例如 Google Cloud Platform 以及微软 Azure)的无服务器产品。


1)半数 AWS 用户对 Lambda 青眼有加


2020 年初,Lambda 早已不是什么小众技术。目前,我们调查的近半数 AWS 云服务客户都在使用 Lambda。从服务采用率以及按所在行业背景划分的 Lambda 使用率角度来看,我们发现 Lambda 已经全面突破了早期云原生应用以及其他小众用例。事实上,无服务器功能目前已经在采用 AWS 服务的各类企业客户当中得到广泛普及。



2)Lambda 在大型业务中的普及度较高


可能令大家意想不到的是,Lambda 广泛普及的背后,依靠的并不是那些规模较小的新兴企业。相反,我们发现 Lambda 采用率与企业基础设施环境规模之间存在着显著的关联性。无论这类环境以传统服务器、容器还是无服务器为主导,在基础设施规模最大的企业群体当中,有超过四分之三的公司已经开始使用 Lambda。



3)容器用户对 Lambda 表现出高涨的热情


 事实证明,Lambda 在那些立足 AWS 环境运行容器的企业客户中极受欢迎。截至 2020 年 1 月,在 AWS 上运行容器的企业中,近八成已经开始使用 Lambda。尽管无服务器函数与容器属于两种截然不同的环境,但出于类似的业务改进诉求,企业对二者表现出了类似的热情——例如通过对基础设施的抽象化,简化日常运营流程。在某些用例当中,用户会将 Lambda 与容器直接连通(例如使用 Lambda 函数触发 Amazon Elastic Container Service 任务);则大多数企业则以各自独立运行的方式满足不同业务需求。例如,一家企业可能将大部分应用程序运行在其容器集群当中,同时将那些突发性、仅需要短期运行的任务(例如付款处理)交由无服务器函数打理。



4)Amazon SQS 与 DynamoDB:Lambda 的好伙伴


Lambda 用户可以通过多种技术选项,将各类函数与基础设施乃至应用程序组件进行对接。在被触发之后,函数往往会将产生的数据发送至消息队列,再由消息队列进一步将数据路由至其他 Lambda 函数、基于服务器的应用程序或者云服务处。消息队列能够帮助组织获取无服务器服务提供的“按需计费”模式。各类无服务器函数可通过消息队列进行异步调用,这就打破了只能由一项函数调用另一项函数、并在等待响应的过程中长期闲置(这会显著增加计费时长)的困境。另外,由于函数具有临时性与无状态等特征,因此通常可以面向独立的持久数据存储执行读取或写入。


在包含 Lambda 函数的请求当中,Amazon DynamoDB 成为调用或查询比例最高的配套服务选项。很明显,这是一套云托管型自动规模伸缩数据存储方案,较低的延迟水平配合键值 / 文档存储机制天然适合与 Lambda 函数的协同需求。在 Lambda 用例当中,SQL 数据库(包括 Amazon RDS 实例以及其他企业自主管理的数据库)与 Amazon S3 则成为第二及第三大高人气数据存储选项。Amazon SQS(简单队列服务)则成为 Lambda 请求中的首选消息队列方案,紧随其后的是 Amazon Kinesis 与 Amazon SNS(简单通知服务)。



5)Node.js 与 Python 在 Lambda 用户中占据主导地位


在 Lambda 用户群体之内,我们还在编程语言与框架方向上找到两大领先方案选项:Python 与 JavaScript(通过 Node.js)。在目前已经部署的全部 Lambda 服务当中,有 47% 运行有 Python 代码,另有 39% 运行着 Node.js 应用程序。其中 Python 3 的普及度又比 Python 2(已经于 2020 年 1 月停止支持)高一倍。


Python 与 Node.js Lambda 运行时的广泛普及,反映出应用程序开发领域的最新趋势以及 Lambda 服务自身的前进方向。AWS 于 2014 年首次发布 Lambda 预览版本,而 Node.js 则成为首个受到支持的运行时。在接下来的 2015 年中,Java 与 Python 支持也陆续上线。在 2018 年的最新一轮迭代中,Lambda 又迎来对 C#(通过.NET Core)、Go 以及 Ruby 的支持。



6)函数的中位数运行时长为 800 毫秒


在全部调用当中,Lambda 函数的中位数运行时长为 800 毫秒,但持续时长也呈现出明显的长尾分布倾向。有四分之一的 Lambda 函数平均执行时间超过 3 秒,12% 的函数甚至拥有 10 秒甚至更长的时间周期。我们之所以高度关注某些特定 Lambda 函数的长时间运行情况,是因为这不仅会直接影响到应用程序的性能表现,同时也决定着云资源使用成本。Lambda 的定价基于“GB- 秒”这一计算单位,即分配给特定函数的内存乘以调用所持续的时长。



进一步关注函数持续时长分布,可以发现近五分之一的函数会在 100 毫秒之内执行完毕,而且约三分之一的函数会在 400 毫秒内结束。



7)半数 Lambda 函数仅具有最低内存容量


如上所述,Lambda 函数的调用成本由函数持续时长与内存占用量相乘而计算得出。因此,采用 Lambda 服务的企业当然会尽可能限制内存分配量(这是一项可配置选项,且控制难度远低于函数持续时长)。实际上,有 47% 的函数以 128 MB 最低内存容量方式运行。更重要的是,虽然 AWS 允许用户为每项函数分配最高 3008 MB 内存,但只有 14% 的函数拥有超过 512 MB 的内存分配量。



8)三分之二的预定义超时低于 1 分钟


每项 Lambda 函数都拥有一条可配置的超时定义,范围在 1 秒到 15 分钟之间,其上限代表着 Lambda 调用所允许的最长持续时间。大部分函数匹配的超时都非常短暂——根据本次调查,三分之二的超时配置不超过 60 秒(创建函数时的默认超时为 3 秒)。


之所以建议使用较短的超时配置,是因为函数闲置既会显著增加云服务成本,也不符合 Lambda 应用架构所通常强调的快速响应理念。用户通常会选择 Amazon API Gateway 在 Lambda 函数之前提供 REST 接口,其最大超时设置为 29 秒。因此,即使 Lambda 成功完成了任务,API 网关后的一切 Lambda 函数也需要经过 29 秒才会被判定为出现响应超时错误。虽然这一保障措施已经相当安全,但大部分用户会为函数设置最大允许超时量——以往上限为 300 秒(截至 2018 年 10 月),目前的最新上限已经提升至 900 秒。



9)只有 4% 的函数具有预定义并发限制


在默认情况下,Lambda 客户只能在特定区域内为全部函数保留 1000 条并发执行空间。用户可以为每项函数设置并发限制,相当于为其指定总并发池中的一定并发资源比例。如果该项函数超出并发限制量,将无法进一步占用并发资源。


目前,虽然大多数客户都很清楚并发限制选项,但只有 4.2% 的函数实际使用到这项限制功能。但在另一方面,有 88.6% 的 Lambda 客户在业务环境中至少对一项函数做出了并发限制。事实证明,具有并发限制的函数确实极有可能发生并发量激增情况。在为期 5 天的评估窗口当中,有 8.3% 的并发限制函数至少触发过一次限制功能;相比之下,按区域限制(而非按函数限制)的函数中仅有 0.3% 触发过并发限制功能。



参考链接:

https://www.datadoghq.com/state-of-serverless/

更多【云计算测评】相关文章

有话要说

全部评论

暂无评论
官方微信
联系客服
400-826-7010
7x24小时
分享
  • QQ好友
  • QQ空间
  • 微信
  • 微博
返回顶部