无服务器并不是物理上没有服务器。 这不是容器杀手，也不是昙花一现的趋势。 这是在云中构建系统的新方法。 今天的文章我们将介绍Serverless应用程序的架构，让我们看看Serverless服务提供商和开源项目扮演什么角色。 最后说一下使用Serverless的问题。
我想编写应用程序（甚至在线商店）的服务器部分。 这可以是聊天、内容发布服务或负载平衡器。 无论如何，都会有很多令人头疼的问题：您必须准备基础设施，确定应用程序依赖项，并考虑主机操作系统。 然后，您将需要更新不影响整体其余部分操作的小组件。 好吧，我们不要忘记负载下的扩展。
如果我们采用临时容器，其中已预先安装了所需的依赖项，并且容器本身彼此隔离并与主机操作系统隔离，该怎么办？ 我们将把整体划分为微服务，每个微服务都可以独立于其他服务进行更新和扩展。 通过将代码放入这样的容器中，我可以在任何基础设施上运行它。 已经好多了。
如果您不想配置容器怎么办？ 我不想考虑扩展应用程序。 当服务负载最小时，我不想为空闲运行的容器付费。 我想写代码。 专注于业务逻辑，以光速将产品推向市场。
这些想法引导我走向无服务器计算。 在这种情况下，无服务器意味着 不是服务器的物理缺失，而是基础设施管理问题的缺失。
这个想法是将应用程序逻辑分解为独立的功能。 他们有一个事件结构。 每个函数执行一个“微任务”。 开发人员所需要做的就是将功能加载到云提供商提供的控制台中，并将它们与事件源关联起来。 代码将在自动准备的容器中按需执行，我只需为执行时间付费。
现在让我们看看应用程序开发过程会是什么样子。
从开发商方面
早些时候我们开始讨论在线商店的应用程序。 在传统方法中，系统的主要逻辑由单一应用程序执行。 即使没有负载，带有应用程序的服务器也会持续运行。
为了转向无服务器，我们将应用程序分解为微任务。 我们为每个函数编写自己的函数。 函数之间相互独立，不存储状态信息（无状态）。 它们甚至可能是用不同的语言编写的。 如果其中一个“倒下”，整个应用程序将不会停止。 应用程序架构将如下所示：
无服务器中的功能划分类似于微服务。 但一个微服务可以执行多项任务，而一个函数理想情况下应该执行一项任务。 让我们假设任务是收集统计数据并根据用户的请求显示它们。 在微服务方法中，一项任务由具有两个入口点的一个服务执行：写入和读取。 在无服务器计算中，这将是两个彼此不相关的不同功能。 例如，如果统计数据的更新频率高于下载频率，则开发人员可以节省计算资源。
Serverless 函数必须在很短的时间内（超时）执行，这是由服务提供商决定的。 例如，对于 AWS，超时为 15 分钟。 这意味着必须更改长期存在的功能才能满足要求 - 这就是无服务器与当今其他流行技术（容器和平台即服务）的区别。
我们为每个函数分配一个事件。 事件是动作的触发器：
事件
该函数执行的操作
产品图片已上传到存储库。
压缩图片并上传到目录
实体店地址已在数据库中更新
将新位置加载到地图中
客户支付货款
开始付款处理
事件可以是 HTTP 请求、流数据、消息队列等。 事件源是数据的更改或发生。 此外，功能可以由定时器触发。
架构已经制定出来，应用程序几乎变成了无服务器。 接下来我们去服务提供商。
从提供商方面
通常，无服务器计算由云服务提供商提供。 它们的名称不同：Azure Functions、AWS Lambda、Google Cloud Functions、IBM Cloud Functions。
我们将通过提供商的控制台或个人帐户使用该服务。 可以通过以下方式之一下载功能代码：
- 通过 Web 控制台在内置编辑器中编写代码，
- 下载包含代码的存档，
- 使用公共或私人 git 存储库。
这里我们设置调用该函数的事件。 对于不同的提供商，事件集可能不同。
提供商在其基础设施上构建并自动化了功能即服务 (FaaS) 系统：
- 函数代码最终存储在提供者端。
- 当事件发生时，已准备好环境的容器会自动部署到服务器上。 每个函数实例都有自己独立的容器。
- 该函数从存储中发送到容器，进行计算并返回结果。
- 并行事件的数量正在增加——容器的数量也在增加。 系统自动缩放。 如果用户不访问该功能，该功能将处于非活动状态。
- 提供者为容器设置空闲时间 - 如果在此期间容器中没有出现功能，则容器将被销毁。
这样我们就可以开箱即用的无服务器。 我们将使用即用即付模式为服务付费，并且仅针对使用的功能以及使用时的时间付费。
为了向开发人员介绍该服务，提供商提供长达 12 个月的免费测试，但限制总计算时间、每月请求数量、资金或功耗。
与提供商合作的主要优势是能够不用担心基础设施（服务器、虚拟机、容器）。 就其本身而言，提供商可以使用自己的开发和开源工具来实施 FaaS。 让我们进一步讨论它们。
从开源方面来说
过去几年，开源社区一直在积极致力于无服务器工具的开发。 最大的市场参与者也为无服务器平台的发展做出了贡献：
- 谷歌 为开发人员提供开源工具 - 。 IBM、RedHat、Pivotal 和 SAP 参与了其开发；
- IBM 在无服务器平台上工作 ，随后成为 Apache 基金会的一个项目；
- 微软 部分开放平台代码 .
无服务器框架的开发也在进行中。 и 部署在预先准备好的 Kubernetes 集群内， 可与 Kubernetes 和 Docker Swarm 配合使用。 该框架充当一种控制器 - 根据请求，它在集群内准备一个运行时环境，然后在那里启动一个功能。
框架为配置工具留出了空间以满足您的需求。 因此，在 Kubeless 中，开发人员可以配置函数执行超时（默认值为 180 秒）。 Fission 试图解决冷启动问题，建议保持某些容器始终运行（尽管这会带来资源停机成本）。 OpenFaaS 提供了一组适合各种口味和风格的触发器：HTTP、Kafka、Redis、MQTT、Cron、AWS SQS、NAT 等。
入门说明可以在框架的官方文档中找到。 与他们合作需要比与提供商合作更多的技能 - 这至少是通过 CLI 启动 Kubernetes 集群的能力。 最多包括其他开源工具（例如 Kafka 队列管理器）。
无论我们如何使用无服务器 - 通过提供商或使用开源，我们都会收到无服务器方法的许多优点和缺点。
从优点和缺点来看
无服务器开发了容器基础设施和微服务方法的想法，其中团队可以在多语言模式下工作，而无需绑定到一个平台。 构建系统变得更加简单，错误也更容易纠正。 微服务架构允许您比单体应用程序更快地向系统添加新功能。
无服务器进一步缩短了开发时间， 允许开发人员专注于应用程序的业务逻辑和编码。 因此，开发的上市时间缩短了。
作为奖励，我们可以自动缩放负载， 我们只为使用的资源付费，并且只在使用资源时付费。
与任何技术一样，无服务器也有缺点。
例如，这样的缺点可能是冷启动时间（JavaScript、Python、Go、Java、Ruby 等语言平均长达 1 秒）。
一方面，实际上，冷启动时间取决于许多变量：编写函数的语言、库的数量、代码量、与其他资源（相同的数据库或身份验证服务器）的通信。 由于开发人员可以控制这些变量，因此他可以减少启动时间。 但另一方面，开发者无法控制容器的启动时间——这一切都取决于提供者。
当函数重用先前事件启动的容器时，冷启动可以变成热启动。 这种情况在三种情况下会出现：
- 如果客户频繁使用该服务并且对该功能的调用次数增加；
- 提供商、平台或框架是否允许您保持某些容器始终运行；
- 如果开发人员在计时器上运行函数（比如每 3 分钟）。
对于许多应用程序来说，冷启动不是问题。 在这里，您需要构建服务的类型和任务。 一秒钟的启动延迟对于业务应用程序来说并不总是至关重要，但对于医疗服务来说却可能变得至关重要。 在这种情况下，无服务器方法可能不再适合。
无服务器的下一个缺点是函数的生命周期短（函数必须执行超时）。
但是，如果您必须处理长期任务，则可以使用混合架构 - 将无服务器与其他技术相结合。
并非所有系统都能够使用无服务器方案工作。
某些应用程序在执行期间仍会存储数据和状态。 一些架构将保持整体性，一些功能将长期存在。 然而（就像云技术和容器一样），Serverless 是一项前景广阔的技术。
本着这种精神，我想顺利地转向使用无服务器方法的问题。
从应用端来看
2018 年，Serverless 使用百分比 。 Twitter、PayPal、Netflix、T-Mobile、可口可乐等市场巨头已经在其服务中实施了该技术。 同时，你需要明白Serverless并不是万能的，而是解决一定范围问题的工具：
- 减少资源停机时间。 没有必要为调用很少的服务持续保留虚拟机。
- 动态处理数据。 压缩图片、剪切背景、更改视频编码、使用物联网传感器、执行数学运算。
- 将其他服务“粘合”在一起。 包含内部程序的 Git 存储库、带有 Jira 和日历的 Slack 中的聊天机器人。
- 平衡负载。 让我们仔细看看这里。
假设有一项服务吸引了 50 人。 其下有一个硬件较弱的虚拟机。 有时，服务负载会显着增加。 那么薄弱的硬件就无法应对。
您可以在系统中包含一个平衡器，该平衡器将在三个虚拟机之间分配负载。 在这个阶段，我们无法准确预测负载，因此我们保留一定量的资源“储备”运行。 而且我们为停机时间支付了过高的费用。
在这种情况下，我们可以通过混合方法优化系统：我们在负载均衡器后面留下一个虚拟机，并放置一个到具有功能的无服务器端点的链接。 如果负载超过阈值，平衡器将启动接管部分请求处理的函数实例。
因此，无服务器可以用在需要处理大量请求但不是太频繁但密集的地方。 在这种情况下，运行多个功能 15 分钟比一直维护虚拟机或服务器更有利可图。
凭借无服务器计算的所有优势，在实施之前，您应该首先评估应用程序逻辑并了解无服务器在特定情况下可以解决哪些问题。
无服务器和 Selectel
在 Selectel，我们已经 通过我们的控制面板。 现在我们正在构建自己的FaaS平台。 我们希望开发人员能够通过方便、灵活的界面使用无服务器解决他们的问题。
如果您对理想的 FaaS 平台应该是什么以及希望如何在项目中使用 Serverless 有想法，请在评论中分享。 我们在开发平台时会考虑您的意愿。
文章中使用的材料：
来源： habr.com