无服务器只是事件驱动架构的一小块儿吗？

最近，笔者回顾了SlashData的云原生发展报告，该报告显示了从2020第一季度到2021季度第一季度的云原生技术的下降。如果他们在2022年第一季度进行类似的调查，会发现无服务器的使用最多是保持稳定，而且占整体开发者的百分比下降。

这让笔者觉得关于无服务器的炒作已经平息，尽管这并不意味着它不会继续存在。

或许正如CNCF首席技术官Chris Aniszczyk表示的那样，“这一趋势反映了人们越来越担心无服务器技术缺乏广泛采用所需的灵活性，以及组织不愿意锁定于特定的技术或供应商。”

这让笔者思考了几年前的另一个云趋势，平台即服务（PaaS）。有一段时间，AWS Elastic Beanstalk、Heroku和Cloud Foundry被吹捧为应用程序部署的未来，但它们也受到模板化方法的影响，缺乏满足企业更广泛需求的灵活性。

这与今天非常相似，无服务器本身可能是事件驱动架构大趋势的一个很有限的子模式。

无服务器是实现细节

无服务器应用在早期发展非常迅速，在Node.js用户间的应用也非常广泛——他们希望在云中快速部署应用程序，主要是在AWS Lambda上。此后不久，Lambda和其他功能即服务提供商提供了更多的运行时，几乎任何现代代码，甚至一些长期部署的遗留代码都可以在无服务器框架中执行。

无服务器确实展示了许多可取的特性。它很容易放大和缩小。它由推送的事件触发，而不是通过轮询机制触发。功能仅根据该作业的需要消耗资源，然后退出并释放资源用于其他工作负载。开发人员受益于基础设施的抽象，可以通过CI/CD管道轻松部署代码，而不必担心如何提供资源。

然而，Aniszczyk提到的一点是，无服务器并不是为包括长时间运行的应用程序在内的许多情况而设计的。对于最终用户来说，它们实际上可能比在容器、虚拟机或裸金属上运行专用应用程序更昂贵。它迫使开发人员使用由供应商提供的模型。此外，无服务器没有一种简单的方式来处理状态。

最后，尽管无服务器部署主要部署在云中，但它们不容易跨云提供商部署。管理无服务器的工具和机制非常特定于云，尽管可能Knative被捐赠给CNCF，可能会出现一个无服务器平台，可以在行业的支持下开发和部署，就像Kubernetes一样。

关键是，许多让无服务器成功的因素实际上适用于云计算领域一个更有趣、更大的趋势：事件驱动架构（EDA）。

云计算中的事件驱动架构

笔者相信无服务器的成功更多地与应用于超越无服务器的广泛用例集的好处有关。首先，系统能够基于实时变化对数据进行操作的想法是遗留批处理应用程序的一大优势。异步生成事件的消耗是非阻塞的，允许应用程序继续工作，而无需等待响应。也没有必要轮询应用程序，因为它们是数据的订户，缺乏聊天会导致网络I/O的减少。

笔者花了大量时间思考这个。我们的第一个想法是，跨云提供商缺乏一致的工具将导致锁定。现在就是这样。不仅如此，并不是所有无服务器运行时都是平等创建的，这会阻止功能的迁移。此外，这些云提供商中很少有机制能够触发一个云中的服务或内部到另一个云中的服务。我们最初研究了如何将无服务器功能发布到不同的云，但这很麻烦，需要将运行时从一个云移植到另一个云。我们发现，能够创建数据管道，使数据可操作，而不是简单地将其付诸实施，这才是最终用户的真正需求。

除了可移植性之外，我们还看到触发这些功能是一场噩梦——当你想要使用来自无服务器提供商之外的系统的输入来触发功能时。我们意识到，像Google EventArc和AWS EventBridge这样的工具在创建更广泛的事件驱动应用程序时缺乏灵活性。因此，我们开发了一种替代EventBridge的开源产品，它不仅可以向任何无服务器平台发送数据流，还可以用于更轻松地构建数据管道，以淹没数据湖，并执行其他类型的数据同步。

事件驱动的数据同步和工作流

我们正在朝着一个事件和数据驱动的未来迈进，在这个未来，实时处理数据的能力正在成为开展数字业务的一项要求。第一步要求数据流技术类似于AWS Kinesis，但不特定于单个供应商。Apache Kafka和Apache Pulsar符合，因为它们是开源的、云不可知论的数据运动方式。下一步是采用跨微服务的发布—订阅通信，而不是对API进行REST调用。

云的未来不一定是all in one供应商。我们以前也经历过这样的情况，用户牺牲了选择同类最佳解决方案的自由，以方便从一家供应商那里获得预装配的堆栈，该供应商提供了一站式的解决方案。未来是由同类最佳技术组成的可组合系统，而不是由单一供应商提供的堆栈。针对云原生用户的新设计模式是可组合的基础设施，以及由此产生的可组合的应用程序，这些应用程序是各种供应商的合并，并通过用于创建自动化工作流的事件流进行连接。

在Coleman Parkes进行的名为《Great EDA Migration》的调查中，大多数组织（85%）认识到采用事件驱动架构的商业价值，但采用仍处于早期阶段，只有13%的组织声称已经实现了完全的EDA成熟。根据这项研究，实时数据的三个最常见的应用是：应用程序集成——无服务器用例属于这一类；跨应用程序共享数据；以及连接物联网设备进行数据摄取和/或分析。

由于许多原因，考虑构建事件驱动架构的时间已经到了。如果你希望增加数据的新鲜度并改善数字交互，EDA可以带来改进，而且实现这一点的工具比以往任何时候都更好。首先，越来越多的免费开源工具允许企业创建数据流，Apache Kafka和Apache Pulsar位居榜首。此外，云原生开发的应用程序可以提供从本地数据到几乎任何提供Kubernetes的云的可移植性。最后，还有其他工具，比如TriggerMesh的开源云原生集成平台，提供了创建和管理数据管道的多云功能，可用于从AWS复制“EventBridge”功能。笔者相信，随着企业对实时信息的渴求和需要使用这些数据的系统数量的增加，向事件驱动架构模式的迁移也会增加。幸运的是，有越来越多的替代方案可以避免锁定在专有云服务或软件供应商中。