是时候完全转向无服务器化了吗？

原文：It’s all going to be serverless — the question is “When?”
作者：Jouni Heikniemi
译者：夜风轻扬

译者注：什么是Serverless？Serverless如何改变未来？本文将会给你一些答案。

在过去的十年里，我们领略了云的灵活性和可管理性。云带来了随时能获得新服务器的体验。接下来应该获得更高级的平台服务：队列、API网关、鉴别等。下一步是不是就要完全告别服务器了？

很多观点将无服务器化（serverless）和现在的功能即服务( functions-as-a-service )产品联系起来，这很令人失望，他们完全曲解了无服务器化。这个观点很狭隘。

本文将会通过实例来揭示无服务器平台如何在未来改变我们的观点。我会把通用的无服务器化分为三个类，然后观察这三类如何共同作用，提供比功能即服务产品更为宽广的平台功能。

定义无服务器化

硬件依然是那些，所以无服务器化是一种服务层抽象，一个给你带来益处的感觉。如此，它有两个明确的特点：配置虚拟机镜像中不可见基础设施，以及基于调用的计费方式而不是传统的按时收费。

并非如你开始所认为那样的模糊不清——云在一定程度上已经是无服务器化。当使用诸如AWS S3或者Azure存储等基础服务时，你要按每GB付账（使用磁盘的成本），按每次I/O操作付账（数据访问所需计算机资源的成本）和按次所传输的字节数付账（网络管道的成本）。服务器就在那里，其资源为成百上千的客户所共享，只是你没有察觉而已。

让很多开发者不安的是无服务器运行自己代码的理念-换言之，通用无服务器化计算。

我怎么知道自己的代码如何运行？我如何调试并且监视环境？我如何加固服务器？

这些都是本能的反应和疑问——这些重要的非功能观点在我们开始探究一个良好的无服务器架构前都必须得到解决。现在开始讨论我们的选择。

事件驱动类

第一种具备广泛用途的无服务器化计算机是功能即服务业务：AWS Lambda和Azure Functions。这两种服务都为按需执行的代码提供运行环境。你不必开发很多应用，你只要写应用片段和事件规则，这些规则在需要的时候触发你的代码。“当我在/foo 收到一个HTTP request时，运行X ”，“当队列中有消息时开始Y”诸如此类。

功能可能很简单：只是输入一个或者几个方法来完成一个简单工作。

你不知道或者不关心服务器，你的代码只是执行而已。现在你处于功能园中，根据内存和CPU的使用，按照零点几秒的时间进行计费。无论一天中进行了一次’或者一百万次调用，这没关系-这种差别你是看不见的。
所以，现在无服务器化是明确的方向。但是功能集并不能单独占据主导地位。为什么？

• 不是所有的任务都适合于基于事件的单操作触发模型。
• 不是所有的代码都能清晰地解耦，有些依赖需要大量的安装和配置工作。
• FaaS 产品可能不支持你的开发语言的与/或范式。
• 将现有的应用转换到功能即服务模型太过复杂以至于在经济上是不可接受的。
  所有这些都是有效的架构层考量。

此外，还要大量的工具问题使得FaaS产品对于一些场景难以使用。我对这些却并不担心——所有这些产品都在以飞快的速度进行改进，如果现在工具问题阻碍了你，这些问题应该很快就会得到解决。问题是“什么时候”？

流程图驱动类

如果你与功能集类无缘，因为你的工作流只是不适合事件驱动模型，这典型地触及了两个问题中的一个：或者是你的流程图需要更为复杂的编排，或者你需要连续不断的运行-或者是在大量时间内连续运行，这两个情况类似。
复杂的编排问题首先可以由诸如 Azure Logic Apps 和AWS Step Functions解决，允许你绘制长运行工作流的流程图。工作流可以调用你自己的功能集代码，允许在直接调度框架内客户功能的注入。

工作流编排产品使得很多复杂的事情变得容易。在一个购物反馈过程中插入24小时的延迟？只要增加一个延迟任务，然后你的应用会在一天后神奇的恢复。有人在twitter上提及你的产品时要有所回应？简单的双击，你也不必考虑使用twitter API。这种开箱即用活动不但能减轻编排的痛苦，而且对于大多普通服务可以消除编写客户代码的需要。

尽管工作流很适合业务过程建模，但是却不是适用于所有无服务器工作负载的灵丹妙药。例如，复杂的决策树用于表示工作流仍显得相当笨拙。原始的代码依然保留其独特的表达潜能。此外，工作流的单步计数计费模型造成频繁的轮询和昂贵的过细粒度的人力划分。

功能集和工作流都不能解决带有大量移动部件的连续运行任务的问题。这听起来 似乎是相当有限的问题，但是有一个额外原因让其成为大问题：过去几十年中几乎所有的应用，至少部分上是设计作为连续运行的任务。
因此，在我们的无服务器化百宝囊中还需要更多的工具。

容器驱动类

容器技术是几年前随着Docker的出现而降临的，并且它的出现引起了不小的震动。容器定义了下一代的虚拟机。尽管最初提供的都是Linux空间，现在也有了对于Windows的支持，容器调度技术（Mesosphere, Kubernetes等）现在逐渐成为主流。

容器不只是用轻量化抽象代替了虚拟机。它也是一种通用的应用包装机制。如果你的节点app需要一个特定的Nginx 配置，把它建立在你的容器中。如果你的ASP.NET Web 站点使用后台的Windows 服务，你可以通过分层把它纳入容器镜像中。

“OK，Jouni,你明显是把容器作为一个软件包装媒介，但是无服务器呢？容器在本质上只是运行在一台容器主机上的打包的迷你服务器，本质上仍然是另外一台服务器！实际上，它们几乎是无服务器的死对头！”

我很高兴你这么问。我相信容器在转化为无服务器平台前需要解决两个问题：无服务器主机和容器维护。

托管没有服务器的容器

对于许多用户来说，容器群集是一种有效主机平台，相比于虚拟机，容器可以真正提升负载密度。

但是，为了转向无服务器化，我们需要忘记等待工作的虚拟机。我们需要在详细耗费度量上基于调用的计费。

第一个这样做的主流产品是 2017年7月发布预览的Azure Container Instances。ACL为我们提供了按需定制容器，而不必考虑运行在何种基础设施之上。需要来个配备一个虚拟CPU和2G内存的容器实例么？

az container create --name JouniDemo --image myregistry/nginx-based-demo:v2 --cpu 1 --memory 2 --registry

使用该容器的账单如下：调用该容器 $0.0025，外加每秒每GB内存 $0.0000125， 每个内核 $0.0000125。 所以上述配置的容器使用10秒的花费是$0.002875。如果你每个月只使用一个小时，你的花费是 $2.07。

上述就是运行中的微账单，事实上它会十分有效。你不必使用一台虚拟机来处理你的批处理任务，如果你需要处理高突发能力，秒级或者更短延迟的无服务器容器就可以满足需要，而不是启动时间更长的虚拟机群集。

但是虽然现在有无服务器容器可供选择，我们仍然要面临包含服务器容器的困境——也就是所谓的“如何获得你修补过的base images”问题。

通过自动化进行容器维护

无服务器化的信条之一是开发者只需关注业务逻辑，而非其他细节。容器是一种奇妙的工具，但是按照定义，其与生俱来的还有维护其环境的技术负担。

你通过创建一个OS base image来构造自己的应用，在其顶端对所需的服务进行分层，最后注入你的应用。当你发布一个新版本，你重建你的容器镜像然后就可以工作了。情况是，一旦base image和依赖都组合到你的镜像中，它们如何更新？近来的windows补丁和新的Linux 内核安全补丁如何更新到你的应用中？

考虑这样的问题和无服务器化的本质有点对立。日常的依赖维护不是无服务器化开发者要关注的，所以这些应该自动化。

但是日常维护和关键决策之间的界线是模糊的。例如，一个典型的web网站很乐意更新其操作系统，并不会在意其副作用。但是你如何划分这界线？你的web服务器应该在你未察觉的情况下进行更新么？一个新Node.js版本呢？

这是一个微妙的问题，但是需要认真研究。对于这点，我推荐花费几分钟听一听在 .NET Rocks #1459上对微软的 Steve Lasker的采访，大约在37分钟处。

这种想法可能性的深度和细节超越了本文的范围，但是想象一下你处于这样的未来：

• 你的容器配有自动化测试包，可以验证你工作载荷的关键功能。
• 你身边的平台熟悉base OS image 更新语义（例如，Alpine Linux 14.1.5有一个关键的安全补丁）
• 这个平台可以为你测试新的补丁。当一个base image 更新时，平台可以尝试在其上面重建应用镜像，运行测试包然后主动报告测试结果。
• 你可能甚至通过基于策略的控制进行自动更新——“当一个关键操作系统更新时，只要测试未发现致命错误，就可以自动更新运行中的应用镜像”

并且，包含服务器的容器看起来似乎更为serverless。容器能够比简单的代码片段功能框架完成更为复杂的工作任务，并且通过减小运行阶段所包含依赖的副作用，它们也更关注业务本身。

现在万事具备？

题目的“即将完全转向无服务器化”咒语，后面跟着一个何时实现的问题。现在答案已经显而易见，就是“现在！”这个平台现在仍然还要很多问题要解决。

例如，在Azure Container Instances 上运行一个24X7容器任务，花费太昂贵；你就想使用一台虚拟机了。实现虚拟机完全自动更新补丁则是另外一个挑战。现在容器的维护自动化还没有实现。FaaS的日志和监控部分以及工作流产品对于AWS和Azure开发者来说，依然是持续的痛苦根源。对于Windows容器的支持呢？还处于开发阶段。

但是工具一直以飞快的速度进行改进。基于功能的无服务器化和工作流产品在去年跨越了一大步。容器仍然处于准备过程中，容器中的所有部分都背负很高的期待。

此外，把工作任务划分为更小的片段，微服务，在无服务器化的理念中根深蒂固。为了极大影响无服务器框架的编排能力，必须要精心安排。这是另外一个需要开发工作的领域。类似 Azure Event Grid的服务，提供了上述几类元素以及平台之间的连接机制：你可以轻易的将AWS Lambda 和 Azure Logic Apps粘合在一起。所有的这些都趋向一致：小的、基于反应的、聚焦业务的工作任务汇集到一起来解决一个大问题。

一旦这些都实现了，就可以将现有事件应用的很大一部分，迁移到具备更少服务器层级依赖的平台上。对于新的原生云应用架构师来说，无服务器微服务平台将会要求完全崭新的设计思想。我期待接下来的12个月里能发生翻天覆地的变化。