为什么选择无服务器模型？

作者 | SparkFabrik Team

译者 | 王强

策划 | 褚杏娟

无服务器计算是一种执行模型，其中云服务提供商将资源动态分配给负责执行的部分代码。在此模型中，客户只需为实际使用的资源付费。

代码通常运行在无状态容器中，可以由各种事件触发，如 HTTP 请求、数据库事件、队列服务、监控警报、文件上传等。那么为什么选择无服务器模型呢？

无服务器模型也称为“函数即服务（FaaS）”，可以为 IT 团队解决遇到的几个传统问题。当应用程序运行在公司专有服务器上，并且公司需要负责提供和管理底层资源时，公司会发现：

• 必须为服务器的运维付费，即使实际上没有服务时也如此。

• 负责服务器和所有底层资源的正常运行和维护。

• 必须维护服务器安全和更新。

• 随着使用量的增加或减少，必须相应地调整服务器的规模。

在没有专门管理服务器的小公司中以及在拥有专用资源的大公司中，这些运维工作都需要花费很多时间，并占用构建和维护应用程序等核心活动的资源。解决这些问题正是无服务器计算诞生的意义所在。

选择无服务器架构的好处

无服务器架构正变得越来越流行。事实上，根据 MarketsandMarkets 的研究，该行业的收入预计将从 2020 年的约 76 亿美元增加到 2025 年的约 211 亿美元，复合年增长率（CAGR）为 22.7%。无服务器架构采用率的增长归因于新开发模式带来的一系列优势。

即付即用

与基础设施即服务（IaaS）模型（无论其实际使用情况如何，都需要租用硬件资源）不同，函数即服务（FaaS）模型基于“即用即付”：当事件调用函数时，只在执行函数所必要的严格时间内支付资源使用费。

只为实际使用的服务价值付费，可以让团队专注于产品及其独特功能的开发，而非服务成本或实现。事实上，这些服务只是为了支持主要功能而集成的。

可扩展性

可扩展性是公司快速发展的一个关键因素，因为它们需要垂直或水平地扩展基础设施。这是一项颇具挑战性的任务，通常需要大量的时间和精力，同时运维成本也会相应增加。

无服务器环境消除了这些限制，允许公司以较小的规模启动，然后随着时间的推移支持其增长，期间不会中断服务，计划变更时也无需付出高昂的代价。

灵活性和适应性

计算资源的供应和管理职责转移到了云厂商身上，公司就能够快速采用新技术，使其可以快速、有效地响应业务和市场需求，而不必担心基础设施升级问题和所有相关成本。

高可用性和容错性

众所周知，当今的公司业务严重依赖 IT，这也为什么是 IT 服务必须保证高可用性。云厂商提供了精心设计的全球基础架构，能够保证客户负载的可用性和弹性。

业务连续性和灾难恢复

如今，业务连续性是公司关心的一个关键方面，因此各项活动必须有可靠的灾难恢复战略和计划支持。提供无服务器解决方案的云厂商提供了很多高级功能，有助于自动恢复应用程序和底层系统应对任何类型的灾难（自然灾害、网络攻击、硬件缺陷等）。

无服务器架构：需要考虑的关键方面

尽管采用无服务器架构的优势众多，但仍有一些问题需要考虑。我们来看看在决定采用这种新的开发模式时要牢记的关键挑战。

供应商锁定

对于无服务器架构，在设计和迁移阶段必须考虑供应商锁定问题。通常，这些类型的架构在各个供应商的“花园围墙”中更容易开发。

这正是为什么公司必须从一开始就清楚地了解从一个供应商过渡到另一个供应商时可能出现的关键问题：

• 并非所有供应商的运行时和编程语言支持都是统一的，他们还会慢慢调整这些内容。

• 业界缺乏用于描述触发无服务器代码执行的事件的标准化格式。

• 一些平台使用专有或内部开发的工具进行打包和部署。

为了缓解这些问题，负责促进云原生实施开放标准传播的云原生计算基金会（CNCF）维护了一个观察站，来跟踪这些按组织分类的无服务器产品。CNCF 支持开发、开放标准和解决方案，例如用于在云端和本地实施 FaaS 服务的 CloudEvents（事件数据的标准化格式）和 Knative 等。

估算成本的挑战

由于 FaaS 服务的定价模式是按使用付费，因此很难估算成本。在没有固定费用的情况下，公司需要在必要时支付资源使用费，因此当应用程序实施到生产环境中时，公司经常会遇到令人讨厌的意外。

分析不同供应商的报价是一个好主意。公司实际上可能会发现，不同厂商在成本、免费可用资源等方面有着显著的差异。

这里有一个有趣的估算工具是无服务器成本计算器，它可以模拟计算一些最流行平台的使用成本，例如 AWS Lambda、Azure Functions、Google Cloud Functions 和 IBM OpenWhisk。

冷启动

在无服务器范式中，资源只有在实际使用时才会被计费。出于经济性考虑，在企业实际不使用资源时，云厂商便会将资源停掉。如此一来，有时可能会出现激活延迟（冷启动）。冷启动是指从调用函数到实例激活和响应请求所需的时间之间的延迟。以下为会影响冷启动问题的三个因素：

• 使用的编程语言

• 已分配和可用的资源

• 依赖项的数量和整体应用程序的复杂性

因此，处理设计到的每个参数、优化函数启动时间是非常重要的。企业可以采用云厂商推荐的特定技术，例如 AWS 用于 Lambda 函数的技术，或 Google Cloud Platform 用于 Cloud Run 函数的技术。

安全风险

虽然所有云厂商都提供了先进的安全系统，但要知道，为多个客户提供服务的服务器自然比专用本地服务器更容易受到安全问题的影响。这是由于存在更大的事件源集，同时也增加了潜在的攻击面。一些常见的风险是由于依赖从第三方软件（如开源包和库）获得的无服务器函数和分布式拒绝服务（DDoS）攻击导致的。

总   结

尽管在采用无服务器架构时可能会遇到各种挑战，但在大多数情况下，使用带来的收益超过了关键问题带来的风险。此外，谨慎选择供应商以避免被锁定、实施前文描述的各种措施来减轻冷启动等，可以很容易地发现和解决一些问题。

原文链接：

https://blog.sparkfabrik.com/en/serverless-architecture-pros-and-cons

点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！

今日好文推荐

俄罗斯或断开全球互联网引发关注；谷歌云业务支持部门裁员；工信部：不得要求用户不下载App就不给看全文 | Q资讯

Oracle等科技巨头对俄罗斯祭出“极限制裁”，我们能从中获得什么启示？

兼容 VS Code 插件！阿里&蚂蚁联合开源国内首个强定制 IDE 研发框架 OpenSumi

亚马逊发文力捧Rust ，Go 技术负责人：别“拉踩”我们！

点个在看少个 bug 👇