容器和函数：如何有效利用临时性基础设施

随着容器、微服务和函数通过现代应用程序设计交织在一起，必须努力找出如何使用容器和函数作为应用程序打包技术的正确方法及如何使用后部署技术。

我们都知道这可能令人望而生畏，因为那是临时性的。建立交付管道和简化微服务工作流是从容器和函数获益的关键，不管是在运营层面获得弹性、性能等方面的自信，还是在战略业务层面获得速度、灵活性等方面的竞争优势。

我们一起来探索几个通用的最佳实践，以便能够在容器和函数的临时性世界中获得成功。本文还将详细介绍一些无服务器计算的恰当用法。然后，我的下一篇博文将介绍如何利用把服务网格整合到技术栈中所带来的价值。

整合编排：容器管理预处理

鉴于其应用几乎无所不在，容器格式及其运行时引擎实际上已经成为标准化的、稳定且可靠的可互操作基础设施。各种规模的组织多年来一直在生产环境中运行容器。他们能够以一种复杂的方式成功地运营容器化工作负载，在很大程度上可能要归功于容器编排器的能力。

如果没有容器编排器解决集群形成、节点准入、二进制打包、服务发现、可编码基础设施实现、声明式模板协调等临时性基础架构的挑战，那么容器部署就不会像今天这样这么普遍或成功。很多组织在容器编排器出现之前就推出了自己的编排器。事实上，其中一些自制的编排器系统现在还存在着。

容器编排器的使用并不能满足所有应用程序或服务层的要求。难道这不是我们运行基础设施的原因吗？为应用程序服务？随着这个反问的提出，容器编排器必须首先关注基础设施层的问题，这对于可靠地管理分布式系统的底层基础至关重要。

不幸的是，这给开发人员留下了大量需要他们处理的分布式系统问题。直到最近，开发人员在很大程度上还是通过在应用程序代码中使用客户端库编写基础设施逻辑来解决这些问题（例如断路器、超时和重试）。在本系列文章的第二部分中，我将重点介绍 DevOps 团队是如何通过容器编排器利用服务网格来管理未解决的挑战层。从现在开始，我们将把注意力放到另一个临时性基础设施——函数上。

无服务器计算的成本和收益

我们大多数人都已经习惯于运行多个容器，现在正在寻求超越容器和微服务，通过引入函数来扩充技术栈。编写单个函数来完成特定任务非常有吸引力，因为这样做可以实现更快的启动速度、更好的资源利用、更细的管理粒度、灵活准确的扩展，而且无需配置、更新或管理服务器基础架构。但是，有些用例比其他用例更适合无服务器计算。在决定无服务器是否适合一个环境时，测试、启动延迟、可调试性和成本都应该在考虑范围内。

运行函数以执行任务及只为运行该任务所需的执行时间付费的概念很吸引人。随着函数在应用程序中占有一席之地，成本会飞快地累积，所以要密切关注无服务器的定价模型。当给定函数的应用太过成功（被调用的次数远远超过了当初计算的次数）时，成本可以在短时间内累积，尤其是如果一个函数的执行又调用了很多其他函数（或者，有可能调用本身而造成无尽的执行循环）。因此，在决定无服务是否适合时，了解函数的调用次数非常重要。函数最适合短时间内运行的任务。从一个函数调用另一个函数时要谨慎：随着软件被划分成更多更小的独立执行单位时，有成本加倍及软件调试复杂性提高的风险。

FaaScinating 用例

使用函数的架构模式遵循事件驱动设计，通常将函数的输入/结果持久保存到数据存储区或队列，然后触发下一个函数（如果需要的话）。在归纳到该模式时，在函数执行的任何时刻请把所有数据视为动态数据而不是静态数据。

在工作负载是如下情况时，最好考虑无服务器：异步；并发；易于并行化的独立工作单元、不经常或零星的需求；可扩展性需求有巨大的、不可预测的差异；无状态；临时性；对瞬时冷启动时间要求不高；或者业务需求变化非常频繁，需要开发人员加快速度。以下是一些可以从无服务器架构中受益的工作负载示例：

• 执行逻辑以响应数据库的变化（插入、更新、触发、删除）。

• 对 IoT 传感器的输入消息，如消息队列遥测传输消息（Message Queuing Telemetry Transport，简称 MQTT），执行分析。

• 处理流处理过程（分析或修改动态数据）。

• 管理单次提取、转换和加载这种短时间内需要进行大量处理的作业。

• 通过聊天机器人界面提供认知计算（异步但相关）。

• 调度执行任务一小段时间（如计划任务或批处理调用）。

• 服务于机器学习和 AI 模型（检索一个或多个数据元素，如表格或图像，并与预先学习的数据模型进行匹配以识别文本、面部、异常现象等等）。

• 持续集成管道可按需为构建作业提供资源，而不是维持一个构建从属主机池等待分配作业。

成功掌控临时性世界的通用技巧

作为应用程序打包技术，容器和函数分别有一些注意事项，因此，了解如何及何时利用它们是关键。在组织中，可以应用 4 个普遍适用的最佳实践来打包、运行、部署和操作容器和函数，包括：

1. 优先考虑可观察性：在编写容器应用程序时，尤其是在微服务设计的情况下，要确保编排和应用层都是可观察的，以确保它们公开关于基础设施和应用程序性能的关键指标，这是至关重要的，这样，可以根据需要推理它们的健康状况。

2. 采用现代工具：容器、微服务和函数所带来的应用程序开发模式可能与你遇到过的那些传统模式不同，因此，不一定有合适的工具。但是，采用支持这些应用程序开发模式的监控和调试工具至关重要，有助于确保部署和运行工作负载的成功。

3. 应用程序设计：现代应用程序开发环境是临时性的，函数会出现和消失，容器也一样，应用程序必须设计成支持这样的生命周期。尤其是函数，用了错误的逻辑就会出现问题，最终导致函数陷入相互调用、成本激增、通常无法有效工作的恶性循环。

4. 匹配用例：以上所列的特征有几个符合你的用例？这个用例或你的应用程序是否适合这些临时性执行环境？

总结

首先，运行函数以执行任务并只为运行该任务所需的执行时间付费的想法很有吸引力。但是，如果运行很多函数或运行特定函数数百万次时，该定价模型会变得很昂贵。考虑到这一点，在决定无服务器是否合适时，了解函数的调用次数至关重要，冗长的批处理任务也许不是最适合使用函数的情况，函数更适合短时间运行的任务。

随着容器、微服务和函数与混合环境和云环境的集成度越来越高，必须努力确保可以成功掌控现代应用程序开发环境的这些方面。实施一些通用最佳实践，包括优先考虑可观察性、采用现代 DevOps 监控工具、应用程序设计和了解特定用例，这些都有助于在容器、微服务和函数的世界中获得成功。

查看英文原文：Containers and Functions: Leveraging Ephemeral Infrastructure Effectively