无服务器计算是当前的一项热门话题，甚至热过了Docker容器。

这么讲是说无服务器计算要成为容器的替代品吗？或者它是可以和容器一同使用的另一项流行技术吗？

在这篇文章中，我将为你介绍无服务器计算需要了解的内容，以及该如何将它融于你的IT战略中。

“无服务器”并不是真的没有服务器

首先需要澄清一点：当然可能大家也都有所了解，无服务器计算并不是意味着没有服务器。它是一个基于云的服务，和云上的其他服务一样，运行在服务器上。

也就是说，称它为无服务器，是因为服务提供者负责处理了所有的服务器侧IT，而你所需要做的只是编写代码并部署它。无服务器计算提供者处理了除此之外几乎所有的事务。这样在使用体验上就是一种无服务器的，虽然底层基础架构并不是如此。

     无服务器计算如何工作

那么它是如何工作的呢？举最流行的一个无服务器计算平台AWS Lambda为例。使用它，你需要编写代码（C#、Java、Node.js或Python），设置一些简单的配置参数，并且将所有的内容（以及所需的依赖项）上传到Lambda。

在Lambda术语中，上传的软件包被称作功能函数(function)。可通过运行在AWS服务（如S3或者EC2）上的应用程序调用该功能。上传Lambda后，Lambda会将你的功能部署在一个容器中，这个容器会在该函数完成执行之前一直存在，之后会释放掉。

需要注意的是，Lambda在这里负责配置、部署和管理容器，而你所做的只是提供在容器中执行的代码，其他的工作都交由后台完成。

     这会是无服务器的天下吗？

那么这是不是就意味着我们现在的软件开发人员和IT团队已不再需要直接处理容器或具体的后端IT了呢？可以只编写代码，把它丢到Lambda，让AWS来处理所有其他的事情吗？如果这听起来让人难以置信的话，那么就只有一种解释——这是不可能实现的。

如果你的DevOps交付链中还没有包含它，AWS Lambda所代表的这类无服务器计算将成为非常有价值的资源。

然而，它只能成为交付链中的一部分。虽然无服务器计算在大多数任务中都很适用，但距全面替代并部署和管理自己的容器还相距甚远。实际上无服务器计算应该和容器一同工作而不是替换它们。

     无服务器计算的优势

那么，无服务器计算的优势有哪些呢？当用它来提供服务时，无服务器计算有以下优点：

      花销低廉

使用无服务器计算，通常情况下只根据实际使用的时间和流量计费。例如，Lambda的计费标准是以每100毫秒的触发次数计费。实际成本通常也相当低，这里有部分原因是因为无服务器涉及的功能很小型，执行相对简单的任务，并且在常规的容器中执行，开销很小。

      低维护成本

在无服务器平台上部署某个功能时，平台为你做了绝大部分的工作。除此之外，你无需再为此设置容器、系统策略和可用性级别，也无需处理任何后端服务器的任务。如果你需要的话，你还可以使用自动伸缩，或是对容量进行简单的手动设置。

      简易性

标准的编程环境、没有服务器和容器部署的开销，你可以更加专注于编写代码。从应用程序角度来看，无服务器的功能基本上是一种外部服务，它不需要紧密集成到应用程序的容器生态系统中。

     无服务器计算的应用场景

      什么时候你会用到无服务器计算？可以考虑如下场景与可能：

●  处理网站或移动应用程序的后端任务。无服务器功能可以从站点或应用程序前端接受请求（例如，来自用户数据库或外部源的信息），检索信息并将其交回到前端。这是一个快速且相对简单的任务，可以根据需要执行，很少占用前端的时间或资源，且只为后端任务的实际持续时间计费。

● 处理实时数据流并上传。无服务器功能可以清理、解析并过滤传入的数据流，处理上传的文件，管理来自实时设备的输入，并处理与间歇性的或高吞吐量的数据流相关的主要任务。使用无服务器功能，可以将资源密集型的实时进程从主应用程序移出（避免占用主应用的资源）。

●  负责高容量的后台进程。你可以使用无服务器功能将数据移动到长期存储上，以及转换、处理和分析数据，并将指标转发到分析服务上。比如，在销售点系统中，无服务器功能可以用来协调库存、客户、订单和交易数据库，以及间歇性的任务，如补货和标记差异。

     无服务器计算的局限

不过无服务器计算有一些非常明确的局限。以Lambda为例，它对功能函数的大小、内存占用和利用时间有内部限制。

这些限制以及有限的本地支持编程语言，并不一定是基础级别的无服务器计算所固有的，可它们也反映出系统的实际限制。对无服务器计算来说，让功能函数体量小，避免占用太多系统资源，是非常重要的，这样可以避免出现数量较少的高需求用户阻碍其他用户或者令系统过载的问题。

无服务器计算的基本性质也会产生一些内在的限制。例如，大多数监视工具如果使用无服务器功能可能很难实现，因为一般情况下你无法访问到该功能所在的容器或者容器管理系统。

调试和性能分析也可能因此被限制在相当原始或使用间接的方式。速度和相应时间也可能不均匀；这些限制以及对大小、内存、持续时间的限制可能会影响到它在性能优先情况下的使用。

     容器在哪些方面做得更好

容器可以比无服务器功能做得好的事情可以列举出非常多，可以用一篇完整的文章做详细的介绍。我们在这里要做的只是指出一些无服务器功能不能替代基于容器的应用程序的主要方面。

你可以做得更大

基于容器的应用程序可以像你所需要的那样规模大而又复杂。例如，你可以将一个非常庞大而复杂的整体应用程序重构为一系列基于容器的微服务，完全按照重新设计的系统要求定制新的体系结构。如果想要重构同样的应用程序并且在无服务平台上运行，可能会因为大小和内存限制遇到多个技术瓶颈。由此产生的应用程序可能由极其分散的微服务组成，而每个碎片的可用性和延迟时间非常的不确定。

你可以完全掌控

基于容器的部署可以完全控制单个容器和整个容器系统，以及它所运行的虚拟化基础架构。这样你可以设置策略、分配和管理资源，对安全性进行细化的控制，充分利用容器和迁移服务。而在另一方面，使用无服务器计算，只能依赖于‘他人’而不能自己控制。

你有精力去调试、测试和监控

完全掌控了容器环境，就可以全面了解容器内外的情况。这样就能够利用所有的资源进行有效的、全面的调试和测试，并可以在各个层面上进行深入的性能监控。你可以识别和分析性能问题，并在微服务的基础上微调性能，来满足对系统的具体性能需求。在系统、容器管理和容器级别上的监控访问还可以对所有这些层面进行完整、深入的分析。

协同工作

目前的实践中发现当无服务器计算和容器在一起工作时效果时最好的，这也需要每个平台都做得很好。基于容器的应用程序，并结合全特性的系统来管理和部署容器，这对于大型和复杂的应用程序和应用程序套件（尤其是在企业或互联网环境）而言是最佳的选择。

另一方面，无服务器计算非常适用于可在后台运行或外部服务访问的单个任务。基于容器的系统可以将这些任务交给无服务器应用程序，而不必占用主程序的资源。对无服务器应用程序来说，它可以为多个客户端提供服务，并且在容器系统中可以与其他无服务器应用程序完全独立地进行更新、升级和切换。

结论

无服务器计算服务和容器服务之间是平台间的竞争吗？答案是：基本不是。基于容器和无服务器的计算正在当今不断发展的世界中，互相地为现在的云计算和持续交付软件提供更好的支持。