在这篇文章中，大数据应用，我思考了功能即服务的概念，它的含义，以及它的好处。最近我们越来越多地听到三个术语，特别是在cloud native的上下文中。人们几乎可以认为它们是云的产物：如果没有云作为一个使能平台，这个概念可能就不会出现。

虽然云功能和功能即服务作为术语几乎是可互换的（从现在开始，我将使用功能即服务，或FaaS），有些人喜欢在无服务器和FaaS之间保持微妙的区别。那很好，他们有充分的理由。有了无服务器，并不是没有任何服务器—当然有—而是我们不必关心它们。它类似于底层的概念；对于基础设施即服务，我们不必关心虚拟机（vm）运行的物理硬件。

云层粒度

与FaaS的区别是粒度更细。当你从基础设施到平台，到软件，到后端，最终到功能，任何关于服务器的概念，无论是物理上还是逻辑上，都会消失。我们从我们仍然负责的vm（基础设施即服务），到我们必须注意的运行时（平台即服务），再到我们必须理解的复杂而有状态的平台（软件即服务），再到我们迄今为止所拥有的可能是最终的平台思考已经渐渐淡出，几乎是一种矩阵式的方式："没有平台"。

我们在FaaS层面必须思考的是重要的事情：函数接口看起来像什么，函数做什么，函数本身是无状态的。函数是如何配置的，它是如何运行的，它是如何删除的，它是如何伸缩的——好吧，我们不关心这个。

最有趣的部分是什么？当我们编写的函数没有被调用时，就好像它们不存在一样。从财务角度来看，这是无服务器理念的基本事实——这是一个与商业模式相关的术语。如果一个函数不存在，大数据入门，你可能会为此付出什么代价？

这就是FaaS的美。至少对我来说，这是计算敏捷性的极限。我在一个简单的编辑器中编写了一个相对较短的函数，对其进行测试和部署，将其连接到事件结构中，然后静观其变。在函数真正被调用之前，我的帐户不会被收费。我不需要运行任何东西来形成传入连接的套接字，或者保持运行时环境的温暖。我所要做的就是从功能的角度来思考。

活动结构

这个活动结构是什么？好吧，不管是缘分还是偶然，或者，正如我喜欢想的那样，由于驱动世界上最大和最具可伸缩性的web服务（web本身）的协议的巨大成功，HTTP已经成为了通用耦合。HTTP的请求/响应机制的模型是很好理解的，当你需要简单性时，它有一个漂亮而普通的简单性，当你需要复杂的场景时，它也有一个深度来处理。可以认为这种类型有两种函数调用样式。一种直接调用风格，其中一个软件直接调用另一个。还有一种间接调用风格，其中一个软件注册一个HTTP端点，一个回调，在稍后的阶段，在一个事件或一些计算的成功（或不成功）完成时调用。这种风格有一个你可能会遇到的名字——webhooks。这是一个由杰夫·林赛（Jeff Lindsay）提出的概念，我从他那里学到了很多。

枫木厂，奥尔德姆

是的，我意识到这个编织的隐喻在我的DNA里，在英格兰西北部工业革命中心的棉纺厂的遗产中成长，一场推动世界工业发展的革命。

除了直截了当的webhook之外，还有其他类型的事件。这些可能是特定于平台或提供商的；一个经常引用的示例来自amazonwebservices的Lambda产品，其中可以从与S3存储桶相关的活动触发云函数（在该示例中，该函数创建并存储刚到达存储桶的图片的缩略图）。当然，您可以想象其他云提供商有自己的技术或业务活动。想想SAP S/4HANA系统中存在的所有业务事件，返利app是真的吗，以及我们可以连接到的事件。

当然，也有基于计时器的更普通但同样重要的事件类型。Cron和其他调度系统都很活跃。即使在Google的App Script环境中，你也可以找到一个基于计时器事件的调度系统，以特定的时间间隔调用你的代码。

注意：对于基于计时器的事件，会出现一个轴心点，在这个轴心点上，让函数以非常频繁的时间间隔运行的成本考虑意味着，也许你想将堆栈向下移动到更大的时间间隔粒度，比如说，一个更永久的容器，甚至是更小的虚拟机。

分布式和异步

所以我们有一个运行时，我们只支付使用时，一组函数——出于所有实际目的——除非需要调用它们，否则它们不存在——以及描述契约的众所周知的标准，我们必须根据这些契约设计计算逻辑。这是一个很好的状态。但是它有什么好处呢？