无服务器计算是一种执行模型, 云服务提供商 通过资源的动态分配,负责执行部分代码。在此模型中,客户只需为实际使用的资源量付费。
代码通常 运行在无状态容器 中,可以由各种事件触发,包括 HTTP 请求、数据库事件、队列服务、监控警报、文件上传等。
一、那么为什么选择无服务器模型呢?
也称为“功能即服务”或 FaaS, 无服务器模型可以成为 IT 团队传统上遇到的几个问题的理想解决方案。当应用程序在专有服务器上运行并且公司负责提供和管理底层资源时,它会发现自己:
- 必须 为服务器的运行付费 ,即使实际上没有请求被提供。
- 负责服务器和所有底层资源的正常运行时间和 维护。
- 必须 管理服务器安全更新。
- 随着使用量的增加或减少,必须相应地 调整服务器的大小。
在没有专门管理服务器的运营团队的小公司中,以及在拥有专用资源的大公司中, 执行这些操作需要时间远离核心活动:构建和维护应用程序。这正是无服务器计算的用武之地。
二、启用无服务器架构的好处
无服务器架构正变得越来越流行。事实上,根据 MarketsandMarkets 进行的研究, 预计该行业的收入将从 2020 年的估计 76 亿美元增加到 2025 年的估计 211 亿美元,复合年增长率 (CAGR) 为 22.7%。采用无服务器架构的这种增长归因于新开发模式带来的一系列优势。他们来了!
1、即付即用
与基础设施即服务 (IaaS) 模型不同,无论其实际使用情况如何,都需要租用硬件资源, 功能即服务 (FaaS) 模型基于即用即付费率: 当事件调用函数时, 在执行函数严格必要的时间内支付资产。
只为实际使用的服务的价值付费可以让团队 专注于产品的开发 及其独特的功能,而不是关注服务的成本或实施,这些服务实际上只是为了支持主要功能而集成的。
2、可扩展性
可扩展性是快速发展的公司的一个关键因素,因为 需要垂直或水平的基础设施扩展。一项颇具挑战性的任务,通常需要大量的时间和精力,并 相应增加运营成本。
无服务器环境消除了这些限制,允许公司 从小处着手,然后随着时间的推移支持其增长,而不会中断服务,也无需实施代价高昂的计划外变更。
3、灵活性和适应性
由于计算资源的供应和管理被转移到云提供商,公司能够快速采用新技术,使他们能够快速有效地响应业务和市场需求, 而不必担心基础设施升级 和所有相关成本。
4、高可用性和容错性
在当今的公司中,众所周知,业务严重依赖 IT:这正是 IT 服务必须保证高可用性的原因。云提供商提供精心设计的全球基础架构,能够保证客户工作负载的可用性和弹性。
5、业务连续性和灾难恢复
今天,业务连续性是公司的一个关键方面,因此,活动必须得到可靠的灾难恢复战略和计划的支持。无服务器解决方案的云提供商提供 高级功能,有助于自动恢复应用程序和底层系统 以应对任何类型的灾难(自然灾害、网络攻击、硬件缺陷等)。
三、无服务器架构:需要考虑的关键方面
尽管采用无服务器架构的优势显而易见且众多,但 仍有一个缺点需要考虑。因此,让我们来看看在决定采用这种新的开发模式时要牢记的挑战和关键方面。
1、供应商锁定
对于无服务器架构,在设计和迁移阶段必须考虑供应商锁定问题。通常, 这些类型的架构在各个供应商的“围墙花园”中更容易开发。
这正是为什么必须从一开始就清楚地了解 从一个供应商过渡到另一个供应商时可能出现的关键问题:
- 并非所有供应商的运行时和编程语言 支持都是统一的,即使他们正在慢慢调整
- 缺乏 用于描述 触发无服务器代码执行的事件的标准化格式
- 一些平台使用 专有或内部开发的工具 进行打包和部署
为了缓解这些问题,负责促进云原生实现开放标准传播的云原生计算基金会维护 了一个观察站, 以跟踪 按类别组织的无服务器产品。CNCF 支持开发开放标准和解决方案,例如 CloudEvents (事件数据的标准化格式)和 Knative等开放产品,用于在云端和本地实施 FaaS 服务。
2、估算成本的挑战
由于 FaaS 服务的定价模式纯粹是按使用付费,因此很难估算成本。在没有固定费用的情况下, 需要在必要时支付资源,因此, 当应用程序实施到生产中时,公司经常会遇到令人讨厌的意外。
分析不同供应商的报价是个好主意 。有时,您实际上可能会在成本以及可用免费层的数量方面遇到显着差异。
一个有趣的估算工具是 无服务器成本计算器,它允许您 模拟最流行的平台的成本, 例如 AWS Lambda、Azure Functions、Google Cloud Functions 和 IBM OpenWhisk。
3、冷启动
在无服务器范式中,我们已经看到资源只有在实际使用时才会付费。这正是云供应商为了使这种模式在经济上可持续, 在实际不使用资源时停用资源的原因。
这样做的缺点是,有时可能会出现 激活延迟(冷启动)。冷启动是指从调用函数到实例激活和响应请求所需的时间之间的延迟。
有几个因素会 影响冷启动问题, 包括:
- 使用的编程语言
- 已分配和可用的资源
- 依赖项的数量和整体应用程序的复杂性
因此,重要的是要处理每个参数以 优化函数的启动时间,采用供应商推荐的特定技术,例如 AWS 用于 Lambda 函数或 Google Cloud Platform 用于 Cloud Run 函数。
4、安全风险
虽然所有云提供商都提供了先进的安全系统,但应该记住,为多个客户提供服务的服务器 自然 比专用本地服务器 更容易受到安全问题的影响。
这是由于 更大的事件源集, 这反过来又增加了潜在的攻击面。一些最常见的风险是由于依赖从第三方软件(如开源包和库)获得的无服务器功能以及分布式拒绝服务 (DDoS) 攻击而导致的风险。
四、结论
尽管在采用无服务器架构时可能会遇到各种挑战,但在大多数情况下, 所获得的优势超过了关键问题的风险。
此外, 通过谨慎选择供应商技术以避免锁定或实施前面描述的选项以减轻冷启动等措施,一些问题是显而易见的并且很容易解决。